No, just adding to the thread with a “working” example ![]()
Now I have one ![]()
How would you go to make it a template ?
sys-vpn-12-template
sys-vpn-1 appVM
sys-vpn-2 appVM
sys-vpn-3 appVM
All using Proton, with three different login ?
I’ve created a template, and 1 appVM from it,
downloaded PVPN using the appVM, transferred it to the template, and installed it, but many errors
Then installed it to the appVM but no VPN available (Q. “proton” nothing)
What errors. I’ve had no errors instaling pvpn in template.
PS: I’ve installed pvpn repository so it updates, but I have separate pvpn template to not mess with base one
I can login to the app but as soon as try to connect to a server it immediately says connection error timeout, like as soon as I hit the button. Any ideas how to resolve ?
I do have restrictive ports on my router, I can open up some if anyone has tips. The rest of my devices have no issue with internet connectivity. My phone uses the proton app on the same router with zero issues.
Can you try different protocol like OpenVPN instead of WireGuard? (or vice versa depending on your current protocol use)
Never had this kind of problem ![]()
Ok thanks, it works with openvpn through the network manager
Did you put proton VPN qube behind sys-whonix?
No, it is connected to sys-firewall
Give it 800 MB of memory minimum
I’ve been running my Proton VPN app qube with standalone Fedora 41 min, with 400 MB “initial memory” and unchecked “Include in memory balancing”.
It seems to work fine, nothing has ever crashed / internet works, but I’m not sure what symptoms I should be looking for that could be attributed to not giving enough memory? But perhaps your 800 MB recommendation was specifically tied to using the “full” template not minimal?
- run
top- it will tell you free memory and swap usage - are you running protonvpn-cli?
Yes, I used a not minimal template.
This guide worked great until I did an update on to the sys-vpn-protonvpn-app standalone qube on 9/27/2025 and then it quit auto-starting on boot. I did some probing around and found that after the update . desktop file had changed from protonvpn-app.desktop to proton.vpn.app.gtk.desktop. After I put a copy of proton.vpn.app.gtk.desktop into the ~/.config/autostart every thing would auto-start on boot same as before the update.
qubes 4.2.4
I hope this info is useful.
Hi, this worked great for me. Thank you
Any tips on how I can add a route so I can still ssh into my local machines on my LAN?
I tried…
ip route add 192.168.0.0/24 via 10.138.32.140 dev eth0
… on sys-vpn which works but obviously this isn’t persistent between reboots. I tried the same command in /rw/config/rc.local and qubes-firewall-user-script. No luck. Thanks in advance.
The best way would be to use a dedicated qube that can reach your LAN servers.
But if you need a qube behind the VPN that also need to access a file server on the LAN, this is trickier. I went down that road, the best method was to use the qube-rpc call ConnectTCP from a qube behind sys-firewall to access a NFS/SMB/SSH server from the qube behind the VPN.
Basically, create a sys-proxy qube and do this, choose the IP and port to suit your needs
mkdir -p /usr/local/etc/qubes-rpc/
ln -s /dev/tcp/192.168.1.39 /usr/local/etc/qubes-rpc/qubes.ConnectTCP+445
in dom0, create this file (or use the policy editor) : /etc/qubes/policy.d/50-samba.policy
qubes.ConnectTCP +445 qube-behind-vpn @default allow target=sys-proxy
In the qube behind VPN, run qvm-connect-tcp ::445 (change the port if you use 22 for ssh for instance), and connect to localhost : $port
Hi @solene thank you for your helpful tutorial
I am sharing a note of my experience and two questions.
This appears to only work with Fedora templates for some reason.
I followed the steps but instead using a Debian base (instead of Fedora) and the sys-proton-app Qube worked within itself, but it would not expose the tunnel to any of the App Qubes which were using it is for their networking. Perhaps I was missing some package in the debian-13-minimal template? But I really don’t think I was ![]()
Must this be a Standalone Qube as opposed to a lighter (non-standalone) Service Qube?
I ask as the memory and disk use of Standalone Qubes are a bit higher.
Is the primary reason isolation of the Proton VPN App just for hardening? With a secondary reason being sharing the VPN with multiple App Qubes?
I ask because perhaps running the Proton VPN App in a Standalone Qube is sufficient for users on a resource constrained machine with lower threat models.
Install to template:
I’m not Solene, but some responses:
I’ve setup the Proton VPN app in an AppVM using Fedora 42 minimal. I run multiple instances of Proton VPN at the same time, and wanted them to have the smallest possible footprint, hence this approach. Here’s exactly what I did:
- Clone unaltered Fedora 42 min template to serve as the template for the Proton VPN AppVM
- In a root terminal, install the following packages in the template
- $ sudo dnf install qubes-core-agent-networking qubes-core-agent-network-manager network-manager-applet
- Still in the template’s root terminal, install Proton VPN
- $ sudo dnf install wget apt-transport-https
- $ export https_proxy=http://127.0.0.1:8082/
- $ wget “https://repo.protonvpn.com/fedora-$(cat /etc/fedora-release | cut -d’ ’ -f 3)-stable/protonvpn-stable-release/protonvpn-stable-release-1.0.3-1.noarch.rpm”
- $ sudo dnf install ./protonvpn-stable-release-1.0.3-1.noarch.rpm
- $ sudo dnf check-update --refresh && sudo dnf install proton-vpn-gnome-desktop
- Delete deb file: $ rm protonvpn-stable-release-1.0.3-1.noarch.rpm
- Shutdown template
- Create new AppVM based on the above template, with networking = sys-firewall, check “launch settings after creation” and check “Provides network access to other qubes” in “Advanced”
- Set “Private storage” size to 5GB, uncheck “include in memory balancing” (leave initial mem at 400 and 2 CPU), add “network-manager” and “qubes-firewall” in Services, and add “Proton VPN” in Applications
- Open root terminal in AppVM, create autostart folder: $ mkdir /home/user/.config/autostart
- Set Proton VPN to autostart: $ ln -s /usr/share/applications/proton.vpn.app.gtk.desktop /home/user/.config/autostart/
- Shut down AppVM, and clone it if you want to use multiple instances of Proton VPN
- Boot AppVM, it will ask for keyring pw, put something (even just one letter / number)
- Log into ProtonVPN
Everything is working perfectly for me, though I’d rather use Debian 13 minimal template instead of Fedora 42 (because I dislike the frequent updates). However, I havent figured out which packages to install in the Debian 13 minimal template to make it work. Proton VPN will open, but it will never connect. I tried installing all these packages:
sudo apt install qubes-core-agent-networking qubes-core-agent-network-manager wireguard network-manager network-manager-openvpn openvpn ca-certificates avahi-daemon python3-unbound firmware-mediatek atmel-firmware
So if anyone knows how to get this working in Debian 13 minimal would be much appreciated ![]()
Can confirm this guide continues to work on Qubes v4.2.4 within a Fedora-42-xfce qube & ProtonVPN v4.13.1 as of Dec2025, with two updates:
- @estoner 's update is necessary to configure autostart on qube boot
- as mentioned higher in the thread, newer ProtonVPN versions contain a kill switch setting in the GUI that seems to be effective, thus eliminating the need to add that config
I’m now running 3 protonVPN qubes to split-tunnel qube traffic to different regions, ProtonVPN app autoconfigures to new IPs within these regions on each boot. Elite functionality unobtainable through OpenVPN, wireguard configs, or ProtonVPN on a non-qubes system
qubes-core-agent-passwordless-root
I believe
What are the security implications of permanently storing your keyring password in plaintext? I find the keyring prompt is blocking automatic scripts I’d like to reliably launch the VPN without user input.
Given this VPN is the only service running in this VM, there are no other PWs on the keyring. But does this makes the Proton credentials insecure? My experience with Proton on other Linux distros, Ive not needed to manually unlock the VPN on boot every time to autostart