Traffic Selector Mismatch on a Route-Based Hub

IKEv2 can negotiate multiple traffic-selector pairs, but the responder only installs pairs that match what it is configured to accept. The hub has an explicit traffic-selector of 10.0.0.0/16 to 192.168.10.0/24. The branch proposes both 192.168.10.0/24 and 10.50.0.0/16, but the hub's configured selector covers only the first, so only that child SA pair is installed. The static route for 10.50.0.0/16 still points into st0.0, so those packets are routed into a tunnel that has no matching selector and are dropped.

Two fixes are valid:

• Add a second traffic-selector with local 10.0.0.0/16 and remote 10.50.0.0/16, keeping the existing one.
• Remove the explicit traffic-selector from the route-based VPN so it uses 0.0.0.0/0 to 0.0.0.0/0 and lets the routing table decide which prefixes enter st0.0. This is usually the better choice for a hub with many branches and changing subnets, because it avoids per-subnet selector maintenance.

After the change, clear the IKE/IPsec SAs so the child SA renegotiates, then verify with show security ipsec sa detail that both selectors are present and test with a ping sourced from the hub's tunnel-side address.

vpn-monitor probes a single destination. The configured destination is in 192.168.10.0/24, which is the selector that works, so the monitor stays up and the static route for 10.50.0.0/16 is never withdrawn. The monitor is answering a coarse question: is this VPN alive at all? It is not answering: is each protected prefix reachable?

Options, in order of preference:

1. Run a dynamic routing protocol over st0.0, such as OSPF or BGP, so each branch advertises its own prefixes and a dead prefix is withdrawn by the routing protocol rather than by a ping monitor.
2. Split the protected prefixes into separate VPNs or separate st0 units, each with its own monitor destination, if dynamic routing is not permitted.
3. Keep vpn-monitor for liveness only and accept that per-prefix blackholing must be detected by other means, such as IP SLA-style probes from a monitoring system.

In all cases, test by blocking the 10.50.0.0/16 selector or shutting the branch's server subnet and confirming that the hub stops forwarding into the tunnel rather than silently dropping.

If the hub's IKE gateway uses a static peer address, the hub keeps sending IKE and ESP to the old address until dead peer detection declares the peer dead and clears the SA. The branch must then re-initiate from its new address. Without DPD, the hub can hold a stale SA for a long time, and traffic is blackholed in both directions.

Configure IKEv2 dead peer detection to send probes and to fail over promptly, and keep rekey timers reasonable. If the branch is behind NAT, enable NAT-T keepalives so the NAT mapping does not expire and the hub can still reach the branch's current UDP port. For a hub with many dynamic spokes, use a dynamic peer configuration rather than a static address, and identify the spoke by identity rather than by IP where the platform supports it.

Verify with show security ike sa detail for peer address and DPD state, show security ipsec sa for the current tunnel, and show log messages for DPD and IKE renegotiation events. Confirm the static route to the branch points at a live st0.0 tunnel, and test with a sourced ping after the branch's address changes.