route -n

ifconfig

route -n



Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

192.168.1.0     192.168.200.200 255.255.255.0   UG    0      0        0 tap0

192.168.200.0   0.0.0.0         255.255.255.0   U     0      0        0 tap0

169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 eth0

172.16.0.0      0.0.0.0         255.255.0.0     U     1      0        0 eth0

0.0.0.0         172.16.1.1      0.0.0.0         UG    0      0        0 eth0

ifconfig



eth0      Link encap:Ethernet  HWaddr 00:1c:23:9c:4b:5b  

          inet addr:172.16.12.XXX  Bcast:172.16.255.255  Mask:255.255.0.0

          inet6 addr: fe80::21c:23ff:fe9c:4b5b/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:838360 errors:0 dropped:0 overruns:0 frame:0

          TX packets:1199028 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000 

          RX bytes:516467581 (516.4 MB)  TX bytes:105098470 (105.0 MB)

          Interrupt:18 



lo        Link encap:Local Loopback  

          inet addr:127.0.0.1  Mask:255.0.0.0

          inet6 addr: ::1/128 Scope:Host

          UP LOOPBACK RUNNING  MTU:16436  Metric:1

          RX packets:3881 errors:0 dropped:0 overruns:0 frame:0

          TX packets:3881 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0 

          RX bytes:213671 (213.6 KB)  TX bytes:213671 (213.6 KB)



tap0      Link encap:Ethernet  HWaddr 8e:66:1f:ca:5a:97  

          inet addr:192.168.200.200  Bcast:192.168.200.255  Mask:255.255.255.0

          inet6 addr: fe80::8c66:1fff:feca:5a97/64 Scope:Link

          UP BROADCAST RUNNING  MTU:1380  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:500 

          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

I have been troubleshooting an issue on Linux which has been reported by 

several people. The problem was difficult to identify since the client 

can establish a connection and negotiate IPSec SAs, but return traffic 

never makes it to the userland applications. For example, ping displays 

the following stalled output ...



mgrooms at ubuntu8-64:~$ ping 10.1.2.100

PING 10.1.2.100 (10.1.2.100) 56(84) bytes of data.



... even though you can see response packets using tcpdump ...



mgrooms at ubuntu8-64:~$ sudo tcpdump -n icmp

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

12:46:45.102547 IP 10.1.2.100 > 10.2.20.5: ICMP echo reply, id 32537, 

seq 1, length 64

12:46:46.102905 IP 10.1.2.100 > 10.2.20.5: ICMP echo reply, id 32537, 

seq 2, length 64



After a lot of tinkering, I was able to determine that the following 

sysctl setting will cause the kernel to drop packets received on one 

interface when the destination address is owned by another interface.



net.ipv4.conf.all.rp_filter



The documentation states the following ...



rp_filter - INTEGER

         2 - do source validation by reversed path, as specified in RFC1812

             Recommended option for single homed hosts and stub network

             routers. Could cause troubles for complicated (not loop free)

             networks running a slow unreliable protocol (sort of RIP),

             or using static routes.



         1 - (DEFAULT) Weaker form of RP filtering: drop all the packets

             that look as sourced at a directly connected interface, but

             were input from another interface.



         0 - No source validation.



For the client to work properly, this option value must be set to 0. 

Making the value stick on some systems can be a bit challenging. For 

example, the 8.10 Ubuntu host I used for testing has the following 

references to this sysctl option under etc ...



mgrooms at ubuntu8-64:/etc$ grep -r rp_filter *

sysctl.conf:#net.ipv4.conf.default.rp_filter=1

sysctl.conf:#net.ipv4.conf.all.rp_filter=1

sysctl.d/10-network-security.conf:net.ipv4.conf.default.rp_filter=1

sysctl.d/10-network-security.conf:net.ipv4.conf.all.rp_filter=1

ufw/sysctl.conf:net/ipv4/conf/all/rp_filter=1

ufw/sysctl.conf:net/ipv4/conf/default/rp_filter=1



I'm not sure which one should be set under what circumstances, but I was 

able to comment out all but the 10-network-security.conf line and set it 

to 0. After rebooting the host, the sysctl values looked like this ...



mgrooms at ubuntu8-64:/etc$ sysctl -a | grep rp_filter | grep -v arp

net.ipv4.conf.all.rp_filter = 0

net.ipv4.conf.default.rp_filter = 0

net.ipv4.conf.lo.rp_filter = 0

net.ipv4.conf.eth0.rp_filter = 0

net.ipv4.conf.pan0.rp_filter = 0

net.ipv4.conf.tap0.rp_filter = 0



And finally, everything works as expected using the VPN client ...



mgrooms at ubuntu8-64:/etc$ ping 10.1.2.100

PING 10.1.2.100 (10.1.2.100) 56(84) bytes of data.

64 bytes from 10.1.2.100: icmp_seq=1 ttl=64 time=1.55 ms

64 bytes from 10.1.2.100: icmp_seq=2 ttl=64 time=0.873 ms