Like any good security-oriented product, OpenVPN can be tricky to set up the first time. The biggest problem that I had was (a) wrapping my head around "what it is actually doing," and (b) getting all of the routing right. Now, I'd like to spill a few of those thoughts for your amusement and amazement.

First of all: OpenVPN runs in one of two modes: "tunnel," or "(telephone wire-)tap." Tunneling is the most common mode, and that will be the one that I discuss here. ("Tap," by contrast, acts as "the room is 'bugged.'" It eavesdrops on all the packets, TCP/IP or otherwise, vacuums them all up, and spews them all to the other side.)

An OpenVPN tunnel is a router. It acts just like any router does, providing a gateway to a secure subnet. Trouble is, most of us don't have any "subnets" in our (home) systems. Although we necessarily "have a router," to connect to the Internet, it is simply a gateway to everything. We usually don't have other ranges of addresses that we need to use a router to get to ... until OpenVPN came along.

A router ... any router ... lives on two networks at the same time, and provides a "gateway" from one to another. On your home machine, that router might live on your network at 192.168.1.1, and on the Internet at whatever address was assigned to it by your ISP. Well, OpenVPN does the same thing. The OpenVPN client or server sits (say ...) on your computer, therefore at "your" local IP-address (say ...) 192.168.1.5, and it sits on the virtual private subnet which it creates. Let's say that that range of addresses is 10.8.0.x.

The OpenVPN software will set-aside two addresses ... 10.8.0.1, 2, to refer to "the client or server itself." These are the gateway addresses for this virtual subnet, and, when you connect, you'll see a route command that forwards all traffic destined for 10.8.0.x to the appropriate gateway address. (The software also sets aside 10.8.0.255 as the "broadcast" address.) It will assign another address to each party who connects. Let's say you get 10.8.0.5.

So, you send a packet, from your secure-subnet IP address (10.8.0.5, to an address somewhere on the other side. Routing commands on your machine send that traffic to the OpenVPN gateway, and it squirts through the encrypted pipe and pops out on the other side. It finds its way to its destination ... still carrying a return address of 10.8.0.5.

Let's follow that packet on its round-trip on the remote side.

Since the packet is bound for an address on the remote side, it quickly arrives. The contacted server dutifully replies, sending a packet back to its final destination address: 10.8.0.5.

Now, here's the trick: there is no physical computer on that network which has that address! The network on the other end, or the replying computer on the other end, must know which computer, on the other side, is the other OpenVPN gateway. Someone, somehow, on that side, must know that packets in this address-range are to be forwarded to the gateway machine ... at its physical address on that network. You can set up route-commands on each computer, or you can program static routes on the other network's router if it has one. (More about that in a moment ...)

Let's say that the local-address of that computer, on that side, is 192.168.2.3. The remote network, or the computers in question on that network, must know that traffic bearing a return-address of 10.8.0.x must be forwarded to the gateway on that side, 192.168.2.3.

(Notice that the packet is forwarded to a physical network-address on that side ... not to a subnet address, which of course has no physical presence.)

Well, this story has a happy ending ... you've got everything set up correctly ... and our packet is duly forwarded.

The OpenVPN gateway on that side grabs the forwarded packet and squirts it back through the pipe. The OpenVPN software on your side recognizes 10.8.0.5 and sends the packet right back to you. Now, the round-trip (a "ping?") is complete.

These technical requirements are the same as for any router appliance that serves a subnet. But, most of us don't encounter "subnets" until we start to use OpenVPN.

A very convenient way to set up routing, say in a virtual-machine cloud setting (on, say, Ubuntu ...) is to use the up prefixed commands in /etc/network/interfaces. For instances, if your computer uses interface ens12 to talk to the OpenVPN server (at 10.22.33.44) concerning a subnet of 10.10.10.x, you might add this line to the entry for that interface:

When this interface is brought up, the route command will automatically be added so that this computer knows how to forward traffic destined for the secure subnet.

HTH! Comments and questions welcomed.

soon as I get to my linux box..

+rep to you for this.

that is good, understandable, valuable information. right there.

Thank you.

(And ... luv your signature!)