Why can’t I ping some OpenVPN adapter addresses?

In SSL/TLS server mode using a net30 style Topology, OpenVPN will not respond to ping on certain virtual addresses used solely for routing endpoints. Do not rely on pinging the OpenVPN endpoint addresses as a means of determining if the tunnel is passing traffic properly. Instead, ping something in the remote subnet, such as the LAN IP address of the server.

Note: This is not relevant when using a subnet style Topology

According to the `OpenVPN FAQ`_, 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, since on the server the ifconfig output looks similar to:

While the client shows:

In this case, .5 or .1. likely will not respond to ping. The .5 address will not respond because it is a virtual address, and .1 because there is no route to reach it directly. The .5 and .6 addresses are part of a /30 that goes from .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 will respond to ping, but not the local. This is also counter-intuitive, but works especially in cases where a site-to-site link is present. 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 will respond to ping from both ends.