Home / server / Questions / 422439
In Process
artfulrobot
Asked: 2012-08-30 03:03:45 +0800 CST

OpenVPN server cannot ping clients

  • 772

I have OpenVPN set up on a Debian server. Clients can connect, and clients can ping and access resources (Samba shares and intranet) on the server.

However, the server cannot ping the client - it just times out.

Diagram

Client OpenVPN assigned IP: 10.67.15.26
   ↓ UDP on 1194
Internet
   ↓
Router port-forwards 1194 to server
   ↓ 
Server LAN IP: 10.67.5.1

Server OpenVPN config (relevant bits)

port 1194
proto udp
dev tun
server 10.67.15.0 255.255.255.0
push "route 10.67.5.0 255.255.255.0"

Server routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.67.15.2      0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.67.15.0      10.67.15.2      255.255.255.0   UG    0      0        0 tun0
10.67.5.0       0.0.0.0         255.255.255.0   U     0      0        0 eth1
0.0.0.0         10.67.5.254     0.0.0.0         UG    0      0        0 eth1

Server firewall

I've temporarily disabled the server's firewall, all chains' policies are ACCEPT and all forwarding flags are set:

1 : /proc/sys/net/ipv4/conf/all/forwarding
1 : /proc/sys/net/ipv4/conf/default/forwarding
1 : /proc/sys/net/ipv4/conf/lo/forwarding
1 : /proc/sys/net/ipv4/conf/eth1/forwarding
1 : /proc/sys/net/ipv4/conf/tun0/forwarding
1 : /proc/sys/net/ipv4/ip_forward

Test cases:

client: ping 10.67.5.1 works, as do other resources.

server: ping 10.67.15.26 times out.

routing

1 Answers

  1. By comparing two different clients I was able to identify and fix 2 problems.

    Problem 1: routing

    For some reason (and I'm not sure I've solved this), the server's routing table kept forgetting the route to/from its LAN (10.67.5.0/24). This was causing all outbound LAN traffic to go through its main gateway, which will not route to the OpenVPN LAN (10.67.15.0/24). This was causing traffic from the OpenVPN network destined for the LAN to fail at the main gateway; thus pings were being sent, but the reply was dropped.

    Edit: Unfortunately I do not know what was causing this route to be dropped; as you can see it was in the routing table above. I tried adding a route command into /etc/network/interfaces, but then I ended up with two duplicate, identical routes, so I took it out again. It was my fwbuilder config that was causing this route to be dropped: when setting up the eth1 adapter I had given a /32 netmask (i.e. a host) instead of /24 (for the LAN).

    By testing a Debian client, I was able to figure this one out, after this, it worked, but the Windows 7 client did not.

    Problem 2: Windows 7 firewall/config

    There were two problems with the Windows set up.

    Windows must have the "Work" private profile set for the TAP adapter

    Credit for this section goes to kalwi

    Update as of 2020-06-11

    You can change an interface to private using the following two powershell commands:

    # this first one will let you see the available connections, 
# find the interface index of the one you would like to change
Get-NetConnectionProfile
Set-NetConnectionProfile -InterfaceIndex NN -NetworkCategory Private

    In the "Network and Sharing Center" you should see (at least) 2 "active networks". I had the wireless network and then an "Unidentified Network". The latter is the OpenVPN TAP device, and it had a park bench icon, meaning it was treated as public, untrusted. In order to be able to change this, you need to add a default gateway for the adapter.

    Start a DOS/Cygwin terminal as administrator. (Start Orb > search for CMD > right-click it > run as administrator).

    Then do route print -4. You'll see an Interface List. Each line begins with a number and on the right you'll see the name. Identify the interface number for the TAP-Win32 Adapter. Mine was 17.

    Now add the route:

    route -p add 0.0.0.0 mask 0.0.0.0 1.2.3.4 metric 500 if 17

    Where 1.2.3.4 needs to be the IP of your OpenVPN gateway (revealed in the Gateway column in the output of the earlier command) and 17 needs to be your TAP interface number. The -p option makes the route permanent. I did it without this first, to test. This does assume that the client's OpenVPN gateway IP is not going to change between connections.

    Once you've done that a dialogue box should pop up and ask you to classify the new network. Choose Work.

    At this point, I was able to send traffic from my company LAN to the client (tested using netcat), however pings were still going unanswered.

    Tell Windows to allow pings (ICMPv4)

    Start Orb > Windows Firewall with Advanced Security Then go to Inbound Rules, and New Rule...

    • Custom Rule
    • All programs
    • Protocol: ICMPv4
    • Allow the connection
    • Apply to Private profile
    • Name it.

    Finally pings were returned.

    • 7