I'm writing this post to document how an issue was found – and resolved.

The Symptom:

On an internal network, it was possible for me to ping 10.11.22.33 but the office staff could not get a ping reply from this address. They could, however, get a ping reply from several other IP-addresses that were nearby.

Diagnosis:

Since this is an OpenVPN situation, we first ran Wireshark on the OpenVPN machine to verify that, when any of these addresses were pinged, the ping arrived at the OpenVPN machine. Of course we already knew that this worked for most addresses. We now verified that 10.11.22.33 was not being omitted. Indeed, we saw the ping.

Then, we checked the routing table (netstat -r) to make sure that these addresses were then routed into OpenVPN's gateway address. Once again, verifying that the address was not being omitted. Indeed, we saw that this address was being routed.

Connecting now to different machines on the other side of the tunnel, a command such as sudo tcpdump -nni ens33 icmp (specifying an appropriate adapter ... or, omitting the adapter entirely) showed that ICMP Echo Request messages were being received, and that they were promptly being given a Echo Reply ... except on this machine, and then only when the request came from the office staff. Only in this case, there was no Reply.

Explanation:

This is a routing problem. The machine at 10.11.22.33 did not know to send traffic from the Office 10.20.30.xx back to its OpenVPN server (at 10.11.22.11). It could not send an Echo Reply because it did not know where to send it.

The machines that could be successfully pinged had routing-commands in their /etc/network/interfaces file as described below. 10.11.22.33 did not.

Resolution:

The problem was resolved by adding this (indented) line to /etc/network/interfaces under the entry for the network interface that joins the computers in the internal network (ens33):

Then restart the interface: ifdown ens33 && ifup ens33.

Verify via netstat -r that the routing table entry is in place. Repeat the ping from various locations and confirm that replies are received. Confirm not only that the problem is resolved but also that no new problems are introduced.

Final Comments:

Every computer in a remote subnet must (one way or the other ...) include routes for the IP-address ranges of all subnets to which it may communicate or which may wish to communicate with it. They must also have routing for the internal IP-address range used by OpenVPN (10.8.0.x) to identify computers which are directly connected. These routing commands must forward the traffic back to the OpenVPN server machine "as a gateway." Thus, the complete set of route commands on 10.11.22.33 is now as follows:

The machine which is serving as an OpenVPN server, however, must not have these directives: the proper routing commands will be issued by OpenVPN itself as directed by the configuration file, and these will direct the traffic into the tunx device. Remote subnets are identified by files in the ccd subdirectory as described in the OpenVPN documentation.

Incidentally, this routing situation is not unique to OpenVPN. It applies anytime you have a remote subnet accessible by "a router," secure or not. OpenVPN in tunnel mode acts as a software secure router.