Connect through two VPN clients

Question

What exactly happens if I connect through two VPN clients on my laptop? For example, I connect using Cisco Any Connect, and then use another VPN client (such as HotSpot Shield or proXPN) to connect through another tunnel.

Will the actual data be decrypted at the first server/site and be in plaintext/visible? I mean, will this happen: data is encrypted at my laptop, sent to server 1, decrypted, then encrypted, sent to server 2 where it's finally decrypted. I doubt it, because the second tunnel is through my client to server 2, not server 1 to server 2.

Or will it be a tunnel in a tunnel? So: data is encrypted and encapsulated twice at my laptop, decrypted at server 1, but is not yet in plaintext, and would be routed to server 2 where it'll be finally decrypted.

Or will the laptop simply pick one tunnel (the latter?) for a normal client-to-site VPN? Or will the second connected not even establish in the first place?

Answer 1

A typical VPN client works like this: it connects to the server, and then it instructs the operating system to give him all packets which are to be sent to any address in a given set. For instance, let's assume that the VPN client advertises that it should handle all packets meant for 10.0.0.0/8 (i.e. all IP addresses which start with "10"). When the OS sees a packet which should go to address "u.v.w.x", it checks whether "u" is "10"; if yes, then it gives the packet to the VPN, which does its magic with it and forwards it, under heavy encryption/MAC/whatever to the server; otherwise, the packet is emitted "to the Internet" as the OS would have done without the VPN client.

Details on how this system is implemented depend on the VPN implementation (e.g. it may declare specific "routes"; or it could intercept all outgoing packets with firewalling rules and redirect the packets it is interested in;...).

If you have two VPN clients and their "advertised sets of addresses" do not overlap, then chances are that they will live together nicely at the IP level: each will grab the packets for its own virtual network, leaving the other packets untouched. However, they might also fight for the "interception resources" which may result in the first VPN client to be wholly deactivated.

On the other hand, if both VPN advertise overlapping sets of addresses, then trouble is pretty much guaranteed. If you are lucky, the second VPN will refuse to run with an explicit message. Otherwise, one of the clients may take precedence, possibly intermittently, and things will be weird and confusing. Possibly, one VPN server will receive the packets which were due for the other VPN, thus incurring a severe data leak.

There will be trouble with DNS. Applications and humans do not want to deal with IP addresses but with host names. The DNS converts host names to IP addresses. A VPN being a "virtual private network", it uses names which are not visible to the worldwide, Internet DNS. Therefore, a VPN client will not only intercept IP packets, but also the name resolution system, and redirect some (if not all) of name resolution requests to a dedicated DNS server on the VPN.

