I just managed to cut my OpenVPN connection to some 20 servers tonight. I was experimenting with the client-connect scripts, and at some point one of the scripts returned a non zero response. This non zero response triggered an AUTH: Received AUTH_FAILED control message in the syslog which eventually resulted in a SIGTERM[soft,auth-failure] received, process exiting exit from the OpenVPN client. Is there a way to protect myself from this? Any configuration on the server or client side?

  • Any help is appreciated... anyone? – Ricardo Marimon Jun 29 '11 at 2:23
  • 1
    This is like typing something in google and getting 0 pages found. – Ricardo Marimon Jun 29 '11 at 16:33

The easiest way to protect yourself from this is to wrap the openvpn client in a while loop that restarts it. Looking at the openvpn discussion list it appears this was a design decision made because auth failures likely require manual intervention and having the client retry repeatedly would in many cases lock out the user (according to SOX/PCI compatible security precautions). It isn't clear what your OS config is, in OS X the launchd would take care of respawning this.

| improve this answer | |
  • Will do this and see how it works. I'm thinking this as a protection mechanism against misconfigurations on my side that would result in a disconnected openvpn client. As for the clientes they are linux so I'll cron my way through it. – Ricardo Marimon Aug 16 '11 at 16:41

I've been seeing the same problem intermittently. polynomial's answer seems to be correct - I'm sure in my cause it's a network/connection error and not authentication.

Starting OpenVPN with the following script has fixed it for me, although you might need to adjust it for your local setup:



while true; do
    /etc/init.d/openvpn restart
    sleep $waitTime

    vpnIp=$( ip addr show dev $device | grep 'inet ' | cut -d ' ' -f 6 | cut -d '/' -f 1 )

    if [ ! -x $vpnIp ]; then

    if [ $attempts -gt $maxAttempts ]; then
| improve this answer | |
  • 1
    Thanks for the script. You should probably edit to: "/etc/init.d/openvpn restart $device" or whatever the tunnel '*.conf' name is, so it will only restart this specific openvpn client/tunnel.. Otherwise it would also restart a running openvpn server - if present. – Motsel Sep 26 '14 at 21:10
  • Great idea, although I suspect the init scripts are specific to each Linux distribution. On Debian Wheezy /etc/init.d/openvpn restart tap0 gives failure: No such VPN is running: tap0. I can't find any reference to the device in the script. Which version of Linux are you using? – fazy Oct 6 '14 at 10:51
  • I'm also running Debian Wheezy (7.6), in my case "/etc/init.d/openvpn restart tun1" works. For this to work the file has to be named /etc/openvpn/<interface>.conf, in my case /etc/openvpn/tun1.conf. – Motsel Oct 7 '14 at 17:00
  • Ah I see, so it's really a config name rather than a device name; just that the config name is named after the device? – fazy Oct 7 '14 at 17:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.