Officiel protonvpn version doesn't work with Qubes OS

Before, proton vpn was maintained by the community and was working fine in a appVM in QubesOS.
But since last year, it’s possible tu use the officicial version of protonvpn, and I since then I never make it to work in a appVM in QubesOS for both debian 10 and fedora 33. But it’s working fine in a normal debian 10 OS and fedora 33 OS without QubesOS

The tuto is from here : How to use the official ProtonVPN Linux CLI

Debian 10

wget https://protonvpn.com/download/protonvpn-stable-release_1.0.1-1_all.deb
sudo apt-get install ./protonvpn-stable-release_1.0.1-1_all.deb -y
sudo apt-get update 
sudo apt-get install protonvpn-cli -y
user@debian-test:~$ protonvpn-cli login openvpnid
Enter your ProtonVPN password: 

org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.NetworkManager was not provided by any .service files

Fedora 33

wget https://protonvpn.com/download/protonvpn-stable-release-1.0.0-1.noarch.rpm
sudo dnf install ./protonvpn-stable-release-1.0.0-1.noarch.rpm -y
sudo dnf update
sudo dnf install protonvpn-cli protonvpn -y
[user@my-new-qube ~]$ protonvpn-cli login openvpnid
Enter your ProtonVPN password: myopenvpnpwd

org.freedesktop.DBus.Error.ServiceUnknown: The name is not activatable

You can use qubes-tunnel then download the ovpn configuration in the protonvpn.

Step in ProtonVPN

Get the ProtonVPN config files:

  • Download the desired configuration files
    • Log into your ProtonVPN dashboard at account.protonvpn.com/login
    • Select Downloads on in the left navigation bar
    • Find the OpenVPN configuration files section and chose
      • Platform: Linux
      • Protocol: UDP (recommended) / TCP if you experience slow VPN speeds (this utilizes port 443)
    • Click the download icons for the server you wish to download

If you selected “Download All configurations”, extract the zip file to your desired location

Find your OpenVPN credentials:

For increased security, ProtonVPN is set-up with two separate credentials to authenticate a connection.

Learn more about how two pairs of credentials increase the security of ProtonVPN.

Log in to the ProtonVPN dashboard and click on Account tab. Here you will see your two type of credentials.
The credentials ProtonVPN Login are used in our applications . OpenVPN / IKEv2 Username is used on manual connections . So please configure the OpenVPN credentials to your preference as you will need to use them to establish a Linux VPN connection. Note : to use our NetShield DNS filtering feature, append the suffix +f1 to your username to block malware, or +f2 to block malware, ads, and trackers (for example 123456789+f2).

Step in qubes-tunnel

Installation:

Install qubes-repo-contrib package using apt-get or dnf in template. Then, install qubes-tunnel in the same way.

Setup

  1. Create an AppVM, called for example sys-vpn , with the provides network option enabled using a template with the previously installed qubes-tunnel package. Make a choice for the NetVM setting, such as sys-firewall .
  2. In sys-vpn settings Services tab, add qubes-tunnel service.

Note: There is no need for adding network-manager service.

  1. As root or using sudo , in sys-vpn execute /usr/lib/qubes/qtunnel-setup --config :
root@sys-vpn:/home/user# /usr/lib/qubes/qtunnel-setup --config

Enter VPN/tunnel login credentials.
Leave blank if not required...

Username: OpenVPN / IKEv2 Username
Password: OpenVPN / IKEv2 Password

Login info saved to /rw/config/qtunnel/tunneluserpwd.txt

Done!
Next, copy or link your config file to /rw/config/qtunnel/qtunnel.conf
  1. Following what’s the last sentence said, still as root or using sudo , in sys-vpn copy the OpenVPN config file from your service provider, for example called user_config.ovpn to /rw/config/qtunnel/qtunnel.conf.conf :
root@sys-vpn:/home/user# cp user_config.ovpn /rw/config/qtunnel/qtunnel.conf

Restart sys-vpn . This will autostart the VPN client and you should see a popup notification ‘LINK IS UP’!

Regular usage is simple: Just use sys-vpn as NetVM for other VMs and start them!

Troubleshooting

If when you restart sys-vpn instead you receive continuous popup notifications stating ‘Ready to start link’, you may need to troubleshoot the connection. To troubleshoot the connection, you can monitor the systemd service that controls the vpn client with journalctl -u qubes-tunnel and view any errors that appear.

If you follow corretly, you should be able to connect.

3 Likes

Thanks you all of the above information that you just bring so fast.
It’s indeed a good way to do it, but I need for my use case to often switch between country and server and so I was wondering how I can do that manipulation fast enough with qubes-tunnel ? Because if I need to switch each time the openvpn file, I don’t know if this method is for me :slight_smile:

Why not make 2 sys vpn / more ? i think it doesn’t need a lot source for sys-vpn 1 core 400 mb should be enough ? then you can just switch net vm.

I think this is good for any other VPN service right? What i’ve read network-manager is great if you’d like to check if the service is running correctly. How can you check without network-manager if the VPN is working great?

you should see a popup notification ‘LINK IS UP’! when connection is connected,

Thanks!

Does it indicate if the connection is down?

It should tell, see here :

su - -c 'notify-send "$(hostname): LINK IS DOWN !" --icon=dialog-error' user

2 Likes

Actually, there was an issue logged for recent template versions, and the side-effect it had on notifications (blocking or delaying them at VM startup) could result in the VPN startup being delayed. If it seems stuck on startup, it should come up after a couple minutes with the notification.

I thought this had been resolved but I guess I was mistaken. Back then I had put a workaround in Qubes-vpn-support that let the service start regardless of the notification state; I should add it qubes-tunnel as well.

If you’re inclined, you can change the following line

su - -c 'notify-send "$(hostname): LINK IS UP." --icon=network-idle' user

to this:

echo \'"sleep 2; notify-send \"$hostname: LINK IS UP.\"" --icon=network-idle\' | xargs su - user -c &

That will run the startup notification as a separate process and allow the VPN service to complete the connection.

Yes, this… I am also wondering about… How can you set up some killswitch maybe? Or that it always reconnects… It’s always good to know when you surf unencrypted, and use passwords on non HTTPS sites and so on. Can anyone answer this? The other VPN guide in qubes have a killswitch. I don’t know about this technique with using a VPN.
How would you set up it, if itäs not already implemented in this technique?

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.