Basic VPN question: Can a windows machine run concurrent VPN sessions?

[NicktheNewbie]

We have a number of customers whose systems we need regular access to via a VPN tunnel. Some people need to be able to access multiple customers from the same system, and thusly, the need to run multiple windows VPN sessions (disconnect one, reconnect another.)
Is it possible to have multiple windows VPN sessions to different networks - all concurrently going?

As I understand it, you can not do this.
Is there a way to do this, either with a hardware device at the user level, or with a "VPN Session Manager" type of application?

 

[John Lewis]

Some VPN clients don't play well with others, however generally speaking you should be able to make multiple connections from most clients.

Some vendor specific clients (Cisco, Nortel in particular) may be configured by the VPN admin to dissallow making connections to multiple networks at the same time, but your 'disconnect one, reconnect another' scenerio should not cause a problem there.

Short version, if all of your connections are based upon the same type of VPN, you should be fine. If you have a variety of platforms to deal with, you may or may not have a problem.

 

[NicktheNewbie]

Hmmm.
So, would/should the following scenario work:

Employee logs on to system: connects to CustomerA through a windows VPN session.
Next, Employee connects to CustomerB through a windows VPN session.
Now, 2 tunnels are going out to two different networks, is windows smart enough to know what traffic should go where?

I have tried this in the past, and got mixed results.

But, you're saying that the official line is, this should work?

 

[John Lewis]

Yes, it should, in theory. Everything has to be just right.

1.) All of the server side networks must be using RFC specified private addresses with the RFC specified mask. The server must assign addresses from within it's home network.

2.) All of the networks involved must have a unique network address.

3.) The 'Use default gateway on remote network' option must be disabled. (Actually, you could have it enabled on the last client connection.)

4.) All of the hardware between the client and the servers must be able to properly deal with GRE. That is the biggest problem. Much of the lower end router hardware that does NAT doesn't deal with it well. That situation is getting better, sometimes a firmware update will do the trick. The real problem there is you are at the mercy of the ISPs involved sometimes, as their hardware is in the middle as well.

5.) The OS should be thouroughly service packed on both ends. Some versions of the MS client do not behave as documented.

While we're here, some of the 'whys' that go with it.:

1 & 2 -- When a connection is created with the MS client, a route is added to the client's routing table. The gateway is the client side of the VPN connection. The destination and mask are inferred from the RFC specs. The server network must follow the specs in order for the route to be correct. Each network must be unique for the routing table to work. If two or more routes appear to point to the same network, only one will be used. Oddly enough, in some versions of the client, the routes are added even if they duplicate networks. (Actually, that might happen even in the current clients, haven't tried.)

3 -- If the default gateway option is in use, the network specific route mentioned above is not added. The default route is added and used to access the remote network. When another connection is made with the default gatway option enabled, the default route is changed and there is no longer a route to the prior network even though the connection is still live.

4 -- GRE is the protocol used for actual data on the connection. It doesn't follow a lot of the rules that otherwise apply to TCP/IP.

5 -- Main problem here is the addition of the routes. There are other things that were fixed along the way, but the routing is the only one that is applicable here.