Re: [Openvpn-devel] Automatically restart Linux systemd OpenVPN client service on failure
Hi Arne, On Saturday, 13 May 2023 16:28:29 CEST Arne Schwabe wrote: > Can you provide some more detail here? Otherwise this seem a bit > nebulously to me what exactly explodes and goes wrong. I changed the --keepalive setting on the server, lowering the timeout from 120 to 60 seconds to make things somewhat more responsive. Figured a small push change like this wouldn't really cause trouble. This triggered a TUN device close/reopen, which makes sense in hindsight. Clients are configured to drop privilege with --user and --group after connecting, so they could not make the change needed. > NOTE: Pulled options changed on restart, will need to close and reopen > TUN/TAP device. > ... > ERROR: Cannot ioctl TUNSETIFF tun_vpn: Operation not permitted (errno=1) > Exiting due to fatal error This is not the only case though, I also had some problems with DCO on a Debian testing client recently, resulting in failure after network was offline for quite a while. Official Debian package DCO 0.0+git20230324-1. > TLS Error: TLS key negotiation failed to occur within 60 seconds (check your > network connectivity) > TLS Error: TLS handshake failed > ... A lot of the same ... > TLS Error: TLS key negotiation failed to occur within 60 seconds (check your > network connectivity) > TLS Error: TLS handshake failed > TLS: tls_multi_process: killed expiring key > No encryption key found. Purging data channel keys > dco_del_key: netlink out of memory error: No buffer space available > (errno=105) > Exiting due to fatal error In some cases this is arguably user/admin configuration error, but in other cases it is genuinely bugs or problems that can cause OpenVPN to fail. >From a security point of view, it's also better to drop privileges after connection and if things really change a lot error, fail, exit and get restarted by systemd, with privileges, set things up and drop them again. The alternative is to forever run OpenVPN client process as root. In conclusion I don't see a reason to *not* automatically restart and retry when configured as a system service through systemd. GUI clients might be a different matter, though even there I'd argue for auto-reconnect until the human user tells the program to stop. Cheers, -- 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
Re: [Openvpn-devel] Automatically restart Linux systemd OpenVPN client service on failure
Am 13.05.23 um 16:24 schrieb Melvin Vermeeren: 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! Can you provide some more detail here? Otherwise this seem a bit nebulously to me what exactly explodes and goes wrong. Arne ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] Automatically restart Linux systemd OpenVPN client service on failure
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
[Openvpn-devel] [PATCH applied] Re: dco_linux: properly close dco version file
Acked-by: Gert Doering "Obviously correct in hindsight"... (there is other weirdness in this function, like, "why use a struct buffer if all you want is a gc-allocated char[256]?", but that's for a different day to fix). Have stared-at-code and test compiled on Linux. Your patch has been applied to the master and release/2.6 branch. commit cf496476b364f8613bacd48e10d6a1bbbf0aceda (master) commit 26ea58f94ce10e108aa7c607b0a7dcb3419449fc (release/2.6) Author: Frank Lichtenheld Date: Fri May 12 17:50:23 2023 +0200 dco_linux: properly close dco version file Signed-off-by: Frank Lichtenheld Acked-by: Gert Doering Message-Id: <20230512155023.06-1-fr...@lichtenheld.com> URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg26650.html Signed-off-by: Gert Doering -- kind regards, Gert Doering ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
