|
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
|
