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