MikeRobinson
OpenVPN serves as "a secure router (or bridge), implemented in software," and with it come the usual headaches that are associated with the setup of any router. But, there's also "one more little surprise": 10.70.80.x.
Fundamentally, in any and every TCP/IP subnet, every computer (or, "default gateway" router) must know how to deal with every TCP/IP address that it encounters, whether that address is a destination, a source, or a gateway. If it doesn't, either the packet will be dropped or it will be presented to the Internet where – being a non-routable local address – it will once again be dropped.
This is generally true of TCP/IP networks and is not specific to OpenVPN. (In this context, "OpenVPN is merely a router.")
Let's say that you're on a 192.168.10.x network, and that there's another 192.168.20.x subnet out there which must also be accessible. Traffic on one of the subnets, bound for the other one, must be sent to a router gateway (on that local subnet) that will ultimately get it there. That router could be a physical device, or it could be a logical one (OpenVPN). Doesn't matter. Each subnet must be aware of, and know how to deal with, addresses from the other subnet; from every other subnet that it might encounter.
But with OpenVPN, there is another subnet-range to deal with: 10.70.80.x. When your computer is directly connected to an OpenVPN server – you have logged-on to it with some kind of client – it will have an address in this range, associated with the utunX virtual-device (the pathway to OpenVPN). This is the special virtual-subnet, implemented and managed entirely by OpenVPN, that directly-connected clients use to communicate with the server, and possibly among themselves. Therefore, the computers and the network-hardware on the various subnets will encounter traffic bearing these IP-addresses, and must know what to do with them: they must be sent back to the physical IP-address of the local OpenVPN server, "as a gateway." The routing throughout the network must accommodate all remote-subnet IP-address ranges and this one. (Often, this is done by setting up "static routes" on the subnet's router.)
When you're troubleshooting TCP/IP routing problems of any sort, "traceroute is your best friend." This command will analyze a TCP/IP path hop-by-hop. And, frequently, you'll see the output turn into "a row of asterisks," which means that a return route from a particular hop could not be found: the packets got there, but had no route by which to return. (The solution is a routing-change on that machine.) Similarly, if the exchange "suddenly stops," you know that the last-hop machine didn't know how to route a packet to its intended next-hop. Whereas "ping can't tell you why ping isn't working," traceroute can.
The other most-common problem I've seen is a very basic one: IP-address conflicts. The IP-address of every computer in "the total network" must be unique. Most home networks use the address-range 192.168.0.x but if you want to connect two home-networks in this way, one or the other of them must use a different range. All of TCP/IP routing is based on those IP-address values, and they must be unique.
