During Internet Key Exchange (IKE) phase 1 negotiation, two types of NAT detection occur before IKE Quick Mode begins--NAT
support and NAT existence along the network path.
To detect NAT support, you should exchange the vendor identification (ID) string with the remote peer. During Main Mode (MM)
1 and MM 2 of IKE phase 1, the remote peer sends a vendor ID string payload to its peer to indicate that this version supports
NAT traversal. Thereafter, NAT existence along the network path can be determined.
Detecting whether NAT exists along the network path allows you to find any NAT device between two peers and the exact location
of NAT. A NAT device can translate the private IP address and port to public value (or from public to private). This translation
changes the IP address and port if the packet goes through the device. To detect whether a NAT device exists along the network
path, the peers should send a payload with hashes of the IP address and port of both the source and destination address from
each end. If both ends calculate the hashes and the hashes match, each peer knows that a NAT device does not exist on the
network path between them. If the hashes do not match (that is, someone translated the address or port), then each peer needs
to perform NAT traversal to get the IPsec packet through the network.
The hashes are sent as a series of NAT discovery (NAT-D) payloads. Each payload contains one hash; if multiple hashes exist,
multiple NAT-D payloads are sent. In most environments, there are only two NAT-D payloads--one for the source address and
port and one for the destination address and port. The destination NAT-D payload is sent first, followed by the source NAT-D
payload, which implies that the receiver should expect to process the local NAT-D payload first and the remote NAT-D payload
second. The NAT-D payloads are included in the third and fourth messages in Main Mode and in the second and third messages
in Aggressive Mode (AM).