Hello Cisco community,
I have a question regarding NAT-T with IPsec. I read that if you want to use IPsec with ESP and NAT, the router needs to add an additional UDP header with port 4500 to the packet since ESP doesn't have any ports by itself.
My question is if that "problem" could be rectified by using tunnel mode. Wouldn't the new IP-Header provide a new port or does it just change the IP-Address?
Thank you for clarification.
Tunnel-mode encapsulation itself does not add any UDP headers. It still is ESP which is an IP-protocol and needs an additionally UDP encapsulation for typical NAT/PAT scenarios.
ESP can go through a NAT device, it can't go through a PAT device because only UDP/TCP can be PAT'ed and your visible header from the IPsec packet, does not have TCP/UDP, unless you run NAT-T which allows you to have a visible outer UDP header. There are some vendors (Cisco is one) that actually can PAT IPsec/ESP traffic, by using the SPI value from the ESP packet and adding it to the port number in the NAT table.
Thank you all for the replies.
Meaning that in tunnel mode the router only checks if the outer IP-header matches its IP interface and then unpacks it further correct? Meaning if you used tunnel mode the router wouldn't even have to perform any NAT since it uses the public IP configured as the peer destination address for the outer header. After the router processes the packet (stripping the outer header) it would see the internal RFC1918 address correct?
With tunnel mode or transport mode configured, all routers in the path (including the VPN gateways) will look at the outer IP header, which has the IP address of the VPN gateways; after the IP header you have the ESP header and the secured payload. With NAT-T negotiated, you have an additional UDP header between the IP header and ESP header.
With tunnel mode or transport mode configured, if there is a NAT/PAT device in transit (which changes the IP of one or both of the VPN gateways), the packet will get NAT'ed.
Look at section 3.3 and 3.4 in the RFC, in order to visualise the packet encapsulation in both transport and tunnel mode. Transport mode, even if configured, for you to know, it's actually used ONLY if the IPsec design supports it; transport mode was designed for host-to-host IPsec tunnel (gateway-to-gateway is possible as well), the condition being that the IP header you want to secure is the same as the IP IPsec header, which means that both initial/unsecure IP header and post-encryption/secure IP header are the same; so it's like when the VPN gateways want to secure traffic through an IPsec tunnel, but the traffic is self-generated, in order for the two IP headers to be the same, so only one IP header is used in the end; cause this is the main advantage of transport mode, you have the luxury of removing one IP header, thus saving 20 bytes of overhead.