Re-routing a nasty VPN connection
Using a VPN is usually a good thing, as it allows a secure connection between you and some secret / sensitive things. Those might be single devices (machines, servers etc.) or directly expose you to a whole (sub)network.
So it’s a quite natural solution to deploy a VPN setup when some of you workforce works from outside your sacred office (where you can physically control things). It might be that you employees are working some days from the home office or they might be sales persons who work, by design, “outside”.
I once got myself in a situation where I was forced to use a VPN to access some ressources, which is usually not a bad thing, but the VPN was configured in a way, that it routes all traffic through this VPN connection.
No just the IP-Range required to access the protected ressource. All of it. No matter if private or work related traffic. Even my online-banking traffic was routed through the VPN.
Making things worse: The VPN was breaking up the SSL chain and doing deep packet inspection and dediced wether or not I was allowed to access various services.
Idea of a solution
I’m per se not a hardcode network engineer but for our solution we only need to know a few basic things:
- Your computer has a routing table that defined how / where network is passed to
- This routing table can contain specific rules that, for example, say “route all traffic to
10.0.0.0/8through my VPN connection”
- But it also contains a
defaultroute that is used as fallback
- DNS servers are used to resolve human readable names (like
michaelcontento.de) to machine addressable IP addresses (like
With this knowledge in mind we can go and try to understand how the VPN will change our system. Once we know what the VPN client changes, we can find some counter measures 😎
Analysing the mess
I came up with the following strategy to analyse “the mess” the VPN client was producing in my routing table:
- Take a snapshot of the routing table before we estable a VPN connection
- Take a snapshot of the routing table after we have a VPN connection established
- Compare the two states and see what / who we can do about it
Luckily those three steps are pretty easy under macOS (the system I’m using), but same should be true for Linux and Windows.
- Before snapshot
netstat -rn > before
- After snapshot
netstat -rn > after
- Comparing both
diff before after
Pretty easy and this left me with a diff that looks like this:
15c5,6 2< default 192.168.32.1 UGScg en7 3--- 4> default 10.231.225.26 UGScg utun3 5> default 192.168.32.1 UGScIg en7 66a8,22 7> 10.231.225.26/32 127.0.0.1 UGSc lo0 8> 22.214.171.124/31 192.168.32.1 UGSc en7 9> 126.96.36.199/31 192.168.32.1 UGSc en7 10> 13.107.64/18 192.168.32.1 UGSc en7 11> 13.107.128/22 192.168.32.1 UGSc en7 12> 13.107.136/22 192.168.32.1 UGSc en7 13> 23.103.160/20 192.168.32.1 UGSc en7 14> 40.96/13 192.168.32.1 UGSc en7 15> 40.104/15 192.168.32.1 UGSc en7 16> 40.108.128/17 192.168.32.1 UGSc en7 17> 52.96/14 192.168.32.1 UGSc en7 18> 52.104/14 192.168.32.1 UGSc en7 19> 52.112/14 192.168.32.1 UGSc en7 20> 52.120/14 192.168.32.1 UGSc en7 21> 104.146.128/17 192.168.32.1 UGSc en7 228a25,29 23> 188.8.131.52/32 192.168.32.1 UGSc en7 24> 132.245 192.168.32.1 UGSc en7 25> 150.171.32/22 192.168.32.1 UGSc en7 26> 150.171.40/22 192.168.32.1 UGSc en7 27> 184.108.40.206 192.168.32.1 UGHS en7 2810a32,33 29> 172.27.2.112 10.231.225.26 UGHS utun3 30> 172.27.2.113 10.231.225.26 UGHS utun3
Looks bad on the first glimpse, but basically it can be read as this:
- The old
- A new
defaultroute is created that routes everything through
- Some IP blocks are actively routed through the old default route (
- I’ve checked some of the IP ranges and they all belong to Microsoft
- So I suspect this is some whitelisted traffic for MS Teams and other things
So to achieve our goal, we just need to somewhat “invert” the routing table. Right now we route EVERYTHING through the VPN (except for the whitelisted stuff) but we actually want to route ONLY SELECTED IP ranges.
So for my case the solutions was as simple as this:
- Establish the VPN connection as usual
- Remove the VPN based
sudo route -n delete default 10.231.224.9
- Instanciate our local
sudo route -n add default 192.168.32.1
- Whitelist the traffic we want to route through the VPN
sudo route -n add 172.27.16.88/32 10.231.224.9
- Enjoy your free, private and unwachted internet traffic