OpenVPN and one way pings

Question

Network configuration

I have set up a network:

Appropriate ports of computers in 192.168.87.0/24 are forwarded on TP-LINK router to be seen "all over the world".

IP forwarding in enabled on OpenVPN server.

I am able to connect from OfficeB from client1 to OpenVPN server in OfficeA. client1 and server see each other -- they reply for pings (both in 192.168.87.0/24 and 10.8.0.0/24 network), send data, create connections (i.e. ssh).

Routing table on TP-LINK router (a.b.c.d is a WAN IP):

DST             MASK                GATEWAY         IFACE
a.b.c.d         255.255.255.255     0.0.0.0         WAN
192.168.87.0    255.255.255.0       0.0.0.0         LAN & WLAN
10.8.0.0        255.255.255.0       192.168.87.2    LAN & WLAN (route added by hand)
239.0.0.0       255.0.0.0           0.0.0.0         LAN & WLAN
0.0.0.0         0.0.0.0             a.b.c.d         WAN

The problem

And now... From ANY computer in 192.168.87.0/24, I can ping 10.8.0.6. Unfortunately 10.8.0.6 can ping ONLY 87.1, 87.2.

But... 10.8.0.6 would start to ping a computer in 87.0/24 (for example 87.104) only if I pinged firstly from this computer to 10.8.0.6:

1. 10.8.0.6: ping 192.168.87.104 -- failed, time exceeded.
2. 192.168.87.104: ping 10.8.0.6 -- ok.
3. 10.8.0.6: ping 192.168.87.104 -- ok.

What I've checked

I've checked with tcpdump, that 192.168.87.104 DOES always get requests send replies for pings from 10.8.0.6. But the replies seem not to pass thru gateway TP-LINK router back to 10.8.0.6 -- I cannot see them with tcpdump on OpenVPN server on both interfaces.

I've also checked, that if I added a route on 192.168.87.104:

(1) route add 10.8.0.0 netmask 255.255.255.0 gw 192.168.87.2

then 10.8.0.6 would always get a ping reply, even if I hadn't pinged it from 192.168.87.104 before.

Another thing I've found out: pinging from 192.168.87.104 to 10.8.0.6 adds to routing cache (route -C) an entry (1). And in the ,,first ping'' (before the entry is added) I get:

PING 10.8.0.6 (10.8.0.6) 56(84) bytes of data.
64 bytes from 10.8.0.6: icmp_req=1 ttl=127 time=37.0 ms
From 192.168.87.1: icmp_seq=2 Redirect Host(New nexthop: 192.168.87.2)
64 bytes from 10.8.0.6: icmp_req=2 ttl=127 time=93.0 ms

I read, that this was a normal behavior, because the gateway to 10.8.0.0 was in the same network segment. And after icmp redirect host a new entry was created in routing cache.

The TP-LINK router, in web configuration panel, has a check-box SPI Firewall - Stateful Packet Inspection. Disabling it does not solve the problem.

My question

I can't understand why a ping reply 192.168.87.104 > 10.8.0.6 does not pass thru TP-LINK router despite TP-LINK router knows a route to 10.8.0.0 and ping request from 192.168.87.104 to 10.8.0.6 does pass.

So my question is: what is the reason? Is there anything I can do to solve the situation (except for adding a route (1) on each computer in OfficeA...)? I, personally, think that a problem is in TP-LINK router.

---

OpenVPN server configuration file:

port 1194
proto udp
dev tun

ca keys/ca.crt
cert keys/server.crt
key keys/server.key
dh keys/dh1024.pem

server 10.8.0.0 255.255.255.0
push "route 192.168.87.0 255.255.255.0"

client-to-client

keepalive 10 120
comp-lzo

persist-key
persist-tun

Solution

My guess is that the TP-LINK is initially dropping the ping replies from .87.104 to .0.6 because of a stateful firewall rule. Notice that when .0.6 pings .87.104, the TP-LINK router never sees the ping request packets. From the point of view of a stateful firewall, it is perfectly reasonable to drop ping replies if it never saw the original ping requests going in the opposite direction. Later, after .87.104 has sent some ping requests to .0.6, the firewall can allow ping replies from .84.104 to .0.6, since it has seen .87.104 initiate communication with .0.6 recently.

It may be possible to modify the TP-LINK's firewall rules. But since it is a "budget" brand router, I suspect your options will be limited to something like a "Stateful Firewall on/off" check-box. Or you may not even get that.

One possible solution is to add a second NIC to the Debian OpenVPN server, and make it Office A's internet gateway router. That way, the default gateway route on Office A clients will also work for 10.8 traffic, and you won't have to add an extra entry to all clients' routing tables. And as an added bonus, you will have the opportunity to use iptables to tailor your firewall rules to your heart's desire.

Comments

[jacek.ciach]

Yes, this TP-LINK has checkbox SPI Firewall - Stateful Packet Inspection. I tried (I forgot to mention it in my Q.) to turn of that SPI -- but the problem still existed. And I also thought about second NIC :). Thank you very much: you've confirmed my ideas:) BTW. I've just setup the connection A-B with OpenVPN Ethernet Bridging (dev tap)-- it's working perfectly now.