HEADS UP: OpenVPN Topology Default Changed to "subnet" (was: "net30")
tl;dr: I pushed several changes over the last two days to change the default behavior for new OpenVPN servers to use the Topology "subnet" style rather than the older "net30" style. Existing settings will be retained – if your tunnel uses net30 now, it will still be net30 after upgrading.
The net30 style is still available as a choice, but the default is now subnet style.
See https://redmine.pfsense.org/issues/5526 and https://community.openvpn.net/openvpn/wiki/Topology for more detail.
It isn't in a snapshot/update yet, but will be shortly.
From the OpenVPN man page:
--topology mode Configure virtual addressing topology when running in --dev tun mode. This directive has no meaning in --dev tap mode, which always uses a subnet topology. If you set this directive on the server, the --server and --server-bridge directives will automatically push your chosen topology setting to clients as well. This directive can also be manually pushed to clients. Like the --dev directive, this directive must always be compatible between client and server. mode can be one of: net30 -- Use a point-to-point topology, by allocating one /30 subnet per client. This is designed to allow point- to-point semantics when some or all of the connecting clients might be Windows systems. This is the default on OpenVPN 2.0. [snip] subnet -- Use a subnet rather than a point-to-point topology by configuring the tun interface with a local IP address and subnet mask, similar to the topology used in --dev tap and ethernet bridging mode. This mode allo‐ cates a single IP address per connecting client and works on Windows as well. Only available when server and clients are OpenVPN 2.1 or higher, or OpenVPN 2.0.x which has been manually patched with the --topology directive code. When used on Windows, requires version 8.2 or higher of the TAP-Win32 driver. When used on *nix, requires that the tun driver supports an ifconfig(8) command which sets a subnet instead of a remote endpoint IP address. This option exists in OpenVPN 2.1 or higher.
What it boils down to is: Using subnet style each client gets on IP address in a common subnet with the server IP address, rather than using the net30 style where each client gets their own /30 point-to-point subnet which results in some confusion and wasted IP addresses.
Changes that came along with this:
Client-specific overrides are no longer forced to be "global" for all servers. Upgraded overrides will still apply to all servers, but they can now be selectively restricted so an override may apply to only specific servers if desired. If you look under the hood you'll see that no longer are all the overrides just dumped in /var/etc/openvpn-csc/ and used in common, now there are copies underneath there for each OpenVPN server using a mode where overrides can function (e.g. /var/etc/openvpn-csc/server1/myname) – You can even have entries for the same CN on multiple servers with different settings.
Client-specific overrides automatically detect the subnet style used by the server and adjust accordingly
OpenVPN server GUI checkbox option for "Topology Subnet" changed to a drop-down to select either "subnet" or "net30" (and in the future, "p2p")
Upgrade code will fix up the setting in config.xml and change it to the new style
The Topology option was added to the wizard, and defaults to subnet there as well. It was not previously present in the wizard at all
Wiki and book references to net30/subnet were changed to reflect the new default and explain the two better
The OpenVPN client export package does not require any updating/adjustment.
Setting client IP addresses via RADIUS works the same as always – send a Framed-Address only and it assumes net30, send a Framed-Address and Framed-Mask and it uses subnet style.
Setting static IP addresses in overrides should work OK either way now -- When using subnet, give the appropriate mask (e.g. x.x.x.x/24) and as before when using net30, use the appropriate /30 mask (e.g. x.x.x.4/30)
Testing/feedback appreciated. I tested it locally several different ways but there is always the possibility that something was overlooked or could be optimized better.