how can NAT-T method solve IKE negotiate process?

[ilovebgp4]

NAT-T lets IPSec peers establish a connection through a NAT device. It does this by encapsulating IPSec traffic in UDP datagrams, using port 4500, thereby providing NAT devices with port information. NAT-T only encapsulates IPSec traffic when necessary.

then how can it solve the IKE negotiate process in NAT environment?

[gfullage]

NAT-T won't solve any IKE negotiation processes, if you have a configuration difference between the two IPSec peers then it won't work with or without NAT-T.

All NAT-T does is detect a NAT device in between the two peers during the negotiation process, and if one is detected, then all ESP packets are encapsulated in UDP/4500. This is done because a lot of NAT (more precisely PAT) devices can't NAT/PAT IPSec ESP packets because they sit right on top of IP, and therefore there is no UDP or TCP port number to differentiate the conversations on. By encapsulating the ESP packets (and only the ESP packets) in UDP/4500 the NAT/PAT devices are able to do their magic correctly.

[ilovebgp4]

Thanks for your reply.So NAT-T only resolve the esp nat traverse,then how can we resolve the IKE negotiation through NAT device?does it need a modification in IKE method?

[abdel_n]

Hi,

Both IPSec peers must support NAT-T that’s why negotiation begin by exchanging VID (using udp 500), if both ends supports it they exchange NAT-T payload (src ip,dst ip, src port, dst port + hash), and if the calculated hash doesn’t match the one received, it mean that there is NAT device(s) between the 2 peers, so in the next exchange peers will change src and dst ports to 4500 and continue IKE phase 1/2 negotiations, this is called “floating IKE”.

[maraz]

Just to clarify: ISAKMP is done with source port udp 500 and destination port udp 500. This phase can actually be NAT/PAT on the way. The stage where you exchange the encrypted traffic is done with the protokoll ESP which has no ports associated with it and can not be PAT on the way. Therefor they "invented" NAT-T.

[ilovebgp4]

Thanks for your apply.

so you mean nat/pat has no impact on ISAKMP process? But the pre-shared key authentication method in ISAKMP use the packet's source IP address as key index,I think ISAKMP can not be NAT/PAT on the way.

[maraz]

Yes, RFC2412 states that the ID-information konsists of the source and destination-address BUT the receiver does not use the source address at the arriving packet. It only computes the correctness of the ID-fields in the ISAKMP-header. Therefor the packet can be NAT/PAT on the way. Other security RFC only describe the ID field very vague. But I have tested to NAT IPSEC-tunnels without any problem (as long as you do not use AH)

Best Regards

Robert Maras