Happy new year!
Once again I am in the situation where I have neglected this blog; feel bad about it; decide to write something to warrant its existence 🙂 …here’s a long overdue post to hold me over for a while:
I run my own VPN that permits split-tunneling, this allows me to access infrastructure behind a VPN but not route ALL of my traffic over it (i.e. Any network that is not in my routing table will be fired off to my default gateway).
When dialing my VPN whilst away from home I would often run into an issue where certain networks I needed to access via the tunnel were unavailable without me setting static routes manually. My operating system (Windows) & the type of VPN I was using were unable to set these routes autonomously based on information provided by the concentrator. Windows does not support this out of the box for simple SSTP/L2TP/PPTP VPNconnections (I think), generally a third-party client would be required [Cisco Anyconnect or OpenVPN for example].
To overcome the above problem I built a simple little tool that can set routes based on a config file during dial-up of a VPN – The workflow is as follows:
- User dials VPN endpoint
- Once VPN Establishes the VPNRouteHelper tool is invoked which:
- Checks if there is a config file on a web-server that is accessible on the one route published
- If the config on the server is newer we replace the existing config with the new one
- We then check for the presence of active PPP dial-up adapters on the computer and grab the tunnels IP address
- Check if that tunnel IP address fits between a set of pre-determined ranges
- If the tunnel fits inside a range we loop through a list of IP ranges we wish to set routes for and then assign a default gateway based on the tunnels IP address
- Displays a message of the day (if enabled in config)
Depending if the VPN concentrator allows us to access the networks using the newly set routes we should now be done:
An example of the config file that is consumed by the tools is below – in this example we we will set two routes one for 184.108.40.206/24 and 10.9.0.0/22 if the user has a PPP adapter that falls inside the ranges 192.168.10.2 – 192.168.10.254 or 192.168.2.2 – 192.168.2.254
<?xml version="1.0" encoding="utf-8"?> <!--Itterate Version number if You make any changes.--> <VPN Version="2"> <Routes> <Route netmask="220.127.116.11" subnet="255.255.255.0" description="Example Destination Subnet 1" /> <Route netmask="10.9.0.0" subnet="255.255.252.0" description="Example Destination Subnet 2" /> </Routes> <DefaultGateways> <DefaultGateway VPNSubnetLower="192.168.10.2" VPNSubnetUpper="192.168.10.254" DefaultGateway="192.168.10.1" SubnetDescription="RESDEV VPN 1 DialIn Range" /> <DefaultGateway VPNSubnetLower="192.168.2.2" VPNSubnetUpper="192.168.2.254" DefaultGateway="192.168.2.1" SubnetDescription="RESDEV VPN 2 DialIn Range" /> </DefaultGateways> <Messages> <MoTD Display="true" TitleMessage="Message From Admin" BodyMessage="This is a private VPN - You agree to all terms and conditions while using it" /> </Messages> </VPN>
This software does not require any external libs and is a self-contained .EXE that can be invoked automatically on connection (i.e. if you were to build a custom VPN client using the Microsoft Connection Manager Administration Kit [CMAK] like I did) or invoking it manually after you connect)
I might look at making this a bit more “enterprisey” at some stage, its not exactly a perfect solution but does the job at a pinch.
Grab the source code from my GitHub: https://github.com/coaxke/VPN-Route-Helper
Pretty easy solution – let me know if you have any questions 🙂