Re-routing a nasty VPN connection

2023-02-03 4 min read Networking Security

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 (like 10.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 via 192.168.32.1 gets inactivated
A new default route is created that routes everything through 10.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 route
- sudo route -n delete default 10.231.224.9
Instanciate our local default route again
- 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