I’ve put together my Qubes OS networking model and would appreciate some feedback. The diagram shows a hardened Alpine Linux router using Wi‑Fi as input and Ethernet only to my Qubes laptop.
Inside Qubes, I’m using hardened sys-net and sys-firewall qubes based on Debian Minimal 13. My default AppVM template is Debian 13.
The VPN qubes use Mullvad with a kill switch. I’d use the levels depending on how sensitive the activity is.
What do you think of this setup in regards to threat model & any vulnerabilities? Does the extra VPN and firewall layering provide meaningful protection, or does it mainly add complexity? How would you rate it in terms of security and privacy, and what weaknesses should I look for?
I’d also be interested in hearing how other Qubes users organize their networking and threat models.
Does the extra VPN and firewall layering provide meaningful protection, or does it mainly add complexity?
Two-hop VPN adds a little bit of protection, if you truly need it. Additional firewall layering after VPN qubes also adds a bit of protection, in the case of VPN qube compromise, though IMO if you’re running short on memory it’s not fully necessary.
Threat model is something you - as the user - should have. And you did not share this.
My personal opinion on such setup: it’s just adds unneccessary complexity.
Even a single VPN-firewall-net connection is much more what is really required. Especially if your firrewall has no custom rules - what I would bet for.
Whithout rules it’s ‘just’ a IP level router wit MASQUERADING. What your VPN is doing so, and your sys-net is also doing - chaining ‘too many’ of those - whithout any real reason - makes no sense to me. (and I’m a network security specialist for 25+ years by now)
Even if you do have some firewall rules, those are just simple packetfilters based on IP addresses - which is pretty much the basics, and considered outdated as a ‘single’ solution.
How would you really increase your security model:
by adding application level filters in the chain.
One might start with a simple outgoing proxy where you can log your AppVMs activity.
Next step would be to add some URL filters to protect your AppVMs from ‘mistakes’
Then you might add an IDS/IPS like Suricata as an easy start.
And/or you can add a real Web Application Firewall, which is combining all of those above…
Not bad, but I would skip two VPNs and use Mullvad multihop if desire is to have different location on exit.
For sensitive work i prefer whonix only. But it is a long debate and it depends on if you need to hide Tor for your ISP. But i would never include VPNs for sensitive work.
My big thought to add is what you define as “Sensitive Levels”? In my opinion, it makes more sense to separate your activity into different “pseudonyms” (i.e. all activity that is done in one “networking session”, and possibly connected to previous networking sessions) because in this age pure anonymity is gone.
From there you can ask: “What activites do I separate into which pseudonyms?” and then create separate qubes which you connect to the appropriate VPN/TOR structure.
I also think people forget that the primary purpose of VPN is to hide yourself from the end-server, which can be a legitimate reason, but not from your state, as the VPN just replaces the ISP as the “man in the middle” and will most certainly hand over your browsing data if big brother comes (or doesn’t) with a warrant.
Creating a new Tor Identity gives you a fresh slate for a new pseudonymous activity, while VPN acts as one big pseudonym that collects all your activity across sessions (it always knows your IP address, and possibly creditcard). Never view the same (niche) sites or use the same accounts across pseudonymity, otherwise the activity from one pseudonym can be connected to another pseudonym, and with enough activity data to yourself.
I would advice alternating between is disteib between VMS, firewall-1 debian-> VPN fedora → firewall 2 Debian etc, adding alpine Linux, gentoo or arch in the loop could help as well but as far as the theory goes I think it DECREASES entropy, ie its easier for well put together organizations to track you, especially if they work together
The reason it decreases entropy is because each distribution is using different compilation flags and so the speed of the kernel, firewall and iproute are marginally different, so it should be more secure to repository attacks as well as a few stack overflow attacks but said attacker can more easily narrow down WHO you are, especially if you use AND update the same base template between personal and sensitive virtual machines, for that matter I would also suggest you update your personal VMS and sensitive VMS at different times or even days if you are too paranoid to avoid correlation that way as well, lastly if you use tor over VPN I can assume your usage is VERY sensitive, I would advice to check whonix’s website, it has a guide on how to use multiple whonix gateways in one qubesos machine, use one whonix machine for updates and the other one for sensitive staff, lastly I would do some of my daily or weekly browsing over the update whonix VM, like downloading books or watching even normal p*rn, it adds entropy to your favor and headaches to your adversarys
I personally used to use setups like that to add entropy for everyone else in the network just to do my daily browsing since if agencies and corpos who track people are focused on the most suspicious user(me) they lose resources that they could use on people that actually need to hide, btw your welcome y’all, even if what I did counts as almost nothing overall
That being said I think this post belongs in that tor reddit forum that I am defiantly not allowed to name here, they should have better advice for your complicated setup
Nice architecture, but I think you’re optimizing for complexity instead of threat clarity.
Look, the dual-VPN setup with all those firewall qubes, it looks impressive on a diagram, but Zrubi nailed it: you’re stacking tools that do the same thing. Without application-level controls, you’re just adding layers that don’t actually talk to each other.
Honestly? If you’re worried about state actors, this doesn’t help. If you’re not, you’re overthinking it.
I’d drop one of the VPN layers and just use Mullvad multihop for the stuff that needs it. Keep your actual OpSec tight, don’t mix your pseudonyms across the same exit node, keep app contexts separate, that kind of thing. That matters way more than another firewall qube.
MYuhter’s point about managing pseudonyms separately is the real insight here, not the architecture.
- chaining ‘too many’ of those - whithout any real reason - makes no sense to me. (and I’m a network security specialist for 25+ years by now)