Automatically Restarting OpenVPN Client



  • I have an OpenVPN client that periodically disconnects from the VPN (sometimes ~1/week, sometimes 1/2-3 weeks) and doesn't automatically reconnect. I can stop/start the service and it will reconnect.

    I am looking for a way to do this automaically.

    Is there a way I can script (bash preferred, but python OK)

    • Detect that the VPN Client has disconnected (It shows as disconnected on the dashboard when I log in)
    • list itemStop/Start the VPN Client


  • The client itself should attempt to automatically reconnect unless an authentication failure occurs and you have enabled the "Do not retry connection when authentication fails" option enabled for that client. However, if the client service itself dies, you can use the Service Watchdog package to automatically restart it. Just install that package, and then go to Services > Service Watchdog and add your OpenVPN client(s).



  • @TheNarc said in Automatically Restarting OpenVPN Client:

    The client itself should attempt to automatically reconnect unless an authentication failure occurs and you have enabled the "Do not retry connection when authentication fails" option enabled for that client. However, if the client service itself dies, you can use the Service Watchdog package to automatically restart it. Just install that package, and then go to Services > Service Watchdog and add your OpenVPN client(s).

    I'm not exactly sure what is happening... Do not retry connection when authentication fails is not checked, but for some reason the VPN does not reconnect unless I start/stop the service.

    The only thing that I noticed in the log was this, and I think it was just showing that the VPN didn't have a connection, so dpinger was failing.

    --- /rc.newwanip: The command '/usr/local/bin/dpinger  --removed-- >/dev/null' returned exit code '1', the output was ''
    

    I think what is happening is the the VPN provider changes the server IP addresses from time to time. I know I had something like this happen on my main WAN when my ISP changed my IP address - I had to restart or something... don't remeber the details.

    In this case will the watchdog package work? I need to determine if dpinger is successful on the VPN, and restart it if it isn't.



  • If the client isn't crashing (not showing "unable to contact daemon" in the widget) and instead showing as disconnected, service watchdog won't solve the issue. If it's disconnecting periodically it could be a reauthentication issue or some options preventing OpenVPN performing a reconnect during network changes.

    Are you able to send me the OpenVPN client config file? (Should be at /var/etc/openvpn/client<number>.conf). Feel free to redact any sensitive data before posting.

    Additionally, this might not be relevant to your set up, but I tracked down a bug in 2.4.4-RELEASE-p3 whereby when running OpenVPN on a multi-WAN set up it won't reconnect successfully when performing gateway failover events. I patched this and is scheduled for 2.4.5. However, if you're not running multi-WAN then this shouldn't be the issue.



  • @guardian This is interesting. If you're using the directive redirect-gateway def1 (route all IPv4 traffic via VPN). This is likely not reconnecting because if the server IP address is changing and you're routing all traffic via the VPN, it could struggle to reconnect because the default route to establish a new VPN connection (via a changed server IP) will be via the now broken VPN tunnel. In any case, if this is the issue, it should be fairly easy to solve after looking at the routing table.

    Do you notice a loss of Internet connectivity when the VPN dies?



  • @jwsi said in Automatically Restarting OpenVPN Client:

    @guardian This is interesting. If you're using the directive redirect-gateway def1 (route all IPv4 traffic via VPN). This is likely not reconnecting because if the server IP address is changing and you're routing all traffic via the VPN, it could struggle to reconnect because the default route to establish a new VPN connection (via a changed server IP) will be via the now broken VPN tunnel. In any case, if this is the issue, it should be fairly easy to solve after looking at the routing table.

    Do you notice a loss of Internet connectivity when the VPN dies?

    I have never noticed a significant loss of Internet connectivity on the main WAN, just on the guest WiFi network. I use the VPN to route all my guest WiFi network traffic though -- most traffic goes straight out. I have a website pinger that checks the startus of my shared host every 5 minutes and as part of the code it does a quick UDP socket connection to about a half dozen differnt public DNS servers. If for some reason none of them connect, then this is logged and the test is skipped. I get between 1 and 10 of these / day. I suspect it might be a temporary loss of cable modem connectivity, (could also be an intermittent NIC interface) and it might also be some sort of bug in my program.

    I also experience some slow DNS resolution and occasional failed attempts that need to be retried (web page not found -- hit the enter key again, and it comes up - and occasional messages in terminal about temporary address resolution failure).

    Here is the config file with appropriate redactions:

    dev ovpnc1
    verb 3
    dev-type tun
    dev-node /dev/tun1
    writepid /var/run/openvpn_client1.pid
    #user nobody
    #group nobody
    script-security 3
    daemon
    keepalive 10 60
    ping-timer-rem
    persist-tun
    persist-key
    proto udp4
    cipher AES-256-GCM
    auth SHA256
    up /usr/local/sbin/ovpn-linkup
    down /usr/local/sbin/ovpn-linkdown
    local xxx.xxx.xxx.xxx
    tls-client
    client
    lport 0
    management /var/etc/openvpn/client1.sock unix
    remote vvvvvvvvvvvvvvvvvvvvvvvvvvvv 1197
    auth-user-pass /var/etc/openvpn/client1.up
    auth-retry nointeract
    ca /var/etc/openvpn/client1.ca 
    ncp-disable
    comp-lzo adaptive
    resolv-retry infinite
    route-nopull
    route-noexec
    persist-key
    persist-tun
    remote-cert-tls server
    reneg-sec 0
    
    

Log in to reply