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:
.