by Default, the in-built windows L2TP client will attempt to tunnel all internet traffic over an L2TP VPN connection. This can of course be disabled to achieve a low level of split tunnelling:
Right click on the VPN adapter > properties > TCP/IP settings > Advanced. Clear the “use default gateway on remote network”
It’s been my belief till now that when using window’s L2TP client, and disabling the default gateway option will cause windows to only tunnel traffic destined to the same subnet as the VPN interface over the VPN. That is to say, if for example the L2TP server give a client the IP address of 192.168.200.1, then windows will only tunnel traffic destined to 192.168.200.0/24.
This is not ideal, what if you need to reach other subnets? This is a common requirement in larger networks, or with certain L2TP servers like SonicWALL which require a different L2TP client subnet. For example, my sonicwall gives the client an ip in the range 192.168.200.0/24, but I need to reach the 192.168.254.0/24 subnet also over the VPN. This is where Windows’ Connection Manager Administrator Kit comes into play. It comes free with windows server OS and can be used to generate an EXE file which can be distributed to clients. When clicked on, the EXE will install an L2TP connection which supports split tunneling to multiple subnets over the VPN.
There is an excellent guide over here:
I followed the steps outlined above very closely, but there were a couple of changes and notes that I needed to get it working:
– At figure 10 on the document above, even though it’s counter intuitive at this stage, do NOT remove the option to use the VPN connection as the default gateway.
– At figure 13, make sure you select the “only use L2TP option” and set a pre-shared key
– Keep on following the document, till you arrive at figure 17. the example does to use the “routing table update” option, but it’s the main feature we need. Create a text file someplace and insert the following lines (adapt to your network):
add 192.168.254.0 mask 255.255.255.0 default metric default if default
The first line will add the route to the subnet I need, but notice the gateway of this route points to “default” – which is the client’s current default gateway. This is why we have to leave the “make this connection the client’s default gateway” ticked previously.
When the route add command is run on the client, at that point in time the client’s default gateway is the VPN adapter. So the net effect is that we get a route added whose gateway points to the VPN adapter, just as we need.
The REMOVE_GATEWAY command removes the VPN adapter as the default gateway, returning the default gateway back to the client’s local gateway… giving us… split tunnels 🙂
– Keep following the document till the end, especially the step showing figure 30 – if you don’t do this you’ll face an error.
After running the connection you can see my default gateway remained 10.91.1.4 (my local LAN router), but I still have a route to the 192.168.254.0/24 subnet over my VPN (192.168.200.5)