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.
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" .
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?
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.
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.
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.
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.
Getting Started
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:
