IP Rules and Tables Confusion

Question

After using openVPN, I have a new TUN device. I also followed some steps online to allow incoming transmissions into my server, however, I don't understand how it's working.

ip addr:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether b8:27:eb:e2:97:22 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.129/24 brd 192.168.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::de8d:8f16:39a0:8bb9/64 scope link 
       valid_lft forever preferred_lft forever

3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether b8:27:eb:b7:c2:77 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::6877:4a6e:7067:da26/64 scope link tentative 
       valid_lft forever preferred_lft forever

4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none 
    inet 10.8.8.118 peer 10.8.8.117/32 scope global tun0
       valid_lft forever preferred_lft forever

ip rules:

0:  from all lookup local 
32765:  from 192.168.0.129 lookup 128 
32766:  from all lookup main 
32767:  from all lookup default

128 table:

default via 192.168.0.1 dev eth0 
10.8.8.117 dev eth0  scope link

main table:

0.0.0.0/1 via 10.8.8.117 dev tun0 
default via 192.168.0.1 dev eth0  metric 202 
10.8.8.1 via 10.8.8.117 dev tun0 
10.8.8.117 dev tun0  proto kernel  scope link  src 10.8.8.118 
128.0.0.0/1 via 10.8.8.117 dev tun0 
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.129  metric 202 
198.148.86.170 via 192.168.0.1 dev eth0

local table:

local 10.8.8.118 dev tun0  proto kernel  scope host  src 10.8.8.118 
broadcast 127.0.0.0 dev lo  proto kernel  scope link  src 127.0.0.1 
local 127.0.0.0/8 dev lo  proto kernel  scope host  src 127.0.0.1 
local 127.0.0.1 dev lo  proto kernel  scope host  src 127.0.0.1 
broadcast 127.255.255.255 dev lo  proto kernel  scope link  src 127.0.0.1 
broadcast 192.168.0.0 dev eth0  proto kernel  scope link  src 192.168.0.129 
local 192.168.0.129 dev eth0  proto kernel  scope host  src 192.168.0.129 
broadcast 192.168.0.255 dev eth0  proto kernel  scope link  src 192.168.0.129

Can somebody explain what route a packet would take through this? I'm mainly confused about Table 128. Without that rule and table, I'm unable to SSH into or connect to the server on my machine from outside our network when the VPN is running. How does adding those two rules allow me to do this? What are they saying?

score 0 · Answer 1 · answered Jan 12 '17 at 18:41

In a world without NAT, without stateful firewalls, and with every interface having addresses with publicly routable IPs, this would not be necessary. But, we don't live in that world. We live in a world where a typical connection usually goes through several firewalls and NAT devices.

Basically you are having an asymmetric routing problem.

Asymmetric routing is not a problem by itself, but will cause problems when Network Address Translation (NAT) or firewalls are used in the routed path.

When a client device makes a ssh connection to your host it will have the src ip/port destination ip/port in the tcp/ip headers. The reply packets will have the src ip/port of the ssh's interface that will be used to reply and the destination address/port of the remote host. In the your example here, you have two ways incoming packets can get to you though, and the default outgoing route is different from the incoming address that will be used. Without your added rules in place the the reply packet is sent, it will have a different src ip/port then what the ssh client's firewall was expecting based what was used with the outgoing packet was sent. Because the destination in the outgoing packet isn't the same as the source in the reply, it may get rejected by a firewall, or may not match something in your NAT state table.

The rules you put in place basically force the incoming system to reply from the interface it received the request on, meaning all the addresses will match up correctly, and the packets will be permitted through any firewalls.

Thank you for that information. It cleared up a lot for me. Just to test my understanding... So anything originating from the host will have a host IP of 192.168.0.129, and will then go into table 128. If the packet was originally received and routed through the VPN, then the source IP would have been 10.8.8.117, and so the return packet would have this as the destination IP, thus invoking the second rule in table 128. For anything else, it goes straight to the 192.168.0.1 gateway. Does that sound right? Also, why is the second rule in table 128 being sent through eth0 instead of tun0? — jeebs, Jan 13 '17 at 06:22

IP Rules and Tables Confusion

1 Answers1