internal zone there is 172.16.0.0/12 so 172.16~172.31.255.255
5 Likes
...now I must stop procrastinating...
And get to doing my taxes - only 8 days left to file 
LOL
3 Likes
Hmm, why didn't that show up in the routing table above?
2 Likes
VPN routing is not part of the normal routing table.
As the destination network is part of the encrypted tunnel between normal IPs [found in the routing table].
Thus, the system routing table is unaware of the contents/routes within VPN tunnels.
2 Likes
I'm not sure what you mean by this, but the traffic has to be routed through the VPN somehow, so there is A LOT going on in the routing tables with a VPN active, at least on my Gentoo GNU/Linux system:
Pretty simple routing table without VPN active:
osiris@erazer ~ $ ip -4 route list
default via 192.168.0.1 dev wlp3s0 proto dhcp src 192.168.0.2 metric 600
192.168.0.0/24 dev wlp3s0 proto kernel scope link src 192.168.0.2 metric 600
osiris@erazer ~ $
With VPN active there's a lot more going on to get everything routed through the VPN and route the actual encrypted VPN traffic correctly on the usual interface:
osiris@erazer ~ $ ip -4 route list
default via 10.23.0.1 dev tun0 proto static metric 50
default via 192.168.0.1 dev wlp3s0 proto dhcp src 192.168.0.2 metric 600
10.23.0.0/16 dev tun0 proto kernel scope link src 10.23.0.2 metric 50
192.168.0.0/24 dev wlp3s0 proto kernel scope link src 192.168.0.2 metric 600
192.168.0.1 dev wlp3s0 proto static scope link metric 50
203.0.113.76 via 192.168.0.1 dev wlp3s0 proto static metric 50
osiris@erazer ~ $
So I'm not sure why you'd say that "VPN routing is not part of the normal routing table".
You could also change the routing table above to only route specific routes through the VPN by removing the default via 10.23.0.1 dev tun0 route and add e.g. 172.0.0.0/8 via 10.23.0.1 dev tun0 as mentioned by OP in the post I quoted.
3 Likes
I guess it depends on the O/S.
I've seen some that separate the two, and VPN routing comes first.
2 Likes
I just tested the netstat -nr command used above and that too shows the VPN routes perfectly.
Maybe it's different on Ubuntu, I dunno.
3 Likes
To me, it makes sense for it NOT to be in the local routing table.
Let me explain...
Let's use:
-
local network ETH1 192.168.1.0/24
gateway 192.168.1.1 [internal IP] with 111.1.1.1 [external IP] -
remote network ETH2 192.168.2.0/24
gateway 192.168.2.2 [internal IP] with 222.2.2.2 [external IP]
On the local side the system routing would look something like just:
0.0.0.0/0 192.168.1.1 ETH1
And you would also like to see:
192.168.2.0/24 192.168.1.1 ETH1
[0.0.0.0/0 already covers that]
But the network 192.168.2.0/24 should actually route through 222.2.2.2 [the remote VPN gateway].
Seeing this makes no sense when shown in the normal routing table, as:
0.0.0.0/0 192.168.1.1 ETH1
192.168.2.0/24 222.2.2.2 ETH1
To me, the route table should be only "EXIT" signs.
Line two is more of a remote "ENTRANCE" than a local exit.
How can anyone route a specific network through "google"?
123.0.0.0/8 8.8.8.8 ETH1
Would that force that destination over the Internet to google? [I seriously doubt it - not without a VPN]
2 Likes
You wouldn't if the VPN was active. It would be routed through something like the tun0 device in my previous post.
4 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.