I was looking for a way to configure a double VPN NetVM rather than just having two VPN NetVMs.
I found an interesting fork of a script, which was adjusted to work with qubes os.
In comparison to the original project, the fork was translated into english (at least the script source) and has some comments about a specific VPN provider. But from looking into the changes via the compare function it should still work like the main project with every vpn provider (which has openVPN configs).
The script could be found here:
It has some nice features like:
configurable length/hops of the vpn cascading chain
configurable random connection timeout to force building a new vpn cascading chain
random vpn cascading chain (it just picks random openVPN configs from a specific folder, which would allow to mix providers as well)
watchdog script to check the connection
There are some things like the alive/ip check (basically: wget -qO- icanhazip.com) I’m not sure about yet.
Or more obvious that it’s not designed with strong “install/update” security, so the source should verified manually before installing.
But besides that, as for the first look I had the code looks good.
What do you think about the solution / code quality ?
I’ll try the script later in a newly created NetVM and see how it works in sense of stability / usability and so on.
I would appreciate your thoughts and opinions a lot !
sorry if I gave not enough context to understand, but it has nothing to do with enrolling own crypto. It’s all based on openVPN connections.
But yes, if you think it through there are similarities to Tor.
I want to connect to a different VPN server of my provider or even to a different VPN provider:
Home -> VPN server 1 -> VPN server 2 -> website
or
Home -> VPN server 1 (provider 1) -> VPN server 2 (provider 2) -> website
But I’ve realized that there is a difference between a real VPN “cascade / multi-hop” and a “nested connection”. So it depends on how / where the connections are made, which is quite important.
I found this website which explains it in a good way:
Basically a multi-hop VPN / cascading VPN can help to mitigate against different “attack vectors”, e.g. traffic correlation.
One of the mentioned VPN providers in the link above has an explanation as well:
The “NeuroRouting” feature takes this idea one step further:
To get back to the script:
My first approach was just to make two NetVMs, each establishing its own VPN connection, but when I thought it through it came down to the “cascade / multi-hop” vs. “nested connection” difference.
I think the “common scenario for revealing users of nested connections” problem mentioned in the first link could be mitigated e.g. with proper firewall rules thanks to the qubes OS architecture. But I thought as well it would be nicer to just have one NetVM for that.
That’s where the script comes into place:
It basically implements the double / cascading / multi-hop idea, as explained in the first link, by handling the multiple openVPN connections, so for example setting the right gateway when connection to VPN server 2 or re-establishing the connection when a server becomes unresponsive or the configurable cascade timeout occurs. One of the “core” functions of the script (updown.sh) is from the VPN provider from the two links above. The rest of the script builds around that.
I hope this helps to understand better what I’m up to and also the questions l raised in the OP e.g. about the alive/IP check.
I think it’s still worth clarifying what your actual goal is. Privacy? If so, what kind of privacy and from whom? For example, if you simply want to hide your traffic from your ISP, you don’t need more than one VPN, so clearly you must want more than that. Do you want to hide your traffic from a nation state? If so, then this will almost certainly not be sufficient (if anything is).
It’s worth keeping in mind that the Tor Project has had dedicated specialists working on this for years. I repeat the caution that attempting a DIY solution is generally a bad idea, unless you’re just doing it as an experiment for fun (i.e., you can afford for it to fail).
Also, the VPNs are only one piece of the puzzle. You also have to take into account things like browser fingerprinting, VM fingerprinting, VPN leaks, and patterns in your own behavior.
Double VPN / Multi-Hop VPN / Cascading VPN is not a new thing nor experimental. It’s just the basic idea of networking to chain multiple connections, for completely different purposes. It’s done for years with different protocols. So it’s not about an own protocol, like Tor, it’s just about chaining connections. Basically, if you use a SSH jumphost to connect to another SSH server, you already have a “double / multi-hop / cascading” SSH connection.
The same is done with a variety of different protocol (combinations); here it’s about openVPN, but it would also work with IPSec + OpenVPN + whatever one can think of. In short, it’s also the nature of the NetVM concept.
Similar of having VPN → Tor, it’s about having VPN → VPN, or even VPN → VPN → Tor.
This brings me to your next question:
As mentioned, the reason why one would like to do that could differ - but in the context of qubes, for me it’s about security / anonymity / privacy. It’s a feature offered by a lot of different VPN providers for years.
In case of VPN → Tor, you want your ISP not to know you are using Tor, or the Entry Node not to know who you are.
For VPN → VPN → Tor there is a similar use case.
If one would use two different VPN providers and wants the second VPN Provider not know who he is; or he wants the first VPN provider not to know that he is using Tor.
For me personally, just using one VPN provider I “trust”, it’s about the enhanced security against e.g. traffic correlation.
I think the first two links of my second post explains the whole concept/idea and its reasons quite well. It would be nice to take the time to read them (if not done already) since they answer already the whys in more detail. They mention also censorship reasons (I’m not affected of), but just to show that the actual goal depends on the needs - but the technique / method is the same.
For sure! That’s one of the reasons why I’m using Qubes OS
thanks for pointing this out, that’s exactly how I’m using Qubes!
But instead of having just one VPN server in the chain (2nd link of yours), I want to make a VPN cascade with two or even more VPN servers. This is also useful without the Tor context.
This brings me back to my original post and the script:
@wobo: You’re right! From what I’ve read so far, the VPN provider needs to support this. Some may just forward the traffic without another layer of encryption (as pointed out in Multi-Hop: Advantages of a cascaded VPN connection).
But if the provider does support it, the script looks so generic that it should work with others than the mentioned once, too, I guess.
@everybody: I would appreciate thoughts about this a lot:
I think this is an issue since it could help to reveal the identity of a user. This should be mitigated somehow.
