2.5+/2.6-dev Bug(?) OpenVPN inactivity timeout default
-
Hi,
after a few updates from our customer installations, we got quite a few reports, that new OpenVPN tunnels/RAS installations would malfunction after a short time. That only seemed to happen with newly created ones after Updateing to 2.5.2.
After checking that in our lab I found that the default setting of the inactivity timeout switched from 0 (disabled) to 300! So every new server created goes down after 5min, even Site2Site tunnels where that behavior surely isn't wanted at all. After switching them back to 0 like the default was before, the reports vanished and customers were happy again.
Why did that setting default switched to 300 instead of inactive (0) as in 2.4? That caused quite a bit of confusion and trouble, especially when the remote side is far away and not easily accessible and with a tunnel going down due to inactivity (and it went down despite being s2s with gateways) that caused quite a stir.
Cheers
-
It is a safer default. See https://redmine.pfsense.org/issues/11699. Without a timeout, OpenVPN fails to cleanup certain items if clients drop off unexpectedly.
-
@jimp That seems to relate to RAS setups, doesn't it?
Nevertheless, that timeout setting make the whole server exit (shutdown) so it has to be restarted either per hand or per watchdog, both completely unnecessary.
Yes of course one can set the timeout to 0 now, but a default change that makes an openVPN tunnel effectively shutdown after 5min of inactivity with the openVPN server stopped and without chance to reconnect is a pretty ... disrupting change for a tunnel default. There are customers running large setups with a multitude of LTE routers from Teltonika and other brands that use OVPN tunnels to a central system. We already had quite a few calls after the update about new servers constantly failing etc. until we checked for changes to old ones.
Didn't try the setting on RAS style servers so don't know if they also shutdown but I guess it's like explicit-exit-notify just "working fine" on that front? Perhaps like the exit notify that should be disabled on tunnels, the inactivity timeout should be 0/disabled, too?
Cheers
-
Hmm, I've never seen it make the server terminate. But it's primarily aimed at remote access.
Are these peer-to-peer static key setups again?
-
@jimp Indeed they are mostly. A few will be certificate based but they are just ramping up and haven't been deployed at large so no input from those yet.
-
It's possible the same issue is there like exit notify where it isn't meant to be used that way with static key.
-
@jimp Seems I have some lab work to do and test that out with a cert based tunnel setup :)
-
It does appear to be a similar case to exit notify for point-to-point modes.
In "sever" mode (SSL/TLS with a tunnel network larger than /30) it considers Inactive to only apply to client sessions and not the server itself.
In point-to-point mode (client or server are ambiguous to OpenVPN) it terminates the process on inactivity.