OpenVPN Adapter Address ICMP Behavior

When using the older net30 topology, OpenVPN will not respond to ping on certain virtual addresses used solely for routing endpoints. Thus, in net30 topology mode pinging the OpenVPN endpoint addresses is unreliable as a means of determining if the tunnel is passing traffic properly. Instead, ping something inside the remote subnet, such as the LAN IP address of the peer.

In contrast, subnet topology in OpenVPN does not use virtual addresses and per-client subnets so it does not have these limitations. OpenVPN servers and clients using subnet topology are capable of responding to ping requests on their interface addresses.

The OpenVPN FAQ addresses this behavior in the section titled Why does OpenVPN’s “ifconfig-pool” option use a /30 subnet (4 private IP addresses per client) when used in TUN mode?:

As 192.168.1.5 is only a virtual IP address inside the OpenVPN server, used as an endpoint for routes, OpenVPN doesn’t bother to answer pings on this address, while the 192.168.1.1 is a real IP address in the servers O/S, so it will reply to pings.

This may seem a little counter-intuitive as an OpenVPN server interface may look like this in ifconfig:

tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
        inet6 fe80::202:b3ff:fe03:8028%tun0 prefixlen 64 scopeid 0xc
        inet 192.168.100.1 --> 192.168.100.2 netmask 0xffffffff
        Opened by PID 27841

While the client shows:

tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
        inet6 fe80::202:b3ff:fe24:978c%tun0 prefixlen 64 scopeid 0xa
        inet 192.168.100.6 --> 192.168.100.5 netmask 0xffffffff
        Opened by PID 1949

In this case, .5 or .1 will not likely respond to ping. .5 because it is a virtual address and .1 because the client has no route to reach it directly. The .5 and .6 addresses are part of a /30 subnet that encompasses .4 to .7 and trying to ping .1 would go out the default route instead.

There are many cases where the far side of an OpenVPN tunnel can respond to ping, but not the local. This is also counter-intuitive, but works especially in cases where there is a site-to-site link. If the server shows its tun addresses as x.x.x.1 -> x.x.x.2 and the client shows the reverse – x.x.x.2 -> x.x.x.1, then the far side will likely respond to ping from both ends.