Take the 2-minute tour ×
Server Fault is a question and answer site for professional 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.

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

Server:
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
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.1.0 255.255.255.0"
client-config-dir ccd
route 192.168.2.0 255.255.255.0
keepalive 10 120
user nobody
group nogroup
persist-key
persist-tun

ccd/client:
iroute 192.168.2.0 255.255.255.0

Server routes:
10.8.0.2 dev tun0 proto kernel scope link src 10.8.0.1
10.8.0.0/24 via 10.8.0.2 dev tun0
192.168.2.0/24 via 10.8.0.2 dev tun0
x.y.z.0/24 dev eth0 proto kernel scope link src x.y.z.q
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.1
default via x.y.z.1 dev eth0

Client routes:
10.8.0.5 dev tun0 proto kernel scope link src 10.8.0.6
10.8.0.0/24 via 10.8.0.5 dev tun0
192.168.2.0/24 dev eth1 proto kernel scope link src 192.168.2.1
a.b.c.d/24 dev eth0 proto kernel scope link src a.b.c.d.5
192.168.1.0/24 via 10.8.0.5 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 8.8.8.8 from the same host is wotking. It's win 7.

share|improve this question
1  
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 0 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: 192.168.1.0/24 via 10.8.0.5 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 8.8.8.8, but hosts on LAN B can, I dont know how. Openvpn client can still ping 192.168.1.2, host on server's LAN. –  Boban P. May 25 '11 at 13:27

Your Answer

 
discard

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.