After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 782584 - Openvpn connection fails after key renegotiation because --auth-user-pass is passed with --auth-nocache.
Openvpn connection fails after key renegotiation because --auth-user-pass is ...
Status: RESOLVED OBSOLETE
Product: NetworkManager
Classification: Platform
Component: VPN: openvpn
1.2.x
Other Linux
: Normal critical
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
https://bugs.launchpad.net/ubuntu/+so...
Depends on:
Blocks:
 
 
Reported: 2017-05-13 05:37 UTC by electricitylikesme
Modified: 2020-11-12 14:25 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch which fixes the problem. (352 bytes, patch)
2017-05-13 05:37 UTC, electricitylikesme
none Details | Review

Description electricitylikesme 2017-05-13 05:37:50 UTC
Created attachment 351769 [details] [review]
Patch which fixes the problem.

Cross-posting from the Ubuntu tracker: https://bugs.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/1681295

When establishing a network-connection, the plugin passes --auth-user-pass, --daemon and --auth-nocache together.

However, according to the OpenVPN man pages, this is an error:

" 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. "

And this is the observed behavior when using a VPN. Importantly - it leads to subtle VPN problems - namely, the connection will disconnect, but NetworkManager won't detect it or notify the user, and while new connections will fail.

The attached patch (from the original thread) fixes the problem completely, and AFAIK needs to be backported to all versions of the plugin.

I can confirm that it fixes the issue entirely.
Comment 1 Thomas Haller 2017-05-13 10:46:25 UTC
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
Comment 2 André Klapper 2020-11-12 14:25:52 UTC
bugzilla.gnome.org is being shut down in favor of a GitLab instance. 
We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time.

If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/

Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).