If I were to run more than one VPN clients on my machine, simultaneously, what risks would be involved?

E.g. are there technical conflicts, such that it wouldn't work right?

Could there be address resolution conflicts?

More scary, can traffic from one network cross over, via my machine, into the other network?
Or can my traffic accidentally be misrouted to the wrong network?

If it matters, the VPN clients I'm running are Juniper Network Connect, and Cisco's AnyConnect (On fully patched and hardened Windows7). I don't know much about the remote endpoints...

5 Answers 5


I've used VPN client software on Mac OS X that hijacks the default route to send all traffic through the tunnel (actually, if memory serves me correctly, that was Cisco's). If two such clients were installed, or even one and a sane client, then the answer to the question "where will this packet go?" will be timing and implementation dependent. Likely options are that one of the clients will 'win' and will pick up all of the traffic, or that one of the tunnels is implemented via the other. What happens on Windows in such a case is beyond me.

When you talk about "address resolution" conflicts, this depends what you mean. If you mean ARP resolution, this shouldn't be a problem. As with any system connected to two networks there ought to be enough uniqueness in MAC addresses to avoid collisions. Regarding DNS resolution, it depends on the specific implementations of the VPN clients and of the client box on the private network. If they behave correctly, then it should be possible to use a DNS server over either private network or the public net (notice the possibility for name collisions on machines in the client's search domains, though). If they misbehave, then again it depends on the specifics of the situation.

  • Thanks, though @Thomas's answer is more "correct" from a purist point of view, this is actually more in line with realworld VPN's, as I see them...
    – AviD
    Commented Feb 8, 2011 at 14:56

On a quite fundamental level, a VPN emulates a "private network" whose purpose is to be isolated from the Internet at large. The "V" means that such isolation is performed cryptographically rather than physically; however, the model is still "separate cables". If your machine is part of two VPN simultaneously, then the private networks are not isolated anymore. This tends to contradict the very reason why the private networks were set up in the first place.

A VPN implementation is called such because applications need not be aware of it. Applications use standard Internet-related protocols (DNS for name resolution, TCP and UDP sockets...) and the VPN picks up traffic and does its magic transparently. A typical VPN implementation hooks itself in the system routing tables, to receive packets which are meant for a given class of addresses. Two VPN can work in parallel only if the addresses used in the two private networks do not overlap -- and that's not easy to achieve, since private networks, being private, do not use a global address allocation scheme. Private networks usually strive on the "private classes" such as 10.*.*.* and 192.168.*.*.

The DNS is a good illustration of the problem of accessing two private networks simultaneously. When an application wants to access a machine named "example", it does not know on which network it is. That's the point of private networks: applications need not be aware of the existence of the private network. The private network hosts its own name server, which can resolve names for the machines it hosts. If you link to two VPN, then, for each name resolution, you will have to talk to both name servers. Hence, the name server from private network 1 will also receive name resolution requests for names which are in private network 2. This is fishy. And if the same name is used in both networks, then all Hell breaks loose. This is the same problem than overlapping IP addresses, translated to the space of names.

Also, if your machine acts as a router, it will happily route packets from one VPN to the other. On a Linux system, this is as simple as:

echo 1 > /proc/sys/net/ipv4/ip_foward

which some Linux distributions will do for you if you asked for it at installation time. Depending on the user not doing something like that looks risky.

To sum up, the normal model for a VPN is that:

  • a given user system is part of the VPN, only the VPN (and thus only one VPN);
  • if the system must be able to talk to the "outer world", it may do so only through a dedicated gateway which, from the user system point of view, is part of the VPN.

In particular, a system linked to a VPN shall not be linked simultaneously to another network, be it the VPN or the Internet at large. A proper VPN software will hijack the default route and make sure that it sees all ingoing and outgoing traffic for the whole system. By nature, this does not tolerate the simultaneous presence of another VPN.

  • Great explanation here. One thing you've alluded to, which may be worth clarifying, is that a VPN should (and often does) also block you from accessing other resources on your local network. For example, when connected to the office over VPN, you should not be able to print documents off of a printer across your home network or copy corporate data to a separate file server on the home network.
    – Iszi
    Commented Feb 8, 2011 at 13:40
  • 3
    Very detailed, thanks! However, though this is correct from a purist PoV, I'm pretty sure that not all implementations actually work that way.
    – AviD
    Commented Feb 8, 2011 at 14:57
  • ok, let say that I connect into 2 VPN at same time and I request some IP address like Can VPNs be set up in such way that if via first VPN there is no connect for this IP it uses second VPN?
    – Cherry
    Commented Sep 11, 2018 at 11:50

The way I work things when I need to use multiple VPN clients is run them under VM's. This currently works really well for me, and avoids the conflicts Graham and Thomas mention - otherwise you can find the OS doing odd things when sending traffic (especially true under Windows)

It also means you don't easily make mistakes on sending data for one VPN down the other one (what I do is have the backgrounds on each VM customised for each environment)

You will need to watch your security requirements. Making sure routing does not exist between VM's is a good then (tm) here.

  • Nice idea here. I've been meaning to try running a VPN in VM, so I can have my work environment separated from my personal environment, but never got around to actually testing it.
    – Iszi
    Commented Feb 8, 2011 at 13:26
  • @Iszi - works really well. The segregation piece is very useful.
    – Rory Alsop
    Commented Feb 8, 2011 at 13:41
  • Very practical idea, thanks. Though in my case, I'm RDP'ing into other machines, which are actually hosting some VMs, so that level of meta-virtualization would just confuse me, be annoying, and make me think of those matryoshkas...
    – AviD
    Commented Feb 8, 2011 at 15:02

I'd suggest you contact both Juniper and Cisco and sign up to be test their client software. I doubt that either company would test this configuration on their own. If you have an issue I imagine the support tech would ask you remove the other companies VPN client and try to access the network again.

More importantly I think that you'll probably be violating someone's security policy. When you create a VPN connection to a site - that is to build a trusted connection. You seem to want to connect to two different trusted networks at the same time. If I managed the VPN headend I'd call accessing my site via one VPN and someone else's site via another VPN a security violation waiting to be exploited.


Not for nothing, but OS X 10.6.x+ will allow you to connect to multiple IPSec VPNs at once. As for passing ALL traffic through a VPN tunnel, yes, this is the default behavior, although Cisco (and I'm certain the same exists for other vendors such as Juniper, etc.) has a technique called "split-tunneling" where only some of your traffic is passed through the tunnel, i.e, the protected networks configured for you by your network admin. If traffic is not destined for one of those networks, then it goes out your regular WAN connection. This can be nice as it enables VPN clients access to the internet sans restrictions, yet also have access to corporate resources. This also eases the load on the corporate VPN servers as they're no longer processing as much traffic.

As for actually USING the built-in OS X VPN client to connect to more than one VPN at a time, I think also would be in direct violation of corporate security policy. Also, if you use a client such as Cisco AnyConnect, you can NOT connect more than 1 VPN instance at a time (AnyConnect is for SSL VPNs only, the built-in OS X Cisco VPN client is for IPSec VPNs only).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .