[4.2] Leakage of network traffic from VM... Any joke?

I made the “mullvad-vpn” machine a few months ago on the Fedora-37 template, I was on qubes 4.1 at the time. I followed all the steps in the instructions at this link:

Two months ago I installed qubes 4.2 and then restored the machines from backup. After some time, I stopped the mullvad-vpn machine and switched the template to fedora-38.

In addition, shouldn’t the network be controlled by Xen, as it works with Microsoft’s hyper-v?

If I install clean windows and do not give network permissions, Windows will not access it in any other way. So I guess qubes controls the network settings of VM machines.

I have installed qubes 4.2-rc3. Release Candidate, and in the meantime, there was an error that compromised the basic security of qubes…

In a terminal in the qube VPN, if you run curl https://ifconfig.me with the VPN connected, and when disconnected.

Do you have the same result? If so, is it your ISP IP in both case?

On my VPN qube, I get this result for instance. My setup is super easy, I just block all traffic in the firewall tab in the qube settings, enable network-manager service and I added my VPN config.

# vpn enabled
user@sys-vpn ~> curl https://ifconfig.me⏎ # (I obfuscated the IP for the forum)

# vpn disabled
user@sys-vpn ~> curl https://ifconfig.me
curl: (7) Failed to connect to ifconfig.me port 443 after 133 ms: Couldn't connect to server

which error?

You know my answer.
When I connect to vpn, curl returns ip mullvad.
When I disconnect from vpn, then curl returns ip ISP.
I did the test on vm “vpn-mullvad” which has rules set up.

Qubes I use on a daily basis and I do not hide the urgency. I will delve into the details of the firewall documentation on the qubes website.

Say - what qubes configuration do you have? Also qubes 4.2 + Fedora-38 template?

Exactly, and I’m using a wireguard VPN but that shouldn’t have any impact here.


For some reasons, it seems the firewall in the qube isn’t applied correctly :thinking:

What do you have in /rw/config/qubes-firewall-user-script? (if there is something)

Did you change something in sys-firewall? The qube firewall settings are applied in a qube’s net qube, which issys-firewall for your VPN qube. Something in /rw/config/qubes-firewall-user-script or /rw/config/rc.local which could have introduce an issue in the firewall.

1 Like

Firewall works differently in R4.2. You are using a pre-release version. Instructions that worked with R4.1 will no longer work with R4.2.

Search and you’ll find details. I’m mobile right now and can’t do it for you.

1 Like

I disagree with your statement.
A statement like “search and find” is unacceptable.
Documentation is for troubleshooting and for experimenting with advanced things.
What angers me most is the fact that the firewall that is supposed to guarantee “reliable” security has failed - and in the RC-3 version.
After all, RC means release candidate.
I can understand the existence of such a bug in an alpha, beta version… But in RC version 3?
What about the zero-trust approach propagated by Joanna?
Since the firewall has been working insecurely since version 4.2, why don’t you make a dual firewall, i.e. a working 4.1 firewall with a 4.2 overlay?
Why are you going to 4.2 with something so heavily untested?

How could I reinstall sys-net and sys-firewall so that they support nftables by default?

It hasn’t failed. You didn’t use it correctly. The problem here is missing documentation. If you want to write that documentation it would greatly help the project. Even just looking up if there is already a task ticket and if not creating one would be helpful.

What I don’t get is your attitude. If you don’t want things to break or be unexpected then don’t play with release candidates.

1 Like

I think Sven was just trying to be helpful. As I understand his comment, he happened to see your post on his mobile device while he was out and about, and he remembered seeing some info that would be of use to you. He wasn’t in a position to find an exact link himself at that moment (as he usually does when helping others), but he knew you’d find it if you searched, so he suggested doing that. (Sometimes, just knowing that the information is out there can be helpful, since then you know to try different search permutations until you get the expected result.) I don’t think he meant it as a final or permanent ultimate solution for everyone, just a quick hint that might be of some value to you in the moment.


Back to the issue, I am interessed in what has been changed and why this has been changed in 4.2.

Can you please drop the links and explanations on what do I need to do with my VPN firewall settings when 4.2 is officially released?

See the Qubes OS changelog and respective merge request. There’s also an issue open on whether to keep it that way for the final release. Imo it’s reasonable to unify everything to nft as Qubes OS was running nft in the backend on most templates anyway. There was just an iptables compatibility layer in front which made people think that they were using iptables. Probably you can even reinstall it. Imho it leads to the false sense of “I’m seeing the whole picture of my firewall” when in fact you are not. It’s e.g. pretty easy to write nft rules that are invisible to the iptables compatibility layer.

Anyway the screenshots the OP originally posted indicate that s/he didn’t use user-specific scripts, but the firewall GUI. Obviously the GUI should continue to work as expected regardless of the change (that’s one of the reasons why it’s usually better to use the GUI rather than custom scripts). So I’d recommend to create a separate issue at qubes-issues in that case.

Btw DNS and ICMP have always been allowed by the firewall GUI by default, i.e. I wouldn’t be surprised about DNS leaks. Use the qvm-firewall command-line interface to disable DNS.

1 Like

4.2.0 switched from iptables to nft, I don’t think the release notes does at great job at explaining this change, but it does mention it.

4.2 Release notes

I’m not sure if this means you can’t or shouldn’t use iptables in appvms, but iptables doesn’t seem to be included in the debian 12 template.

The main issues I ran into is that you can’t use iptable rules to remove the forwarding rules when settings up a vpn qube, the result being it just uses the default gateway when the VPN is down.

1 Like

Hi all + @Sven
ok - I can write the documentation.
Only first you would have to arrange a meeting for me with the person who implemented the solution.

It has never yet occurred to me to deploy in production something that is not documented in any way.
There is no working firewall in the current “RC” version - even though it worked in r4.1. Such changes should be processed in the “current testing” repository, not in the “stable” repo update server release 4.2-rc3.

In Qubes, things are implemented independently by Qubes developers, so it’s not identical to the implementation in fedora or debian.

In summary, it comes out that Qubes 4.2 has no documentation for the implemented firewall :slight_smile:

Whereas 4.1 has a documented firewall.

Let’s say - how are we supposed to test an RC distribution if we don’t have documentation of the things implemented in it, which are the basis of the distribution?

I don’t know what’s better - throwing out the firewall from qubes 4.2 completely, or having a firewall GUI coming from the 4.1 distribution that is fake, non-functional and unsafe?

I reported the problem here on the forum, and as it turned out later - only a handful of people know about the problem. Is this what testing should be about?

We still didn’t figure why you have this issue though :confused:

In the meantime, I dealt with the problem “around”; I implemented wireguard with kill switch function.

  1. Create a new qube:*

Click on the Qubes app menu and then Create Qubes VM.

  1. Name and label: MullvadVPN.
  2. Type: Qube based on a template (AppVM).
  3. Template: fedora-38 (or later).
  4. Networking: default (sys-firewall).
  5. Advanced: Check (enable) provides network.
  6. Click on OK.
  1. (example: in personal qube) Visit www https://mullvad.net/en/account/wireguard-config
  2. check the option “Linux”:


  1. The server that our computer connects to (this is the server that the local ISP sees). This means that in this example, my computer will only connect to the Honk Kong server, while traffic from the Honk Kong server will be redirected to the Israeli server.
    That is, I am connecting to Hong Kong, while the outgoing IP address is Israeli.

4.Check the “kill switch” option

  1. (Optional) select the content to which mullvad should block access:

  2. Generate and download configuration.

Note: In the Qubes app menu, the newly created MullvadVPN AppVM qube will show up as “Service: MullvadVPN” and not “Qube: MullvadVPN” due to its “provides network” setting.

  • Click on the Qubes app menu and go to your current AppVM and open Files.
  • Open the Downloads folder and right click on the downloaded WireGuard file.
  • Select Copy To Other AppVM… and then enter MullvadVPN as the Target and click on OK.
  1. Install WireGuard

We will install WireGuard in the Fedora-38 template so your MullvadVPN ProxyVM can use that.

  1. Click on the Qubes app menu and go to Template: fedora-38 and open the Terminal.
  2. In the Terminal run the command
    sudo dnf install wireguard-tools -y
  3. Shut down the VM with the command
    sudo shutdown -h now
  4. Shutdown and Start the MullvadVPN so that wireguard-tools are added to it.

Configure WireGuard

