Local LAN subnet cannot ping OpenVPN subnet

GRAUPS

All,

I have an OpenVPN server setup on a WNDR3700 ddwrt router. Everything is working great except computers on my local network are unable to ping computers on my OpenVPN subnet. I've read a myriad of other posts and guides looking for a solution, but have come up empty thus far. I assume I'm being squashed by a firewall or don't have a route setup properly, but I'm unsure how to diagnose this. While I have a basic understanding of what the firewall rules are doing, I also don't pretend to understand them completely. I'm looking for some help in understanding what's going wrong in the setup, and how to fix it. Please let me know if additional info is needed!

What Works :
An openvpn client can connect successfully to the server, access the internet, ping the OVPN server, ping the local router (192.168.1.2), ping local (192.168.1.0 subnet) computers, resolve local domain addresses... basically everything on the client side works.
Local subnet (192.168.1.0) computers can ping the OVPN server (192.168.2.1)

What doesn't work (and the goal of this thread to resolve) :
Local router (192.168.1.2) and local clients (192.168.1.0 subnet) cannot ping OVPN subnet (192.168.2.6 for example) clients (even though they can ping the OVPN server)

My setup:

WNDR3700 (local address : 192.168.1.2 - OVPN Server address : 192.168.2.1) :

Local Subnet :           192.168.1.0
OpenVPN Server Subnet :  192.168.2.0

Firewall Rules :

iptables -I INPUT 1 -p udp --dport 1194 -j ACCEPT
iptables -I FORWARD 1 -s 192.168.2.0/24 -j ACCEPT
iptables -I FORWARD -i br0 -o tun0 -j ACCEPT
iptables -I FORWARD -i tun0 -o br0 -j ACCEPT
iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -j MASQUERADE
iptables -I INPUT -i tun0 -j ACCEPT

DNSMasq Options:

interface=br0,tun0
no-dhcp-interface=tun0

Server Config :

client-to-client
push "dhcp-option DOMAIN graups.lan"
push "route 192.168.1.0 255.255.255.0"
push "dhcp-option DNS 192.168.1.2"
server 192.168.2.0 255.255.255.0
dev tun0
proto udp
cipher AES-128-CBC
auth sha1
comp-lzo
keepalive 20 60
dh /tmp/openvpn/dh.pem
ca /tmp/openvpn/ca.crt
cert /tmp/openvpn/cert.pem
key /tmp/openvpn/key.pem
verb 0
management localhost 16
push "redirect-gateway def1"

Client Config :

remote my.router.wan 1194
client 
remote-cert-tls server 
dev tun0 
proto udp 
cipher AES-128-CBC
auth sha1
comp-lzo
resolv-retry infinite 
nobind 
persist-key 
persist-tun 
float 
verb 0
ca ca.crt 
cert laptop.crt 
key laptop.key

maikcat

iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -j MASQUERADE

why are you perfoming NAT ?

Michael.

GRAUPS

Michael,

Thanks for your reply. Truthfully, I don't understand completely what network address translation does. What I do know is that if I remove that line, OVPN clients can no longer access the internet.

With that said, I went ahead and read the wikipedia article on NAT. It mentions that it maps one address space into another. I assume my NAT firewall line then is mapping the 192.168.2.0 subnet into the 192.168.1.0 subnet, which allows clients to access the internet? Is that somewhat correct?

I also noted in the article that MASQUERADE apparently hides an entire ip address space, which very well might be the problem you were hinting at.

Assuming my above analysis is correct, can you help me with an alternative to this line? One that will allow OVPN clients to access the internet and allow local (192.168.1.0 subnet) computers to communicate to clients in the 192.168.2.0 address space?

iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -j MASQUERADE

Thanks again for your help and your patience while I learn how to do this.

GRAUPS

maikcat

What I do know is that if I remove that line, OVPN clients can no longer access the internet.

so you want to redirect internet traffic through your openvpn server side...
that complicate things :S

I assume my NAT firewall line then is mapping the 192.168.2.0 subnet into the 192.168.1.0 subnet, which allows clients to access the internet? Is that somewhat correct?

partialy,NAT (in your case) alters from ip field on packets and replaces it with your
openvpn's server LAN ip,if you connect from a vpn client to a lan pc you will
actually see that your openvpn's lan ip is actually made the connection to your pc
not the vpn client itself...

you will need a rule to NAT traffic from vpn subnet destined to internet but not on your
lan itself...

something like:

iptables -t nat -A POSTROUTING -s 192.168.2.0/24  -d ! 192.168.1.0/24 -j MASQUERADE

not sure if the above works though... 🙁

Michael.

GRAUPS

Michael,

Thanks again for your reply.

so you want to redirect internet traffic through your openvpn server side

The above is correct, I would like to re-route traffic through the gateway

if you connect from a vpn client to a lan pc you will actually see that your openvpn's lan ip is actually made the connection to your pc not the vpn client itself

Thank you for this explanation, that does make sense. After playing around with it some more, I was able to verify this through an rdp session. I can open a rdp session from my ovpn client to a lan pc. Inside the rdp session, I ran the following in a windows cmd prompt to find the ip address of the connecting pc...

netstat -n | find ":3389" | find "ESTABLISHED"

...it revealed the following...

TCP    192.168.1.100:3389     192.168.1.2:45839      ESTABLISHED

...which verifies your statement, because the 192.168.1.2 address is the lan address of the router that the ovpn server is running on.

Next, I applied the new NAT rule that you came up with and ran the same test, here are the results...

TCP    192.168.1.100:3389     192.168.2.6:45835      ESTABLISHED

...which shows that the connecting computer is now on the vpn subnet (as it should be). Internet also works on the ovpn client with this new rule. So your new rule that you came up with seems to be making some progress! Thank you!

As a third test, just because I was curious, I reversed the roles. I tried to open a rdp session from a lan machine directly to the ip address of the ovpn client. To my amazement, it worked!

TCP    192.168.2.6:3389     192.168.1.100:56042      ESTABLISHED

For my purposes, this is what I wanted, so I think my problem is nearly resolved.

With that said, pings still fail from the lan to ovpn clients, which makes me think that there are still some paths that aren't defined properly. I really appreciate your help thus far, do you have any additional comments/ideas regarding the tests or ping failures?

maikcat

keep in mind that ping uses icmp and by default its dropped on vpn interface by windows firewall.

Michael.