| Ports Used in IKE/IPsec. - Without NAT-T (no NAT detected):
- IKE Phase 1 and Phase 2 negotiations happen over UDP/500.
- ESP traffic flows directly using IP protocol 50 (no UDP port).
- UDP/4500 is not used.
-
With NAT-T (NAT detected in the path): - Negotiation always starts on UDP/500.
- During IKE Phase 1, peers exchange NAT-Discovery (NAT-D) payloads.
- If NAT is detected, both peers switch to UDP/4500:
- IKE continues on UDP/4500.
- ESP traffic is encapsulated in UDP/4500 (because NAT cannot handle the raw IP protocol 50).
From that point onward, all VPN traffic (IKE + ESP) uses UDP/4500. Always start on UDP/500 due: - Protocol standard (RFC 2407/2409 for IKEv1, RFC 5996/7296 for IKEv2):
All IKE negotiations must begin on UDP/500 for compatibility. A peer cannot know in advance if NAT exists. -
NAT-Discovery process: - Initial packets are exchanged over UDP/500.
- Each peer includes hashes of its IP/port.
- If the values differ (modified by NAT), both peers agree to switch to UDP/4500.
-
Transparent transition: After detection, all further packets (IKE and ESP) are encapsulated in UDP/4500.
If there is no NAT, the entire negotiation stays on UDP/500. Port Summary.
| Scenario | IKE Phase 1 | IKE Phase 2 | ESP Traffic |
| ---------------- | -------------- | ----------- | ------------------------ |
| Without NAT-T | UDP/500 | UDP/500 | ESP (IP protocol 50 ) |
| With NAT-T (NAT) | UDP/500 → 4500 | UDP/4500 | ESP encapsulated in 4500 |
The reason to always see the first attempt on UDP/500 (even with NAT-T) is that the IKE standard requires negotiation to begin there.
If NAT is detected, the session then migrates to UDP/4500.
Related articles: Technical Tip: IPSec VPN NAT-traversal Troubleshooting Tip: IPsec VPN tunnels Troubleshooting Tip: IPsec VPN failure due to one way IKE (UDP 500) communication | 
