Sign up ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Here is the problem: Server is on LAN A, client on LAN B. Client can ping server, including hosts on LAN A, but hosts on LAN B cant ping addresses from LAN A. Tracoroute shows that ping from LAN B host to LAN A host, actually goes to gateway of client, instead to server. Both server and client are gateways to their LANs.

dev tun
proto udp
remote x.y.z.q 1194
resolv-retry infinite
user nobody
group nogroup
ca /etc/openvpn/ca.crt
cert /etc/openvpn/client.crt
key /etc/openvpn/client.key

port 1194
proto udp
dev tun
ca /etc/openvpn/easy-rsa/2.0/keys/ca.crt
cert /etc/openvpn/easy-rsa/2.0/keys/server.crt
key /etc/openvpn/easy-rsa/2.0/keys/server.key
dh /etc/openvpn/easy-rsa/2.0/keys/dh1024.pem
ifconfig-pool-persist ipp.txt
push "route"
client-config-dir ccd
keepalive 10 120
user nobody
group nogroup


Server routes: dev tun0 proto kernel scope link src via dev tun0 via dev tun0
x.y.z.0/24 dev eth0 proto kernel scope link src x.y.z.q dev eth1 proto kernel scope link src
default via x.y.z.1 dev eth0

Client routes: dev tun0 proto kernel scope link src via dev tun0 dev eth1 proto kernel scope link src
a.b.c.d/24 dev eth0 proto kernel scope link src a.b.c.d.5 via dev tun0
default via a.b.c.1 dev eth0 metric 100

When I traceroute 192.168.1.y (LAN A) address from 192.168.2.x (LAN B), the first hope is a.b.c.1 ?! How is that happened? IP forwarding is on. eth0 is interface with public IP on the client, I did iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Pinging from the same host is wotking. It's win 7.

share|improve this question
Boban P, please add the solution as an answer and mark that as the correct answer. Thanks! :-) – 3molo Jul 8 '11 at 7:14

1 Answer 1

up vote 1 down vote accepted

That's because the hosts on LAN B don't know how to route traffic to LAN A, so they send their packets to their default gateway. The default gateway obviously doesn't know anything about LAN A either, and therefore drops the packets.

In order to fix this, you will need to route traffic for LAN A through the tunnel. There are 2 ways to do this:

  1. Add a permanent route for LAN to the routing table on the default gateway in LAN B.
  2. Add a route option to the DHCP server in LAN B, so that all clients get this additional route when they acquire their IP addresses. This will require restart of networking on all clients (and destruction of the current leases, to guarantee that the clients do not just refresh the existing lease, which would NOT push the new route out to them).

The route that you need is along the lines of

route add <LAN A><netmask LAN A> gw <tunnel IP>

The exact syntax depends on whether the host is a Windows or Linux machine.

share|improve this answer
That's true but that route alrready exists: via dev tun0, and it's created every time openvpn is started on client – Boban P. May 25 '11 at 12:13
Could you update your post with the contents of the routing table from the default gateway on LAN B, please? And have you checked your firewall settings? – wolfgangsz May 25 '11 at 12:37
openvpn client is default gateway on LAN B. I don't have rules in iptables' filter table, and all policies are ACCEPT – Boban P. May 25 '11 at 12:44
Remove the masquerading from iptables. This translates requests from clients to the public IP of the gateway and then they go out via the public interface. Since you are on separate subnets, you don't need masquerading. – wolfgangsz May 25 '11 at 13:08
I need masquerading beacause hosts on LANs must have internet access. Anyway, I turned off masquerading on both server and client, but the problem persist. Now hosts on LAN A can't ping, but hosts on LAN B can, I dont know how. Openvpn client can still ping, host on server's LAN. – Boban P. May 25 '11 at 13:27

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.