OpenVPN exits without restarting with exit-notify

[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

[Bob.Dig]

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.

[Bob.Dig]

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

[JeGr]

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?

[jimp]

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

[JeGr]

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

[jimp]

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.

[JeGr]

@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 :)

[jimp]

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.