How to Budget Address Space for a Multi-Site VPN

How big the VPN subnet should be has no answer until you name which addresses you are counting. In one design those addresses are the two endpoints of a numbered tunnel link, in another they are the office LAN behind a policy-based tunnel, and in a third they are a managed gateway's reserved infrastructure. Three objects, three budgets, and most sizing mistakes come from filling one column with another column's number.

Four Roles, Four Different Questions

The outer transport is the address a peer connects to, so its size follows your public addressing or the provider's, never the number of devices behind it. Inside tunnel links exist only in designs that number a virtual interface, and there the count follows the topology's adjacencies. Protected LAN prefixes follow the real networks and their growth plan. Provider-reserved infrastructure follows whatever the managed service documents.

Only the third of those has any relationship to how many laptops the office contains. That single confusion explains most of the arguments.

Write the four roles as separate columns before opening a calculator. Each gets its own allocation, owner and growth assumption, and none of them inherits another's size. When a design has no numbered inside link, that column is empty rather than small, and an empty column is a fact worth recording for the next reviewer.

Counting Blocks: What a /30 Really Costs

A point-to-point link needs two addresses and consumes a block whose size depends on the platform. A /30 holds four addresses, two of which are usually usable, so twelve links consume forty-eight addresses in the plan while offering twenty-four endpoints. A /31 holds two addresses and both are usable, which halves the arithmetic but only where both ends accept it.

RFC 3021 defines the two-address model, and support is a property of the endpoints and the service rather than of good intentions. A provider API may impose its own mask requirement on an inside tunnel option, and a general RFC does not override a documented constraint. Check what your platform states before summarising the budget, because the difference between forty-eight and twenty-four addresses decides whether the plan fits the reserved range. Run the arithmetic rather than trusting it at the end of a long day.

ipcalc -n 10.44.12.0/30
ipcalc -n 10.44.12.4/31

Multiply only after the topology is settled. Twelve separate links and one multipoint overlay with twelve participants produce very different totals from the same site count.

The Managed Gateway Subnet Is Not a Client Pool

A managed service often reserves a subnet for its own gateway infrastructure, and that subnet is consumed by the service rather than handed to clients. It has a documented size, sometimes a documented name, and no relationship to how many users connect. Treating it as the address pool for remote machines produces a design that exhausts itself on the first busy morning.

Read the provider's requirement as a fixed cost, the way you would treat a rack unit. It is not part of the protected prefix budget.

The same reading applies to names. A subnet whose documented purpose is gateway infrastructure is infrastructure by convention in that service, and renaming it to fit your own scheme breaks the deployment rather than improving the diagram. Keep the provider's names and sizes, and spend your own numbering scheme on the parts you control.

Document the Plan So It Survives the Second Site

A plan that lives in one engineer's head fails at the first overlap between an office prefix and a home router's default range. Publish the allocations with their owners, and state which end of each link assigns which address. Routes or selectors still have to be advertised, because numbering an inside link does not publish a LAN by itself.

Record the growth assumption behind each block, since that is the part no later reader can reconstruct from the addresses alone.

Then test the plan against the awkward cases: a site that arrives with a prefix you already use, a link whose far end someone else manages, and a region whose provider requirement differs from the first one you documented. If any of those forces a redesign, what you had was a diagram rather than a policy. A plan that survives them is short enough to sit in the repository beside the tunnel configuration, which is exactly where the next person will look for it.