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

    OpenVPN exits without restarting with exit-notify

    2.5.2 Release Candidate Snapshots (Retired)
    3
    9
    8.7k
    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.
    • JeGrJ
      JeGr LAYER 8 Moderator
      last edited by JeGr

      OpenVPN Server/Client configuration, Option "exit-notify". Configured as site2site shared-key:

      Send an explicit exit notification to connected clients/peers when restarting or shutting down, so they may immediately disconnect rather than waiting for a timeout. In SSL/TLS Server modes, clients may be directed to reconnect or use the next server. In Peer-to-Peer Shared Key or with a /30 Tunnel Network, this value controls how many times this instance will attempt to send the exit notification.

      As the client configuration default is "retry 1x" the following is happening in our lab:

      • client gets restarted due to config change or manual restart/stopping action

      • server side immediatly is stopped! It will not disconnect the client/peer side but instead completely exit the server!

        Jun 7 22:03:44	openvpn	12752	SIGTERM[soft,remote-exit] received, process exiting
        Jun 7 22:03:44	openvpn	12752	/usr/local/sbin/ovpn-linkdown ovpns1 1500 1572 172.27.254.253 172.27.254.254 init
        Jun 7 22:03:44	openvpn	12752	Closing TUN/TAP interface
        
      • server will NOT come back, service remains stopped

      • client is trying to connect and tunnel will not come back online

      Same behavior can be seen vice versa. If Server is configured with exit notify, it notifies the client peer instance of its restart and the client terminates the OpenVPN instance. It will not come back thus the tunnel remains down until one restarts the client, too.

      Only workaround: disable exit notify on both ends to avoid any side effects from happening while restarting the service. As I read the OpenVPN reference manual it seems to me it shouldn't exit/terminate the peer instance (or the clients) but just use the information to immediatly disconnect the corresponding client internally instead of waiting for the ping-timeout to happen. So currently setting the option will essentially break tunnels or RAS servers as a client can "notify" a server running on pfsense and simply terminate it that way.

      EDIT: After a quick test, a RAS server configuration with a client that has explicit-exit-notify [n] doesn't kill the server but it also does not disconnect the client. If you reconnect the client, you have a second client listed with a new IP so the server isn't told, that client1 has disconnected and should be removed correctly.

      This seems also the case since 2.5.0 and the option first appearing but we didn't notice until setting up a tunnel in our lab now and testing.

      Cheers

      Don't forget to upvote ๐Ÿ‘ those who kindly offered their time and brainpower to help you!

      If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

      1 Reply Last reply Reply Quote 0
      • Bob.DigB
        Bob.Dig LAYER 8
        last edited by

        I don't know if this is related, but I noticed for some time now, that my OVPN-Clients on pfSense don't come back after a nightly reboot done by cron, although they are even sometimes shown as "online". I am on 2.5.1-RELEASE.

        Before, they often had the problem, that some of them "shared" the same IP by the VPN-Server from the VPN-Provider, so I had to manually restart them, that they can diverge. But for quite some time now, they all don't work after a nightly reboot via cron (/usr/bin/nice -n20 /etc/rc.reboot).

        Now I will have a look if disabling "exit-notify" will make any change.

        1 Reply Last reply Reply Quote 0
        • Bob.DigB
          Bob.Dig LAYER 8
          last edited by

          My problem had nothing to do with exit-notify. Still I don't know the cause, but could be specific to the vpn-provider.

          1 Reply Last reply Reply Quote 0
          • JeGrJ
            JeGr LAYER 8 Moderator
            last edited by

            Sadly, in 2.5.2 final that error/bug (IMHO) is still active.

            -> RAS Style setup:

            • exit notify set to 1,2,...5 - all tested on server/client side configs do exactly what they are supposed to. Client gets notified of server restart and reconnects almost instantly to the restarted server. THAT'S GREAT! This minimizes downtimes of clients after a server restart. Great!

            • exit notify on a S2S tunnel setup on both nodes will bring the opposite node DOWN!

            Logs:

            Jul 9 15:40:56	openvpn	58850	SIGTERM received, sending exit notification to peer
            Jul 9 15:40:57	openvpn	58850	Closing TUN/TAP interface
            Jul 9 15:40:57	openvpn	58850	/usr/local/sbin/ovpn-linkdown ovpnc1 1500 1572 172.27.254.254 172.27.254.253 init
            Jul 9 15:40:57	openvpn	58850	SIGTERM[soft,exit-with-notification] received, process exiting
            

            So if one side restarts the client because of a WAN failure or a reconfig issue, the remote side exits the server/client process and does NOT restart! The process is stopped and killed!

            Any tunnel configured with explicit-exit-notify is therefor a "DoS" waiting to happen when the other side restarts the connection and "notifies" the other side.

            @jimp it may be my misunderstanding but the OpenVPN docs don't specify such behavior and as it works fine on RAS style connections, I'm wondering why the S2S style setup just exits and kills the process?

            Don't forget to upvote ๐Ÿ‘ those who kindly offered their time and brainpower to help you!

            If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

            1 Reply Last reply Reply Quote 0
            • jimpJ
              jimp Rebel Alliance Developer Netgate
              last edited by

              Is that an SSL/TLS site-to-site or shared key?

              Remember: Upvote with the ๐Ÿ‘ button for any user/post you find to be helpful, informative, or deserving of recognition!

              Need help fast? Netgate Global Support!

              Do not Chat/PM for help!

              JeGrJ 1 Reply Last reply Reply Quote 0
              • JeGrJ
                JeGr LAYER 8 Moderator @jimp
                last edited by

                @jimp It's a shared key. Quick and simple setup to test on 2 VPS instances

                Don't forget to upvote ๐Ÿ‘ those who kindly offered their time and brainpower to help you!

                If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

                1 Reply Last reply Reply Quote 0
                • jimpJ
                  jimp Rebel Alliance Developer Netgate
                  last edited by

                  OK so it's not RAS vs Site-to-Site but SSL/TLS vs Shared Key behavior difference. Well, to be more accurate, Shared Key and SSL/TLS with a /30 subnet both behave similarly as they use OpenVPN's "point-to-point" mode rather than a client/server model.

                  I wouldn't call it a bug, but perhaps we could prevent the setting from being used when a client or server instance is set to Shared Key or SSL/TLS with a /30 tunnel network. This has come up before, see https://redmine.pfsense.org/issues/6718 for example.

                  Remember: Upvote with the ๐Ÿ‘ button for any user/post you find to be helpful, informative, or deserving of recognition!

                  Need help fast? Netgate Global Support!

                  Do not Chat/PM for help!

                  JeGrJ 1 Reply Last reply Reply Quote 0
                  • JeGrJ
                    JeGr LAYER 8 Moderator @jimp
                    last edited by

                    @jimp That would surely be possible, but as I read the OpenVPN docs that setting should be safe to use for site 2 site either, shouldn't it? Perhaps I'm reading it wrong :)

                    Don't forget to upvote ๐Ÿ‘ those who kindly offered their time and brainpower to help you!

                    If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

                    1 Reply Last reply Reply Quote 0
                    • jimpJ
                      jimp Rebel Alliance Developer Netgate
                      last edited by

                      OpenVPN doesn't know "site-to-site" vs "remote access". It just knows point-to-point and point-to-multipoint ("server/client" mode). pfSense masks all that in terms users are more familiar with by changing the GUI options to make it more like what our users have expected and requested over time.

                      Under the hood, a Remote Access VPN and Site-to-Site SSL/TLS VPN (with a tunnel network larger than a /30) operate in the same way using the client/server mode of OpenVPN.

                      Exit notify only makes sense for UDP, since TCP will already know when a connection closes.

                      If you re-read the OpenVPN man page with all that in mind, it makes more sense.

                      Remember: Upvote with the ๐Ÿ‘ button for any user/post you find to be helpful, informative, or deserving of recognition!

                      Need help fast? Netgate Global Support!

                      Do not Chat/PM for help!

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