Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Network configuration

I have set up a network:

Network diagram

Appropriate ports of computers in 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 and 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         WAN         LAN & WLAN    LAN & WLAN (route added by hand)          LAN & WLAN             a.b.c.d         WAN

The problem

And now... From ANY computer in, I can ping Unfortunately can ping ONLY 87.1, 87.2.

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

  1. ping -- failed, time exceeded.
  2. ping -- ok.
  3. ping -- ok.

What I've checked

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

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

(1) route add netmask gw

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

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

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

I read, that this was a normal behavior, because the gateway to 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 > does not pass thru TP-LINK router despite TP-LINK router knows a route to and ping request from to 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

push "route"


keepalive 10 120

share|improve this question
up vote 2 down vote accepted

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.

share|improve this answer
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. – jacek.ciach Jul 6 '13 at 16:58

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.