2.5.2-release still has OpenVPN Site2Site Bug with explicit-exit-notify

[JeGr]

See my report here:
https://forum.netgate.com/topic/164257/openvpn-exits-without-restarting-with-exit-notify/4

TL;DR

A OVPN site2site tunnel configured with explicit-exit-notify flags (retry 1 or 2) will instantly go down, exit and kill the process if the other side sends notification of exit. Instead of speeding up the process of reconnection on either side through notification of its exit, that essentially brings down a tunnel without a chance to reconnect, as the peer shuts down the process instead of trying to reconnect immediatly (or removing the peer from its connected client list for the server side).

ATM best thing to do is to avoid the setting with tunnels but if you have a client, that does send an exit notification, the server can/will go down.

Cheers

[JeGr]

Details:

Server:

Client:

---

Server/Client Tunnel is up and running:

restarting Server Instance:

Client shuts down and exits/kills process, Server now restarted and waits for connection, but nothing is incoming:

[JeGr]

@jimp as the old thread was in the 2.5.2 subforum and is locked to further answers:

We had that problem here with a 2.5.2-release and a 2.6-testing system. The customer has LTE routers from a brand, that can run OpenVPN and they connect them via a Site2Site tunnel to their pfSense setup. As the LTE router's OVPN implementation has explicit-exit-notify set up (whysoever), every time one of them disconnects the pfSense server side goes down and stays down.

No we don't have the possibility to change the client side and have server side always exiting. Customer says, that with a normal linux vhost with openvpn set up, they don't have that problem so the server seems to behave in another way as the one running on pfSense.

Is that something we can fix in pfSense' implementation? Upstream FreeBSD? Upstream OVPN? Don't understand why the server behaves like that in s2s mode in the first place, as - as tested - in RAS mode it just works as expected.

Cheers
\jens

[jimp]

I explained all that in my responses on the other thread -- it's something in OpenVPN internally.

For point-to-point tunnels exit-notify is not desirable. Re-read my past responses for the distinction between "point-to-point" in OpenVPN and "site-to-site" in the pfSense GUI.

[JeGr]

@jimp I did, nevertheless the router on the other end is configured that way and every time it restarts/reconnects the tunnel, the whole server goes down.

I completely understand it is not desirable, but that doesn't help in that scenario when the other side sets that config option and can crash our side of the tunnel at will? That can't be by design nor an allowed configuration IMHO? I mean what software offers to DoS itself by a peer config option? It just makes no sense to me. So no offense meant against you or the project, just trying to grasp an understanding if that could somehow mitigated on pfSense' side by auto-restarting the server or it not killing and permanently exiting.

[jimp]

explicit-exit-notify must be disabled on both sides of point-to-point. If either one has it on, the other will still receive and honor the notification. It's doing exactly what OpenVPN has programmed it to do -- it's nothing that pfSense is doing. And it's been that way for years. The other end of that connection must be changed.

If you want a way to ignore that, you'd have to take it up with OpenVPN upstream.

In the meantime, you can always use the Service Watchdog package to restart the service when it has stopped.

[JeGr]

@jimp said in 2.5.2-release still has OpenVPN Site2Site Bug with explicit-exit-notify:

In the meantime, you can always use the Service Watchdog package to restart the service when it has stopped.

Ah didn't think of that. Normally I'm more "solve the problem, don't restart" type of engineer but you're right, if the other side is "wrongdoing" and there's nothing we can do - so be it :/