Anyone who has attempted a Virtual Private Network (VPN) connection in Windows XP has run into this problem: You want to have access to computers at your home or office, but Windows accomplishes this by routing all of your activity to the home network. If your work involves transferring files to a server and surfing the Internet, then your Internet activity has to piggyback on the VPN and travel twice within your limited home bandwidth. This means your slow VPN is even slower when you load a website, and any interruption of the VPN will break all of your connections to FTP sites, IM services, etc.
You may have tried to coerce Windows into routing your traffic to two different gateways, but quickly realized it wasn’t designed to do that. Adding entries to the local routing table can solve the problem temporarily, but doing so requires administrative privileges and ugly dynamic logic to handle a gateway address that changes every time you connect the VPN.
My solution for this scenario comes in two parts: 1. A static address for the VPN client computer, and 2. A persistent route for the VPN client’s static address. This is a bit easier said than done, so the following tutorial includes screenshots and details.
To get started on a split tunnel system, you will need a Windows XP VPN connection that is already working. In this example, I will assume that the network addresses are as follows:
- Private network segment: 192.168.4.0/24
- VPN segment: 192.168.3.0/24
- VPN server: 192.168.4.8
- Private DNS server: 192.168.4.8
- Private network router: 192.168.4.1
If your addresses are different, or if your VPN server is located on the network router, then you will need to make the appropriate adjustments to the screen shots. For the sake of separating static addresses from dynamic addresses, I have chosen to reserve the upper half of the VPN address range for static addressing. My first static client is numbered 192.168.3.128. That address gets typed into the TCP/IP networking properties of the VPN connection, along with the address of the private DNS server.
To begin splitting up private from public traffic, the default configuration needs to be changed by clicking the Advanced button. In the Advanced TCP/IP Settings window, disable the option named “Use default gateway on remote network”. You should also specify the address of your private WINS server where appropriate.
After saving the new TCP/IP settings, you will likely need to correct a bug in the Windows XP registry. For whatever reason, the network binding order specified in the Network Connections Advanced Settings menu doesn’t work properly. The way to fix it is to change the order of the devices listed in HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage\Bind. The line at the top of the value must say “\Device\NdisWanIp”, and it must be moved if it shows up in any other order. This step should be completed carefully by following the Microsoft knowledge base article, Cannot Change the Binding Order for Remote Access Connections. If you skip this step, you might notice that all of your DNS queries are sent to the wrong server. It is important to use your private DNS server so that your client computer can resolve private addresses.
The next step should be relatively easy, so I will simply explain what to do. You need to add a “persistent route” on your client computer, for your home network, pointing to the static client address. Here is how I did that:
- Connect to the VPN.
- Use “route print” in a Command Prompt window to find the WAN Interface hex number. Example: 0x60004
- Use “route -p add” to create a persistent route to the home network. Example: route -p add 192.168.4.0 MASK 255.255.255.0 192.168.3.128 METRIC 1 IF 0x60004
After you finish that step, the next time you connect the VPN, you should get a split tunnel routing table like mine automatically. I have highlighted in yellow all of the table entries that are created automatically when the VPN is connected. The first highlighted line shows the route for the VPN connection itself. The next three highlighted lines are the VPN segment routing. Next, you can see that Windows has automatically added a route to the home network, 192.168.4.0, using the static address of 192.168.3.128 as the gateway.
If the steps above seemed a little too easy, it’s because half of the magic happens in the home network and not in the client itself.
First, the Routing and Remote Access Service (RRAS) must be configured with the lower half of the VPN address range for dynamic addressing. In this example, I used 192.168.3.1 – 192.168.3.126. Next, you need to make sure that your user account is allowed to connect remotely, and is allowed to use a static address. The default policy settings will require that the VPN client use an address provided by the VPN server instead of a static address, so be sure to use the “Client may request an IP address” setting.
The last two steps are equally important. Because the VPN server has a private address, the private network router must be configured to route incoming public VPN traffic to the VPN server.
Finally, the reciprocal of the client’s “persistent route” must be considered. If the client attempts to communicate with any computer on the private network other than the VPN server, that other computer will recognize the connection’s return address, 192.168.3.128, is not a local computer, and promptly send a response to its default gateway, 192.168.4.1. That is indeed the correct place to send such information, but the router doesn’t have any physical segment in that address range. The router has to be configured to send private VPN traffic to the VPN server.
Obviously, there is more than one possible approach to this solution. The VPN server can be configured to assign static addresses to each user, but I felt it was more appropriate to assign them to each computer. There are also 3rd-party solutions and better hardware that could accomplish all of this. But if you love Windows XP VPN connections for what they’re worth, you should love the idea of splitting public and private connections over the Internet.
Update: For some new ideas, check out my follow-up article, Split Tunnel VPN Part 2.