Leak proof VPN set up?

Does anyone know which of these leak proof set ups for vpn is preferable, or is there a better method out there?

I use this utility script, that lets you create multiple VPN app VMs and does all the configuration for you. It even lets you create and manage server profiles, so that you can select specific servers, automatically changes the server to which you’re connecting each time you reboot your VPN app VM ect… And a bunch of other pretty neat functionalities.


Don’t use that script, guy swoops in here post everywhere to use this script, then disappears.

It’s my understanding that any vpn setup using the qubes guide with “fail close” aka kill-switch will work for your needs. Somebody chime in if I’m wrong.

See the following:

@adw Am I correct that fail close is technically what is marketed as a kill switch on most VPNs? If so wouldn’t it be useful to mention in the documentation. Seems there are about 20 threads started about VPNs inside qubes failing, and people asking for kill switch or “leak proof” when what they’re looking for is actually called “fail close”. Tell me if I"m wrong here.

I’m the wrong person to ask about this, as I know very little about VPNs compared to many of the experts here. But, for what it’s worth, that sounds right to me. As a consumer, like you, that’s how I’d interpret such marketing claims.

Perhaps. The documentation is a community effort, especially the actual Qubes-Community documentation, so it’s up to folks like you to take the initiative to improve it when you see an opportunity to do so! :slight_smile:

I don’t know much about this topic, but I thought this was the whole point of qubes-tunnel. I see that it says:

This is closely based on the Qubes-vpn-support project.

But, to be honest, I don’t know what that means. Are we supposed to use both of them together somehow? Are we supposed to pick just one? How should we decide which one to choose? Does Qubes-vpn-support already include qubes-tunnel? (But then wouldn’t it say that instead of “closely based on”?) It’s all over my head, TBH. (I also notice that the documentation never explains why you need a tunnel in the first place and why the standard Qubes VPN setup of isolating the VPN client in a separate proxy qube with firewall rules restricting traffic to the VPN provider’s IP address(es) isn’t enough. I’m sure folks have their reasons; it’s just a bit surprising that the need and motivation for it isn’t presented upfront.)

1 Like

Yes I was confused about this as well. Is tunnel supposed to be chaining as referred to in the whonix documentation? And is regular vpn just using openvpn through network manager but with no tunneling? I won’t speculate which will turn into a labyrinth, instead I hope an expert on the differences can chime in.

Also I think you mentioned it before, but how do I edit documentation again? If I can get someone else to verify that yes "fail close is marketed as “kill switch by such and such companies” and then I’ll figure how how to add that blip very concisely and non-verbosely :laughing: in the docs.

One simple method is to configure the firewall that sits between sys-net and your vpn qube to only allow IP addresses of your VPN service. This way, if the connection fails, then any traffic attempting to reach sys-net will be blocked by the firewall since they won’t be attempting to reach the VPN’s IP addresses. This should function as a rudimentary kill switch of sorts.


Not technically-trained; consume with salt.

Not sure about the kill switch term, but you’re right about the “leak proof” == “fail close”.

Btw [1] doesn’t look like it fails close to me (there’s essentially no error handling anywere).

IIRC the two tasket repos are essentially the same, just one is newer and one is available as Qubes community package via dom0 qubes-dom0-update.

All in all I still believe the Qubes VPN doc is rather terrible and thus causing so many forum threads on the topic (cf. argument in [2]). Unfortunately it has been like that for the last 5 years or so.

[1] Sangsoic / QOSVPNM · GitLab
[2] VPN page requires rework · Issue #103 · Qubes-Community/Contents · GitHub

But how? Can I do this from sys-firewall settings in gui? And what is the format in this box? And don’t I have to also block DNS and mask?

Edit: I think I found the solution via Micah’s blog suggested by Sven, to save you from the expense, please don’t break your neck doing a full write on my behalf! But thank you setting me in the right direction. See Svens suggestion here: PSA: using a VPN under Qubes for Dummies - #5 by Sven

