OpenVPN server helper: network plus netmask, never CIDR

A server line that mixes a CIDR suffix with a dotted mask stops the daemon before it ever opens a port. The IPv4 server helper wants two separate arguments: an aligned network address, then the netmask in dotted form. Everything else on that line is inference, and inference is where pool sizes and client masks go wrong.

The two arguments the helper accepts

Write the network first and the mask second, with nothing joined to the address:

server 10.72.16.0 255.255.240.0

This is the form for a /20. The line below is the mistake, and it fails at option parsing rather than at runtime:

server 10.72.16.0/20 255.255.240.0

Keep the two ideas apart when you debug this. A prefix length and a dotted mask describe the same span, but the helper does not accept both at once, and a rejected line produces an options error that names the directive rather than the arithmetic.

Align the network before you type the mask

The first address is the network address of the range, not a convenient client address inside it. For a /20 the span runs from 10.72.16.0 to 10.72.31.255, and only the first of those is a valid network argument. A /21 uses 255.255.248.0 and spans 10.72.16.0 through 10.72.23.255, so its line is server 10.72.16.0 255.255.248.0.

Changing the prefix changes the span and nothing else. It does not change how many addresses a single client receives, because that is a property of the topology, not of the mask on this line.

Confirm the pool from the server side

Start the instance in the foreground with verbose logging and read the lines the helper emits. The pool it built is printed at startup, which is more reliable than working the arithmetic out by hand:

openvpn --config /etc/openvpn/server.conf --verb 4 --dev tun9 --port 1195

Look for the pool summary near the top of the output. It lists the range the helper reserved, and if that range does not match your intention, the arguments on the line are wrong regardless of what the mask arithmetic says.

Then connect one client and find the line that records the address it was handed. That single address, next to the pool range, tells you whether the client landed inside the reserved block or somewhere you did not expect. If the two disagree, fix the arguments rather than the client. If they agree and the client still cannot reach anything, the pool was never the problem.

Read the client's mask with the topology in mind

A client showing a /30 on its tunnel interface is not proof of a broken pool. Under point-to-point addressing each client gets a small block and its interface mask describes that block, while the server's pool covers the aggregate. Under a subnet topology the client's mask matches the pool mask instead. The mask alone therefore tells you which topology is in play, not whether the pool was written correctly.

Check the configured topology and the assigned address together before drawing a conclusion:

ip -4 addr show tun0

If the address is inside the pool and the mask is narrower than the pool, that is the topology doing its job. If the address is outside the pool, the pool is wrong, and no amount of client-side inspection will fix it.

Changing a live pool

Pick a range that does not overlap the current pool, the LAN, or any route already pushed to clients. Overlap is the failure that survives a restart and then shows up as one site being unreachable from one direction, days later.

Change the line, restart, and re-read the startup pool before letting users back on. If the new range collides with something, the same startup output shows it immediately, and rolling back is a one-line edit plus another restart.

Keep the old range reserved for a while after the change. Clients that reconnect late can still hold an address from the previous pool, and a new range that reuses those addresses produces duplicate assignments that look like a routing fault. The OpenVPN 2.6 manual documents the helper's arguments and its expansion, which is worth reading before you assume a directive takes the same notation as its neighbour.