The issue was reported upstream and they commented "the plugin doesn't use --daemon, so it's unclear why the quoted message would matter.
It looks like the plugin is unable to re-request the password. So, having openvpn cache the password might workaround the issue in some cases, but it doesn't seem to be the right fix. Maybe it's due to --user, and later the plugin's /usr/libexec/nm-openvpn-service-openvpn-helper is unable to connect NetworkManager via D-Bus. Or maybe, openvpn requests a new secret via the --management socket, but the plugin fails to handle the request. It would be helpful to provide a logfile with full debugging info enabled (beware of private data!!). On recent versions, you can enable verbose logging via sudo nmcli general logging level TRACE domains ALL,VPN_PLUGIN and re-activate the connection. See https://cgit.freedesktop.org/NetworkManager/NetworkManager/plain/contrib/fedora/rpm/NetworkManager.conf?id=master"; ** Changed in: network-manager-openvpn (Ubuntu) Importance: Undecided => High ** Changed in: network-manager-openvpn (Ubuntu) Status: Confirmed => Triaged -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager-openvpn in Ubuntu. https://bugs.launchpad.net/bugs/1681295 Title: Problem in nm-openvpn-service.c, openvpn connection fails after key renegotiation because --auth-user-pass is passed with --auth-nocache. Status in network-manager-openvpn package in Ubuntu: Triaged Bug description: So I've been using OpenVPN through the network-manager-openvpn package integrated into the network manager GUI. I experienced an odd problem where consistently, during or after downloading (in this case, I tested by just downloading the kernel tarball from kernel.org repeatedly, which is around 90MB) Every single time, without fail, the openvpn client would fail and my connection would go dead. To reconnect, I would have to manually restart the network manager. Now, I played around with .conf files and the CLI openvpn client and noticed EXACTLY the same behavior happening. I eventually arrived to the conclusion that the flag or option "auth-nocache" would cause a connection reset after or during downloads and streaming. I then got to reading the openvpn man pages and I stumbled across this message (you can easily find it by going 'man openvpn | grep nocache') about the guaranteed failure of key renegotiation if auth-user-pass and auth-nocache were used together: " Further, using --daemon together with --auth-user-pass (entered on console) and --auth-nocache will fail as soon as key renego‐ tiation (and reauthentication) occurs." When I removed auth-user-pass from my .conf files, the problem went away. Then I wondered. Now what if...network-manager-openvpn was actually passing both flags to openvpn? Then I downloaded the source tarball and found that indeed, this exact thing is happening on a SINGLE line. See line 1380 of network-manager-openvpn-1.1.93/src/nm-openvpn-service.c "add_openvpn_arg (args, "--auth-nocache");" So I decided to comment out that single line. I then rebuilt the packages network-manager-openvpn and network-manager-openvpn-gnome using 'dpkg-buildpackage -us -uc -nc', installed them, and tested downloading the source kernel repeatedly to see if the connection would hold. It does! Literally commenting out ONE line fixed weeks worth of extreme annoyance repeatedly reconnecting to my vpn. This issue is rather annoying and needs to be fixed so openvpn doesn't keep cutting out. I've attached a patch for the source. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/1681295/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
