Why an OpenVPN /24 runs out of clients sooner than you expect

Pools built on a /24 that stop accepting clients in the sixties are behaving as designed, not hitting a license limit. Under net30, every client is handed a virtual point-to-point link that consumes four addresses, so a 256-address subnet supports roughly a quarter of what the prefix suggests. The count that matters is allocations, not addresses. Reading the prefix as a client count is the mistake that produces a search for a hidden user cap.

Two topologies, two arithmetic models, and only one of them matches the prefix people assume.

net30 spends four addresses per client

net30 allocates a /30 block per client, because each session is modelled as a point-to-point link with an address at each end. Four addresses go into that block and two are usable, which is why the effective client count is a quarter of the subnet. On a /24 that leaves 64 blocks before the server's own block and any fixed assignments come out. A reported ceiling near 63 is arithmetic showing through, not a configured maximum.

The server also needs its own allocation, and static client entries consume blocks whether or not those clients connect. Both reduce the dynamic range without changing the prefix you started with.

The pool boundaries matter more than the prefix

The server directive may define a pool narrower than the subnet it names, and a helper script can expand into additional settings that are not visible in the profile you opened. Fixed addresses from a client-config directory sit inside that range and cannot be handed out twice. The prefix describes the maximum possible space; the effective pool is what the running configuration actually offers.

Compare the two before concluding anything about capacity, because a smaller configured range explains the ceiling just as well as the topology does.

Find the limit that actually refused the client

Read the topology and the effective pool first, then account for fixed assignments and reserved addresses. Check max-clients and any admission control outside OpenVPN before blaming the address space. Finally, match the server's own message at the moment of refusal against those candidates. The message names the constraint; the count only narrows the field.

A refusal that arrives with a concurrency error and a refusal that arrives with an allocation error have different fixes, and guessing between them wastes a maintenance window.

Changing topology changes the address plan

Switching to subnet topology gives each client one address instead of a block, which is the right move when the prefix is genuinely too small. It also changes what the client address parameters mean, so every pinned assignment and every client-specific file has to be re-derived rather than renumbered by hand. Plan the new range, migrate the static entries, and update the routes that reference them.

The switch is not a synonym for the old configuration. Treat it as an address-plan change with its own review, and expect at least one client to hold an address from the previous scheme.

Size the pool from the plan, not from the mask

Choose the size from the number of concurrent clients plus headroom for reconnects and testing, then pick the smallest prefix that covers it under the chosen topology. Widening to a /16 to solve a sixty-client ceiling trades a capacity problem for a routing and overlap problem, because a larger private range is more likely to collide with something the client already reaches.

Document the topology, the pool, the fixed assignments and the resulting client ceiling together. The next capacity question is then arithmetic instead of an investigation.