Critical error occured after applying firewall rules in VPN-proxy VM using Qubes Manager


I just followed this description (link) to create a VPN-proxy. When i arrived to add VPN servers IP addresses i added all IP address to the VPN-proxy’s firewall through Qubes Manager, When i tried to apply the changes these 2 errors have occured:
firewall-dom0-VPN-proxy1.log (1.7 KB) >> the PCI device in the 8. line is my ethernet controller
firewall-dom0-VPN-proxy2.log (394 Bytes)

It is mentioned in the description that Qubes (in 2019) can’t handle too much firewall rules applied in Qubes Manager, and i just added 100+ IP address to the firewall. Is it still an issue, and maybe the source of the problem?

Thanks any help!

You might not want to add the addresses to the firewall, because if an attacker can compromise your VPN VM, they are probably in a position to spoof their IP address to match the VPN provider’s. Also, openvpn won’t connect to an address unless its authentic (its validated with a cryptographic key).

However, I see those addresses would be your only anti-leak protection, so I suggest a different method.

There is qubes-tunnel which has automatic anti-leak rules, and it runs pretty smoothly with re-connections (Network Manager often has issues with that). I have a draft of more detailed qubes-tunnel setup instructions here.


I’ve read in other threads about the qubes-tunnel, so i will give it a try. Your last link is 404. Is it the one from your github repo named Qubes-vpn-support? If yes is it similar to unman’s settings? I see you are using different service in the VPN-qube ( vpn-handler-openvpn), and it seems to me that your setting is a bit different from unman’s settings.

Sorry about the link, it should be accessible now. Its for qubes-tunnel not Qubes-vpn-support.

The two are like sister projects, where new changes go into Qubes-vpn-support first. It would actually be preferable to use Qubes-vpn-support until qubes-tunnel can be updated with the notification workaround (an issue I was reminded about today). In that case the Qubes-vpn-support Readme should have what you need.

If you still want to use qubes-tunnel, I posted a workaround for the notification blockage issue here.

1 Like

if I understand you correctly, the only difference between the Qubes-vpn-support and the Qubes-tunnel is that Qubes-vpn-support gets the updates first. If it is correct, when i try to follow the description, it says: " Next, add vpn-handler-openvpn to the ProxyVM’s Settings / Services tab…". Now i’m trying to make my sys-vpn based on a minimal debian template, and when i try to make the changes in the Proxy VM, i can’t find any vpn-handler-openvpn service. Does it depend on some package i should install to the template, or what? So it seems i wasn’t too attentive here. I had to install the package from the file. But unfortunately i’m still not able to do anything after it. Here is what i tried to do:

  1. Making a template VM for the sys-vpn (vloning the debian-10-minimal template):
    in dom0: qvm-clone debian-10-minimal sys-vpn-template

  2. Installing these packages to the sys-vpn-template template:
    in dom0: qvm-run --pass-io -u root sys-vpn-template "apt install --no-install-recommends qubes-core-agent-networking qubes-core-agent-nautilus nautilus zenity libblockdev-crypto2 policykit-1 gnome-keyring openvpn gedit curl -y && poweroff"

  3. Creating a Proxy VM based on the sys-vpn-template template, with the “Provide network” option enabled, called sys-vpn

  4. Downloading the Qubes-vpn-support tar.gz file to the sys-vpn Proxy VM and decompress it with tar:
    in sys-vpn’s Xterm: curl -L -o /home/user/Qubes-vpn-support.tar.gz
    in sys-vpn’s Xterm: tar -xzvf /home/user/Qubes-vpn-support.tar.gz

  5. Installing the Qubes-vpn-support package:
    in sys-vpn’s Xterm:
    cd /home/user/Qubes-vpn-support-1.4.4
    sudo bash ./install

And there is still no vpn-handler-openvpn service. Could you write a small summary about how can i get to the point where i should add vpn-handler-openvpn service?

You have to manually type in the service name. Its different between Qubes 4.0 & 4.1… IIRC on 4.0 you type the service name into the box then click +/Add, and on 4.1 you select Custom from the dropdown menu first.

Alternately, in dom0 you can type qvm-service vmname vpn-handler-openvpn on which seems simpler.

I’m sorry, i was right in the middle of writing a small novel about my failure when you replied to me. So i just need to use the qvm-service vmname vpn-handler-openvpn on command in dom0. Seems simple enough! I will try it! Yeah, i’m using 4.0.


Thanks for your help @tasket ! It seems that everything is working fine, except for one thing: when i restarted the VPN proxy-VM after installing the Qubes-vpn-support installation script the ‘LINK IS UP’! popup notification didn’t show up. The connection testing was ok (with the test link command the result was: “Initialization Sequence Completed”), and if i set the VPN proxy-VM as a NetVM to my disposable Fedora-33 qube, the IP address was the one from my VPN provider, checked with and webpage. What do you think about the not sown popup notification? Is there any log or something i could send to you to investigate?

Sometimes the initial notification won’t appear because the notification system hasn’t started yet. But the problem doesn’t usually manifest on my 4.0 and 4.1 systems.

The only thing this impacts is the visual notification, so its safe. But if it still bothers you, then possibly try a couple things:

  • Switch to debian-10 template, as its less prone to startup anomalies and more secure overall

  • Try adding to the After= line in qubes-vpn-handler.service. If you installed to the VPN VM you can find it in /rw/config; if you installed to the template, it will be there under /lib/systemd/system.