For starters, Solene’s @solene WireGuard VPN setup is amazing! I use it every day. Thanks!
However, I think we (the QubesOS VPN community) should reconsider the strategy of using a single VPN connection VM proxy for the following reasons:
The Internet is becoming increasingly restrictive, so there’s a high chance that the VPN server connection you picked for your VPN proxy VM will be blocked. At that point, you would need to set up a new VPN server configuration or a second VM with a different connection, which is inconvenient. What we need is a native VPN client that exposes all VPN servers, allowing us to switch with the click of a button.
Native VPN clients often come with additional features not part of standard WireGuard connections. Again, we would need the native client to take advantage of these features, which I deem increasingly important. These features include network obfuscation to avoid censorship, post-quantum secure key exchange (Mullvad), and traffic analysis obfuscation (Mullvad’s DAITA).
In short, I think plain WireGuard is a limited solution that is difficult to set up. Therefore, I recommend starting a community effort to transition to native solutions (meaning I pitch the idea to Solene LOL).
I am a total idiot when it comes to Linux networking commands, so I would prefer not to set up a proxy VM to create a VPN for multiple VMs. Avoiding this would simplify the setup process for less tech-savvy users and ensure greater robustness when QubesOS networking changes in the future. It is also preferable because it more closely resembles the typical VPN user experience. Rather than running nmcli commands and manually handling WireGuard configurations (which is not what normal VPN users do), users could simply install the app using the regular documentation. Usage would also be straightforward, which is ideal. Finally, the extra precaution of leveraging QubesOS to prevent VPN leakage would be much more appealing to new QubesOS users because it adds to the old way instead of replacing it.
That said, I propose installing the native app directly on all my VMs (or installing it once in a template, but you get my point). I don’t think many users have more than five VMs that require VPN connectivity, so Mullvad’s five-device limit would work for most. Otherwise, there is Solene’s nmcli WireGuard proxy VM. The only necessary thing is a way to prevent VPN leakage using the QubesOS method, also known as sys-firewall, to avoid a compromised VM with the native VPN app leaking a user’s real IP address. I would also be okay with manually whitelisting each server that I want to use.
Why not create a guide for some VPN providers and let the QubesOS community maintain sys-firewall scripts that conveniently add all the necessary firewall rules? The setup would then be incredibly easy, powerful, and flexible.
Also, perhaps a collaboration between the Whonix and Qubes communities to do the necessary research/experiments regarding the interplay between VPNs and TOR.
At the moment, it is very difficult (marked Too Difficult in this recent Whonix post) to setup a solid VPN-after-TOR configuration.
the term VPN - and it’s main purpose - is heavily misused nowadays.
the VPN is a service - most of the time - provided by a 3rd party.
the different VPN providers using different - and incompatible - technology under the hood. Some are open, but some others are not revealing any technical details.
neither of those providers, and not event the technology they use can provide ‘leak-proof’ solution out of the box.
What I mean by those points above?
Simply, those are the reasons why you can’t find a unified VPN guide. Let alone if you want this for Qubes OS, which has it’s unique architecture (among any other desktop OS)
Your idea:
I propose installing the native app directly on all my VMs
simply ignore most of the benefits that Qubes OS can offer for it’s users. However, it is working just like if you would use a ‘normal’ Linux distribution. If you are happy with that → go ahead and use it that way. No Qubes specific instructions and/or configurations are needed for such setup!
However, if you want more - and you understand what and how Qubes OS can provide you much more control - then you have to adopt to it’s architecture.
And why it is not so easy?
Because you must align with multiple different things:
the VPN technology and it’s limitations and features
the VPN service provider’s features are limitations (for example: all assumes that they are the only VPN clients on your machine)
Qubes OS also a changing target (iptables vs nftables)
there are also multiple VPN clients for the same technology
the very different expectations of the VPN users.
You might also noticed, that VPN is just about ‘secure’ routing… if you want to route all traffic trough the VPN tunnel, then additional actions are needed. And those (DNS resolution for example) are nothing to do with the VPN providers, neither with the VPN technology itself.
And there is still one big issue remains:
The false belief that a (3rd party) VPN can provide you anonymity.
I think the way forward is to self-host a hardened VPN in an offshore location that is immune to jurisdictions such as Epstein’s island and Washington, D.C. .
I tried to make my absolutely modest contribution, and now I await the Linux gurus:
Would you care to elaborate a little further on your current configuration?
That would certainly be interesting for those looking for free solutions in the immediate, or indeed to secure a devise before being able to obtain the preferred VPN setup.
I assume you are running 6 different VM’s with 6 VPNs… But that is an assumption. Of course we know who assumption is the mother of…
Anyway - I currently await the delivery of the software, and a few extra cables and adapters for my hardware VPN, and at this moment am using nothing outside of Tor, which is a little less that I would prefer to be doing right now. But hey… I can play around with Proton for a while before I do another clean install on the other machine I intend to be using.
then its pretty much plug and play for the price of an RPi, and 90 bucks a year.
Of course you don’t actually need the RPi, but that’s what makes it easy!
NOTE
The hardware option will inevitably force your entire machine (All Qubes) through the same VPN tunnel:
Qube/S > With or withoutTor > Hardware VPN > Outside world
Theoretically…
If that is not to your liking, and IF it is possible in Qubes for you to configure Ethernet Qubes (For the hardware VPN) AND a separate Wifi (Software VPN) Qubes network, then it could be possible to configure separate tunnels that are both running through your ISP router.
You could also run multiple RPi hardware VPN’s via Ethernet (If you don’t like getting microwaved to death) and/or multiple WiFi VPN’s
I’ve cloned default pristine fedora template to tmpl-protonvpn-fc42.
In that template I’ve installed ProtonVPN-app GUI.
On base of that template I’ve made sys-vpn-tmpl - for ease of creation.
Then I’ve cloned sys-vpn-tmpl to:
sys-vpn-crypto
sys-vpn-forums
sys-vpn-shopping
sys-vpn-torrent
sys-vpn-untrusted
sys-vpn-youtube
I’ve run proton in each of those sys qubes to login and configure. Some vpn’s have same exit country as mine, some have not.
Then I use (if you set particular sys vpn as Net qube in appVM then it starts with that appVM):
sys-vpn-crypto with app-crypto
sys-vpn-forums with app-forums
sys-vpn-shopping with dvm-shopping
sys-vpn-torrent with app-torrent
sys-vpn-untrusted with dvm-untrusted
sys-vpn-youtube with app-youtube
Simple.
I use no qube vpn with app-email, app-devel, dvm-banking and no sys use vpn as well.
Few qubes have no network.
I use one selected protonvpn wireguard server on my OpenWRT router.
Selected, because my old local e-mail provider don’t work with most local vpn servers - strange monkeys.
.
