Digging through this, it turns out that: Networkmanager unconditionally appends --key-persist if Key-persist had been disabled, the openvpn client would have reloaded the key+cert from disk after a failed connection, and then would reconnect succesfully. As it is, it seems I have to either restart NetworkManager or send a HUP to openvpn, forcibly resetting the connections and causing an interruption. could it be possible to disable key-persist, or make it an option? Keys persisting is good when your network drops and you have password protected / hardware protected keys. When you have software that's miles away that drops connection and are unreachable because the VPN doesn't reload the fresh keys from disk, it becomes a bit more annoying. Right now I'm pondering how to get the machines to power cycle, as that would get the keys loaded properly. I have to get this sorted quickly if I'm not to get locked out of all my machines, so any suggestion on how to work around this in the short term would be good. //D.S. On 14/10/14 21:43, D.S. Ljungmark wrote:
Hi, I have some problems with the openvpn plugin for NetworkManager that might be. a bit special. Basically, we run automated setups where we have short-lived certificates. This is causing problems with NM+openvpn as the certificates aren't reloaded after they are updated. So, a process has cached the certs, which are then replaced on disk, but there is no way of telling NM+openvpn to reload the certificates from disk (or restart the vpn?) Is there a better way of doing this than to `pkill vpn` after updating the certificates, something that might cause.. issues. This went for a while before being noticed, until the first batch of certificates timed out. Any suggestions on how to get NM+openvpn to reload the certificates from disk? //D.S.
-- 8362 CB14 98AD 11EF CEB6 FA81 FCC3 7674 449E 3CFC
Attachment:
signature.asc
Description: OpenPGP digital signature