I have read that it is recommended to encapsulate IPsec packets into UDP (port 4500) packets in order to circumvent NAT. Could anyone please provide a detailed explanation of the reasons behind this solution?

2 Answers 2


ESP Security Associations (SA) are unidirectional. So to communicate bidirectionally two SAs are required, on each end one SA is for inbound traffic and one for outbound traffic (and vice-versa on the other end).

These SAs are identified by the protocol (ESP/AH), destination IP address and a 32-bit identifier called Security Parameters Index (SPI). And that's all the information that's contained in each ESP packet (protocol, destination address and destination SPI).

So unlike the source and destination ports that are part of UDP headers, only one SPI is contained in an ESP header. For a NAT router it is, therefore, not possibly to know to which host behind the NAT it has to forward inbound ESP packets. If there was never any outbound traffic it wouldn't know that even if both SPIs were contained in the ESP header as it doesn't know these SPIs, which are communicated encrypted via the Internet Key Exchange protocol (IKE) when the SAs were established.

What NAT routers often have is a feature called "IPsec passthrough". The NAT router will detect IKE traffic and then forward any plain ESP packets between the two hosts that communicated via IKE. However, this only works for one VPN client behind the NAT communicating with a particular server IP address. With more than one client the NAT again wouldn't know to which client to forward a particular inbound ESP packet.

In order to support this scenario UDP headers are added to the ESP packets. This allows the NAT to treat these ESP-in-UDP packets just like any other UDP packets. Since the same ports are used that are already in use for IKE the NAT actually already has port mappings in place when the peers start exchanging ESP traffic (unless the NAT router does deep inspection it can't distinguish this traffic from the IKE traffic).

To separate the IKE packets from the UDP-encapsulated ESP packets on the recipient the former have four zero bytes added between UDP and IKE header (called non-ESP marker), which is where the SPI is stored in ESP packets (which can't be 0 if RFC 3948 is implemented). This changed packet format is also why a different port is used for this traffic (4500).

UDP encapsulation basically works for both IPsec modes (tunnel/transport). However, there are some issues (described more detailed in RFC 3948's security considerations):

  • When using tunnel mode, the IP addresses of two clients behind different NATs could be the same, which would cause duplicate SAs/policies on the gateway. To avoid that gateways will usually assign virtual IP addresses from designated subnets to mobile clients (roadwarriors) during the IKE negotiation or via DHCP.

  • With transport mode, multiple clients behind the same NAT are problematic. If they all use the same protocol and port selectors the IPsec policies will overlap (as they all share the same public IP) and it could be difficult for the gateway to decide which SA to use to send traffic. In some scenario the ports used for the UDP encapsulation may be used to fix this issue (that's what strongSwan's connmark plugin tries to do). Also problematic is the situation when not all clients behind the NAT use IPsec to communicate with a gateway (see the RFC for details).

AH is inherently incompatible with NAT as its Integrity Check Value (ICV) includes the outer IP header (only excluding some fields). So any modification to the IP addresses by a NAT will invalidate the ICV.


The problem is IPsec tunnel mode, which uses the ESP protocol. ESP doesn't work with NAT for two reasons:

  1. ESP creates a checksum covering the whole packet, including the addresses. If the NAT changes the addresses, the integrity check will fail and the packet will be discarded.
  2. ESP also doesn't use ports. Therefore, NAT will not be able to add them to its translation database. (This doesn't prevent communication, but it does complicate it)

The solution is encapsulate the ESP traffic in UDP. The NAT can change the UDP addresses because the checksum of UDP is not relied on. The use of udp/4500 also means that the ESP traffic will be limited to a single port, allowing the NAT to add it to the translation dictionary.

For more details, check RFC 3947 and RFC 3948

  • 2
    Your first reason does not apply to ESP as the ICV does not include the outer IP header that would be modified by the NAT. It only applies to AH, whose ICV is computed over the complete packet, including the outer header.
    – ecdsa
    Commented Jul 12, 2017 at 7:22
  • Also you should probably mention NAT-T Commented Apr 20, 2019 at 21:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .