OpenVPN client fails to reconnect automatically "Error connecting - Authentication failed")

[coqypef]

I run an OpenVPN client on my ASUS RT-AC86U with 384.10_2 firmware. Everything works fine except that whenever the VPN client disconnects (happens occasionally for various reasons), it is unable to reconnect automatically. It gives the following error: "Error connecting - Authentication failed". The log file says:

ovpn-client1[1314]: AUTH: Received control message: AUTH_FAILED
ovpn-client1[1314]: SIGTERM[soft,auth-failure] received, process exiting

Every time this happens, I have to log on to my router's browser interface and switch the VPN client's service state selector back ON. After which it quickly reconnects without issue.

I've seen other threads about this issue but no solution.

Screenshot of my VPN client settings: https://i.imgur.com/Q6tVb0n.jpg

Complete log file: https://pastebin.com/raw/ffRk5L1s

 

[eibgrad]

The problem is the directive you added, auth-nocache. Get rid of it.

 

[coqypef]

The problem is the directive you added, auth-nocache. Get rid of it.

I only added that line in an attempt to solve the problem.

 

[eibgrad]

I only added that line in an attempt to solve the problem.

Then there is some other problem, because auth-nocache causes the username/password to be purged from memory once the connection is established. And if the openvpn client needs to reestablish the connection, and that information is no longer in the cache, it won't reread it from the file system. At least that's how I read the OpenVPN documentation.

It's certainly not going to help resolve the problem.

 

[eibgrad]

One thing is for sure, the connection is being brought down by a soft restart, due to inactivity.

May 22 13:37:05 ovpn-client1[30016]: [*.somesvpnservice.com] Inactivity timeout (--ping-restart), restarting
May 22 13:37:05 ovpn-client1[30016]: SIGUSR1[soft,ping-restart] received, process restarting

It tries to restart, but fails authentication, which would make sense if you're using auth-nocache. Maybe if you remove that directive, it will fail for some other reason. And that information may prove useful. IOW, auth-nocache is masking the real problem.

 

[coqypef]

(...)

OK, thanks for the information. I have removed the "auth-nocache" line (and restarted my router). I'll post a new log file when (or if) it happens again.

 

[eibgrad]

OK, thanks for the information. I have removed the "auth-nocache" line (and restarted my router). I'll post a new log file when (or if) it happens again.

FYI, it's possible to force a soft restart w/ the following command from the shell (ssh).

killall -s SIGUSR1 openvpn

I'm not sure if there's a specific set of circumstances that triggers the problem, or *any* soft restart. But at least this could save some time if it's the latter.

 

[RMerlin]

