How to set up a proper OpenVPN infrastructure for multiple, independent client-to-client communication with central OpenVPN server in the middle

Question

I have a little bit of experience with setting up a simple OpenVPN solution where a few clients connect to a central server and communicate altogether in one VPN.

However I am now about to set up an OpenVPN-Infrastructure from scratch and I am questioning my self if my considered approach is a reasonable one. The OpenVPN infrastructure has the following characteristics:

• There are N sites of two types:
  • Mobile sites
  • Stationary sites
• Logically, each mobile site has exactly one assigned stationary site
• Stationary clients of site A may only talk to mobile clients of site A and vice versa
• One or multiple mobile clients (linux) per site shall connect to a central server (linux) via a mobile network and thus have no fixed IP that can reached directly because of the provider's NAT.
• One or multiple stationary clients (windows) per site shall connect to one central server. Each of those clients should have the possibility to connect to one of the mobile clients or a subset of the mobile clients. However, the stationary client must not communicate with more than a single mobile client at a time.
• The communication between two connected clients should be isolated from all other possibly established connections.
• Mobile clients most likely try to always have a connection to the central server. But they might be configured to only connect upon request.
• Stationary clients may establish a connection to the central server at any time and shall be able to communicate instantly to the desired mobile client (when it is also connected, of course)
• A communication amongst all mobile clients of one mobile site or a communication amongst a subset of clients of one mobile site could be a requirement for the future. However even if that requirement would be given, the stationary clients may still only connect to one single mobile client.
• Stationary clients, even belonging to the same site do never have to talk to each other
• One administrative stationary client in charge of the infrastructure must have access to each mobile client (one at a time), no matter which site it belongs to. The administrative client never has to talk to one of the stationary clients.
• The whole infrastructure will (in the first place) have all mobile clients equipped with OpenVPN 2.1.3 which is quite old and might change with firmware updates (nothing that I am in charge of). Stationary clients and server will have far more recent versions of OpenVPN.
• The amount of data that is transferred regularly between stationary and mobile client is quite low (I expect it to be less than a few KiB/s) however this may increase a lot over time, depending which additional communication technologies we will use in the future.

After some reading and thinking I came up with the idea, that all of those requirements can be met by:

• Providing a single central OpenVPN server (Considering using a docker-contained solution like https://github.com/kylemanna/docker-openvpn)
• Providing a scripted infrastructure where an adminstrative authority can request a pair of staionary cert/pk and mobile cert/pk as well as performing a configuration change in the OpenVPN server, that sets some routing/ip configs based on the common names that are used.
• Providing a possibility in the stationary clients to select the desired mobile target to connect to by simply connecting to the server using a specific cert/pk pair.

Does this sound like a reasonable mechanism to meet the requirements? If looking at the approach with scalability and speed in mind, should I set up the things like that or should I do some research for alternatives (even other technologies than OpenVPN?)

Thank you for your input in advance

Answer 1

Sorry, I have no time pondering your answer completely (though kudos for so well-put explanation, which is rare for SO format, I admit) but here's the list of assorted ideas which you might not yet be familiar with but which might help you going forward:

• You may have multiple OpenVPN instances running on the single server (on different ports); this may provide for coarse-grained separation of the groups of clients (and see below for Netfilter).
• Use topology subnet to connect your clients and put them into different private subnets; you may have any number of private networks wielded by an OpenVPN server instance.
• Enable client-to-client option in the server config to allow the clients to communicate with each other within the context of a single OpenVPN server instance.
• Use push "route <addr> <netmask>" to tell the clients which other networks they can reach via their OpenVPN connection (that is, networks other than their "native"—the one they happen to be connected to when they connect); note that you might need to have the matching iroute directives in the OpenVPN config.
• You can use client-specific configuration snippents via the client-config-dir parameter (dubbed ccd); this allows pushing specific route directives to specific clients so that different clients can connect to different sets of networks, when needed.
• When you have complete OpenVPN setup you might refine it with Netfilter rules (iptables) as all the traffic which is handled by OpenVPN still passes via the approptiate tables of the FORWARD chain, so here you might control which networks handled by OpenVPN are allowed to talk to each other.
• It's also possible to have OpenVPN accept simultaneous connections of the clients presenting certificates with the same Common Name (CN); this can be used as a last resort to have the same settings applied to different clients (typically via the ccd mechanism referred to above). I'd stress this is a last-resort solution as it precludes fine-grained revocation of the access for individual clients.

Hope this helps!