How to size address space for a site-to-site VPN

Ask how large the VPN subnet should be and the honest answer is that there may be four different subnets inside the question. A site VPN can involve transport endpoints, numbered tunnel links, the protected LAN prefixes and, on managed gateways, an infrastructure subnet the provider reserves. Only one or two of those exist in a given design. Sizing them from the number of office devices is how a plan ends up with a /24 that satisfies nobody.

Name the four roles before you allocate anything

Transport endpoints are the addresses two gateways use to reach each other across the internet or a private circuit, and their count comes from the gateway and redundancy model rather than from the LAN. Inside tunnel links exist only where the design numbers a point-to-point interface, which a policy-based IPsec configuration typically does not. Protected prefixes are the real office or VPC networks that must be routable, and the provider-reserved subnet belongs to the managed service.

Inventory what already exists before adding to it, because the expensive mistake here is reusing a prefix that is already routed somewhere else. A stale tunnel from a pilot project is enough to poison a plan. Write the inventory down with dates, since memory of a decommissioned link outlives the link itself.

ip -br addr show
ip route show | head -40

Those two commands give the local view of connected networks and of the routes that reach everything beyond them. Repeat the inventory at every site, since a plan built from one site's output will collide with the next one's. Collect the outputs before you allocate a single block.

Count links and topology, not devices

A design with eight point-to-point adjacencies consumes eight blocks, not one. At /30 each block spends four addresses to connect two hosts, so the plan carries thirty-two addresses for sixteen usable endpoints, and that is the figure the budget has to hold. A platform supporting /31 links spends half of it, but only when both ends and the service agree on that model. Round the budget up rather than down, because shrinking a block later means renumbering live links.

Provider constraints beat general practice. A documented inside tunnel range may require /30 even where /31 works on your routers, and a managed gateway may demand a specific mask for its own subnet. Read the service requirement before applying a rule of thumb borrowed from another platform.

A multipoint overlay changes the arithmetic again: one address per gateway, with the overlay handling reachability between them. Decide which topology the implementation actually uses before multiplying sites by a block size.

Growth deserves its own line in the plan. Reserving a coherent infrastructure range is reasonable, and so is recording which smaller allocations sit inside it, so the next engineer does not read the reservation as one broadcast domain.

Keep the gateway subnet out of the LAN pool

Managed gateway infrastructure is not a client pool. The addresses in a reserved gateway subnet host the service's own components, and remote workers never draw from them. Sizing that subnet from the user count is a category error that either wastes a large range or starves the gateway.

The same applies to tunnel ranges on cloud VPN connections, where the provider allocates a small inside range per tunnel for its own use. That range is not where your branch servers live, and it is not yours to hand out.

aws ec2 describe-vpn-connections --query "VpnConnections[].{Id:VpnConnectionId,Tunnels:Tunnels[].OutsideIpAddress}" --output table

Listing the outside addresses confirms what the provider allocated and which redundant tunnel is currently up. It is faster than reading a design document written before the connection existed.

Record role, owner and growth for every prefix

A plan that survives contact with operations states, for each prefix, what role it plays, who assigns the far end and how much headroom it holds. Without the owner field, two teams allocate the same /24 in the same quarter and the collision surfaces only when the tunnel comes up.

Keep these ranges clear of home and branch prefixes arriving through other tunnels, because overlapping space is the usual reason a site-to-site connection negotiates successfully and then passes no traffic.

Assigning inside link addresses does not advertise the LANs behind them. Routes or traffic selectors, return paths and access rules are separate work items, and the plan should say so instead of implying that a numbered interface does the routing for you.