A library consortium sees intermittent IPsec failures to one DMVPN spoke after the spoke ISP introduced asymmetric return paths. What underlay issue most likely undermines the protected tunnel?
Select an answer to reveal the explanation.
Short Explanation
When your spoke’s packets take different routes out and back, underlay asymmetry can disrupt IPsec state or path expectations even if the overlay tunnel addresses look right. You can still see intermittent failures because those addresses alone don’t guarantee a healthy protected path.
Full Explanation
When a library consortium sees intermittent IPsec failures after a spoke ISP introduces asymmetric return paths, underlay asymmetry is the likely culprit. IPsec state, anti-replay handling, and firewall or NAT expectations can be disrupted when forward and return packets take different provider routes, even when overlay tunnel addressing and crypto configuration look correct. You may see flaps, incomplete SAs, or one-way encrypted traffic between hubs and branch libraries. NHRP is not necessarily unaffected by underlay asymmetry, and failures are not limited to an incompatible OSPF network type; treating those as the only possible cause confuses distinct mechanisms. IPsec does not require identical traceroute hops in both directions as an absolute rule, and GRE encapsulation is not gated solely by traceroute symmetry, though severe asymmetry can accompany a broken protected path. Asymmetry does not only affect Telnet to the console: console Telnet and IPsec use different planes, and IPsec can be sensitive to path behavior. Exam caveat: after verifying crypto configuration, investigate underlay paths, NAT, and firewall behavior. Practical check: traceroute both directions between hub and spoke NBMA addresses, compare ISP ingress and egress, inspect SA counters for encrypt-without-decrypt patterns, and engage the spoke ISP or pin paths if asymmetry is confirmed.