What's new

Solved OpenVPN server not starting at boot

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

macdis

Occasional Visitor
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.
 

Attachments

  • 1.png
    1.png
    498.4 KB · Views: 134
  • 2.png
    2.png
    280.4 KB · Views: 125
  • 3.png
    3.png
    190.1 KB · Views: 135
Last edited:
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.
 
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.
 
Last edited:
Ok, I think I know what the issue is wrt that policy rule.


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.


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.
 
Last edited:
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).
 
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.
 
use: service restart_vpnserver1
 
@octopus is correct, although it doesn't explain why the server doesn't start on bootup. Are there any relevant messages in the syslog?
 
use: service restart_vpnserver1
Right, ok, whoops, so if I put the following in the services-start script, then the server eventually comes online.

Code:
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.
 
Last edited:
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.
 
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.
 
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.
 
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.

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

Similar threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top