IPsec Transport mode with NAT-T | Why doesn't it work?

[ameen.ahmed]

Hi,

1) I understand that if ISAKMP identifies any NAT device, it encapsulate ESP in UDP-4500. If this NAT-T mechanism is designed to make IPsec compatible with NAT, why doesn't the transport mode work with NAT? 

2) If the only difference between tunnel mode and transport mode is the encryption of original IP header, how does Tunnel mode support NAT-T ?

3) Why doesn't DMVPN support the NAT-T feature and why is that transport mode is a MUST for DMVPN?

Regards,

Ameen.

[ameen.ahmed]

Could anyone pls help answer?

[asdg]

I'm not sure about it, but in my short knowledge, and not good English,

1) In a normal NAT environment ( without IPsec ),  not only original IP header is translated to specify public IP address, but also TCP/UDP checksum that is created by TCP/UDP header and IP header ( pseudo header ) is properly modifed to other values which is suit for NAT'ed address. 

But, in IPsec transport mode, because the TCP/UDP header is encrypted, while translating the IP Header of Origin IP Header, NAT device is not able to modify that TCP/UDP checksum to some suitable values for NAT'ed address. then the TCP/UDP checksum will not be matched at destination, so connection isn't established normarlly.

However, in IPsec Tunnel mode, while the transport mode does not encrypt Origin IP Header, that Origin IP Header,TCP/UDP Checksum is encrypted, so the "New IP Header" which is IP address of VPN GW can be only translated to other IP address with no affect to Origin IP Header. So the TCP/UDP Checksum will be matched normally with Origin IP Header and connection will be established.

2)Well...Maybe the make PAT to work?

3) I think that IPsec Transport mode is "recommended" for DMVPN in order to reduce 20byte of overhead. Not MUST, since GRE Tunnel already hide its own original IP address with GRE Delivery Header ( PUblic IP address ) .