Your two VPN clients will compete for that redirection. Things might just work well if the clients manage to redirect requests for just some domains. But chances are that hijinks will ensue. Some names for one VPN will probably cease to be convertible to IP addresses, resulting in reduced functionality. Possibly, one VPN will receive name resolutions for the other VPN, so not only is the functionality broken (because the DNS in one VPN will not know what to do with names from the other VPN) but some private data leaks from one VPN to another (host names are rarely very sensitive, but that's still a leakage).

In this last situation, the VPN which receives name resolution requests for private names of the other VPN is in ideal position to respond with forged DNS answers and redirect all traffic from the other VPN to itself.

So don't do that. Running several VPN clients concurrently is a source of trouble, hard-to-diagnose failures and potential data leaks.

---

To avoid issues with multiple VPN, you should endeavour to use more "controlled" forms of VPN. For instance, a SOCKS proxy with ssh. This would allow you to run one Web browser which redirect all its traffic to another host (the "VPN server") while leaving the rest of the machine (and, crucially, other browser instances) unaltered. See this answer for instance. Some purists say that such proxying is not a VPN, but for many practical purposes (anything which is Web-based, really), this is functionally equivalent. See also the alternative with port-based tunnels.

I used to do that a lot at one time (a dozen or so port-based tunnels, and also SOCKS proxying, and it was all working well). The SOCKS solution works well for name resolution too: the name resolutions requests from the Web browser will go through the tunnel, to be resolved on the other side (i.e. in the VPN), without touching the local DNS configuration. Port-based tunnels require a static local name declaration.

Answer 2

For example, I connect using Cisco Any Connect, and then use another VPN client (such as HotSpot Shield or proXPN) to connect through another tunnel.

I assume that you are using both clients on a single computer, so you have two parallel tunnels, not one inside the other (as you would have if you connected from your computer to Server1, and there you fired up VPN2 to connect Server1 with Server2).

In the first (parallel) scenario, each VPN client will create its own virtual interface, with its own address, netmask, remote gateway and related routing.

Any data sent through a tunnel will be encrypted by that tunnel and no other, so the question becomes: how does your computer determine what data send down which tunnel?

This is done through routing rules on the client. For example, you might receive address 192.168.42.17/24 on VPN1, and address 192.168.77.13/24 on VPN2. If you tried to link with host .42.33, you would go through VPN1, and VPN2 would know nothing of it.

Now, 192.168.42.0/24 might only be the private network used between you and the server, i.e. the one assigned by Server1 to all its VPN clients; the real network served by Server1 could be 10.20.30.0/24, and therefore Server1 would also add a routing to 10.20.30.0/24 through 192.168.42.1; then when you try to connect to 10.20.30.137, that connection would flow through VPN1, be encrypted, and again VPN2 would not even know this is taking place (why should it?).

Possible problems: what happens if both VPN1 and VPN2 broadcast a route for the same subnet, which does not correspond to the same physical hosts? E.g., you have two offices with the exact same configuration, and ServerAtOffice1 has address 10.20.30.137, while ServerAtOffice2 has address 10.20.30.195. Since those two networks never talk to each other, this ensues no conflicts at all.

Until you fire up VPN1, which tells that 10.20.30.0 goes through VPN1, and then also fire up VPN2, which tells that, no, 10.20.30.0 goes through VPN2 and no one else.

What happens in that case depends on the VPN client. A smart client would tell you "Hey, I was about to route 10.20.30.0 but, what do you know?, this route already goes somewhere else, and maybe I could notify this to my System Administrator, just in case you were up to something frisky".

Or you might have two stupid clients, and the last to overwrite the other's configuration requests stands to profit.

Or something even weirder might go on, and connections might start working and then die messily a few packets later.

A final possibility could be that both clients want to set up a default route - one for addresses you don't know about - through themselves.

Then, when connected to Server1, all your Internet navigation could be encrypted through Server1. Then you also fire up VPN2, and the "default" navigation gets routed through VPN2. Now all your Google queries about Customer #1 are routed, in clear, through Customer #2's network, firewalls, packet analyzers and so on and so forth; which could spell no end of troubles, depending on your role and the two customers' amicableness of terms.

Answer 3

Two cases, two possibilities:

You could initiate a client connection from your laptop to the cisco, than a second connection from the cisco to the final target:

<laptop> ---- <cisco> ... <cisco> ---- <final>

In this case, datas will transit in clear at cisco host.

Or you could initiate a client connection from your laptop to the cisco, than a second connection from your laptop to the final target:

<laptop> ---- <cisco> .... <final>
<laptop> ----------------- <final>

In this case (while both encryption tunnels are initiated successively from the same host: the laptop), it will be a tunnel within a tunnel and cisco won't see unencrypted datas.

Nota: In this,

----  mean encrypted connection and
....  mean unencrypted (local or network) connection

Answer 4

Theoretically, it will be a tunnel within a tunnel. The first tunnel is between your computer and the first VPN endpoint. The second tunnel goes through the first tunnel to the first VPN endpoint where it exits the first tunnel and then goes to the second VPN endpoint.

I say theoretically because I think it depends how the VPN clients set up the connections and routing table. The second VPN client could set up the routing table and metrics in such a way that even if you have the tunnel in tunnel theoretical setup from above, data will be sent to the first tunnel and the second tunnel will not be used at all.