Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Automatically Restarting OpenVPN Client

    Scheduled Pinned Locked Moved OpenVPN
    6 Posts 3 Posters 6.3k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • G
      guardian Rebel Alliance
      last edited by

      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

      If you find my post useful, please give it a thumbs up!
      pfSense 2.7.2-RELEASE

      1 Reply Last reply Reply Quote 0
      • T
        TheNarc
        last edited by

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

        G 1 Reply Last reply Reply Quote 1
        • G
          guardian Rebel Alliance @TheNarc
          last edited by

          @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 you find my post useful, please give it a thumbs up!
          pfSense 2.7.2-RELEASE

          jwsiJ 1 Reply Last reply Reply Quote 0
          • jwsiJ
            jwsi
            last edited by

            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.

            1 Reply Last reply Reply Quote 0
            • jwsiJ
              jwsi @guardian
              last edited by

              @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?

              G 1 Reply Last reply Reply Quote 0
              • G
                guardian Rebel Alliance @jwsi
                last edited by

                @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
                
                

                If you find my post useful, please give it a thumbs up!
                pfSense 2.7.2-RELEASE

                1 Reply Last reply Reply Quote 0
                • First post
                  Last post
                Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.