A branch Cisco Secure Firewall (FTD) sits behind an ISP router performing NAT. The tunnel to HQ starts IKEv2 successfully, then fails once the peers detect NAT. The ISP filter permits only UDP 500 between the peers. Which change resolves this?
Select an answer to reveal the explanation.
Short Explanation
NAT and plain ESP don't get along, because ESP has no ports for NAT to track. So when the peers spot NAT, they move everything onto UDP 4500 and keep going. If your path only allows UDP 500, the conversation stops right after the move.
Full Explanation
IKEv2 begins on UDP 500. During the initial exchange, each peer includes NAT detection payloads, which are hashes of the addresses and ports it believes it is using; if the received values do not match, a NAT device is present. The peers then switch to UDP 4500 for the remaining IKE messages and encapsulate ESP inside UDP 4500 as well, so that port-based NAT can track the flows. If the path permits only UDP 500, the first exchange succeeds and everything after the switch is dropped, which matches the symptom. Permitting IP protocol 50 helps only when no NAT is present, because native ESP has no ports and many NAT devices cannot translate it; once NAT-T is in use, ESP travels inside UDP 4500. AH, protocol 51, authenticates the outer IP header and is fundamentally incompatible with NAT, and the FTD tunnel uses ESP, so permitting it changes nothing. IKE does not move to TCP 500; NAT traversal is UDP based, and the stated filter shows UDP 500 already works. Exam caveat: NAT-T keepalives keep the translation alive during idle periods, so very short NAT timeouts can still cause intermittent drops. Operational check: permit UDP 4500, clear the security associations, and confirm the IKE and IPsec security associations show NAT-T in use with UDP 4500.