In the MullvadVPN VM:

  1. Click on the Qubes app menu and go to MullvadVPN and open the Terminal.
  2. Now you will copy the WireGuard .conf file that was copied from the other AppVM to the /home/user/ folder so it persist after reboot. First run:
    cp /home/user/QubesIncoming/*/se9-wireguard.conf /home/user/
  3. Now you will edit the /rw/config/rc.local file using a text editor. First install nano:
    sudo dnf install nano -y
  4. Then run
    sudo nano /rw/config/rc.local
  5. Add
    wg-quick up /home/user/se9-wireguard.conf
    (or the config file you used) on a new line.
  6. Press Ctrl+O (Enter) and then Ctrl+X to save and exit.

Make sure that WireGuard connects:

  1. Run
    sudo wg-quick up /home/user/se9-wireguard.conf
  2. Run
    curl https://am.i.mullvad.net/connected
  3. Run
    sudo wg
    and check for a WireGuard network interface and a peer handshake.

Add DNS hijacking rules

Now we will add firewall rules to redirect DNS requests to (the DNS on the VPN server) for all AppVMs that use the MullvadVPN ProxyVM.

Make sure that you have started an AppVM that has the Networking set to MullvadVPN, otherwise the “vif” IP address will not be visible.

Still in the MullvadVPN Terminal:

  1. To find out your MullvadVPN_local_IP address, run
    ip a | grep eth0
  2. Edit the firewall user file with nano:
    sudo nano /rw/config/qubes-firewall-user-script
  3. Copy and paste the following in the bottom.
    Only Replace
    with your own MullvadVPN_local_IP IP address:
**# replace with the IP address of your vif* interface**
iptables -F OUTPUT
iptables -I FORWARD -o eth0 -j DROP
iptables -I FORWARD -i eth0 -j DROP
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS  --clamp-mss-to-pmtu
iptables -F PR-QBS -t nat
iptables -A PR-QBS -t nat -d $virtualif -p udp --dport 53 -j DNAT --to $vpndns1
iptables -A PR-QBS -t nat -d $virtualif -p tcp --dport 53 -j DNAT --to $vpndns1
  1. Press Ctrl+O (Enter) and then Ctrl+X to save and exit.

Set the Networking

  1. Click on the Qubes app menu and go to System Tools > Qube Manager.
  2. Select the AppVM that you want to use with the MullvadVPN ProxyVM and click on the Stop button in the toolbar to shut it down.
  3. Right click on the same AppVM and then select Qube settings.
  4. On the Basic tab, click on the Networking drop-down list and select MullvadVPN.
  5. Click on OK.
  6. Click on the Start button in the toolbar to start the AppVM again.

Kill-switch works only when a Wireguard connection is established.
When VM:Mullvad VPN is started before Wifi traffic is established, wireguard will not be automatically set up.
The solution is to create a VPN setup button in the Dom0 panel.

  1. Point the mouse cursor at the Dom0 panel, then press the right mouse button and select the option
    panel → panel preferences

  2. in the “Items” tab, press the plus icon, and then press twice on the “launcher” item

  3. in the launcher settings, place the pointer in the “Command” field and enter the following command:

qvm-run --pass-io MullvadVPN 'sudo wg-quick up /home/user/config.conf

Remember to replace the name of the “config.conf” file with the name of the wireguard configuration file downloaded from the mullvad website.

Check the option “Run in terminal” and press “save”. From now on, every time you press the icon, it will trigger an attempt to connect to the tunnel.

Preventing leaks in the browser

  1. Run the firefox browser on the AppVM connected to the MullvadVPN network
  2. Go to the website Download Extension |Mullvad VPN
  3. press the “Install” button, and then accept the request to install the browser add-on.
  4. when you see the mullvad icon on the firefox icon bar, then press on it and select “Connect Proxy” option.
  5. the Proxy will only work if the Mullvad tunnel is running. When the VPN connection is not established for some reason, the browser will stop allowing traffic to pass through to the Internet (that’s because the proxy is only reachable on the MullvadVPN network by the local mullvad server address)
1 Like

The problem probably stems from the fact that GUI rules are written in Qubes as iptables entries.
Qubes, on the other hand, decided to implement nftables as a firewall and mark iptables as a thing to be abandoned.
That’s how I understood it on github.
Since there is no such information passed through the official route from the developers’ side, it scares me to know what else threatens security, and at the same time the developers know about it :))
@marmarek Do I understand the situation correctly?

the thing is, the firewall tab is working for me on 4.2-RC3 (and on a system that used to be 4.1 and upgraded to 4.2-RC3), so I’m a bit meh at the moment :confused:

any news?