An IKEv2 site-to-site tunnel is up, but only one branch subnet passes traffic and which one changes after each restart; how does traffic-selector narrowing explain it?
answer
- the two ends disagree on granularity
- the first selector comes from the packet
- responder keeps a subset, not the whole
- ADDITIONAL_TS_POSSIBLE versus TS_UNACCEPTABLE
basics
~20 sThe peers' selector configurations disagree. The initiator proposes a wide range led by the triggering packet's addresses; a narrower responder MUST keep a subset containing that first selector, so only the subnet that sent first gets a Child SA.
solid answer
~40 sIn IKEv2 the initiator sends `TSi` and `TSr`, and when a data packet triggered the request it SHOULD put a very specific selector built from that packet first. A responder whose policy accepts only part of the proposal narrows it, and if it accepts the first selector it MUST narrow to a subset that includes it — so the Child SA covers the subnet of whichever host spoke first, perhaps with an `ADDITIONAL_TS_POSSIBLE` notify saying other subsets need a separate SA. Unless the initiator then negotiates those extra Child SAs, other subnets are dropped, and after a restart a different subnet can win. `TS_UNACCEPTABLE` appears only when no part is acceptable. The fix is configuration that agrees on granularity at both ends, or any-to-any selectors on both.
code
pseudocode · 14 lineson child_sa_request(TSi, TSr):
allowed = local_policy intersect (TSi x TSr)
if allowed is empty:
reply notify TS_UNACCEPTABLE
else if allowed covers all of (TSi x TSr):
reply TSi, TSr unchanged
else if local_policy allows (TSi[0], TSr[0]):
S = an allowed subset containing (TSi[0], TSr[0])
reply S
else:
S = any allowed subset
reply S
if other allowed subsets exist that cannot join S:
MAY add notify ADDITIONAL_TS_POSSIBLEgo deeper
Recall that IKEv2 traffic selectors list the addresses an SA protects, and that the responder may accept only part of what it is offered.
Explain TSi and TSr, the packet-specific first selector, and the responder's four outcomes, including when TS_UNACCEPTABLE and ADDITIONAL_TS_POSSIBLE appear.
Diagnose the one-subnet symptom from the negotiated selectors, recognise why it follows the first speaker and survives rekeys, and fix it with matching granularity rather than one-sided widening.
Treat selector agreement as a contract across teams and implementations: standardise subnet lists or wide route-based selectors estate-wide so narrowing never decides reachability.
## What the two gateways exchange When IKEv2 creates a Child SA, in `IKE_AUTH` or a later `CREATE_CHILD_SA`, each side carries two **traffic selector** payloads: `TSi` (the initiator's side) and `TSr` (the responder's side). Each payload holds **one or more** selectors, and each selector is an address range, a port range and an IP protocol ID. They tell the peer which packets the new SA is for, drawn from the sender's Security Policy Database (SPD). RFC 7296 lets the responder accept **less** than it was offered. It explains why: the ends are often configured by different people, the mismatch can persist for a long time, and sometimes one end deliberately tunnels everything and relies on the other to hold the exact list. It also shapes the offer: if a data packet triggered the negotiation, the initiator **SHOULD** put a very specific selector built from that packet's addresses, ports and protocol first in each payload, followed by the wider range from its policy. ## The responder's four outcomes 1. No part of the proposal is allowed: reply with the `TS_UNACCEPTABLE` notify (no Child SA). 2. The whole proposal is allowed: return `TSi` and `TSr` unchanged. 3. The first, packet-specific selectors are allowed: the responder **MUST** narrow to a subset that **includes** them. 4. The first selectors are not allowed: narrow to some acceptable subset. When several subsets are acceptable but their union is not, the responder picks one and **MAY** add `ADDITIONAL_TS_POSSIBLE`: the other subsets were acceptable too, but only in a separate SA. RFC 7296 also defines `SINGLE_PAIR_REQUIRED` for a responder that insists on one address pair per SA, and says responders SHOULD narrow instead of using it. ## Tracing the symptom The branch is configured with one wide entry; the cloud gateway with one entry per branch subnet, each to be its own SA. | Step | What happens | |---|---| | 1 | Host `10.1.1.5` sends to `10.20.0.9`; the branch SPD matches `10.1.0.0/16` to `10.20.0.0/16`, no SA exists, so IKE starts | | 2 | Branch proposes `TSi` = [`10.1.1.5`, `10.1.0.0`-`10.1.255.255`], `TSr` = [`10.20.0.9`, `10.20.0.0`-`10.20.255.255`] | | 3 | Cloud policy allows `10.1.1.0/24` and `10.1.2.0/24` separately; it accepts the first selector, so it MUST narrow to a subset containing it, here `TSi` = `10.1.1.0/24`, and may add `ADDITIONAL_TS_POSSIBLE` | | 4 | A Child SA now exists for `10.1.1.0/24` only | | 5 | Traffic from `10.1.2.0/24` needs a second Child SA; if the branch implementation treats its one policy as satisfied and never asks, or pushes those packets into the existing SA, they die | In step 5 the cloud's RFC 4301 inbound check drops packets whose inner source falls outside the SA's selectors — an auditable event, optionally reported with the `INVALID_SELECTORS` notify. After a restart, if a host in `10.1.2.0/24` speaks first, step 3 lands on that subnet instead, which is exactly the "it changes after each restart" report. The mirror symptom: when the cloud side initiates, it offers its narrow pair, the wide branch accepts it unchanged, and everything "works when they start the tunnel". ## Why it persists across rekeys RFC 7296 forbids a rekey from shrinking scope: the new SA **MUST NOT** have narrower selectors than the one it replaces, and the responder MUST NOT narrow below the scope in use. A rekey therefore keeps whatever the first narrowing produced. The outcome changes only when the SAs are torn down and rebuilt, which is why restarts reshuffle it. ## Diagnosing and fixing - **Compare negotiated with configured.** IKE logs on both ends show the `TSi`/`TSr` actually installed; a narrower result than either side configured is the tell. - **Read the notifies.** `ADDITIONAL_TS_POSSIBLE` means narrowing happened; `TS_UNACCEPTABLE` means nothing overlapped; `INVALID_SELECTORS` means packets arrived on an SA they do not fit. - **Agree on granularity.** RFC 7296 notes that when both ends agree, the initiator never requests a tunnel wider than the responder accepts. Make the subnet lists identical at both ends. - **Or go wide on both ends.** Two route-based peers with any-to-any selectors leave nothing to narrow. - **Do not widen one side only.** RFC 7296 warns an initiator not to propose selectors that violate its own policy; a lopsided widening just moves the mismatch.
- In IKEv2, why does the initiator put a packet-specific selector first in TSi and TSr?So a responder with narrower policy can pick the range that actually matters. When narrowing is needed and the first selector is acceptable, the responder MUST keep a subset that includes it, so the packet that triggered the negotiation is guaranteed to be covered. Without it, the responder would have to guess which subset to return.
- Can a later IKEv2 rekey repair a Child SA that was narrowed too far?Not by narrowing, and it does not widen it on its own. RFC 7296 requires a rekeyed Child SA to have the same or wider selectors, and an initiator SHOULD propose the same set or a superset. In practice the narrowed scope is carried forward until the SA is deleted and renegotiated, or the configurations are made to agree.
saying these in an interview costs you the question
- If the tunnel is up, the traffic selectors must match on both ends.
- A responder that accepts only part of the selectors must reply TS_UNACCEPTABLE.
- A rekey will narrow the Child SA back to the correct subnets.
- Narrowing picks the responder's first configured subnet, not the packet's.
- Widening the selectors on one side only always fixes a mismatch.