I85PREP
⌘ K
Cisco 300-730 SVPN study materials
Cisco 300-730 SVPN study resources

FlexVPN Spoke Behind NAT and Missing Spoke-to-Spoke Path

Cisco 300-730 SVPN · Put your knowledge to work in context.

All case studies

FlexVPN Spoke Behind NAT and Missing Spoke-to-Spoke Path

A FlexVPN hub on IOS-XE 17.6 uses IKEv2 with pre-shared keys, a dynamic virtual-template, and EIGRP AS 10. Thirty spokes connect to hub 203.0.113.10; each spoke uses a crypto ikev2 profile with match identity remote fqdn, a keyring, and virtual-template 1. The hub uses ip nhrp redirect on the virtual-template; spokes use ip nhrp shortcut. One spoke is behind a home NAT and fails IKEv2 with 'no matching policy' while other spokes work. A second spoke establishes IKEv2 but cannot build a direct path to a third spoke; traffic goes through the hub. The customer also reports that after a spoke's public IP changes, the hub keeps the old IKEv2 SA for 30 minutes. Proposed fixes must avoid disabling NAT-T and must keep the hub from becoming a bottleneck.

1. What is your troubleshooting sequence for the spoke behind NAT that reports 'no matching policy'?

Read the worked answer

Start by separating IKEv2 negotiation from authorization and routing. 'No matching policy' usually means the responder did not find an IKEv2 profile whose match conditions fit the initiator, not that the pre-shared key is wrong.

Sequence:

  1. On the hub, show crypto ikev2 sa and show crypto ikev2 session to see whether an IKE_SA exists for that spoke. If no SA exists, the failure is in IKEv2 policy/profile matching.
  2. Compare proposals: show crypto ikev2 proposal, show crypto ikev2 policy, and the spoke's configured proposal. Encryption, integrity, and DH group must match exactly.
  3. Check the hub profile's match identity remote fqdn value against the spoke's configured identity. A NAT device does not change the IKEv2 identity, but a spoke using match identity remote address or a different FQDN will not match.
  4. Confirm the hub's keyring contains the correct pre-shared key for that identity.
  5. For NAT, verify UDP 500 and 4500 are permitted and that crypto ikev2 nat keepalive is configured on the spoke. NAT-T is negotiated only after the IKE_SA forms; it does not cause 'no matching policy' by itself.
  6. Use debug crypto ikev2 packet and debug crypto ikev2 error on the hub during a test connection. The debug should show which profile match failed.

2. Why is the direct spoke-to-spoke path missing, and how do you fix it without making the hub carry all data traffic?

Read the worked answer

FlexVPN spoke-to-spoke uses the same NHRP redirect/shortcut model as DMVPN Phase 3. The hub must see the first packet on the virtual-template, send an NHRP redirect to the source spoke, and the source spoke must resolve the destination's NBMA address and install a shortcut. If the hub's virtual-template lacks ip nhrp redirect, or the spoke lacks ip nhrp shortcut on the virtual-template interface, traffic stays hub-and-spoke.

Verify:

  • On the hub virtual-template: ip nhrp redirect, correct ip nhrp network-id, and ip nhrp map multicast dynamic where multicast routing is used.
  • On the spoke: ip nhrp shortcut on the virtual-template interface, and routing that points the remote prefix at the hub (EIGRP over the tunnel).
  • show ip nhrp on both spokes; the destination should resolve to the peer's public NBMA address, not the hub.
  • show crypto ikev2 sa on the hub should show a dynamic IKEv2 SA between the two spokes after the shortcut forms.

Fix by adding the missing redirect/shortcut, then clear the NHRP cache and test with a ping that forces the first packet through the hub. Do not solve this by adding a full mesh of static tunnels; that defeats the hub's dynamic virtual-template and increases operational overhead.

3. The hub keeps an old IKEv2 SA for 30 minutes after a spoke's public IP changes. What causes this, and what tuning would you apply?

Read the worked answer

The hub has no way to know the spoke's public IP changed unless IKEv2 dead peer detection (DPD) probes fail and tear down the old SA, or the spoke sends a new IKE_SA_INIT that replaces it. Without DPD, the old SA remains until its lifetime or until the next rekey. A 30-minute stale SA is consistent with default or long DPD/rekey timers.

Apply:

  • crypto ikev2 dpd 10 3 on-demand (or periodic, depending on design) on both hub and spoke profiles so the hub detects an unreachable peer quickly.
  • Keep NAT-T enabled; DPD probes are sent inside UDP 4500 when NAT is detected, so do not disable NAT-T to solve this.
  • Confirm crypto ikev2 nat keepalive is configured on the spoke so the NAT mapping stays alive between probes.
  • Check the IKEv2 SA lifetime/rekey settings. Shortening the lifetime forces more frequent rekeys but also faster cleanup; DPD is the better primary control.
  • Test by changing the spoke's public IP (or breaking the NAT mapping) and watching show crypto ikev2 sa on the hub; the old SA should disappear within the DPD interval, not 30 minutes.