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.

  • 1
    Boban P, please add the solution as an answer and mark that as the correct answer. Thanks! :-)
    – 3molo
    Commented Jul 8, 2011 at 7:14

1 Answer 1


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.

  • That's true but that route alrready exists: via dev tun0, and it's created every time openvpn is started on client
    – Boban P.
    Commented May 25, 2011 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
    Commented May 25, 2011 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.
    Commented May 25, 2011 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
    Commented May 25, 2011 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.
    Commented May 25, 2011 at 13:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .