A retailer IOS XE router sits behind a NAT device and builds a route-based tunnel to an Azure VPN gateway. IKE starts on UDP 500, then the SA never completes. UDP 4500 is blocked on the path. What is the failure?
Select an answer to reveal the explanation.
Short Explanation
Once the router notices it is being translated, it knocks on a second door. That door is UDP 4500, and something on the path has it shut. You are not going to finish NAT traversal to Azure on UDP 500 alone, and BGP is not the IKE port.
Full Explanation
IKEv2 starts on UDP 500. When the IOS XE router detects NAT, NAT-T moves the subsequent datagrams to UDP 4500. Azure route-based VPN gateways accept that NAT-T behavior. If UDP 4500 is blocked, the SA never completes even though the first UDP 500 packets were seen. The failure is the blocked NAT-T port, not a refusal by Azure to allow translation. Azure does not require a NATed router to remain on UDP 500 only. TCP 179 is BGP and runs after the tunnel exists. It is not a substitute for IKEv2. A GRE keepalive is not this session. The native Azure VPN gateway is expecting IPsec, and the symptom is an IKE session that stalled after NAT detection. Exam caveat: if the router were on a public address with no NAT, UDP 500 could carry the whole negotiation and 4500 would matter less. The stem puts the router behind NAT, so 4500 is required. Operational check: a capture between the NAT device and the internet should show UDP 4500 toward the Azure public IP after the first UDP 500 exchange, and show crypto ikev2 sa should then reach a ready state.