Topology in OpenVPN
Several network topologies exist for servers configured to accept multiple client connections. These are controlled with the --topology option.
Possible topology choices
These are available options as values to the --topology parameter in --dev tun mode. Each topology is described further in its own section below.
- The recommended topology for modern servers. Note that this is not the current default. Addressing is done by IP & netmask.
- This is the old topology for support with Windows clients running 2.0.9 or older clients. This is the default as of OpenVPN 2.3, but not recommended for current use. Each client is allocated a virtual /30, taking 4 IPs per client, plus 4 for the server.
- This topology uses Point-to-Point networking. This is not compatible with Windows clients, though use with non-Windows allows use of the entire subnet (no "lost" IPs.)
Subnet topology is the current recommended topology; it is not the default as of OpenVPN 2.3 for reasons of backwards-compatibility with 2.0.9-era configs. It is safe and recommended to use subnet topology when no old/outdated clients exist that are running OpenVPN 2.0.9 under Windows.
In subnet topology, the tun device is configured with an IP and netmask like a "traditional" broadcast-based network. The traditional network and broadcast IPs should not be used; while tun has no concept of broadcasts, Windows clients will be unable to properly use these addresses. All remaining IPs in the network are available for use.
Since every IP can be used, subnet topology allows the better utilization of IP space and easier to understand network layout.
Example subnet configs
Example server config snippet:
--dev tun --topology subnet --server 10.8.0.0 255.255.255.0
Example ccd setup:
--ifconfig-push 10.8.0.3 255.255.255.0
net30 is effectively "deprecated" but remains the OpenVPN 2.3-series default for fear of breaking backwards-compat configs that rely on this behavior. Each client is allocated a virtual /30 network, and Windows clients must use the 2 IPs in the center, generally allocating the even IP to the client (though this is convention only.)
The only real reason to use the net30 topology is when requiring support for Windows clients before 2.0.9, or when any Windows clients must be supported and non-Windows clients must be supported that cannot set IP+netmask on the tun adapter. These conditions are rare, and the 2.0.9 client is around 7 years out of date as of 2014.
Windows allocates the fake /30 as a local network, while non-Windows will set up a true Point-to-Point config, treating the IP pairing the same as the p2p topology described below.
Routing to/across the VPN range gets harder in net30 since the clients on-link network is just the /30, so an additional "supernet" route must be added to reach the rest of the VPN, including the server at its designated IP. This complicates routing and makes understanding the config harder.
By convention, the server has the first usable IP in the VPN network, and the remaining /30's are available for pool or static assignment.
Example net30 configs
Example server config snippet: Note that in this example, the server consumes the 10.8.0.0/30 network, with the remaining 63 available /30's available for use by clients.
--dev tun --topology net30 --server 10.8.0.0 255.255.255.0
Example ccd setup:
--ifconfig-push 10.8.0.10 10.8.0.9
This topology is not usable on Windows systems, and is not suitable if the server or any client might be Windows. In this topology, all nodes are configured as true Point-to-Point links. This has the advantage of making every single IP in the subnet usable, including the first/last IPs normally unusable due to Windows considering them network/broadcast addresses. In other words, with a /24 in the p2p topology, all 256 IPs can be used.
By convention, the peering IP of the client should match the assigned IP that the server is using, but thanks to the nature of Point-to-Point networking, the IPs are arbitrary and serve only to mean "this end" or "that end." It is not necessary these IPs be adjacent, and generally won't be for a client.
Example p2p configs
Example server config snippet: Note that the --server helper directive cannot be used here; neither can --ifconfig-pool; addressing must be static.
--dev tun --topology p2p --push "topology p2p" --mode server --tls-server --ifconfig 10.8.0.1 10.8.0.0
Example ccd setup:
--ifconfig-push 10.8.0.3 10.8.0.1