Hi all, Today I changed some OpenVPN server configuration and restarted the service, thinking all clients will reconnect just fine as usual. Unlike other days however, all Linux clients ended up exploding due to unexpected tun-device recreation and lack of permission to do so, resulting in fatal exit with service failure. Quite a surprise to me, and a bit of a mess to fix!
After first researching Debian's OpenVPN package, I find the service is provided by OpenVPN itself. Looking further, I find a PR on GitHub from 2018. https://github.com/OpenVPN/openvpn/pull/104 After doing some thinking I shared my thoughts there as well. https://github.com/OpenVPN/openvpn/pull/104#issuecomment-1546384702 However, mailing list seems preferred for OpenVPN, so here it is! I'll quote my message on GitHub here for convenience, I'll also add a ref from GitHub to this mail on the mailing list archives once I see it live. > Today I was bitten by this issue. I adjusted some seemingly irrelevant > options on a OpenVPN server instance and restarted it, expecting the clients > to handle it gracefully. Because the clients drop a bunch of privileges > however and OpenVPN decided recreation of the tun device was needed it ended > in an explosion where all clients fatal exited and as a result the openvpn- > client@.service for them failed. Quite a mess I had to manually untangle to > get critical systems talking to each other again. > > Personally I think the default should be to retry. A system service should > do it's best to keep working, as it usually means it's part of a server or > managed workstation, etc, and not a human user interacting with a VPN GUI or > similar. Especially nasty if you rely on the VPN for remote access to the > other machines, luckily didn't happen for me today. > > I genuinely don't see a use case where you don't want it to automatically > restart and try again on failure! Imagine if a DHCP client would stop trying > if it encountered a very weird situation and fatal exited, resulting in a > host without network connectivity. This with OpenVPN client feels very > similar in principle to that. It has been quite some years since 2018, and with things like remote work etc getting more common client VPN reliability I feel is much more important than before. Losing the client VPN could mean having to physically travel to the machine in question in order to fix it, as remote access could be impossible! Thoughts on changing this by default? Thanks, -- Melvin Vermeeren Systems engineer
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
