Why NAT doesn't support in Transport Mode

[rakesh24csco]

Hi,

I have some queries.

1. Why NAT doesn't work in Transport mode?

2. How NAT-T works with IPsec? I have gone through some documents, however, didn't understand it exactly. 

https://supportforums.cisco.com/document/64281/how-does-nat-t-work-ipsec

This document says that a). in Main Mode first exchange detection process is performed to see if both end supports NAT-T.

b). In 2nd exchange process is performed to see if any NAT device exists in the path. 

c). If a NAT device has been determined to exist, NAT-T will change the ISAKMP transport with ISAKMP Main Mode messages five and six, at which point all ISAKMP packets change from UDP port 500 to UDP port 4500. 

I am agreed with points a) and b), however, not agreed with c). UDP port is changed to 4500 after it encapsulates the ESP packets in UDP. So my understanding is that phase 1 is still going to use UDP 500 and phase 2 is going to be UDP 4500.

Please help me to understand queries 1) and 2). Seeking prompt resposne.

Thanks,

Rakesh Kumar

[Rahul Govindan]

1) To explain this, we would need to understand tunnel vs transport mode. Look at the tunnel and transport mode headers without NAT-T.

Transport mode: http://www.tcpipguide.com/free/t_IPSecModesTransportandTunnel-2.htm

Tunnel mode: http://www.tcpipguide.com/free/t_IPSecModesTransportandTunnel-3.htm

Basically tunnel mode adds a new ip header and the ESP header goes in after that (original ip payload is encrypted after esp header). Transport mode basically adds the ESP header after existing ip header. In both cases, the TCP/UDP header is behind the ESP header, hence encrypted. Thus passing this through a PAT (Port Addres Translation) wont work as there is no non-encrypted tcp/udp field to change. If you just use one-to-one NAT (network address translation), only the ip headers change - so you can technically send the traffic through NAT device.

In short, NAT/PAT can be used with both tunnel and transport mode and ESP. In fact, DMVPN requires you to have transport mode when there is a NAT device in between hub and spoke.

http://www.cisco.com/en/US/docs/ios-xml/ios/sec_conn_dmvpn/configuration/15-2mt/sec-conn-dmvpn-dmvpn.html#GUID-D8F6839F-D735-4C8E-A199-602CDD8F7DD0

Most site to site vpn's use tunnel mode by default so that is the recommendation for those types of deployment which should work well with Nat-T

2) After receiving Main mode message 4 (MM4) , IKE starts uses NAT-T ports starting from message 5. This is explained in the RFC here:

https://tools.ietf.org/html/rfc3947#section-4

[rakesh24csco]

Hi Rahul,

As per my understanding, ESP works with NAT/PAT with NAT-T in tunnel mode, however, it doesn't work in transport mode.

Here is the toplogy and configuration for transport mode with NAT and it's not working. Phase 1 is successful and it stucks at phase2. NATing is done on PIX for R1.

Lo1----------R1 (vpn endpoint)-------------(inside) PIX (out)-----------------R3 (vpn endpoint)-------Lo1

Current configuration : 1459 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R1
!
!
!
crypto isakmp policy 10
encr 3des
hash md5
authentication pre-share
group 2
crypto isakmp key cisco address 20.1.1.1
!
!
crypto ipsec transform-set tset esp-3des esp-md5-hmac
mode transport
!
crypto map cmap 10 ipsec-isakmp
set peer 20.1.1.1
set transform-set tset
match address 102
!
!
!
interface Loopback1
ip address 1.1.1.1 255.255.255.0
!
interface FastEthernet0/0
ip address 10.1.1.1 255.255.255.0
duplex auto
speed auto
crypto map cmap
!
ip route 0.0.0.0 0.0.0.0 10.1.1.2
!
!
access-list 102 permit ip host 10.1.1.1 host 20.1.1.1
!
!
!
!
end

hostname R3
!
!
crypto isakmp policy 10
encr 3des
hash md5
authentication pre-share
group 2
crypto isakmp key cisco address 30.1.1.1
!
!
crypto ipsec transform-set tset esp-3des esp-md5-hmac
mode transport
!
crypto map cmap 10 ipsec-isakmp
set peer 30.1.1.1
set transform-set tset
match address 102
!
!
!
interface Loopback1
ip address 3.3.3.3 255.255.255.0
!
interface FastEthernet0/0
ip address 20.1.1.1 255.255.255.0
duplex auto
speed auto
crypto map cmap
!
ip route 0.0.0.0 0.0.0.0 20.1.1.2
!
access-list 102 permit ip host 20.1.1.1 host 10.1.1.1
!
!
end

PIX Version 8.0(3)
!
hostname pixfirewall
enable password 8Ry2YjIyt7RRXU24 encrypted
names
!
interface Ethernet0
nameif inside
security-level 100
ip address 10.1.1.2 255.255.255.0
!
interface Ethernet1
nameif outside
security-level 0
ip address 20.1.1.2 255.255.255.0
!
access-list out extended permit ip any any
!
access-list in extended permit ip any any
!
static (inside,outside) 30.1.1.1 10.1.1.1 netmask 255.255.255.255
!
access-group in in interface inside
access-group out in interface outside
!
end

[rakesh24csco]

Is there anyone who can answer my query "why Transport mode doesn't work with NAT?"

[Abhirajsingh yadav]

Transport mode use orginal ip header and tunnel mode orignal ip header is encanpsulated with new ip header.. additional ip header helps to work nat in tunnel mode and not in transport mode

[asad7488]

Hello Rakesh,

Here you go.

Because of the UDP checksum calculated at origin will not match with the checksum calculated at destination. UDP calculates checksum over below fields:

1. From IP Header (AKA Pseudo Header)

Source and Destination IP addresses

Length of Packet (Total length - Header Length)

Protocol (TCP/UDP)

2. UDP header + Data/Payload

Since the source IP is NATted, the destination will never have the visibility to original source IP address used to calculated UDP checksum.

Once the packet arrives at destination, the checksum will be computed again.  The new checksum computed will have different value since the source IP has been changed and the packet is discarded.

Please refer to RFC: https://tools.ietf.org/html/rfc3948#section-3.1.2

It is recommended to keep the UDP checksum calculation DISABLED when NAT T is used (IPv4 with UDP only).

As a result, IPsec Encapsulating Security Payload (ESP) will only pass through a NAT unimpeded if TCP/UDP protocols are not involved (as in IPsec tunnel mode or IPsec protected GRE), or checksum are not calculated (as is possible with IPv4 UDP).

As described in
[RFC793], TCP checksum calculation and verification is required in IPv4.
UDP/TCP checksum calculation and verification is required in IPv6.