Hello, today my internet traffic was deanonymized because QubesOS didn’t save my AppVM configuration.
To clarify, I have a Qube which runs a VPN (Mullvad) which provides network to other qubes. The Mullvad Qube is an AppVM which runs ontop of a duplicate of debian-12-xfce which includes mullvad preinstalled and the repo attached (so I can make as many instances of mullvad as I want).
Mullvad includes a systemd service which blocks internet traffic until the user connects to the proxy. This service was enabled.
However, QubesOS deleted my user configuration for both AppVMs resulting in Mullvad not having any credentials which, for some reason, re-opened my internet access. I had restarted (not shutdown) these qubes which left Qubes which depend on them for internet still running.
Now both Qubes immediately effectively had access directly to sys-firewall, deanonymizing my activity on both qubes since they no longer went through the VPNs.
If QubesOS didn’t destroy my /home/user directory, I would have retained connection to mullvad and not deanonymized.
BTW: I had this in the firewall scripts for both VPN qubes:
iptables -I FORWARD -o eth0 -j DROP
iptables -I FORWARD -i eth0 -j DROP
ip6tables -I FORWARD -o eth0 -j DROP
ip6tables -I FORWARD -i eth0 -j DROP
I guess I learned the hard way that this does literally nothing.
PSA: Always make your VPN qubes non-volatile (i.e. standalone) even if /home/user should have been non-volatile.
Mullvad VPN is storing the configuration files in /etc/mullvad-vpn, not in /home/user directory.
Qubes OS 4.2 and newer is using nftables instead of iptables.
You can find community guides for setting up Mullvad VPN on this forum if you search for them, for example:
Why is it that I had this false sense of a correct configuration? If that’s the case then I should have lost login details after the first reboot. Something has clearly failed here.
Ok? And? nftables provides an iptables implementation. Why is QubesOS breaking old configs by not including iptables-nft?
Ok? And? This does not take away that QubesOS has completely failed here by providing a false sense of a correct configuration. I had rebooted both that Qube and the host multiple times, my mullvad credentials should have NOT persisted and yet here we are. Something broke and now I pay the consequences for not quadruple checking to ensure my setup would be persistent.
*As much as I would like to stay and blame everyone but the OS. I have some shit to go fix now. There’s no avoiding that this is a catastrophic failure. I will not be responding further.
This is really unfortunate. For such requirements, you should absolutely use a firewall to block everything over clearnet except the traffic to the VPN endpoint, so you have a second layer of protection against problems like this.
Even after reading multiple times, I do not understand exactly why multiple restarts did not reveal the mistake to the OP.
Ignorant question from a non-VPN-user follows:
Is there an elegant way to add a third level of protection in the “client” VM against use of clearnet?
In general, I do not see a lot of “make sure it works” tricks in the different VPN guides.
I see there is mullvad check, and https://am.i.mullvad.net/connected and even a JSON API. If anonymity is important they seem very useful for manual verification.
I wonder - could they be used in a systemd service inside my AppVMs to block network activation, or even to test periodically?
The current situation for setting up VPNs in QubesOS is really not satisfactory. The risk of setting it up incorrectly is way way way higher than the chances of setting it up correctly. The current community practice of reading guides for how to set it up correctly is also not good, as guides can become outdated for any number of reasons, and there is no way to judge whether a guide even got it right in the first place.
According to the principles of Usable Security, a system should be designed such that it is secure out-of-the-box, and no following of any guides should be needed.
I strongly believe QubesOS should offer an easy way to configure a VPN, that automatically creates a sys-vpn qube from a Wireguard configuration file, and sets up firewall rules appropriately using the QubesOS provided firewall functionality to block all chances of leaks.
I plan to have the VPN community guides in the official Qubes OS documentation, I’m waiting for some internal work we have in the documentation done before working on this.
I strongly agree, which is why I provide packaged solutions here
The idea is that users install a Mullvad package, and the system is
configured to provide a sys-vpn and disposables, with firewalls
configured to block clearnet traffic.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
This is quite unfortunately. I don’t know about this particular situation. What I do know is that it is incredibly challenging to get a VPN working on Qubes.
I’ve had some foot gun experiences as well with VPNs and I can empathize with the situation, even if this ended up being a user mistake, while setting it up.
One of the projects started during the Qubes Summit this weekend are to solve this exact problem: a VPN setup tool. Even if such a thing does not tackle all VPN providers and configurations it’s such a huge step to solve the VPN foot gun issue. (CC @marmarta)
Well. It’s not a walk in the park but it is not “incredibly challenging” either.
Can be scripted if the goal is to provide a standard configuration, not a Swiss Army Knife VPN tool that can configure hundreds of possible permutations between:
VPN tech: wireguard, OpenVPN etc.
Qubes choices: standard qubes|disposables|standalones, split-secrets etc.
