Created attachment 1215297 [details] Log snippet in the time of the vpn connection activation Description of problem: Activation of an VPN Connection in NetworkManager does not work and the Switch in the Network Config GUI jumps instantly back to off. Version-Release number of selected component (if applicable): NetworkManager-bluetooth-1.4.2-1.fc25.x86_64 NetworkManager-openvpn-1.2.6-1.fc25.x86_64 NetworkManager-vpnc-gnome-1.2.4-1.fc25.x86_64 NetworkManager-wifi-1.4.2-1.fc25.x86_64 NetworkManager-pptp-gnome-1.2.4-1.fc25.x86_64 NetworkManager-pptp-1.2.4-1.fc25.x86_64 NetworkManager-1.4.2-1.fc25.x86_64 NetworkManager-vpnc-1.2.4-1.fc25.x86_64 NetworkManager-glib-1.4.2-1.fc25.x86_64 NetworkManager-openvpn-gnome-1.2.6-1.fc25.x86_64 NetworkManager-team-1.4.2-1.fc25.x86_64 NetworkManager-libnm-1.4.2-1.fc25.x86_64 NetworkManager-adsl-1.4.2-1.fc25.x86_64 NetworkManager-openconnect-1.2.3-0.20160606git5009f9.fc25.x86_64 NetworkManager-wwan-1.4.2-1.fc25.x86_64 NetworkManager-config-connectivity-fedora-1.4.2-1.fc25.x86_64 How reproducible: Everty time Steps to Reproduce: 1. Open Network Manager Settings in Gnome 2. Activate OpenVPN Connection Actual results: VPN Connection is not established Expected results: Established VPN Connection Additional info: Log shows errors <error> [1477745516.1511] vpn-connection[0x55d6c53044d0,591e11aa-057b-4f9a-b65a-d6b5065b1f37,"myvpn",0]: Failed to request VPN secrets #3: No agents were available for this request.
I am getting the same error and no vpn connection - please take a look at this problem and update - thanks #cat /etc/redhat-release Fedora release 25 (Twenty Five) #uname -a Linux dellin 4.10.6-200.fc25.x86_64 #1 SMP Mon Mar 27 14:06:23 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux #rpm -qa|grep -i vpn openvpn-2.4.1-2.fc25.x86_64 NetworkManager-openvpn-gnome-1.2.8-2.fc25.x86_64 NetworkManager-openvpn-1.2.8-2.fc25.x86_64 from journalctl... NetworkManager[1259]: <error> [1490984571.5125] vpn-connection[0x555822e546b0,8748b6a8-3b13-4af2-be1a-6a13430505fe,"VPN",0]: Failed to request VPN secrets #3: No agents were available for this request. please let me know if you need any further information
just looking at other NetworkManager-openvpn bugs, it seems that lkundrak never actions any of them :( can these please be assigned to someone else? thanks
When the VPN password is not stored in the connection, NM needs an external entity ("secret agent") to provide it. The agent can be for example the Gnome Shell, Networkmanager-applet or nmcli. In the journalctl output there is: No agents were available for this request which means that no agent is registered to provide secrets to NM. Which desktop environment do you use? Does the VPN connection work if you start it with: nmcli --ask connection up <VPN-connection-name> ?
I am having the same issue. Using "nmcli --ask connection up <vpn>" works - even when run as a script. However, when the script is called by NetworkManager, I get the error as described above. I do not have GNOME installed on this server.
(In reply to Ted Brunell from comment #4) > I am having the same issue. Using "nmcli --ask connection up <vpn>" works - > even when run as a script. So, does it ask you a password? > However, when the script is called by > NetworkManager, I get the error as described above. What do you mean that the script is called by NM, is it a dispatcher script?
(In reply to Beniamino Galvani from comment #5) > (In reply to Ted Brunell from comment #4) > > I am having the same issue. Using "nmcli --ask connection up <vpn>" works - > > even when run as a script. > > So, does it ask you a password? Yes - it asks for a password when I run the dispatcher script directly from the terminal. > > > However, when the script is called by > > NetworkManager, I get the error as described above. > > What do you mean that the script is called by NM, is it a dispatcher script? Yes.
(In reply to Ted Brunell from comment #6) > Yes - it asks for a password when I run the dispatcher script directly from > the terminal. > > > > > However, when the script is called by > > > NetworkManager, I get the error as described above. > > > > What do you mean that the script is called by NM, is it a dispatcher script? > > Yes. As any other script that is run by a system daemon, dispatchers scripts can't interact with the user. Instead, you should remove the '--ask' option from the script and start a 'nmcli agent' instance on a terminal; this will register a secret agent that receives password requests from NM when needed. Also, if you want to start a VPN when a connection is activated, you don't need a dispatcher script but you can set the VPN as 'secondary' connection: nmcli connection modify my-ethernet-con connection.secondaries my-vpn-con
I am running Fedora26 and initially got the same error when trying to get my L2TP VPN running. I got around all errors and finally got it running by using the Gnome Network GUI and setting. I created a new L2TP VPN connection with the following settings: Gateway: <Hostname of my VPN server> User Name: <VPN User Name> <click on IPsec Settings> Gateway ID: <LEAVE BLANK> Pre-shared key: <Pre-shared key I created in the VPN config on server> <click OK> <click PPP Settings> <Uncheck all Authentication methods except CHAP> <click OK> Once the PPP Authentication Methods were unchecked the VPN connected and all errors went away. Cheers! Mike
The same issue happens for me when using the setting "Automatically connect to VPN when using this connection" in nm-connection-editor for my wifi. OS: Fedora 26, x86_64 NetworkManager packages installed: NetworkManager-ssh-gnome-1.2.6-1.fc26.x86_64 NetworkManager-vpnc-1.2.4-2.fc26.x86_64 NetworkManager-openvpn-1.2.10-1.fc26.x86_64 NetworkManager-pptp-gnome-1.2.4-2.fc26.x86_64 NetworkManager-ssh-1.2.6-1.fc26.x86_64 NetworkManager-adsl-1.8.2-1.fc26.x86_64 NetworkManager-tui-1.8.2-1.fc26.x86_64 NetworkManager-wwan-1.8.2-1.fc26.x86_64 NetworkManager-wifi-1.8.2-1.fc26.x86_64 NetworkManager-openconnect-gnome-1.2.4-4.fc26.x86_64 NetworkManager-openconnect-1.2.4-4.fc26.x86_64 NetworkManager-config-connectivity-fedora-1.8.2-1.fc26.noarch NetworkManager-glib-1.8.2-1.fc26.x86_64 NetworkManager-pptp-1.2.4-2.fc26.x86_64 NetworkManager-team-1.8.2-1.fc26.x86_64 NetworkManager-bluetooth-1.8.2-1.fc26.x86_64 NetworkManager-libnm-1.8.2-1.fc26.x86_64 NetworkManager-vpnc-gnome-1.2.4-2.fc26.x86_64 NetworkManager-1.8.2-1.fc26.x86_64 NetworkManager-openvpn-gnome-1.2.10-1.fc26.x86_64 Steps to reproduce: 1. Import client.ovpn file to NetworkManager using certificates and user/password 2. Open nm-connection-editor 3. Select your WiFi network and click "Edit" 4. Navigate to the first tab "General" 5. Tick the checkbox next to "Automatically connect to VPN when using this connection" 6. Select the VPN connection in the dropdown 7. Click "Save", and then "Close" 8. Turn off wifi 9. Open a terminal and run "sudo journalctl -f" 10. Enable WiFi and let it autoconnect 11. Watch the journal repeat the following message three times before givimg up: "okt 10 22:54:10 free nm-dispatcher[9271]: req:3 'pre-up' [wlp3s0]: new request (1 scripts) okt 10 22:54:10 free dhclient[9346]: bound to 192.168.1.17 -- renewal in 98452 seconds. okt 10 22:54:10 free NetworkManager[1057]: <info> [1507668850.6093] device (wlp3s0): state change: ip-check -> secondaries (reason 'none', internal state 'managed') okt 10 22:54:10 free NetworkManager[1057]: <info> [1507668850.6096] policy: set 'WIFI-SSID' (wlp3s0) as default for IPv4 routing and DNS okt 10 22:54:10 free dnsmasq[1694]: reading /etc/resolv.conf okt 10 22:54:10 free dnsmasq[1694]: using nameserver 192.168.1.1#53 okt 10 22:54:10 free NetworkManager[1057]: <info> [1507668850.6248] vpn-connection[0x560b588796a0,2584bfa6-6118-40b2-bda4-1192ba91e5cb,"Integrity",0]: Started the VPN service, PID 9367 okt 10 22:54:10 free NetworkManager[1057]: <info> [1507668850.6341] vpn-connection[0x560b588796a0,2584bfa6-6118-40b2-bda4-1192ba91e5cb,"Integrity",0]: Saw the service appear; activating connection okt 10 22:54:10 free gnome-shell[2789]: Invalid connection type: vpn okt 10 22:54:10 free gnome-shell[2789]: Invalid connection type: vpn okt 10 22:54:10 free NetworkManager[1057]: <error> [1507668850.6761] vpn-connection[0x560b588796a0,2584bfa6-6118-40b2-bda4-1192ba91e5cb,"Integrity",0]: Failed to request VPN secrets #3: No agents were available for this request. okt 10 22:54:10 free NetworkManager[1057]: <info> [1507668850.6763] device (wlp3s0): state change: secondaries -> failed (reason 'secondary-connection-failed', internal state 'managed') okt 10 22:54:10 free NetworkManager[1057]: <info> [1507668850.6766] manager: NetworkManager state is now CONNECTED_LOCAL okt 10 22:54:10 free NetworkManager[1057]: <warn> [1507668850.6774] device (wlp3s0): Activation: failed for connection 'WIFI-SSID' okt 10 22:54:10 free NetworkManager[1057]: <info> [1507668850.6870] vpn-connection[0x560b588796a0,2584bfa6-6118-40b2-bda4-1192ba91e5cb,"Integrity",0]: VPN service disappeared " 12. Manually connect to WiFi again, and the connection is successfully started.
The same issue is present in Fedora 26.
(In reply to Beniamino Galvani from comment #7) > (In reply to Ted Brunell from comment #6) > > As any other script that is run by a system daemon, dispatchers scripts > can't interact with the user. Instead, you should remove the '--ask' option > from the script and start a 'nmcli agent' instance on a terminal; this will > register a secret agent that receives password requests from NM when needed. > > Also, if you want to start a VPN when a connection is activated, you don't > need a dispatcher script but you can set the VPN as 'secondary' connection: > > nmcli connection modify my-ethernet-con connection.secondaries my-vpn-con Using the above command in combination with: nmcli connection modify <SSID> autoconnect yes The outcome of this is the behaviour as I explained in #9 with the exact same log messages
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. 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 '25'. 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 25 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.
This issue is still present in Fedora 26. Please change "Version".
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 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.
Reopening as this still occurs with Fedora 28. But only if the VPN connection is established as the "secondary" of a parent connection. Connecting through nmcli directly with VPN secrets configured in the connection works without problems. No need for any --ask options or entering passwords.
So which is actually the needed agent? I have two F28 machine. One is OK. But I don't know how to figure out the agent program.
(In reply to Robin Lee from comment #16) > So which is actually the needed agent? > I have two F28 machine. One is OK. But I don't know how to figure out the > agent program. for example: - nm-applet - gnome-shell - plasma-nm - `nmcli agent` (or `nmcli --ask` for various subcommands) - nmtui
Issue persists in F29, GNOME Attempted "nmcli --ask connection up <NAME>" prompted for password, after entry I received a notification that it failed. Log shows the following error: "Message recipient disconnected from message bus without replying" Within the NetworkManager GUI even when selecting remember password, information is not saved. Looking into manually editing the VPN files at "/etc/NetworkManager/system-connections" now
(In reply to Chad Penny from comment #18) > Issue persists in F29, GNOME > > Attempted "nmcli --ask connection up <NAME>" > prompted for password, after entry I received a notification that it failed. > Log shows the following error: > "Message recipient disconnected from message bus without replying" > > Within the NetworkManager GUI even when selecting remember password, > information is not saved. > > Looking into manually editing the VPN files at > "/etc/NetworkManager/system-connections" now Note to above, reattempted "nmcli --ask connection up <NAME>" with a different VPN connection, and after entering password I was able to connect, after disconnecting, password was shown as saved in GUI (as I had save for this user only selected) and toggle selector for vpn can now activate the VPN properly.
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.