Linking LANs with OpenVPN Reverse Routing

With a properly-configured OpenVPN client-server configuration it is possible to establish bi-directional routing between two private LANs behind NAT firewalls such that any private address in either network is directly addressable from any host in the other. Prerequisites for pursuing this configuration are:

• At least one of the LANs must have a reachable public IP in order to host the server
• The server LAN's public IP must be knowable so the client can connect, either via:
• a static public IP address from the ISP, or
• (more commonly) a dynamic DNS registration from the server network in order to establish a hostname that maps to the dynamic public IP 
• The two private LANs must have distinct, non-overlapping subnets (i.e. if the server net is operating on 192.168.1.0/24, plan to configure the client net to 192.168.2.0/24, for example)

It is also helpful before setting out to understand what this configuration will and will not accomplish. The details that follow describe a routed VPN setup, not bridged. Bridged configurations between overlapping LAN subnets are possible, but routed is almost always more sensible because it isolates the broadcast and multicast domains from one another and limits the amount of unnecessary network chatter that gets pushed into the VPN tunnel. While the individual hosts in each LAN will be reachable from one another, any protocols which rely on broadcast discovery or non-IP protocols will not work over the VPN tunnel. So, for instance, while you will be able to browse to the web configuration interface of a device at Site 2 from a browser instance at Site 1, you will not be able to, say, Chromecast a YouTube video from a mobile device at Site 1 to a Chromecast device at Site 2, since Chromecast relies on UPnP M-SEARCH multicast packets in order for the DIAL protocol to function, and those multicast packets will not route out of the private LAN.

Also helpful before beginning is to identify the devices that will function as the OpenVPN server and client. While PCs can be used to provide this functionality, low-power embedded devices such as consumer WiFi routers or Raspberry Pi SBCs are more than capable of providing the encryption and routing services required to terminate a tunnel. 

Almost all of the information needed to establish a bi-directional routed VPN tunnel is contained in the OpenVPN How To Guide, but I'll endeavor to highlight the most relevant parts here. In any case where the guide distinguishes between a routed and bridged VPN configuration, follow the instructions for the routed setup.

• Installing OpenVPN
• Numbering private subnets
• Setting up a CA for the server and client certificates and keys
• Creating configuration files for the server and client
• If the client network will be unattended for a prolonged period of time, take special care to set the resolv-retry infinite configuration option on the client host; this is what will instruct the client to retry connections to the server indefinitely if internet connectivity at either site is lost for any reason
• Even with the inclusion of the resolv-retry infinite configuration option on the client side, OpenVPN client connections are known to terminate under non-ideal connectivity conditions; it may be helpful to set up a connectivity watchdog job at the client
• Expanding the scope to include hosts on the server and client networks
• This is the part that allows hosts which know nothing about the OpenVPN tunnel to reach one another by routing through the client and server
• The "iroute" options added to the ccd configuration directory on the server are the critical part that specify the client network to the server and make the reverse routing from the server network to the client network possible
• Do not overlook in this section that if the OpenVPN server and client devices in their respective LANs are not the gateways for those LANs, static routes will need to be established at the gateway to redirect traffic bound for the remote LAN to the OpenVPN server or client so it can be pushed into the tunnel; on many consumer routers this is a relatively trivial configuration item wherein the remote network and forwarding host are specified for addition to the routing table
• Running the OpenVPN server on a dynamic IP address

The real beauty of this configuration beyond the obvious advantages of bi-directional routing between private LANs is that the client LAN does not even need to have a public IP address as long as it has a route to the internet to connect to the server. This allows for unconventional setups at the client side, such as a LAN NAT behind a Raspberry Pi which is connected to a neighbor's WiFi network or to a public hotspot within range. This is a configuration which I will attempt to cover in a future post.