linux-cli
linux-cli copied to clipboard
Cannot connect on Fedora 33 (neither with GUI nor CLI)
I'm on Fedora 33 and I can't connect to ProtonVPN - neither with the GUI nor with the CLI. The GUI just gets stuck in the connection process and loads forever (but never succeeds or fails). The CLI also just gets stuck when running protonvpn-cli connect
and selecting a free server. When inspecting the logs I found the following:
protonvpn.log
:
2021-07-16 11:34:52,500 — ipv6_leak_protection.py — INFO — update_connection_status:219 — IPv6 status: {'pvpn-ipv6leak-protection': {<KillSwitchInterfaceTrackerEnum.EXISTS: 0>: False, <KillSwitchInterfaceTrackerEnum.IS_RUNNING: 1>: False}}
2021-07-16 11:34:52,662 — nm_client_mixin.py — INFO — __dynamic_callback:90 — Callback type: "add"
2021-07-16 11:34:52,663 — nm_client_mixin.py — ERROR — __dynamic_callback:124 — Exception: NM.Client.add_connection_finish() takes exactly 2 arguments (1 given)
Traceback (most recent call last):
File "/usr/lib/python3.9/site-packages/protonvpn_nm_lib/core/connection_backend/nm_client/nm_client_mixin.py", line 117, in __dynamic_callback
(callback_type_dict[callback_type]["finish_function"])(result)
TypeError: NM.Client.add_connection_finish() takes exactly 2 arguments (1 given)
2021-07-16 11:34:52,664 — utilities.py — INFO — ensure_internet_connection_is_available:21 — Checking for internet connectivity
2021-07-16 11:34:52,664 — utilities.py — INFO — ensure_internet_connection_is_available:23 — Skipping as killswitch is enabled
2021-07-16 11:34:52,665 — nm_client.py — INFO — connect:89 — Starting VPN connection
2021-07-16 11:34:52,665 — nm_client.py — INFO — __get_protonvpn_connection:172 — Getting VPN from "NetworkManagerConnectionTypeEnum.ALL" connections
2021-07-16 11:34:52,665 — nm_client.py — INFO — __get_protonvpn_connection:207 — VPN connection: <NM.RemoteConnection object at 0x7fad90071180 (NMRemoteConnection at 0x7fad88007010)>
2021-07-16 11:34:52,665 — nm_client_mixin.py — INFO — _start_connection_async:29 — Starting VPN connection
2021-07-16 11:34:52,703 — nm_client_mixin.py — INFO — __dynamic_callback:90 — Callback type: "start"
2021-07-16 11:34:52,704 — nm_client_mixin.py — ERROR — __dynamic_callback:124 — Exception: NM.Client.activate_connection_finish() takes exactly 2 arguments (1 given)
Traceback (most recent call last):
File "/usr/lib/python3.9/site-packages/protonvpn_nm_lib/core/connection_backend/nm_client/nm_client_mixin.py", line 117, in __dynamic_callback
(callback_type_dict[callback_type]["finish_function"])(result)
TypeError: NM.Client.activate_connection_finish() takes exactly 2 arguments (1 given)
2021-07-16 11:35:00,223 — settings_backend.py — INFO — get_backend:13 — Settings backend: <class 'protonvpn_nm_lib.core.user_settings.default_settings_backend.Settings'>
network_manager.service.log
:
nge: disconnected -> unmanaged (reason 'user-requested', sys-iface-state: 'managed')
2021-07-16 11:34:52.624763 <info> manager: (ipv6leakintrf0): new Dummy device (/org/freedesktop/NetworkManager/Devices/15)
2021-07-16 11:34:52.626383 <info> device (ipv6leakintrf0): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'external')
2021-07-16 11:34:52.628035 <info> audit: op="connection-add" uuid="0faeccc2-a050-4ef0-b793-fe0e669b0972" name="pvpn-ipv6leak-protection" pid=123635 uid=1000 result="success"
2021-07-16 11:34:52.628868 <info> device (ipv6leakintrf0): state change: unavailable -> disconnected (reason 'none', sys-iface-state: 'managed')
2021-07-16 11:34:52.629818 <info> policy: auto-activating connection 'pvpn-ipv6leak-protection' (0faeccc2-a050-4ef0-b793-fe0e669b0972)
2021-07-16 11:34:52.630347 <info> device (ipv6leakintrf0): Activation: starting connection 'pvpn-ipv6leak-protection' (0faeccc2-a050-4ef0-b793-fe0e669b0972)
2021-07-16 11:34:52.630483 <info> device (ipv6leakintrf0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
2021-07-16 11:34:52.630974 <info> device (ipv6leakintrf0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
2021-07-16 11:34:52.639098 <info> device (ipv6leakintrf0): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
2021-07-16 11:34:52.639504 <info> dhcp4 (ipv6leakintrf0): activation: beginning transaction (timeout in 45 seconds)
2021-07-16 11:34:52.641551 <info> device (ipv6leakintrf0): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'managed')
2021-07-16 11:34:52.659494 <info> audit: op="connection-add" uuid="b1068394-ce4b-49e4-86f1-873b243688af" name="ProtonVPN NL-FREE#1" pid=123550 uid=1000 result="success"
2021-07-16 11:34:52.663344 <info> device (ipv6leakintrf0): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'managed')
2021-07-16 11:34:52.663704 <info> device (ipv6leakintrf0): state change: secondaries -> activated (reason 'none', sys-iface-state: 'managed')
2021-07-16 11:34:52.665378 <info> policy: set 'pvpn-ipv6leak-protection' (ipv6leakintrf0) as default for IPv6 routing and DNS
2021-07-16 11:34:52.665409 <info> policy: set-hostname: current hostname was changed outside NetworkManager: 'localhost.localdomain'
2021-07-16 11:34:52.666369 <info> device (ipv6leakintrf0): Activation: successful, device activated.
2021-07-16 11:34:52.667446 <info> policy: set-hostname: current hostname was changed outside NetworkManager: 'localhost.localdomain'
2021-07-16 11:34:52.702591 <info> audit: op="connection-activate" uuid="b1068394-ce4b-49e4-86f1-873b243688af" name="ProtonVPN NL-FREE#1" pid=123550 uid=1000 result="success"
2021-07-16 11:34:52.709941 <info> vpn-connection[0x55bff3e7a2b0,b1068394-ce4b-49e4-86f1-873b243688af,"ProtonVPN NL-FREE#1",0]: Started the VPN service, PID 123748
2021-07-16 11:34:52.722534 <info> vpn-connection[0x55bff3e7a2b0,b1068394-ce4b-49e4-86f1-873b243688af,"ProtonVPN NL-FREE#1",0]: Saw the service appear; activating connection
2021-07-16 11:34:52.731906 <error> vpn-connection[0x55bff3e7a2b0,b1068394-ce4b-49e4-86f1-873b243688af,"ProtonVPN NL-FREE#1",0]: Failed to request VPN secrets #3: No agents were available for this request.
2021-07-16 11:34:52.737381 <info> vpn-connection[0x55bff3e7a2b0,b1068394-ce4b-49e4-86f1-873b243688af,"ProtonVPN NL-FREE#1",0]: VPN plugin: state changed: stopped (6)
2021-07-16 11:35:37.973483 <warn> dhcp4 (ipv6leakintrf0): request timed out
2021-07-16 11:35:37.973507 <info> dhcp4 (ipv6leakintrf0): state changed unknown -> timeout
Nothing exciting in the other log files.
Any help would be greatly appreciated because I would love to actually get ProtonVPN Premium if it would only work on my machine!
Hey @markf94
Thanks for the logs. From what I've seen, this seems to be the issue:
2021-07-16 11:34:52.731906 <error> vpn-connection[0x55bff3e7a2b0,b1068394-ce4b-49e4-86f1-873b243688af,"ProtonVPN NL-FREE#1",0]: Failed to request VPN secrets #3: No agents were available for this request.
I did not get you DE btw.
Hi @calexandru2018 - thanks for getting back to me! What do you mean with DE? So it failed to request VPN secrets - any suggestion how to fix that? I did authenticate and used my ProtonVPN password & username
@markf94 DE stands for Desktop Environment. Have you tried running protonvpn-cli c -f
?
oh sorry! I'm on Fedora 33 (Workstation Edition) with i3
. Just tried running protonvpn-cli c -f
but it again got stuck in a seemingly endless loop and I had to kill the process after a while because I couldn't connect to the internet....
I have the exact same issue with Arch Linux and dwm.
I had a similar issue before regarding No agents were available for this request.
for other VPNs and Docker things. Similarly, my protonvpn also experienced hangs after attempting to connect via the CLI or GUI. Last night, journalctl had some logs (for the life of me I can not find again) that noted some error messages about failing to establish some VPN connection. Googling it indicated the issue is because NetworkManager didn't manage the device.
I was running Ubuntu 20.04 LTS headless until I came across the nasty requirement of the protonvpn stuff needing a GUI. As such, I needed to install the full GUI and such which still didn't fix my issue with NetworkManager not managing the devices. This morning I changed the network management over to NetworkManager by modifying /etc/netplan/00-installer-config.yaml
to the following:
# This is the network config written by 'subiquity'
network:
version: 2
renderer: NetworkManager
And then restarting the system. From there, NetworkManager picked up the devices and protonvpn and protonvpn-cli were both able to successfully establish connections. When doing a headless installation, NetworkManager isn't typically the entity managing interfaces for Ubuntu (maybe systemd-networkd
?). For a default Ubuntu 20+ desktop installation with GNOME as the desktop environment, I would presume none of these issues would be occurring.
I think protonvpn{-cli} rely on more than just some python packages and require
- Access to some X11 or similar (so full GUI or something)
- NetworkManager managing the interfaces
- Access to
nm-applet
(and thus NetworkManager running with GNOME or something else if you can figure that out)
If this is the case, the Linux docs absolutely need to be updated to note these things, as not everyone runs GNOME with NetworkManager. For example, @enes4949 above runs just a window manager (dwm) and likely would have similar issues. @markf94 let me know if you were able to get your setup running by starting NetworkManager and having nm-applet
running. nm-applet
not running is the most common reason for your No agents were available for this request
error.
@haithcockce YOU ARE MY HERO!!! Running nm-applet
did indeed solve the problem. I can't believe that the fix was that simple but this should really be updated in the docs since I had no clue that this was needed!
I think protonvpn cli requires X11, i'm on rasbian w/o DE and seeing error like this protonvpn_nm_lib.exceptions.KeyringError: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
when will it work with a headless linux or have a webhook for auth? It's a no go right now since it requires a display
When running nm-applet, it show "failed because there were no valid VPN secret".
@markf94 I'm on Fedora 33 i3 too, Fedora provided a protonvpn package (named protonvpn-cli, v2.2.6), it works well. You'll need to uninstall protonvpn-stable-release-1.0.1-1.noarch
to install this.
When running nm-applet, it show "failed because there were no valid VPN secret".
@markf94 I'm on Fedora 33 i3 too, Fedora provided a protonvpn package (named protonvpn-cli, v2.2.6), it works well. You'll need to uninstall
protonvpn-stable-release-1.0.1-1.noarch
to install this.
This can be a few different things.
Not sure if you mean that you got protonvpn to work with the fedora provided package or not. In case not, you may need the right package (which I don't know how it would interact with i3). Network manager stores passwords for some things in the gnome keyring so make sure to have the network manager OpenVPN gnome package installed. Doing this from mobile while on the run so can't quite remember the name of the package.
@haithcockce Thanks! I got it to work with the fedora provided package.
@haithcockce YOU ARE MY HERO!!! Running
nm-applet
did indeed solve the problem. I can't believe that the fix was that simple but this should really be updated in the docs since I had no clue that this was needed!
It worked but is asking for IKEv2 password for connecting every time. Is it so for everyone?
@abinlatheef nope that's not the case for me
Just found out that my problem is that I switched to bspwm from gnome. Apparently, remembering password works with gnome-keyring, kwallet, etc. only. Hope protonvpn team fixes the issue.
Just found out that my problem is that I switched to bspwm from gnome. Apparently, remembering password works with gnome-keyring, kwallet, etc. only. Hope protonvpn team fixes the issue.
Same here, I moved from kde to i3 and protonvpn-cli kept throwing an error related to kwallet so I kept looking around OS to delete it completely. Once I did it still didn't work until I realized protonvpn-cli requires some keyring backend.
Source: https://github.com/ProtonVPN/linux-cli/issues/64#issuecomment-1058224569
Luckily they are working on a new client that will not require these... The solution for now is to install either gnome-keyring or kwallet.