Yes, that’s my argument as well and it fits really well with the Qubes compartmentalization idea. In theory you could even use VPN scripts or programs that you don’t fully trust to be fail close.

Ironically the counter argument is that some people don’t trust the Qubes OS firewall code to actually do its job.
See [1] for the whole picture.

[1] VPN page requires rework · Issue #103 · Qubes-Community/Contents · GitHub

The GUI can’t be used for that, use qvm-firewall for full control over all Qubes firewall rules incl. DNS & ICMP.

For official docs:

For Qubes-Community docs:

1 Like

I have used the following guide in the past and it seems to work well. It involves using a separate proxyVM for the VPN configuration. The firewall settings and an “anti-DNS hijacking script” are both manually configured in the proxyVM, not sys-firewall. I assume it can be tweaked to accommodate other VPN service providers.

Hi all, is there any free VPN to use with qubes VM’s , like the free built-in VPN in Kodachi OS, also why don’t we all recommend to qubes team to include in qubes os a free built-in VPN like kodachi os developers did, thanks in advance

Hi all, is there any free VPN to use with qubes VM’s , like the free built-in VPN in Kodachi OS, also why don’t we all recommend to qubes team to include in qubes os a free built-in VPN like kodachi os developers did, thanks in advance

@Hero I am NOT speaking for the Qubes OS project, but I can tell you this:

  1. VPN protect you against very little. Basically you transferring your “trust” from your ISP to the VPN provider.

  2. Using a VPN the way you propose, amounts to reselling bandwidth. If that VPN is “free” the money for that bandwidth needs to come from someone else. You should ask: who is paying for it and why? … what are they getting out of it?

  3. Qubes OS ships with Whonix/Tor, which gives you everything a VPN could plus more. In case of TOR you are using a mix network where the entities running the nodes basically donate the bandwidth. They either see who you are but not where you connect to, or they see where you connect to but not who you are.

  4. Even the protection TOR can provide is explicitly limited and it won’t give you full anonymity / can be worked around by nation states and large corporations who have access to 80% or more of all internet traffic

So for Qubes OS to provide a build-in “free” VPN would mean:

  • the project recommending something that doesn’t actually provide much advantage (other than hiding your destination from your local access point)

  • creating a massive target

  • the project accepting bandwidth donations from someone, who needs to be trusted by all Qubes OS users

Nothing “reasonable” about that in my opinion.


Great points… but to be fair, all security is a matter of transferring trust. :wink:

I suppose if someone doesn’t trust a VPN provider (but trusts the protocol itself), another option would be to set up a private multihop VPN on off-shore servers with cloud providers that accept bitcoin or money orders (or cash?). Of course, that involves trusting the integrity of the cloud provider, trusting network infrastructure and trusting one’s own skills to configure everything properly.

Regardless of the approach, we can’t do much of anything alone. We are forced to trust many people and many things along the way - people we have never met and things we likely know little about. So when it comes to security, are we really trusting something “out there” or is it more a matter of trusting the trust itself - trusting our own choice to transfer trust? Perhaps the the problem is less a matter of objective measure and more of a game theoretic consideration with a healthy dose of intuition and a roll of the dice? :slight_smile:

@necker it’s all “best effort”.

I am trying to not fool myself and concentrate my energies at points where they actually matter.

In this particular case:

  • using VPNs to hide my connections from the local access point? … yes.
  • using VPNs to hide my connections from global persistent mass surveillance? … no.

Same with everything else: understand what it is and what it can do.

Lot’s of folks think having a qube named “firewall” will magically protect them (without ever understanding what it is and what it can and cannot do).

Others just can’t wrap their head around the concept that in a template based qube there is just no point to having a root password. Because they don’t understand the particular use case and have read in many other places that this is an important thing.

Yes… “best effort” sums it up nicely.

I also agree regarding common notions about privacy. It reminds me of a guy walking down the street with a t-shirt that has the word “INVISIBLE” written on the front of it.

A post was split to a new topic: Stop worrying about GPAs