Client side devices can't ping server, Server can ping client

PerryJL

I have a client side network, 172.20.250.0/24 connecting to an Azure OpenVPNAS Server 2.5.2 with a vnet of 10.0.0.0/24 with routing enabled for the connection. Tunnel establishes and client side hosts are able to ping the OpenVPN eth0 interface (10.0.0.4). I have a second server in the same subnet 10.0.0.5 that my clients cannot ping.

Doing a tcpdump on the OpenVPN host, I see the packets reaching the eth0 interface but there is no reply:

sudo tcpdump host 172.20.250.57 -i eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
22:44:01.176938 IP 172.20.250.57 > dns1.internal.cloudapp.net: ICMP echo request, id 31298, seq 162, length 64
22:44:02.200874 IP 172.20.250.57 > dns1.internal.cloudapp.net: ICMP echo request, id 31298, seq 163, length 64
22:44:03.224875 IP 172.20.250.57 > dns1.internal.cloudapp.net: ICMP echo request, id 31298, seq 164, length 64
22:44:04.248798 IP 172.20.250.57 > dns1.internal.cloudapp.net: ICMP echo request, id 31298, seq 165, length 64

Strange thing is if I do the ping from DNS1 (10.0.0.5) to 172.20.250.57 it works as expected...

$ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.0.5  netmask 255.255.255.0  broadcast 10.0.0.255
        inet6 fe80::20d:3aff:fe18:ad0c  prefixlen 64  scopeid 0x20<link>
        ether 00:0d:3a:18:ad:0c  txqueuelen 1000  (Ethernet)
        RX packets 79153  bytes 27164779 (27.1 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 103155  bytes 23053926 (23.0 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

$ ping 172.20.250.57
PING 172.20.250.57 (172.20.250.57) 56(84) bytes of data.
64 bytes from 172.20.250.57: icmp_seq=1 ttl=62 time=25.6 ms
64 bytes from 172.20.250.57: icmp_seq=2 ttl=62 time=24.4 ms
64 bytes from 172.20.250.57: icmp_seq=3 ttl=62 time=24.9 ms
64 bytes from 172.20.250.57: icmp_seq=4 ttl=62 time=25.3 ms
--- 172.20.250.57 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 24.496/25.102/25.669/0.435 ms

OpenVPN AS Server

$ sudo tcpdump host 172.20.250.57 -i eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
22:48:11.926395 IP dns1.internal.cloudapp.net > 172.20.250.57: ICMP echo request, id 14247, seq 1, length 64
22:48:11.951396 IP 172.20.250.57 > dns1.internal.cloudapp.net: ICMP echo reply, id 14247, seq 1, length 64
22:48:12.928258 IP dns1.internal.cloudapp.net > 172.20.250.57: ICMP echo request, id 14247, seq 2, length 64
22:48:12.952243 IP 172.20.250.57 > dns1.internal.cloudapp.net: ICMP echo reply, id 14247, seq 2, length 64
22:48:13.930134 IP dns1.internal.cloudapp.net > 172.20.250.57: ICMP echo request, id 14247, seq 3, length 64
22:48:13.954087 IP 172.20.250.57 > dns1.internal.cloudapp.net: ICMP echo reply, id 14247, seq 3, length 64
22:48:14.932176 IP dns1.internal.cloudapp.net > 172.20.250.57: ICMP echo request, id 14247, seq 4, length 64
22:48:14.956410 IP 172.20.250.57 > dns1.internal.cloudapp.net: ICMP echo reply, id 14247, seq 4, length 64

Client Side Server

lab00001:~$ sudo tcpdump host 10.0.0.5
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp1s0, link-type EN10MB (Ethernet), capture size 262144 bytes
23:02:17.292096 IP 10.0.0.5 > lab00001: ICMP echo request, id 15009, seq 1, length 64
23:02:17.292154 IP lab00001 > 10.0.0.5: ICMP echo reply, id 15009, seq 1, length 64
23:02:18.294480 IP 10.0.0.5 > lab00001: ICMP echo request, id 15009, seq 2, length 64
23:02:18.294529 IP lab00001 > 10.0.0.5: ICMP echo reply, id 15009, seq 2, length 64
23:02:19.295995 IP 10.0.0.5 > lab00001: ICMP echo request, id 15009, seq 3, length 64
23:02:19.296031 IP lab00001 > 10.0.0.5: ICMP echo reply, id 15009, seq 3, length 64
23:02:20.297240 IP 10.0.0.5 > lab00001: ICMP echo request, id 15009, seq 4, length 64
23:02:20.297280 IP lab00001 > 10.0.0.5: ICMP echo reply, id 15009, seq 4, length 64

The other thing is sourcing pings from eth0 on the OpenVPNAS server to the client also fail:

$ ping -I eth0 172.20.250.57
PING 172.20.250.57 (172.20.250.57) from 10.0.0.4 eth0: 56(84) bytes of data.
--- 172.20.250.57 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1006ms

Azure has the route table updated to point to the OpenVPN as, the NSG's are fully open between 172.20.250.0 and 10.0.0.0... I am guessing this is something simple that I am overlooking, but just stumped at this point.

Thanks in advance for the help.

PerryJL

Ughhh....I totally missed this step since I built the server from the MarketPlace appliance...

Enabling IP Forwarding (required)
In order for your instance to function properly, IP forwarding will need to be turned on for your instance. You can do this by clicking on the instance on the Azure dashboard, then select Networking on the navigation bar.

Note: You will want to note the Private IP address that is displayed here for the next configuration step of this guide.

Afterward, click on the blue link right next to the text Network Interface. Select IP configurations from the newly created navigation bar, and click Enabled under IP forwarding to enable this option. Click Save to finalize the configuration.

The Johan

Hm well the weird thing is that Access Server itself always tries to enable IP forwarding by itself. But I mean there could be other programs interfering and disabling it. But usually the issue is just that it's a security setting that stops traffic that doesn't come from the instance's own network interface IP address itself. So generally it's a security thing that needs to be disabled. Looks like on Azure that's the way to do that. On Amazon AWS for example it's source/dest checking that usually stops routed traffic.