has anyone taken the time to try this with a minimium template and know what are the least amount of packages needed for just running the gui clinet and acting as proxy?
Which firewall VM are you guys setting up qvm firewall rules in?
Is the proper setup
sys net- >sys firewall → VPN qube → Another firewall qube → app vms
or
sys net → sys firewall → VPN qube → app vms.
The latter is the setup im currently using and it has worked for me. when i try the former setup with the extra firewall qube in front of the vpn connection, i end up having no internet in the app qube.
If you want to limit VPN qube connections then you need to add the firewall rules to the VPN qube and both setups will work.
If you want to limit app vms connections then both setups will work as well, but this setup:
sys net- >sys firewall → VPN qube → Another firewall qube → app vms
Will be more secure because the app vms firewall rules will be enforced in the Another firewall qube instead of a VPN qube in this setup:
sys net → sys firewall → VPN qube → app vms
If the VPN qube will be compromised (e.g. by VPN software) then the app vms firewall rules in it could be removed.
Both should work, although as @apparatus said (and it is recommended in the official Qubes OS firewall documentation), a sys-firewall between the appvms and the vpn qube is recommended for security reasons
Sorry, am a bit confused, should i used the guide here, or the one on PrivSec or the one on the mullvad Page? I would prefer having the mullvad App and want to use the mullvad qube as Network for other cubes… Thank you very much 
well, it seems Mullvad updated their official guide to say iptables (the firewall command line tool) is not working anymore in Qubes OS 4.2, without updating their guide itself Mullvad on Qubes OS 4
the PrivSec guide is neat, but does not explain how to configure the VPN netvm to block everything (it’s explaining here if you want). At least, it handles the /etc/resolv.conf issue better than this guide (I should update it to take the idea of a using a systemd unit)
You mean Killswitch Configuration?
Yes
Thanks, applied the nft lines to qubes-firewall-user-script in the template and wondered why it is not applied to the appvm, even not after creating a new appvm from the template, so I added them to the appvm too…
But I’m asking me what “Lockdown mode” in Mullvad app does, shouldn’t it do the same? Is this not reliable? And should I still turn it on even after following your Killswitch method?
Thank you very much!
Here are some extensions.
Debian minimal template
Install dependencies
# [in dom0]
qvm-clone debian-12-minimal mullvad-vpn-app-d12m # or other name
# [in mullvad-vpn-app-d12m]
# netVM dependencies
apt install -y qubes-core-agent-networking qubes-core-agent-network-manager ntp
# Needed for Mullvad install script
apt install -y curl lsb-release
# Mullvad VPN app prerequirements
apt install -y libnss3 libasound2
# needed in order to listen for nameserver changes in /etc/resolv.conf
apt install inotify-tools
Install Mullvad VPN app
# Download the Mullvad signing key
sudo curl -fsSLo /usr/share/keyrings/mullvad-keyring.asc https://repository.mullvad.net/deb/mullvad-keyring.asc
# Add the Mullvad repository server to apt
echo "deb [signed-by=/usr/share/keyrings/mullvad-keyring.asc arch=$( dpkg --print-architecture )] https://repository.mullvad.net/deb/stable $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/mullvad.list
# Install the package
sudo apt update
sudo apt install mullvad-vpn
Original instructions can be found here.
DAITA
Note: This is an experimental feature and currently supports only a few servers.
DAITA (Defence against Al-guided Traffic Analysis) hides patterns in your encrypted VPN traffic. If anyone is monitoring your connection, this makes it significantly harder for them to identify what websites you are visiting. It does this by carefully adding network noise and making all network packets the same size.
Attention: Since this increases your total network traffic, be cautious if you have a limited data plan. It can also negatively impact your network speed. Please consider this if you want to enable DAITA.
See Defense against AI-guided Traffic Analysis (DAITA) for mor infos. DAITA is supported with latest Linux beta version as of now, so we need to adjust the repository source (see here):
# add the Mullvad BETA repository server to apt
echo "deb [signed-by=/usr/share/keyrings/mullvad-keyring.asc arch=$( dpkg --print-architecture )] https://repository.mullvad.net/deb/beta $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/mullvad.list
I haven’t encountered any stability issues so far.
Then activate setting in Mullvad VPN app:
Settings → VPN settings → WireGuard settings → DAITA → enable
Setup as ProxyVM / NetVM
Settings → VPN settings → Local network sharing → enable
This setting adds additional nftables entries, which are needed for Mullvad VPN app to work properly within NetVM as of now. I did not observe any other effects for local network access in context of Qubes OS, you also can inspect nft rules yourself. Credit goes to privsec.dev.
Of course you still need to forward DNS (dnat) as described in the guide, thanks @DVM for the script.
App-native killswitch / lockdown mode
Settings → VPN settings → Lockdown mode → enable
This is a more strict setting than “Kill switch” on same tab. It uses nftables to prevent leaks, hence not dependent on app startup; especially useful for people not used to invoke nft manually; seems to work well.
Misc
Settings → VPN settings → Launch app on start-up → enable (for convenience)
1 Like
This guide seems not to work with latest Mullvad VPN and Qubes 4.2. I followed the instructions multiple times, but can’t get VPN to work in my other cubes.
Net cube is set to sys-firewall (current) and the mullvad cube is using “qubes-firewall”. I also created the qube using the “provide network access to other qubes” in advanced settings.
No idea, what I’m missing here …
by net qube, what do you mean?
this is right (it’s a qube by the way)
can you establish a VPN from the app? in a terminal in the mullvad qube, can you try
ping -c 4 9.9.9.9 and if it works, try ping -c 4 qubes-os.org.
- If the first command does not work, there is something wrong, the VPN does not work.
- If the first one worked but not the second command, there is an issue with the DNS.
- If both commands work in mullvad qube, repeat in a qube using the mullvad VPN as a netvm.
My mullvad account for this guide expired so I can’t verify myself if it still work.
there are MTU Issues when using DAITA and quantum secure connections. Please update this guide.
Isn’t the snippet about MTU problems enough to fix it?