Can ping openvpn server while connected but not others

Dispel

Hello,

Complete VPN and linux networking newbie here. What I need is to be able to connect using other services (samba etc) to other machines behind the openvpn machine. So I can login and use VNC and grab files etc.

I have a routed VPN I set up a couple weeks ago. I have not done anything with iptables. My openvpn server has IP 192.168.5.1 and my openvpn subnet is 10.10.0.X . I do not understand the route and push route stuff. Was just trying to follow examples to get it working.

server.conf has
port 8787
proto udp
dev tun
server 10.10.0.1 255.255.255.0
route 10.10.0.0 255.255.255.0
push "route 192.168.5.0 255.255.255.0"
push "route 10.10.0.0 255.255.255.0"
push "dhcp-option WINS 10.10.0.1"

When I connect I can ping 10.10.0.1 and 192.168.5.1 which are the same machine really
But I cannot ping 192.168.5.77 which is the desired target (as well as any other 192.168.5.X)

I'd like not only to solve the problem but to understand how this works and possibly how to diagnose.

Thank you to anyone who will help, I have been trying to solve this off and on with various push/route statements for a couple weeks now.

janjust

whilst your server config does not deserve the "config of the week" award there is nothing fundamentally wrong with it...
the reason you cannot reach any other host on the 192.168.5.x network is because either the linux server does not allow IP forwarding :

cat /proc/sys/net/ipv4/ip_forward

should return 1; if it does not, then do

echo 1 >  /proc/sys/net/ipv4/ip_forward

(this will not survive a reboot, modify /etc/sysctl.conf for that).

OR the clients on the 192.168.5/24 network are not aware of your VPN range (10.10.0/24); you can add a return route to the LAN GW on the 192.168.5.x network OR you can use masquerading to make all traffic to appear as if it were coming from the VPN server itself:

iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE

(where 'eth0' is the network interface with IP address 192.168.5.1)

Dispel

I would be a little more comfortable putting in a return route of some sort, but not sure about the rules to set that up. From reading various iptables statements and looking at the help, this is my *guess* but I feel I need some verification or help before trying it. Could you see if this is nonsense? The connections to the vpn server are happening via the eth1 interface, and the LAN is on the eth0 interface.

my forwarding is enabled, thanks for that.
Does this make any sense?
iptables -A FORWARD -i eth1 -s 10.10.0.0/24 -o eth0 -d 192.168.5.0/24 -p udp -j ACCEPT
iptables -A FORWARD -i eth0 -s 192.168.5.0/24 -o eth1 -d 10.10.0.0/24 -p udp -j ACCEPT

janjust

the VPN is on the tun interface, not on eth0 ; you'll want to forward all kinds of traffic, just not UDP.

which machine is the GW on the 192.168.5.0/24 network? the VPN server @ 192.168.5.1 ?

I'd go for iptables rules similar to

iptables -A FORWARD -i tun0 -s 10.10.0.0/24 -o eth0 -d 192.168.5.0/24 -j ACCEPT
iptables -A FORWARD -i eth0 -s 192.168.5.0/24 -o tun0 -d 10.10.0.0/24  -j ACCEPT

Dispel

Yes, the gateway is also the openvpn server. I will try those rules shortly and see how it goes when I get home (kind of annoying to test the VPN from inside the network...)

Dispel

So I tried these rules out, but as far as I can tell, nothing happens any differently now. I don't need to restart any daemon or anything to get the iptables rules to work, correct?

I can try the masquerade soon, but I was hoping to have the least general rule possible to take care of the situation just for security purposes. Maybe that's silly.

janjust

the iptables rules should take effect immediately.
I'd run tcpdump on the server and then try to ping a host on the 192.168.5.x lan from the VPN client; if you run

tcpdump -nnel -i eth1 icmp

then you should see all ping traffic to and from hosts on the LAN 192.168.5.x - is the VPN traffic there? do you see the right kind of return traffic?

Dispel

After several confused minutes of looking at the man page for iptables, I decided you probably meant tcpdump instead of iptables for that part 🙂

Will test soon.

janjust

of course I meant tcpdump - see previous post ;-)

Dispel

