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”.
The problem
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/8
through my VPN connection” - But it also contains a
default
route that is used as fallback - DNS servers are used to resolve human readable names (like
michaelcontento.de
) to machine addressable IP addresses (like10.23.24.1
)
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> 13.107.6.152/31 192.168.32.1 UGSc en7
9> 13.107.18.10/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> 131.253.33.215/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> 154.14.194.89 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
default
route via192.168.32.1
gets inactivated - A new
default
route is created that routes everything through10.231.225.26
- Some IP blocks are actively routed through the old default route (
192.168.32.1
)- 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
The solution
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
default
routesudo route -n delete default 10.231.224.9
- Instanciate our local
default
route againsudo 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