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

Attachment: 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

Reply via email to