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.


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

Server OpenVPN config (relevant bits)

port 1194
proto udp
dev tun
push "route"

Server routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface UH    0      0        0 tun0   UG    0      0        0 tun0   U     0      0        0 eth1         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 works, as do other resources.

server: ping times out.

1 Answer 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 ( This was causing all outbound LAN traffic to go through its main gateway, which will not route to the OpenVPN LAN ( 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
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 mask metric 500 if 17

Where 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.

  • I had to disable the windows defender firewall for "public" in order to get ping to work. My PC is at home, behind a router, so I'm less concerned.
    – Jacksonkr
    Jan 24, 2020 at 16:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .