skip to content

How many IPsec SAs does a cloud VPN gateway hold for 40 branches, each pairing 10 local with 10 cloud subnets, policy-based versus route-based?

level: seniorimportance: should knowfreq 15%

answer

  1. selectors set SA granularity
  2. one pair per subnet pair
  3. SAs are one-way
  4. IKEv1 Quick Mode: one ID pair
  5. TS payloads carry several selectors

basics

~20 s

With one Child SA pair per subnet pair, policy-based tunnels need 100 pairs per branch: 4,000 pairs or 8,000 one-way ESP SAs at the hub. Route-based tunnels with any-to-any selectors need one pair per tunnel: 40 pairs, 80 SAs.

solid answer

~40 s

Selectors set SA granularity. In a policy-based design each local/remote subnet pair is its own selector pair, and IKEv1 Quick Mode (deprecated by RFC 9395, still met on legacy peers) carries exactly one `IDci`/`IDcr` pair, so 10 x 10 subnets means 100 Child SA pairs per branch; across 40 branches that is 4,000 pairs, or 8,000 ESP SAs because each SA is one-way, each rekeyed on its own. IKEv2 lets `TSi` and `TSr` each carry several selectors, so one Child SA can cover all 100 combinations — but only if both ends' implementations negotiate it that way, and many still build one SA per configured pair. A route-based tunnel negotiates one any-to-any pair: 40 pairs, 80 SAs, and an eleventh cloud subnet is a route, not 400 new SAs.

go deeper

for a junior

Remember that an IPsec SA is one-way and comes in pairs, and that narrow selectors mean more SAs than wide ones.

for a middle

Walk the multiplication: subnet pairs per branch, times branches, times two directions, and explain why IKEv1 Quick Mode forces one SA pair per selector pair.

for a senior

Separate protocol from implementation: IKEv2 allows multi-range selectors, but the count is what both ends negotiate, and the operational pain is rekey load, SA caps and partial outages.

for a principal

Argue the estate choice: route-based collapses SA count and change cost but relocates policy into interface filters and route filtering, which must then be owned and audited.

## Where the count comes from Three facts set the arithmetic: - **An SA is one-way.** RFC 7296 states that ESP and AH SAs exist in pairs, one in each direction; IKE creates them as a **Child SA pair**. - **Selectors set the granularity.** RFC 4301 says the SPD's selectors "define the granularity of the SAs" created for outbound traffic or a peer's proposal. Narrow selectors mean many SAs. - **There is one IKE SA per peer.** Each branch has an IKE SA with the hub, and every Child SA for that branch is negotiated under it. The scenario: a cloud VPN gateway, 40 branches, each branch with 10 local subnets that must reach 10 cloud subnets. ## Policy-based arithmetic In the worst case each subnet pair gets its own Child SA pair: | Quantity | Calculation | Result | |---|---|---| | Selector pairs per branch | 10 local x 10 cloud | 100 | | Child SA pairs per branch | 1 per selector pair | 100 | | Child SA pairs at the hub | 40 x 100 | 4,000 | | One-way ESP SAs at the hub | 4,000 x 2 | 8,000 | | IKE SAs at the hub | 1 per branch | 40 | | SPD entries at the hub | 40 x 100 | 4,000 | Each Child SA is normally rekeyed with its own `CREATE_CHILD_SA` exchange when its lifetime runs out. IKEv2 does not negotiate lifetimes — each end applies its own policy — so the figure depends on configuration: with a one-hour lifetime (a configuration choice, not an RFC value) the hub runs about 4,000 rekeys an hour, a little more than one per second. Adding one cloud subnet adds 10 selector pairs per branch, so **400 new Child SA pairs** and configuration changes on all 41 devices. ## Why the worst case is a protocol fact in IKEv1 and a choice in IKEv2 1. **IKEv1.** Quick Mode (RFC 2409) carries one client identity per side, `IDci` and `IDcr`, each an address, a subnet or a range. One Quick Mode, one selector pair, one SA pair: the 100-per-branch figure is built in. IKEv1 is deprecated by RFC 9395, which moved RFCs 2407, 2408 and 2409 to Historic, but estates still meet peers that speak it. 2. **IKEv2.** RFC 7296 says each TS payload "contains one or more Traffic Selectors". A single Child SA can carry `TSi` with ten ranges and `TSr` with ten ranges and protect all 100 combinations with **one pair**. 3. **Implementations decide.** Many configure and negotiate one Child SA per configured subnet pair, and some peers accept only one range per side. The count you get is whatever *both* ends agree to, so read the negotiated selectors rather than assuming. A multi-range Child SA carries a caveat of its own: it covers the full cross-product of local and remote ranges. If policy wanted only some pairs to talk, one SA is too wide, and filtering must happen elsewhere. ## Route-based arithmetic A route-based tunnel binds one Child SA pair with any-to-any selectors (`0.0.0.0`–`255.255.255.255`, all protocols and ports) to a tunnel interface: - 40 tunnels give **40 Child SA pairs, 80 ESP SAs**, plus 40 IKE SAs; - the redundant pair a cloud gateway usually expects doubles that to 80 pairs and 160 SAs — still two orders of magnitude below 8,000; - an eleventh cloud subnet is one more route, static or advertised, and **zero** new SAs. ## What the count costs in operation - **SA table size.** Hardware and software gateways cap how many SAs they hold; the cap is an implementation limit, and policy-based sprawl reaches it first. - **Rekey load.** Thousands of independent rekeys mean steady control-plane work and more chances for one rekey to fail. - **Partial outages.** One of 100 Child SAs failing to negotiate leaves one subnet pair dark while the tunnel looks up — the hardest outage to spot. - **Change risk.** Every subnet change is a coordinated edit at both ends, and a mismatch triggers traffic-selector narrowing. ## The trade you are making Route-based does not make the policy vanish; it moves it. With wide selectors the RFC 4301 inbound selector check no longer restricts which inner sources a branch can use, so filtering moves to the tunnel interface and to route filters on the routing protocol run over it. In an interview, give both numbers, say which ones IKEv1 forces and which IKEv2 merely allows, and name what you add when you choose route-based.

  • If IKEv2 can put all ten local and ten cloud ranges into one Child SA, why not do that and keep policy-based?
    You can, when both implementations negotiate multi-range selectors. The SA count falls to one pair per branch, but you keep the other policy-based costs: every subnet change is still a coordinated edit at both ends, failover is not driven by routing, and the single SA covers every local-to-remote combination, which may be wider than policy intended.
  • Why does an IPsec SA count of 8,000 matter if each SA uses little memory?
    Memory is rarely the first limit. Gateways cap the number of SAs they can hold or offload, each SA is rekeyed on its own schedule, and every SA is a separate thing that can fail to negotiate. With thousands of them, a single dark subnet pair hides behind a tunnel that reports itself as up.

saying these in an interview costs you the question

  • One IPsec SA carries traffic in both directions.
  • An IKEv2 Child SA can only carry one subnet on each side.
  • Route-based tunnels need a new SA for each newly added subnet.
  • SA count only depends on the number of branches, not selectors.
  • IKEv2 negotiates the SA lifetime, so both ends rekey together.