Solved OpenVPN server not starting at boot

[macdis]

Hi all,

I'm having a problem with firmware 386.4 on my RT-AX88U. I have set up an OpenVPN server, which works as expected on its own. And I have set up an OpenVPN client, which works as expected on its own.

The problem: if I have them both configured, then the server won't start at boot, whereas the client always works fine. The server page shows: "Initialinzing the settings of OpenVPN server now, please wait a few minutes to let the server to setup completed before VPN clients establish the connection." But it never starts.

Some facts:

This configuration worked on multiple previous firmware versions.

The configurations are pretty basic. For the server, I modify the port and the subnet. For the client, I just use a default config file from NordVPN with "exclusive" DNS, kill switch, and VPN director policies. In VPN director, I have my DHCP pool routed through the client VPN and a rule for accessing a maching behind the router from clients connected via the VPN server. See the screenshots below.

I have tried factory resets (in the GUI, in ssh ("erase nvram"), WPS-button hard reset).

I am not restoring an old config file.

[EDIT:] If I put a "sleep 20; service restart_vpnserver1" in the services-start script, that seems to get the server going.

The server will start if I hit "Apply" after boot. It just won't start at boot.

Thanks for any pointers.

 

[eibgrad]

I don't believe this would account for the server NOT starting, but there's no need for a rule to bind 192.168.50.151 to the WAN based on the destination 10.99.0.0/24. Remote OpenVPN clients of the router's OpenVPN server will have their replies automatically routed back over its network interface (tun21) whenever they access the local network of 192.168.51.0/24. IOW, that WAN rule doesn't make sense to me.

 

[macdis]

More info: looking at syslog, I am not seeing any ovpn-server1 messages after boot, until I click on "Apply"

Also re:

I don't believe this would account for the server NOT starting, but there's no need for a rule to bind 192.168.50.151 to the WAN based on the destination 10.99.0.0/24. Remote OpenVPN clients of the router's OpenVPN server will have their replies automatically routed back over its network interface (tun21) whenever they access the local network of 192.168.51.0/24. IOW, that WAN rule doesn't make sense to me.

Thanks for that. There’s probably a much better way of doing what I’m trying to do with that rule, but without it, a client of the router’s OpenVPN server can’t ssh into 192.168.50.151. With the rule activated, it can. Please correct my thinking on this or let me know if there’s a better way to do this.

 

[eibgrad]

Ok, I think I know what the issue is wrt that policy rule.

problem with connection between wan and device connected to vpn client

Hello The AC-86U runs on 384.19. I have 2x vpn client set up. I have a device (VU) assigned to one vpn client(tun13). I would like to connect to this device(VU) from outside via WAN. I have redirected the port, but there is no communication. There is communication only when I am connected via...

www.snbforums.com

IOW, this is a known bug (or at least I consider it a bug, not so much Merlin), and I created a script to fix it.

[SOLVED] OpenVPN server and Client not allowed at same time?

I have both OpenVPN server and OpenVPN client configs in my router, and I use them for different purposes. I have noticed that if I am connected by client to a remote vpn server, if I connect from outside my lan to my openVPN server on my router that I am unable to get to any internal machine...

www.snbforums.com

However, what you've done is resolved the problem by forcing that particular client back to using the WAN's routing table (main), where the OpenVPN server's network interface is specified.

To be honest, I didn't think of that possible solution at the time the problem was originally identified. And I'm wondering if it could lead to other problems. It does seem counter-intuitive since 192.168.50.151 is NOT actually using the WAN to reply back to the remote OpenVPN client. Instead, specifying the WAN simply forces it to use the main routing table, where it actually replies back over the OpenVPN server's network interface (tun21). That's why I became confused, at least until I finally realized the real issue you were having.

Again, I don't know if that's ideal, but at the moment, I suppose if it works, it's fine. I suppose you could just as well specify the entire network (192.168.50.0/24), making everything accessible.

P.S. The one situation where your approach would NOT work is if your router's OpenVPN client was NOT using routing policy, but was instead configured to route ALL internet traffic over the VPN.

 

[macdis]

Ok, I think I know what the issue is wrt that policy rule.

Thanks, that's very helpful. I'll play around with your script and see how it goes, but the simplicity of the rule is appealing (so long as there are no unintended downsides).

 

[macdis]

Regarding the OpenVPN server that won't start, I've now noticed that when it's hanging in the "Initialinzing the settings of OpenVPN server now" state, I can't even do a "service restart_ovpnserver1". Nothing happens and nothing is logged. I'll edit the original post to reflect this.

 

[octopus]

use: service restart_vpnserver1

 

[eibgrad]

@octopus is correct, although it doesn't explain why the server doesn't start on bootup. Are there any relevant messages in the syslog?

 

[macdis]

use: service restart_vpnserver1

Right, ok, whoops, so if I put the following in the services-start script, then the server eventually comes online.

sleep 20
service restart_vpnserver1

However, as mentioned there aren't any post-reboot ovpn server messages in the syslog until the restart that I manually added to services-start. That's weird, no? The server should come online automatically at boot.

There's nothing remarkable about the OpenVPN messages in syslog.

 

[eibgrad]

It is weird. I have OpenVPN server and client configured here, and both startup just fine during reboot. In fact, I'm having problems getting that bug to appear! I'm wondering if perhaps @RMerlin added something to the 386.4 firmware to delay the start of the OpenVPN client(s) until the OpenVPN server gets started to avoid the bug. But that's pure speculation. But I find it curious I can NOT get the bug to trigger w/ 386.4 after numerous attempts. Maybe it requires other configuration changes before it gets triggered that I don't have.

 

[macdis]

It is weird. I have OpenVPN server and client configured here, and both startup just fine during reboot. In fact, I'm having problems getting that bug to appear! I'm wondering if perhaps @RMerlin added something to the 386.4 firmware to delay the start of the OpenVPN client(s) until the OpenVPN server gets started to avoid the bug. But that's pure speculation. But I find it curious I can NOT get the bug to trigger w/ 386.4 after numerous attempts. Maybe it requires other configuration changes before it gets triggered that I don't have.

Yes, I'm now going through the changes I've made to default settings (not that many, really) to see if I can find a configuration that works. So far no joy.

 

[macdis]

I think I've solved this. In my ddns-start script, I was updating two hostnames on afraid.org. Because I didn't want to hammer the server, I put a "sleep 30" between the two update commands. Removing the sleep command was all it took to get the OpenVPN server and client to start at boot. So I guess there was a timeout caused by waiting on ddns-start that prevented the OpenVPN server from coming online. Something must have changed in a recent firmware update that made the previously innocuous sleep command into a problem. All's good now. Thanks.

 

[eibgrad]

I think I've solved this. In my ddns-start script, I was updating two hostnames on afraid.org. Because I didn't want to hammer the server, I put a "sleep 30" between the two update commands. Removing the sleep command was all it took to get the OpenVPN server and client to start at boot. So I guess there was a timeout caused by waiting on ddns-start that prevented the OpenVPN server from coming online. Something must have changed in a recent firmware update that made the previously innocuous sleep command into a problem. All's good now. Thanks.

You should probably configure that script to run in the background, so it doesn't hold up any other processes. Esp. when you start introducing sleep commands.

#!/bin/sh
(
do something asynchronously
) &

 

[macdis]

You should probably configure that script to run in the background, so it doesn't hold up any other processes. Esp. when you start introducing sleep commands.

Cool, will do! Thanks again!