MIssed that one… I do not even get a LINK UP… Need to fix something i did wrong…
Edit the qtunnel-connect file and search for
su - -c 'notify-send "$(hostname): TEST LINK IS UP." --icon=network-idle' user
to
echo \'"sleep 2; notify-send \"$hostname: LINK IS UP.\"" --icon=network-idle\' | xargs su - user -c &
And
su - -c 'notify-send "$(hostname): LINK IS DOWN !" --icon=dialog-error' user
to
echo \'"sleep 2; notify-send \"$hostname: LINK IS DOWN.\"" --icon=dialog-error\' | xargs su - user -c &
I made it simple for myself and installed the official protonvpn-cli in sys-net. It can run with nice features like secure core, fastest vpn server selection and permanent kill switch. The standard installation for Fedora from ProtonVPN website worked like a charm.
My goal is to permanently use the VPN connection on sys-net so I need to figure out the best way to start this on startup of the VM sys-net.
I followed the guide provided by 51lieal and it worked perfectly but I’m curious when you set up protonvpn-cli in sys-net, did you not get connection issues in any of the other vms? Did you have to do anything?
For me, I had connection issues after setting up protonvpn-cli but it worked after using the openvpn method
The GUI and CLI both work for me. You need to add network manager in the Services tab and it has to be a persistent VM like standalone. The most important benefit is having the permanent killswitch.
1 Like
I tried that, but still not working for me
I have the following messaging error
-------------------------------------------------
----------- Initialized protonvpn-cli -----------
-------------------------------------------------
2021-10-28 18:34:40,251 — cli.py — INFO — __init__:32 — ProtonVPN CLI v3.10.1 (protonvpn-nm-lib v3.6.0; proton-client v0.7.1)
2021-10-28 18:34:40,253 — cli.py — INFO — __init__:64 — CLI command: Namespace(command='login', get_logs=False, help=False, version=False)
2021-10-28 18:34:42,859 — cli_wrapper.py — INFO — login:68 — Credentials provided, attempting to login
2021-10-28 18:34:42,862 — cli_wrapper.py — ERROR — login:117 — org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.NetworkManager was not provided by any .service files
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/dbus/bus.py", line 175, in activate_name_owner
return self.get_name_owner(bus_name)
File "/usr/lib/python3/dist-packages/dbus/bus.py", line 361, in get_name_owner
's', (bus_name,), **keywords)
File "/usr/lib/python3/dist-packages/dbus/connection.py", line 651, in call_blocking
message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NameHasNoOwner: Could not get owner of name 'org.freedesktop.NetworkManager': no such name
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/protonvpn_cli/cli_wrapper.py", line 73, in login
self.protonvpn.login(username, password)
File "/usr/lib/python3/dist-packages/protonvpn_nm_lib/api.py", line 30, in login
self._utils.ensure_connectivity()
File "/usr/lib/python3/dist-packages/protonvpn_nm_lib/core/utilities.py", line 16, in ensure_connectivity
utils.ensure_internet_connection_is_available()
File "/usr/lib/python3/dist-packages/protonvpn_nm_lib/core/utilities.py", line 22, in ensure_internet_connection_is_available
if ExecutionEnvironment().killswitch != KillswitchStatusEnum.DISABLED:
File "/usr/lib/python3/dist-packages/protonvpn_nm_lib/core/environment.py", line 66, in killswitch
self.__killswitch = KillSwitch()
File "/usr/lib/python3/dist-packages/protonvpn_nm_lib/core/killswitch/killswitch.py", line 61, in __init__
self.get_status_connectivity_check()
File "/usr/lib/python3/dist-packages/protonvpn_nm_lib/core/killswitch/killswitch.py", line 597, in get_status_connectivity_check
nm_props = self.nm_wrapper.get_network_manager_properties()
File "/usr/lib/python3/dist-packages/protonvpn_nm_lib/core/dbus/dbus_network_manager_wrapper.py", line 461, in get_network_manager_properties
self.get_network_manager_proxy_object()
File "/usr/lib/python3/dist-packages/protonvpn_nm_lib/core/dbus/dbus_network_manager_wrapper.py", line 510, in get_network_manager_proxy_object
return self.__get_proxy_object(SystemBusNMObjectPathEnum.NETWORK_MANAGER.value)
File "/usr/lib/python3/dist-packages/protonvpn_nm_lib/core/dbus/dbus_network_manager_wrapper.py", line 536, in __get_proxy_object
path_to_object
File "/usr/lib/python3/dist-packages/protonvpn_nm_lib/core/dbus/dbus_wrapper.py", line 60, in get_proxy_object
bus_name, object_path
File "/usr/lib/python3/dist-packages/dbus/bus.py", line 241, in get_object
follow_name_owner_changes=follow_name_owner_changes)
File "/usr/lib/python3/dist-packages/dbus/proxies.py", line 248, in __init__
self._named_service = conn.activate_name_owner(bus_name)
File "/usr/lib/python3/dist-packages/dbus/bus.py", line 180, in activate_name_owner
self.start_service_by_name(bus_name)
File "/usr/lib/python3/dist-packages/dbus/bus.py", line 278, in start_service_by_name
'su', (bus_name, flags)))
File "/usr/lib/python3/dist-packages/dbus/connection.py", line 651, in call_blocking
message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.NetworkManager was not provided by any .service files
2021-10-28 18:35:05,611 — cli.py — INFO — __init__:27 —
Try installing it in a template. I used debian 10.
-
Download the protonvpn for debian
https://protonvpn.com/download/protonvpn-stable-release_1.0.1-1_all.deb -
Create minimal vpn template and install protonvpn
a. Open dom0 terminal and run
qvm-run --pass-io -u root <your vpn template> xterm
b. From xterm run:
apt install qubes-core-agent-nautilus qubes-core-agent-network-manager qubes-core-agent-networking qubes-core-agent-passwordless-root
c. Copy protonvpn-stable-release_1.0.1-1_all.deb to the minimal template
d. Install the protonvpn repo from /home/user/QubesIncoming/
dpkg -i protonvpn-stable-release_1.0.1-1_all.deb
e. Update the apt-get package list
apt update
f. Install the ProtonVPN Linux app
apt install protonvpn
g. Install the system tray icon
apt install gnome-shell-extension-appindicator gir1.2-appindicator3-0.1
h. Shut down template
2 Likes
Thanks for the info !
So I tried everything with Debian 10 as you explained, step by step, but I’m still having the same error.
I guess if you’ve eliminated the template, appvm and maybe persistence as the problem, maybe there’s something with sys-firewall or sys-net. Did you customize them?
No that’s the default configuration
I’m now on QubesOS 4.1 rc1, with Debian 11, and still have the same error and can’t make it work
ProtonVPN now offers Wireguard connections. Setting up a Wireguard VPN is easier and much less crufty than dealing with OpenVPN, and it is said that the ciphers are stronger too. There are probably instructions out there for using Wireguard with Proton on Linux, so follow those.
Also, just a heads up that Proton AG (which runs ProtonMail and ProtonVPN) isn’t exactly the darling of the privacy world right now:
2 Likes
I don’t know man. I would have thought using a minimal is a lowest common denominator and rules a lot of stuff out. A few have it working so it doesn’t make sense to me.
Who will be the first with data centers in space? No heat problem either. I don’t see wg support on their website yet.
1 Like
I’m unfamiliar with this turn of phrase in the context of this conversation–please elaborate.
Have you considered entering ‘protonvpn wireguard’ into a search engine of your choice?
Also see:
1 Like
If you’re concerned about dishonest providers, marketing scams, and legal jurisdiction, a data center in space has no jurisdiction.
I’m using it. It’s not available for linux through the app.
1 Like
The issues with Proton seem to be deeper (see the second link)
You’re correct here; I spoke too soon. Linux support should be here soon though:
Who will be the first with data centers in space?
data center in space has no jurisdiction
Article VIII of the 1967 Outer Space Treaty:
A State Party to the Treaty on whose registry an object launched into outer space is carried shall retain jurisdiction and control over such object, and over any personnel thereof, while in outer space or on a celestial body.
However, with private entities this might become more difficult.
What a rabbit hole! Thanks @joe.blough 
Big news 
Since it’s out, after almost one year of trying everything and waiting the release of new version fixing it, this day has come, I am now able to use the official protonvpn version, and remplace the community protonvpn inside QubesOS and use it as an intermediate Qubes.
Exemple : sys-net → sys-firewall → sys-VPN → debian-11-work
What I am using :
Qubes OS : 4.1 lastest version
Debian version : 11
Officiel protonvpn gui version : ProtonVPN: v1.7.0 (library: v3.8.0 / api-client: v0.7.1)
Officiel protonvpn cli version : ProtonVPN CLI v3.11.1 (protonvpn-nm-lib v3.8.0; proton-client v0.7.1)
Step 1 :
Create a new and clean Qubes with debian 11 template
Very important → 
In the configuration of that new Qubes, go in services and enable network-manager
Step 2 :
In command line
In any Qubes terminal with internet :
wget https://protonvpn.com/download/protonvpn-stable-release_1.0.1-1_all.deb
Move the file to the debian-11 template
In debian-11 template
sudo apt-get install ./protonvpn-stable-release_1.0.1-1_all.deb -y
sudo apt-get update
sudo apt-get install protonvpn-cli protonvpn -y
Step 3 :
Now start the new Qube you created with debian-11 template
You can use the graphical version for exemple, Log in and enjoy
Or use protonvpn-cli login
Community version
Secure-core 
Netshield 
Do not use root
KillSwitch not working well
Command line
Everything is working perfectly fine with the official version:
Do not use root
Graphical interface
Command line
Secure-core
KillSwitch
Netshield
More info if you need :
1 Like
That’s old buddy. That’s where I got the info I posted earlier. I guess I should have thought to post those links.
Trying the Proton official method described above.
Have created a branch template from Debian-11 template. We’ll call it protonvpn-template.
Performed first step: ‘wget https://protonvpn.com/download/protonvpn-stable-release_1.0.1-1_all.deb’
I noticed my terminal stated ‘HTTP request sent’ instead of ‘HTTPS request sent’- is that typical? Network pathway was: sys-net > sys-firewall > clearnet-appvm. No Tor or other VPN involved in this process.
Moved to my protonvpn-template. Success.
In protonvpn-template things not as expected. See below:
Action:
‘sudo apt-get install ./protonvpn-stable-release_1.0.1-1_all.deb -y’
Result:
‘Reading package lists… Done
E: unsupported file ./protonvpn-stable-release_1.0.1-1_all.deb given on commandline’.
Any thoughts?
Follow up: Opened up file manager in protonvpn-template and dragged the file with GUI into it’s associated protonvpn-template after ‘sudo apt-get install’. The whole thing in terminal appeared as 'sudo apt-get install ‘/home/user/QubesIncoming/protonvpn-stable-release_1.0.1-1_all.deb’.
Result: [mostly omitted because it appears to be what you’d expect?]
BUT AT THE END
‘N: Download is performed unsandboxed as root as file ‘[above referenced home directory location]’ couldnt be accessed by user ‘_apt’/ - pkgAquire: :Run (13: Permission denied)’
I take this to mean the permissions of the downloaded file are not such that I can run them after sending from one vm to another. Possibly because I downloaded the vpn stable release in step 1 with ‘sudo wget’ instead of ‘wget’. Maybe this puts some sort of lock on the file download? Am deleting all newly created vms and templates and starting over now.
After deleting all created vms and repeating this process, the cli and gui versions of protonvpn now do appear in my protonvpn qube. I cannot determine if it’s because if reinstalled in fresh qubes with ‘wget’ instead of ‘sudo wget’, or simply because i restarted qubes between loading up appvm qube this time around. I am able to log in with my proton credentials (it appears to recognize my status as a free user, but maybe that is just the default presentation when downloaded and it hasnt acknowledged my credentials at all). In any case- CANNOT CONNECT.
Initially all I had was a failed to connect notification in the protonvpn GUI. After trying to reconnect and making sure I had assigned a password for the default key that I was prompted to complete, I now get linked to a protonvpn troubleshooting window.
Anyone else had this? Will continue to troubleshoot and update.
1 Like
@anon59741345 Are you running KDE on your installation by any chance?
I had the exact same series of issues you mentioned while trying to set ProtonVPN up on Qubes 4.1.0 running KDE installed via sudo qubes-dom0-update kde-settings-qubes (but otherwise stock install).
Couldn’t figure out how to solve the issue, tried with all sorts of combinations of templates and settings but nothing stuck so ended up just reinstalling Qubes, skipping KDE and sticking instead with stock XFCE, repeating the “official” steps to set up ProtonVPN as sys-net → sys-firewall → sys-VPN → fedora-34 and all works fine now.