1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.
Dismiss Notice

Welcome To SNBForums

SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.

If you'd like to post a question, simply register and have at it!

While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!

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

Discussion in 'Asuswrt-Merlin' started by coqypef, May 24, 2019.

  1. coqypef

    coqypef Occasional Visitor

    Joined:
    Aug 6, 2017
    Messages:
    20
    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
     
  2. eibgrad

    eibgrad Senior Member

    Joined:
    Feb 20, 2017
    Messages:
    233
    The problem is the directive you added, auth-nocache. Get rid of it.
     
  3. coqypef

    coqypef Occasional Visitor

    Joined:
    Aug 6, 2017
    Messages:
    20
    I only added that line in an attempt to solve the problem.
     
  4. eibgrad

    eibgrad Senior Member

    Joined:
    Feb 20, 2017
    Messages:
    233
    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.
     
    L&LD likes this.
  5. eibgrad

    eibgrad Senior Member

    Joined:
    Feb 20, 2017
    Messages:
    233
    One thing is for sure, the connection is being brought down by a soft restart, due to inactivity.

    Code:
    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.
     
    Last edited: May 24, 2019
  6. coqypef

    coqypef Occasional Visitor

    Joined:
    Aug 6, 2017
    Messages:
    20
    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.
     
  7. eibgrad

    eibgrad Senior Member

    Joined:
    Feb 20, 2017
    Messages:
    233
    FYI, it's possible to force a soft restart w/ the following command from the shell (ssh).

    Code:
    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.
     
  8. RMerlin

    RMerlin Super Moderator

    Joined:
    Apr 14, 2012
    Messages:
    30,836
    Location:
    Canada
    Disable auth token support (check the OpenVPN manual, I don't remember the keyword for it).

    Sent from my P027 using Tapatalk
     
  9. coqypef

    coqypef Occasional Visitor

    Joined:
    Aug 6, 2017
    Messages:
    20
    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?

    Capture.JPG
     
  10. octopus

    octopus Very Senior Member

    Joined:
    Jul 17, 2012
    Messages:
    1,202
    auth-nocache
    pull-filter ignore "auth token"
     
  11. coqypef

    coqypef Occasional Visitor

    Joined:
    Aug 6, 2017
    Messages:
    20
    Those were the settings in my first post. It doesn't work.
     
  12. octopus

    octopus Very Senior Member

    Joined:
    Jul 17, 2012
    Messages:
    1,202
    Which port do you use?
     
  13. coqypef

    coqypef Occasional Visitor

    Joined:
    Aug 6, 2017
    Messages:
    20
    1194
     
  14. Quoc Huynh

    Quoc Huynh Regular Contributor

    Joined:
    Jan 11, 2018
    Messages:
    56
    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 :confused:

    [​IMG]
     
    Last edited: May 25, 2019
  15. eibgrad

    eibgrad Senior Member

    Joined:
    Feb 20, 2017
    Messages:
    233
    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.

    Code:
    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).

    Code:
    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.
     
  16. pusb87

    pusb87 Regular Contributor

    Joined:
    Dec 15, 2016
    Messages:
    59
    isnt this normal behaviour if you have
    upload_2019-5-25_12-58-42.png
     
  17. eibgrad

    eibgrad Senior Member

    Joined:
    Feb 20, 2017
    Messages:
    233
    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.
     
  18. coqypef

    coqypef Occasional Visitor

    Joined:
    Aug 6, 2017
    Messages:
    20
    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
     
  19. eibgrad

    eibgrad Senior Member

    Joined:
    Feb 20, 2017
    Messages:
    233
    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.

    Code:
    service restart_wan
     
    Last edited: May 25, 2019
  20. eibgrad

    eibgrad Senior Member

    Joined:
    Feb 20, 2017
    Messages:
    233
    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.

    Code:
    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.
     
    Last edited: May 25, 2019