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
I am able to connect from OfficeB from
OpenVPN server in OfficeA.
server see each other -- they reply for pings (both in
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) 220.127.116.11 255.0.0.0 0.0.0.0 LAN & WLAN 0.0.0.0 0.0.0.0 a.b.c.d WAN
And now... From ANY computer in
192.168.87.0/24, I can ping
10.8.0.6 can ping ONLY
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
ping 192.168.87.104-- failed, time exceeded.
ping 10.8.0.6-- ok.
ping 192.168.87.104-- ok.
What I've checked
I've checked with
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
OpenVPN server on both interfaces.
I've also checked, that if I added a route on
(1) route add 10.8.0.0 netmask 255.255.255.0 gw 192.168.87.2
10.8.0.6 would always get a ping reply, even if I hadn't pinged it from
Another thing I've found out: pinging from
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.
TP-LINK router, in web configuration panel, has a check-box
SPI Firewall - Stateful Packet Inspection. Disabling it does not solve the problem.
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
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
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