Okay so I tried this out.. What I get now is.. When logged into the VPN from outside, I get assigned IP for example 10.10.0.6.. From there I can ping 10.10.0.1 and 192.168.5.1 but not 192.168.5.77 still.. However from machine 192.168.5.77, I can also ping 10.10.0.1 and 192.168.5.1 (of course), but not 10.10.0.6..

Strangely, I am getting errors for an IP address 1 above the one I tried to ping. Like so..
192.168.5.78 > 192.168.5.1: ICMP 192.168.5.78 udp port 49920 unreachable

However 10.10.0.1 > 192.168.5.77 succeeds obviously. But I never pinged .78, or from .78, so I don't know why that shows up as the IP...

So puzzled now.

janjust

you are seeing ALL ICMP messages on your LAN now, including messages sent back to other clients when they try connect to port that is not available; the ICMP message

192.168.5.78 > 192.168.5.1: ICMP 192.168.5.78 udp port 49920 unreachable

means that client .78 tries to reach UDP port 49920 on the host .1 and was told that that port is not reachable.

Just for debugging purposes, try the masquerading rule to see if it works then - if that works then you go back to the routing issue. If that ALSO does not work then there's something else going on.

Dispel

Turned on the masquerade rule, still no dice. Everything is same as before. Though strangely I'm not seeing my pings to 192.168.5.1 in the tcpdump anymore (but they still ping correctly)

Dispel

What sorts of things can I do to figure out why this simple setup isn't working? I'm thinking I could maybe turn off the firewall altogether temporarily and see if that helps, but I don't think it's blocking anything internal to the network, so I'm doubting that is the problem. Hmmm...

janjust

I'd go for disabling the entire firewall to see if it helps.
The fact that it also does not work when masquerading is applied shows that there is something else going on - can you try running something like tcpdump/wireshark on a LAN client? you could then watch the flow of packets there: is traffic from the VPN client actually arriving on the LAN client? what kind of packets are being sent back? perhaps it's a firewalling issue on the LAN client, not on the VPN server itself.

Dispel

The LAN clients don't have firewalls enabled, but I will try to check this out shortly.

Dispel

Took firewall down for a microsecond and tested, but I still get no pings. Also, running on a LAN client, tcpdump sees nothing. So somehow the clients aren't receiving the traffic at all?

However, I decided to reset the iptables rules and try again from scratch in case anything I tried had been conflicting, and now, with just the two routing rules from before, I'm able to ping 10.10.0.6 (my VPN machine) from 192.168.5.77, which I found odd. I just can't ping the other way. Huh?

janjust

I'm able to ping 10.10.0.6 (my VPN machine) from 192.168.5.77, which I found odd. I just can't ping the other way. Huh?

this sounds like a classic firewalling issue , most likely on the .5.77 box itself ; try pinging the .5.77 from the VPN server using the VPN IP, e.g.

ping -I 10.10.0.1 192.168.5.77

most likely that also does not work...

Dispel

Actually, it does work just fine.

janjust

very odd..

Might be an ip_forwarding issue (ip_forward is still '1', right?) or an ARP resolving issue. Are there any virtual machines involved?

run 'tcpdump' again on the server LAN i/f and look for packets with a 10.10.0.x address ; compare the flow when pinging from the server (using -I 10.10.0.1) vs from the VPN client (10.10.0.6)

Dispel

forward is definitely on. no VM's...
on 192.168.5.2, I can see pings from 10.10.0.1.
but 192.168.5.2 definitely doesn't from the VPN client 10.10.0.6.

Even when I have turned firewall off.

Totally does seem like packets are not being forwarded though.

And just so you know I'm not insane.. cat /proc/sys/net/ipv4/ip_forward does indeed still return 1.

Also, is this usual? On the vpn client, when I type ifconfig, on my tun0 device, I have "inet 10.10.0.6 --> 10.10.0.5 netmask 0xffffffff"

Just confused about the 10.10.0.5 bit. I wanted to find some way to test if my vpn client is pinging from the right interface also, but ping -I 10.10.0.6 (or 5) to anything gets nowhere with error "flags cannot be used with unicast destination".