asus rt-ax88u vpn director not connected right after reboot

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

amigo74

New Around Here
Hello,

i have installed latest asuswrt merlin on asus rt-ax88 router.
I have installed a vpn connection as vpn client with openvpn protocol.
When i reboot the router or take it from power, vpn director shows vpn connected status but it is not connected and i have no internet connection.
Always after reboot i have to disable and enable the vpn connection in vpn director, then it functions again..
Is there a solution for that problem, that vpn director starts the vpn connection automatically without a problem after reboot ??


Thanks
 

seraphim

New Around Here
I have the same problem except mine occurs after a period of uptime (no reboot required).

Same symptom of OpenVPN client status showing connected but it's not connected. A simple stopping and restarting of the client restores the connection ... until the next timeout.
 

eibgrad

Very Senior Member
If I had to guess …

One of annoyances about using OpenVPN w/ commercial providers is that they sometimes *force* an AUTH FAIL error during the connection attempt. Or it may even occur asynchronously w/ an active connection. What this error means is that the server has determined the username/password is invalid. But in this particular case, where it's KNOWN to be valid, and was even working up until that point, it's the OpenVPN provider that's forcing the AUTH FAIL, presumably to prevent access to certain servers, or perhaps kick off users once the server becomes overloaded. IOW, they're using it to *manage* their servers rather than for the purposes it was intended (an actual invalid username/password).

I see this a lot more w/ the lower-tier OpenVPN providers (FastestVPN, KeepSolid, etc.) rather than more reputable ones like ExpressVPN (just one of the reasons they cost a bit more, but sometimes worth it). But even so, *any* OpenVPN provider is capable of pulling this "trick" to manage their servers. And the problem for the end-user is that an AUTH FAIL error is considered fatal; it kills the OpenVPN client process completely! And until YOU manually restart it (or reboot), it will remain OFF. In many cases, the GUI won't even be aware this has happened. It just assumes the OpenVPN client will keep retrying the connection. But that's only a valid assumption for NON fatal errors.

Bottom line, I strongly recommend that *everyone* use a watchdog script to monitor for the loss of the OpenVPN client process and restart it as necessary. I don't normally use Merlin for my own OpenVPN clients, but more commonly FreshTomato and/or DD-WRT. And in both those cases, I've written scripts for these purposes.


As you can see, these aren't particularly complicated. They just monitor the process table for the OpenVPN client on a periodic basis, and if not found, restart it. As simple as it is, it's *very* effective. So much so, I wish @RMerlin would incorporate a watchdog for each OpenVPN client as part of the firmware, since this is such a common problem (even if not everyone is aware of it) and easily fixable.

There may be some watchdog scripts floating around this forum I'm unaware of. But just in case there isn't, what I may do is put together a script for Merlin based on the ones I've already written for DD-WRT and FreshTomato.
 
Last edited:

eibgrad

Very Senior Member
FYI. I quickly threw together the following OpenVPN client watchdog script for Merlin based on the others. I only did a quick test, so it could still require some fine tuning. But I would at least try it and see if it helps.


Make sure JFFS and JFFS scripts are enabled under Administration->System. Then using the shell (ssh), copy/paste the script into the window. It will automatically create and install the necessary services-start script. Then reboot.

Note, if it finds an existing services-start script, it will NOT overwrite it. You'll instead have to add the code manually to the existing services-start script.
 
Last edited:

eibgrad

Very Senior Member
Something else to consider here as well.

Even though the script will attempt to restart the OpenVPN client process, realize that it may take several restarts before the connection succeeds. Or in the worst case, it may never succeed (or at least not for a very long time until the server is available again).

For these reasons, it's critical for the greatest reliability that you specify more than one server (i.e., remote directive) for the given OpenVPN client. I'm NOT talking about multiple OpenVPN clients. I'm talking about any single OpenVPN client being configured to try more than one server. Most users only specify the one server in the Server Address and Port fields. That gets converted into a remote directive in the underlying OpenVPN config file.

Code:
remote us-new-york-2-ca-version-2.expressnetw.com 1195

But it's perfectly valid to specify *multiple* remote directives (i.e., multiple servers) in that config file. But you need to do that via the custom config field. And if you add the remote-random directive as well, the OpenVPN client will randomly pick among the available servers when attempting a connection. So if you have at least 3 or more servers specified, your chances of getting a successful connection established will increase significantly.

Code:
server-poll-timeout 10
remote-random
#remote us-new-york-2-ca-version-2.expressnetw.com 1195
remote usa-atlanta-ca-version-2.expressnetw.com 1195
remote usa-chicago-ca-version-2.expressnetw.com 1195
remote usa-dallas-2-ca-version-2.expressnetw.com 1195
remote usa-dallas-ca-version-2.expressnetw.com 1195

The above is from my own custom config field. The one remote directive commented out is the one I specified in the Server Address and Port fields (I only did it that way for clarity's sake). The server-poll-timeout directive limits how long before the connection attempt will be aborted and another server is randomly chosen for the next attempt.

NOTE: This technique only works when all the servers require the same certs and keys! Fortunately, that's pretty common these days among commercial OpenVPN providers, but it's NOT unheard of for some to require *different* certs and keys. IMO, those providers should be avoided because it makes solving this kind of problem much more difficult.

Again, if you leave yourself the one and only server specified on the Server Address and Port fields, you're asking for trouble (imo). Esp. w/ these lower-tier OpenVPN providers forcing AUTH FAIL errors.
 
Last edited:

eibgrad

Very Senior Member
FYI. I just updated the watchdog script (v2.0.0) to include the option to perform ping checks across the tunnel, and NOT just check for failed VPN connections.


I've personally never had a problem w/ unresponsive tunnels, esp. when using the OpenVPN keepalive directive, which seems to work reasonably well. But for completeness, and because I know some ppl still like to include that type of check, I added it (but you can disable if you like).
 
Last edited:

octopus

Very Senior Member
FYI. I just updated the watchdog script (v2.0.0) to include the option to perform ping checks across the tunnel, and NOT just check for failed VPN connections.


I've personally never had a problem w/ unresponsive tunnels, esp. when using the OpenVPN keepalive directive, which seems to work reasonably well. But for completeness, and because I know some ppl still like to include that type of check, I added it (but you can disable if you like).
Sorry, but pastebin is PW protected.

Error, this is a private paste or is pending moderation. If this paste belongs to you, please login to Pastebin to view it.
 

eibgrad

Very Senior Member
Yeah, sorry about that. It's not something done by me (it's definitely a Public paste). PasteBin suddenly locked my scripts for some reason. Maybe too many updates over a short period. I'm gonna let it sit for a while and see if things return to normal.
 
Last edited:

Latest threads

Sign Up For SNBForums Daily Digest

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