A Bigger VPN Pool Is Not a Bigger Session Limit

A /22 holds 1,024 IPv4 addresses, and that number is easy to mistake for capacity. It describes how many assignments the range could support, not how many sessions the gateway will admit or how much traffic it can forward. Three separate counts sit behind any answer, and they fail in different ways. Comparing them is how a refusal gets attributed to the right one.

The pool, the entitlement and the workload are counted in different units and by different owners.

What the Pool Actually Offers

Start with the effective bounds rather than the mask. Subnet topology decides how many addresses the server can hand out, fixed assignments and reservations consume some, and the network and broadcast addresses are unavailable. A /22 offers 1,024 in principle and fewer in practice, which is already enough to break the arithmetic people expect. Overlap with networks the clients must reach can rule out a range that looked generous. Verify that the assignment mechanism supports the proposed range before announcing it.

A larger pool removes exactly one constraint. It does not touch admission limits, licensing or forwarding throughput, and enlarging a subnet while leaving the routes and access policy unchanged produces a range nobody can reach.

What the Licence Actually Permits

The platform's supported concurrency and the product entitlement are two more numbers, and they are frequently not the same. Entitlements may count users, devices or concurrent sessions, and those measures are not interchangeable. Vendor ordering guides show how different the models can be, which is why an old datasheet's peer count should not be carried into a new deployment. Read the agreement that applies to the service you actually run.

A licence counting named users will not admit more devices merely because the pool has room.

What the Gateway Can Actually Carry

The third count is workload. Estimate the traffic those sessions generate together: packet rates, authentication bursts, encryption cost and whichever policy features are enabled. Interactive sessions and bulk transfers land very differently on the same box. A gateway can have addresses free and licensed admission available while the intended load exceeds what it can forward. Capacity planning that ignores the feature set produces a number that holds only in a lab with everything switched off.

A refusal is the moment to look at what the gateway logged for that attempt: an allocation event, an admission decision, or a stalled authentication call. Those three produce different corrections, and guessing from the client side rarely picks the right one.

Attribute the Refusal Before Changing Anything

The useful comparison is between the three counts and the observed failure. If the pool is full, expand it and update the routes and policy that describe it. If admission is refused while addresses remain, the constraint is elsewhere. If sessions are admitted and performance collapses, the problem is capacity rather than either limit.

Record which count was exhausted, when it happened and what changed afterwards. That record keeps the next investigation from starting at the subnet mask again.

Enlarging a pool is a one-line change with a three-part follow-up: routes, policy and a retest.