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
1.2.3.4⏎ # (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.
ok!
For some reasons, it seems the firewall in the qube isn’t applied correctly 
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.
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.
Sven,
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.
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.
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.
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.
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 
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 
In the meantime, I dealt with the problem “around”; I implemented wireguard with kill switch function.
Click on the Qubes app menu and then Create Qubes VM.
- Name and label: MullvadVPN.
- Type: Qube based on a template (AppVM).
- Template: fedora-38 (or later).
- Networking: default (sys-firewall).
- Advanced: Check (enable) provides network.
- Click on OK.
4.Check the “kill switch” option
(Optional) select the content to which mullvad should block access:
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.
We will install WireGuard in the Fedora-38 template so your MullvadVPN ProxyVM can use that.
- Click on the Qubes app menu and go to Template: fedora-38 and open the Terminal.
- In the Terminal run the command
sudo dnf install wireguard-tools -y- Shut down the VM with the command
sudo shutdown -h now- Shutdown and Start the MullvadVPN so that wireguard-tools are added to it.
In the MullvadVPN VM:
- Click on the Qubes app menu and go to MullvadVPN and open the Terminal.
- 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/- Now you will edit the /rw/config/rc.local file using a text editor. First install nano:
sudo dnf install nano -y- Then run
sudo nano /rw/config/rc.local- Add
wg-quick up /home/user/se9-wireguard.conf
(or the config file you used) on a new line.- Press Ctrl+O (Enter) and then Ctrl+X to save and exit.
Make sure that WireGuard connects:
- Run
sudo wg-quick up /home/user/se9-wireguard.conf- Run
curl https://am.i.mullvad.net/connected- Run
sudo wg
and check for a WireGuard network interface and a peer handshake.
Now we will add firewall rules to redirect DNS requests to 10.64.0.1 (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:
ip a | grep eth0sudo nano /rw/config/qubes-firewall-user-script10.137.0.47**# replace 10.137.0.47 with the IP address of your vif* interface**
virtualif=*10.137.0.47*
vpndns1=10.64.0.1
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
Warning
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.
Point the mouse cursor at the Dom0 panel, then press the right mouse button and select the option
panel → panel preferences
in the “Items” tab, press the plus icon, and then press twice on the “launcher” item
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
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
Hi,
any news?