Here are some basics:
OpenVPN in tunnel-mode fundamentally acts as a secure, software-implemented, "TCP/IP Router." It normally communicates with its peers using UDP port 1192.
(Which is not a TCP/IP "socket" and which therefore doesn't show up on any scan.)
Your OpenVPN process must of course be able to receive traffic sent to it from the internet, so your [physical] router must provide "port forwarding" to send incoming UDP/1192 traffic to the OpenVPN machine on your network.
So, the first order of business is to make sure that the various machines can, in fact, send UDP packets to one another. You can't read the packets, of course, but you can see them coming and going.
(Commands such as nc are great ... if you want to generate packets and listen for 'em, this tiny little tool is a great big help.)
- - -
Usually, "client" machines connect to a "server" which basically acts as "a common 'machine for everyone else to connect to.'"
- - -
The next order of business is the TCP/IP addresses that will be traveling into and out of this router. (This is fundamentally true for any router.)
OpenVPN reserves one range of addresses, usually
10.8.0.x for
itself. The server machine, and every client machine that is
directly connected to it, will be assigned an IP-address from this range (by OpenVPN itself), and if you are running a client yourself, traffic for your machine will use such an address.
(Because your computer's physical address is being used to refer to your OpenVPN client.) Traffic originating from the server or from any other directly-connected client will also use this address pool. These packets will therefore be seen on your local network (subnet).
Meanwhile, if the server or any connected client exposes a
subnet that you are entitled to address, the IP-address ranges used by other computers on that subnet may also show up on your local network.
The "gateway" that must be used by all of these addresses – in order for them to get back home – is the (physical) IP-address of your OpenVPN client.
(Or, the other-client that serves your subnet.) Therefore, all such addresses
and 10.8.0.x must somehow be directed back to your OpenVPN machine "as a gateway."
This is often accomplished simply by setting up static routes on your router, covering each of these address ranges and specifying your OpenVPN machine as the gateway.
(For this reason, you set up the router to assign a known IP-address to your machine within your network.)
(Actually, I'm going to assume that your computers are not "exposing subnets behind themselves," which would necessitate a talk about "
ccd files and
iroute," and I see that your eyes have glazed-over already.)
- - -
traceroute is your best friend, along with a packet-sniffer like
tcpdump or WireShark. You must see the encrypted packets going and coming. You must also verify, from each subnet, that there is a successful route to
and back again from all other subnets. The routing at each location must be correct.
(If traceroute starts spitting "rows of asterisks," you're missing a return route at that "hop." The traffic gets there but can't get home.)
Both the client and the server will automatically take care of issuing
route commands
upon themselves, in order to cause traffic to be sent to the virtual
tunx device which is the actual portal into the OpenVPN process. But they do not do anything about the rest of your network(s).
- - -
Security throughout should be by means of
certificates.
Do not(!) 
use "PSKs == Pre-Shared Keys == Passwords!"
The server's certificate should be marked as being a "server certificate."
You should also use
tls-auth which allows your clients to give a recognition-signal to the server to cause it to reply to them. Any connection-request that does not bear this will be silently dropped. This makes your OpenVPN server
invisible(!) to the prying public, and also saves system resources. (It takes almost nothing-at-all to "drop a packet.")
Yeah, it can be a little tricky at first to get the two sides to connect: look at the system logs on each side. (The two parties are designed to "give no help nor information whatsoever ... not one single miserable clue" to any invalid connection attempt.)
- - -
I have written additional and more-detailed posts here on
LQ, as have others. Look on the
Networking, Security, and
Server forums – or just use Super Search.
