Split-Tunneling for PPTP vpn clients

As far as I can tell Split-Tunneling isn't supported by the Windows XP vpn client.  By split-tunneling I mean sending traffic destined for the private network through the encrypted tunnel while sending all other traffic over the VPN client's local gateway.  What this means is that remote users that connect via VPN can access private/company network resources but CAN'T access the internet (this setup has no router, just a PIX firewall).  This is a real bummer for users; they have to repeatedly disconnect then reconnect just to access the internet while they're accessing the company network.


Windows XP's vpn client bumps up the metric of the client's local default gateway (from 1 to 11 on my machine) and adds the new vpn pool address as the new default gateway.  This can be seen in the output of "route print" from a command prompt; there will be 2 entries - these are the original default gateway (which has a metric of 11) and the VPN pool default gateway (which has a metric of 1).  Since routers use the route with the lowest metric, traffic only gets routed over the VPN tunnel.


However, if the vpn address pool overlaps the private network pool then windows adds a network route (a route for all packets destined for a network) instead of a default route ( = a route to use if nothing else matches).  So traffic destined for the company/private network gets routed properly and all other traffic uses the client's local gateway.  Be sure to disable the "use default gateway on remote network" tcp/ip option in the XP vpn connection settings otherwise clients won't be able to access the internet.



A packet's trip back

Should you find yourself setting up Remote Access VPN for a Cisco PIX firewall (or any Cisco IOS based device) you may find it helpful to keep in mind something that kept me stymied for a few hours.  Packets have to be able to make the trip back.  So if you've got a NAT rule translating all outbound packets so that they look like they're coming from your external IP then packets sent from the dial-up/vpn network wont be able to make the return trip.


In this setup, like most SOHO setups I imagine, the remote access VPN network is setup on the outside interface.  That's so that people can access it via their ISP.  Although TCP provides the illusion of a single connection, it's still based on packet switching which means that what you've really got are packets going in 2 directions.  Something like:


Source to dest is: Remote ISP -> VPN Server at outside interface -> pix firewall -> internal network on inside interface.

Dest to Source SHOULD be: internal network on inside interface -> pix firewall -> outside interface -> remote ISP


but with NAT in place, the trip through the firewall changes the packets to make them look like they're coming from the outside interface's external IP.  Since the remote ISP is waiting for packets from the internal network, it ignores packets that look like they're from the oustide interface's external IP.


The solution is to exempt outbound packets going to the vpn group from translation.


The other part of the solution is to allow packets from the vpn network (which is on the outside interface, a lower security interface) into the internal network.