Disable auth token support (check the OpenVPN manual, I don't remember the keyword for it).

Sent from my P027 using Tapatalk

 

[coqypef]

(...)

It happened again, overnight:

ovpn-client1[4857]: SIGTERM[soft,auth-failure] received, process exiting

Complete log file since my last comment (after i restarted my router): https://pastebin.com/raw/0XZJL8jD

Settings (same as last time except "auth-nocache" is removed): https://i.imgur.com/z9JVkkR.png

Disable auth token support (check the OpenVPN manual, I don't remember the keyword for it).

Sorry, I was unable to find such a setting in the OpenVPN 2.4 manual. Which setting is this exactly?

 

[octopus]

It happened again, overnight:

ovpn-client1[4857]: SIGTERM[soft,auth-failure] received, process exiting

Complete log file since my last comment (after i restarted my router): https://pastebin.com/raw/0XZJL8jD

Settings (same as last time except "auth-nocache" is removed): https://i.imgur.com/z9JVkkR.png



Sorry, I was unable to find such a setting in the OpenVPN 2.4 manual. Which setting is this exactly?

View attachment 17777

auth-nocache
pull-filter ignore "auth token"

 

[coqypef]

auth-nocache
pull-filter ignore "auth token"

Those were the settings in my first post. It doesn't work.

 

[octopus]

Those were the settings in my first post. It doesn't work.

Which port do you use?

 

[coqypef]

Which port do you use?

1194

 

[Quoc Huynh]

I think it may be due to your ISP's DHCP malfunction, which leads to network being unreachable. Thus, the authorization of VPN service is failed. Perhaps you should check your ISP modem or the cable between it and your router

 

[eibgrad]

Well the pattern is very clear. At some point a soft restart is initiated, and it says due to inactivity. It then repeatedly attempts to restart, failing each time, and increasing the time by double between retries, until it hits 300 secs and quits for good. But there's no indication as to *why* it can't restart.

On the face of it, it would at least appear the server side is initiating this, perhaps to rid itself of dead connections, or at least what it thinks are dead connections. Esp. given it tends to happen overnight. You could try using a keepalive directive to see if it prevents the inactivity issue in the first place.

keepalive 10 60

I know from my own OpenVPN client on Merlin that he's NOT using such a directive. But I can't tell from the log whether the OpenVPN server is pushing one (that would appear at the beginning, when the connection is first established). In my own case, it shows as follows (it's the ping 5, ping-restart 28 settings).

May 25 04:36:15 ovpn-client1[6370]: PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 10.13.0.1,route 10.13.0.1,topology net30,ping 5,ping-restart 28,ifconfig 10.13.0.26 10.13.0.25'

Before doing so, I want to see if perhaps there's just something in general in this config that can't handle a soft restart properly. What I'd like you to do is reestablish the connection (without the keepalive) and *force* a soft restart using the command I explained above. It *should* recover from the soft restart and get connected again. If it doesn't, then perhaps there is something else going on.

 

[pusb87]

I run an OpenVPN client on my ASUS RT-AC86U with 384.10_2 firmware. Everything works fine except that whenever the VPN client disconnects (happens occasionally for various reasons), it is unable to reconnect automatically. It gives the following error: "Error connecting - Authentication failed". The log file says:

ovpn-client1[1314]: AUTH: Received control message: AUTH_FAILED
ovpn-client1[1314]: SIGTERM[soft,auth-failure] received, process exiting

Every time this happens, I have to log on to my router's browser interface and switch the VPN client's service state selector back ON. After which it quickly reconnects without issue.

I've seen other threads about this issue but no solution.

Screenshot of my VPN client settings: https://i.imgur.com/Q6tVb0n.jpg

Complete log file: https://pastebin.com/raw/ffRk5L1s

isnt this normal behaviour if you have

 

[eibgrad]

I think it may be due to your ISP's DHCP malfunction, which leads to network being unreachable. Thus, the authorization of VPN service is failed. Perhaps you should check your ISP modem or the cable between it and your router

isnt this normal behaviour if you have
View attachment 17781

The kill switch should only block clients on the local network behind the router, NOT the router itself. The router itself obviously always needs access to the WAN, whether to establish the initial or subsequent connections.

 

[coqypef]

(...)

I used PuTTY to execute "killall -s SIGUSR1 openvpn" (while the VPN connection was fine). It recovered without issues. Here's the log file:

https://pastebin.com/raw/WmdDg27g

 

[eibgrad]

So it's not a general problem w/ soft restarts. And I can even see the keepalive has been pushed (ping 3,ping-restart 10). Pretty short one at that.

Given the facts so far (it handles a soft restart just fine, in fact rather quickly, it happens overnight, it's using a keepalive, etc.), I suspect the VPN provider is just dropping the connection and refusing to restart. Or else something like an issue w/ the WAN (as someone else pointed out) is preventing it. But you'd think that could happen at any time.

May be worth forcing a WAN restart to see if the VPN recovers correctly.

service restart_wan

 

[eibgrad]

Also, just to see if it makes a difference, try using a UDP connection w/ this OpenVPN provider. Right now it's TCP. And besides, UDP is usually faster anyway.

Also, I would throw some additional remote directives into custom config so if it's a problem w/ that particular server, the OpenVPN client has additional servers from which to choose. One of the problems w/ using a hardcoded remote IP is that it gives you only one option. And if the OpenVPN provider happens to bring a server down for some reason (maintenance, overloaded, etc.), you just have no other options.

For example, here's what my custom config looks like w/ my OpenVPN provider, SecurityKISS.

server-poll-timeout 10
#remote 91.227.222.7 5353 # United Kingdom, Cambridge
remote 91.227.222.7 5000 # United Kingdom, Cambridge
remote 23.19.26.250 5353 # United States, Los Angeles
remote 23.19.26.250 5000 # United States, Los Angeles
remote 69.175.85.2 5353 # United States, Chicago
remote 69.175.85.2 5000 # United States, Chicago
remote 78.46.254.48 5353 # Germany, Nuremberg
remote 78.46.254.48 5000 # Germany, Nuremberg
remote 217.147.94.149 5353 # United Kingdom, Maidenhead
remote 217.147.94.149 5000 # United Kingdom, Maidenhead
remote 178.63.171.106 5353 # Germany, Nuremberg
remote 178.63.171.106 5000 # Germany, Nuremberg
remote 178.32.250.32 5353 # United Kingdom, London
remote 178.32.250.32 5000 # United Kingdom, London
remote 88.150.208.131 5353 # United Kingdom, Gosport
remote 88.150.208.131 5000 # United Kingdom, Gosport
remote 173.212.205.240 5353 # Germany, Munich
remote 173.212.205.240 5000 # Germany, Munich
remote 195.154.232.143 5353 # France, Paris
remote 195.154.232.143 5000 # France, Paris

The one commented out is the one specified in the GUI. The server-poll-timeout limits how long I want it to wait for a connection on the current remote directive before moving on to try the next one.