Requires Free Membership to View
But it's often possible to configure a single VPN Client with a policy that permits more than one destination to be reached. This is known as split-tunneling. For example, the VPN policy might say all traffic sent to 192.168.0.0/24 goes over LAN #1 in the clear (no VPN), and all other traffic goes over the VPN tunnel to Concentrator XYZ. Or it could say all traffic sent to 192.168.0.0/24 goes to Concentrator XYZ, all traffic sent to 10.0.0.0/24 goes to Concentrator ABC.
To accomplish this, you'll face two challenges: one technical, one political.
The technical challenge is whether you can come up with a VPN Client policy definition that reflects what you want to do. Are the IP addresses of the two private destinations you want to use non-overlapping and static? For example, if the remote host that connects to your machine has a dynamic address, configuring a policy could be tough.
The political challenge is whether whoever owns the VPN Concentrator will let you configure a VPN Client policy with split-tunneling. Split-tunneling is a security no-no for this very reason -- the configuration you want opens a back-door because (theoretically) traffic originating in network #1 could enter through tunnel A, route through your machine, then ride tunnel B into network #2. You could prevent this host routing through careful machine and VPN policy configuration, but the fact remains that some will consider this too risky.
One last point: I'm unclear about how you want to connect from a remote host to your machine. Your machine now runs a VPN Client to reach a VPN Concentrator. Your machine could use the same VPN Client to reach another VPN Concentrator, but that wouldn't let a remote host initiate an incoming connection to your machine. Or you could use a different client/server protocol to accept incoming connections to your machine -- for example, remote desktop access or a telnet server. In that case, you'll only have one VPN tunnel, not two. However, your VPN Client policy will still need to "have a hole" to exclude the client/server protocol from VPN tunneling.
This was first published in March 2005
Network Management Strategies for the CIO

Join the conversationComment
Share
Comments
Results
Contribute to the conversation