Why preshared key should not be used with nat traversal. What is the solution for this problem ?

[KAMAL55555]

I am establishing a VPN using IPSec with preshared support for authentication, but I studied that preshared key should not be used with nat traversal, what is the solution for this.

[Karsten Iwen]

Where did you read that? Of course you can use PSKs while also using NAT-Traversal.

[KAMAL55555]

Mr. Karsten I am using ipsectools-0.7.2 open source package, where I have a sample racoon.conf configuration file to racoon daemon . In that configuration file it has been mentioned that "With NAT-T you shouldn't use PSK" .

[Karsten Iwen]

Sadly, there is no reason for that statement mentioned. I never heard that before, and from the differences from native exchanges to NAT-T I have no idea why you shouldn't use PSKs in that case. Anyone else?

[KAMAL55555]

Mr. Karsten please go through this document attached (Page 5 paragraph 4) and answer.

[Karsten Iwen]

That problem is solved since a very long time; at least most vendors (including Cisco) have solved that problem. I remember a setup I had some years ago with an Astaro-device where the authentication failed due to NAT, but I assume that nowadays every vendor can handle that. Just think about it that the described problem in that document problems is over a decade old.

[KAMAL55555]

Mr.Karsten can U explain me what happens when a IPsec end point receives first packet of IKE phase 1 negotiation whose source address has been changed to another address(by PAT device) then is this packet accepted by the IPsec end point.

[Karsten Iwen]

There are two typical scenarios for that:

1. You have NAT but a fixed IP. That if often the case when there is a DSL-router in front of your VPN gateway and for whatever reason you can't or don't want to operate that device in "Bridge" or "Modem"-Mode. Another scenario is where the VPN gateway sits behind a dedicated Firewall and is natted to the internal DMZ-IP. In that case the VPN-device (1) has a private IP that gets translated to the fixed public IP. On the other VPN-gateway (2) you configure that public IP as the peer-address. Here you can run into problems with older equipment when the peer behind NAT tells the gateway 2 "my identity is 10.10.10.10" (the private IP). But I haven't seen problems with that for quite long time.
2. You have a dynamic IP with a PAT device. In that case you typically configure one of the various Remote-Access styles where the Hub-gateway doesn't reference the IP of the spoke and therefor the spoke can connect with any IP. Here wildcard-PSKs are used which are not a best practice. In that case the use of digital certificates is the better choice.