What does netstat -r on OSX tell you about gateways?

Question

I noticed the route table has a lot of entries I do not understand.

The route tabel is:

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
default            192.168.0.254      UGSc           28        0     en1
10.8.0.1/32        10.8.0.5           UGSc            1        2    tun0
10.8.0.5           10.8.0.6           UH              2        3    tun0 
127                localhost          UCS             0      284     lo0 
localhost          localhost          UH             10     3663     lo0
169.254            link#5             UCS             0        0     en1
192.168.0          link#5             UCS             4        0     en1
192.168.0.25       localhost          UHS             0        0     lo0
192.168.100        10.8.0.5           UGSc            0        7    tun0

I believe this route says:

1. All traffic in 192.168.100.* should route to 10.8.0.5 (!?)
2. All traffic to 10.8.0.5 should route to 10.8.0.6 (!?)
3. All traffic to 10.8.0.1/32 should route to 10.8.0.5 (!?)

Why is 192.168.100 not going to 10.8.0.1, but instead to 10.8.0.5, and then from 5 to 6, and then i guess 1/32 is supposed to match 6, and it seems like there is a loop.

I can not ping 10.8.0.5, but I thought that was my ip on the vnetwork. I can not ping 10.8.0.6, however I think that is masked, I get some output "Communication prohibited by filter"

ifconfig shows:

tun0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    inet 10.8.0.6 --> 10.8.0.5 netmask 0xffffffff 
    open (pid 1307)

And there is 6 -> 5 again!

NOTE: from here down is just specifics, in case you need more info to understand the routes.

My setup is: - Laptop on local network (192.168.0..) with router (192.168.0.254) - VPN connected via virtual router (10.8.0.1) on net (10.8.0...) to a network of (192.168.100...) with router (192.168.100.1) - 192.168.100.200 is a server on the remote network

Now when i 'traceroute 192.168.100.200', i expected

10.8.0.1 (VPN router on the other side) 192.168.100.1 (Router on the physical network on the other side) 192.168.100.200 (host reached.)

Instead I just get an endless set of *s

This is not the same as this question, and I could not find an answer, so Thanks!

Solution

You are reading route information only partly correctly.

tun0 is virtual interface used for VPN, which uses (for it's own internal purposes) point-to-point link from 10.8.0.6 (VPNGW your side) to 10.8.0.5 (VPNGW remote side). That is the same thing that "ifconfig tun0" says to you. You should not access those two addresses directly.

So, any traffic you route via GW 10.8.0.5 will enter the VPN tunnel (via interface tun0), and exit VPN tunnel at other side (of course, assuming VPN tunnel is established and working, by VPN process running with pid 1307).

10.8.0.1/32 10.8.0.5 UGSc 1 2 tun0

This means that anything sent to host 10.8.0.1 (/32 is CIDR notation, meaning "just this one host") will be routed via gateway at 10.8.0.5 (that is, it will enter a VPN tunnel).

So when you ping 10.8.0.1, it will work only if VPN tunnels works. That's why it is here (so you can verify if tunnel is working, even if none of computers on the other side are up).

192.168.100 10.8.0.5 UGSc 0 7 tun0

same as above, but for whole class-C network 192.168.100.* (it could have also be written as "192.168.100.0/24" in CIDR instead of shorter "192.168.100"). This is the main thing you setup the tunel for - so you access this range of addresses on remote side via VPN.

10.8.0.5 10.8.0.6 UH 2 3 tun0

this one you got wrong, notice the flags "UH" - missing "G" means that is directly connected point-to-point link, and NOT a gateway through which you can route data. So it does NOT mean that traffic for 10.8.0.5 will be sent via 10.8.0.6, but instead only that 10.8.0.5 is directly visible to this computer (which has IP 10.8.0.6) using tun0 interface.

Why is 192.168.100 not going to 10.8.0.1, but instead to 10.8.0.5, and then from 5 to 6, and then i guess 1/32 is supposed to match 6, and it seems like there is a loop.

Hopefully the above info cleared up those misconceptions.

I can not ping 10.8.0.5, but I thought that was my ip on the vnetwork. I can not ping 10.8.0.6, however i think that is masked, i get some output "Communication prohibited by filter"

Yes, those two addresses are used internally by tun0 interface, and you should not concern yourself with them (unless you're running traffic analyzer between networks etc) - they won't work the way regular addresses would.

Comments

[Raystafarian]

Is this thread of any use?

[nycynik]

WOW. This is great information. Thank you, I read about the flags, and was very close to actually understanding it, now I feel like I have it! Thank you for the explanation!

[PnotNP]

@Matija do you know why ping 10.8.0.6 goes over the VPN tunnel? On Linux ping is answered like loopback address is.

[Matija Nalis]

@NulledPointer probably the different implementation detail of internal point-to-point link handling. IIRC Cisco routers also implement local endpoint handling of PtP link in the same way. Not that it should matter (except as academic exercise), as in practice you should never be doing anything with that IP address (in example above, you should ping 10.8.0.1 instead if you wanted to check if VPN tunnel is alive). Pinging 10.8.0.6 might check if the VPN tunnel is alive, or it might not (depending on local implementation as you noticed), so you should always avoid it.