Two years ago, I devised a Windows XP split tunneling solution that involved static routing. That solution had the advantage of being cheap, but also had the disadvantage of scaling poorly with any number of client computers.
Now I have a second solution that eliminates the static routing problems.
While researching new VPN security issues recently, I came across an obscure piece of information about the Windows VPN client. It is nestled cryptically in this one sentence from a Microsoft whitepaper:
When the Use default gateway on remote network check box is cleared, a default route is not created, however, a route corresponding to the Internet address class of the assigned IP address is created.
Absent any other explanation, that sentence requires some mental gymnastics to understand. Allow me to help with this.
The phrase “Internet address class” refers to an archaic system of grouping hosts together based on the numbers that precede the first dot in each IP address. While this system is generally not in use on the Internet today, the sentence quoted above indicates this system plays an important role in the Windows VPN client. To put it simply, Windows looks at the first number in the client’s assigned address before determining how to route traffic to the private network. If the client’s assigned address begins with “192” then the private route created by the client will always have a netmask of 255.255.255.0. This explains why additional routes must be added manually to create a split tunnel in my previous solution. With a fixed netmask of 255.255.255.0, the only other way to have both a private subnet and a VPN subnet would be to split up an address pool of only 256 numbers. That is not a realistic design constraint for most networks, so my new solution focuses on changing the private route’s netmask.
In this example, I will assume that the network addresses are as follows:
- Private network segment: 172.16.4.0/24
- VPN segment: 172.16.3.0/24
- VPN server: 172.16.4.8
- Private DNS server: 172.16.4.8
- Private network router: 172.16.4.1
Because “172” had been considered part of a different class from “192” in the early years of the Internet, this address scheme would cause Windows to use a netmask of 255.255.0.0 when routing VPN traffic. This change solves the problem of split tunnel networking with the Windows VPN client. There are, however, several other design considerations involved.
Why This Works
Using a “172” subnet in this example causes the Windows VPN client to use a 16-bit netmask and assume that every address starting with 172.16 is part of the VPN segment. This is desirable because all traffic for the subnets on the private network, regardless of their assigned netmask, will all need to route to the same next hop from the VPN client. The next hop is the VPN server. Traffic for the example subnets 172.16.3.0/24 and 172.16.4.0/24 will hop from the client to the server. At the server, these are recognized as separate subnets and they are routed appropriately. Also, as in my old solution, the Internet router on the private network has been configured with a route from the LAN segment back to the VPN server.
The technical problem with using a “192” subnet and a 24-bit netmask scheme across the board is that the Windows VPN client assumes the private network consists of only one subnet unless the remote gateway is the default route. On the VPN segment 192.168.3.0, any address beginning with 192.168.4 will fall outside of the VPN address range and will hop to the default gateway, unless some other route has been defined manually. In a split tunnel arrangement, the default gateway is going to be a hop toward the Internet, where the 192.168.4 address is invalid. Eventually, one might wonder why the VPN needs a separate subnet at all? The answer is that my design assumes the home network has two physical routers: One is the gateway to the Internet and one is the VPN server. The two distinct subnets are required for routing between the VPN clients, the private LAN hosts, and the two routers.
Advantages
- Client addresses can be assigned by the VPN server in the 172.16.3.1 – 172.16.3.254 range.
- Clients do not require a static route for split tunneling.
- Easy to implement on a new network.
- Server configuration is essentially unchanged.
Disadvantages
- Potentially expensive re-design of the entire IP addressing system on an existing network.
- If the client connects to the Internet with a foreign DHCP subnet of 172.16.0.0/16 then an IP routing conflict exists. However, 172.16.0.0/24 would work.
- Foreign DHCP subnets still must not conflict with the private network or VPN segment addressing. This is always a potential problem.
- In Windows XP, client configuration still requires hacking the registry to fix the binding order bug for proper DNS functionality.
Alternatives
In addition to the solutions described in my articles so far, Microsoft also offers a program called Connection Manager Administration Kit (CMAK). In my opinion, CMAK deployment adds another layer of complexity to the VPN design and it is critically inadequate for configuring security protocols such as PEAP. What CMAK does simplify is the process of adding routes to the VPN client configuration. In some rare situations, this might be the best way to set up a split tunnel connection.