Description of problem: NetworkManager appears unable to connect to an OpenVPN. The same VPN works with Fedora 26. Version-Release number of selected component (if applicable): NetworkManager-openvpn-1.8.4-1.fc28.x86_64 NetworkManager-libnm-1.10.8-1.fc28.x86_64 NetworkManager-1.10.8-1.fc28.x86_64 openvpn-2.4.6-1.fc28.x86_64 dbus-1.12.8-1.fc28.x86_64 glib2-2.56.1-3.fc28.x86_64 glibc-2.27-15.fc28.x86_64 libgcc-8.1.1-1.fc28.x86_64 How reproducible: Always Steps to Reproduce: 1. Set up VPN using saved configuration imported into configured networks. 2. Request activation of connection. 3. Provide user password. Actual results: Connection fails / disconnects immediately. Expected results: Successful connection to VPN. Additional info: Connection attempts with nmcli yield "Error: Connection activation failed: No valid secrets". /var/log/messages reports "final secrets request failed to provide sufficient secrets". I've tried rebooting to rule out previously reported issues due to recent installation of NM / VPN components.
(In reply to Matthew Woehlke from comment #0) > Additional info: > Connection attempts with nmcli yield "Error: Connection activation failed: > No valid secrets". /var/log/messages reports "final secrets request failed > to provide sufficient secrets". This means that an external agent couldn't ask the password to user or failed to provide it to NM. Which GUI component are you using to connect and enter the password? If logs don't contain sensitive information, can you please run 'nmcli general logging level TRACE', try to connect and then attach the output of "journalctl -u NetworkManager --since '2 minutes ago'" ? Thanks.
> Which GUI component are you using to connect and enter the password? Whatever is set up by default on the KDE spin. However, I get the same error *using nmcli --ask*, which is not using a GUI at all to ask for the password. Whatever is wrong, it isn't specific to what's asking for the password. > can you please run 'nmcli general logging level TRACE', try to connect and then attach the output of "journalctl -u NetworkManager --since '2 minutes ago'" ? Will attach shortly. I redacted the VPN name and UUID and lopped off some WiFi-related stuff (it followed the last message in what's in the attachment with over a half second gap).
Created attachment 1453527 [details] TRACE log from connection attempt
To be clear, I *was* asked for a password. Here's my console output from the attempt: root# nmcli --ask connection up Kitware A password is required to connect to '<redacted>'. Password (vpn.secrets.password): Error: Connection activation failed: No valid secrets Exit 4 The password is not echoed, but I did type it. (Note: I am doing this as root because I am currently working over SSH and otherwise lack the necessary permissions to manage network connections. When physically at the machine, I use my user account, with the same results.)
Thanks. It looks like the openvpn plugin is expecting some other secrets. Can you also paste the output of: nmcli -f vpn.data connection show Kitware ?
ta = /home/matthew/.local/share/networkmanagement/certificates/<redacted>-tls.key, cert = /tmp/<redacted>/<redacted>.p12, key = /tmp/<redacted>/<redacted>.p12, ca = /tmp/<redacted>/<redacted>.p12, username = <redacted>, port = 1194, cert-pass-flags = 4, cipher = AES-256-CBC, remote = <redacted>, password-flags = 1, auth = SHA1, connection-type = password-tls, ta-dir = 1 (Line breaks added for readability.) All of the redactions except username and remote are the same string. Hmm... are all those fields pointing to /tmp supposed to be doing that? (Regardless, that file *does* exist.) I don't know what other secrets it could be expecting; I'm using the same files that I used to set up this same VPN connection (successfully) on F26.
I see two issues: 1. if nmcli is run as root, it cannot use the plasma applet to ask a password and it uses the built-in secret-agent. 2. the nmcli agent only asks the cert-key password when cert-pass-flags is 'agent-owned' or 'not-saved' (1 or 2), but in your connection it is set to not-required (4). Do you remember if you had to enter the private-key password each time of Fedora 26? IOW, is the .p12 key password-protected? I would proceed in the following way: - first, please try to run the nmcli command as non-root user so that the plasma applet secret-agent is used instead of nmcli to ask a password: $ nmcli connection up Kitware and capture logs as above. - let's also try to change the cert-pass-flags to 'always-ask' and connect again using nmcli as root: # nmcli connection mod Kitware +vpn.data cert-pass-flags=2 # nmcli --ask connection up Kitware
> 1. if nmcli is run as root, it cannot use the plasma applet to ask a > password and it uses the built-in secret-agent. Sure, but... shouldn't that still work? Also, I get the same results whether running as root or not. > Do you remember if you had to enter the private-key password each time > of Fedora 26? IOW, is the .p12 key password-protected? It is not; "password is not required" is correct. (I talked to our sysadmin; they mentioned a known problem on Ubuntu that the connection fails unless *something* is provided as the certificate password. I'm not convinced that's what's happening here, and won't be able to tell until later, when I have physical access to the machine again, but even if that's the case, it's still a bug.)
> let's also try to change the cert-pass-flags to 'always-ask' and > connect again using nmcli as root: Arf... okay, so I tried doing that through the UI, and it still didn't ask. After doing it via nmcli, per your instructions, *now* I can connect, even though I'm putting in garbage for the cert password. So I guess that *is* the bug; the VPN stack is refusing to proceed without a cert password despite being told it doesn't need one. Hmm... and thinking about it again, I *think* on F26 I have the VPN cert password set up as "remember for all users (unencrypted)", but the password is also empty.
> the VPN stack is refusing to proceed without a cert password despite being told it doesn't need one. Yup. Worked with plasma, also, though I had to enter junk for the cert password (providing an empty string didn't seem to work). Note: since I'm using garbage, I have the cert password set to 'remember for all users (unencrypted)'.
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.