I have a strange situation where the WR21, sometimes, does not shift to UDP4500 and the phase 2 negotiation with a Cisco IOS router never completes. The IKE sa is there but the Digi and the Cisco are stuck into the dance of the phase 2 never completing. I can see the WR21 trying to negotiate phase 2 over UDP500 on the Cisco debug which will fail because it behind a NAT wall…and it does fail. If I reboot the Digi, sometimes once, sometimes twice, the tunnels then come up fine of UDP4500.
Has anyone every seen this before?
Is there anyway to force the WR21 to use NAT-t?
In the old FW there used to be a setting but I don’t see it anymore.
Detects NAT devices along the transmission path (NAT-Discovery)
Step one occurs in ISAKMP Main Mode messages one and two. If both devices support NAT-T, then NAT-Discovery is performed in ISKAMP Main Mode messages (packets) three and four. THe NAT-D payload sent is a hash of the original IP address and port. Devices exchange two NAT-D packets, one with source IP and port, and another with destination IP and port. The receiving device recalculates the hash and compares it with the hash it received; if they don’t match a NAT device exists.
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. NAT-T encapsulates the Quick Mode (IPsec Phase 2) exchange inside UDP 4500 as well. After Quick Mode completes data that gets encrypted on the IPsec Security Association is encapsulated inside UDP port 4500 as well, thus providing a port to be used in the PAT device for translation.
To visualize how this works and how the IP packet is encapsulated:
Clear text packet will be encrypted/encapsulated inside an ESP packet
ESP packet will be encapsulated inside a UDP/4500 packet.
NAT-T encapsulates ESP packets inside UDP and assigns both the Source and Destination ports as 4500. After this encapsulation there is enough information for the PAT database binding to build successfully. Now ESP packets can be translated through a PAT device.
When a packet with source and destination port of 4500 is sent through a PAT device (from inside to outside), the PAT device will change the source port from 4500 to a random high port, while keeping the destination port of 4500. When a different NAT-T session passes through the PAT device, it will change the source port from 4500 to a different random high port, and so on. This way each local host has a unique database entry in the PAT devices mapping its RFC1918 ip address/port4500 to the public ip address/high-port.
Thanx Nic…but I am already aware of how its “supposed” to work, what I was after is how does this particular function work on the Digi.
Anyhow, I did some testing and in short, if you set it to force Nat-T, you’ll never connect again. I had to send “ike 0 natt 2” via sms to fix it (which tells the system to change ti back to auto).
I did some testing with a new WR44 with two differnt SIM cards:
One that uses real IP addresses (no NAT),
One that uses private IPs (Nat’d).
When using 1 if I look at he Cisco, the source and destination UDP ports are both 500 which you’d expect. For number 2 the source port on the Cisco was 4500 and the source port on the Digi was 4500 but the port the Cisco saw was some arbitrary port from the telco’s gateway that was Nat’ing it.
In short, when I set it to force, nothing worked.