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

The network infrastructure looks as follows:

VM → sys-firewall-vpn-> vpn-Mullvad → sys-firewall → sys-net.

The “vpn-mullvad” machine has firewall rules restricting traffic to the vpn servers - so traffic coming out of the VM shouldn’t go anywhere else if I don’t connect to the VPN.

It turned out that I was wrong. Despite not connecting to the VPN, traffic from the VM freely goes out anywhere.
I don’t hide my irritation, because this kind of thing shouldn’t happen. This is a fuckup. Can you tell me what the issue is with this and why there is a leak?
I attach pictures of the configuration.
@umman2005 @Sven

In sys-firewall-vpn and vpn-Mullvad, did you use qube firewall to disable all traffic except the IP and port to the next hop?

When I set the rules in sys-firewall-mullvad identical to those found in mullvad-vpn then I lose the Internet completely: with vpn tunnel on or off.

When I add a restriction on port 1197 (udp) to the firewall settings of the vpn-mullvad-vpn machine I also lose the network completely.

I guess this should be like that:

  • sys-firewall-vpn should only allow to reach vpn-mullvad on all ports.
  • vpn-mullvad should only be allowed to reach mullvad servers on the UDP port for your tunnel

I don’t know if mullvad can provide such a list of if they have a dynamic list of servers in which case that make the setup more complicated than listing a few IPs.

With this configuration, sys-firewall-vpn can’t leak anything outside of vpn-mullvad, and vpn-mullvad traffic will be limited to only establishing the tunnel. You can’t have leak with that.

An issue you may have is if vpn-mullvad isn’t allowed to do DNS requests, and you use an hostname for the mullvad remote endpoint, the system won’t be able to resolve the IP of that hostname and connect.

I did as you say - and the problem still occurs, traffic still leaks without vpn…

On the other hand, with the following configuration, I completely lose access to the Internet, regardless of whether the tunnel is enabled or not.

does it still “leak” even if you don’t connect the VPN? (keep the rules in the vpn qube) I’d expect that you lose network, that may mean the mullvadvpn check may be faulty?

in sys-firewall-vpn-mullvad-PL you need to allow the internal IP of the vpn qube, it may be something like 10.137.0.x

When I connect to the vpn, I have the status “connected to vpn” on mullvad.net.

When I disconnect, the mullvad.net website loads correctly and displays the precise details of my ISP.
Other sites also land such as Google.com

I did as you say. Internet is not there even after connecting to vpn. Below is the current configuration

Ok! That’s interesting :thinking:

What if in the VPN qube network manager applet you “disconnect” its virtual interface? Do you still have internet access? If yes, this would mean that it’s the firewall qube that is leaking, not the vpn qube.

Pages don’t load after “unplugging” interface

Okay! (by the way, did you remove the firewall rules in the firewall VM for this test? I forgot to tell you to remove them)

This mean that’s the VPN qube that is leaking, and not the firewall VM, that’s progress :thinking:

Did you add anything special in /rw/config/rc.local in the VPN qube?

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