Specifying VPN connection in 'secondaries' of LAN connection can lead to deadlock
I'm using the connection.secondaries
configuration of my LAN interface to specify the OpenVPN connection for auto-connect. I read that this is the recommended way of doing this. Especially since the OpenVPN plugin does not support auto-connect.
I've a script running on startup ensuring VPN is setup correctly (with certificates and all) and if it is configures the LAN interface's secondaries to include VPN. Usually it just works as it is supposed to be. The LAN connection comes up on boot and pulls in the VPN connection afterwards.
However I've observed a severe problem with that: when there is a problem with the VPN connection while configured as secondary (certificate not valid anymore, connection to VPN server not possible, etc.) the VPN connection fails and to my surprise also pulls down the primary LAN connection. I've had the case where the certificate was invalidated at the server, which is usually not that big of a problem because the device will automatically initiate a new CSR but in that case the VPN connection died with the old cert, pulled down LAN which then causes the renewal process to fail because there is no network connection which then keeps going indefinitely.
For a start I'd expect secondary (optional, desired) connections of the primary interface to not influence the operation of the primary interface in any way (if not explicitly configured). Pulling the primary down if the secondary fails may seem like a reasonable way to restart the connection and retry, but it also can cause connectivity issues as described above. I'd actually expected that the VPN connection would be retried without restarting the primary connection as it is "only" a secondary connection. Right now it feels like the other way around, that the VPN connection is some kind of dependency for LAN to stay active.