Cisco-proprietary NAT Transparency can be enabled in environments where NAT/PAT is not used, but perhaps a firewall allows UDP but not ESP packets. The standards-based implementation does not allow for this option, since it is autodetecting the need for NAT transparency based on whether or not the client is in a NAT/PAT environment.
Requesting a mechanism per profile to force use of NAT-T even if the VPN Client or VPN Concentrator do not detect that they are behind a NAT/PAT device.
What is that mechanism though, is it a new line in the profile .pcf file?
Something other than EnableNAT (which is already set to 1 on the machine in question, by default we presume)
NAT-T is enabled by default on both the concentrator and client versions since back around 3.6 days. They will automatically detect the presence (or not) of a device in between doing NAT during the IKE negotiation, and automatically do UDP encapsulation if necessary. There is nothing you can configure on either the client or the concentrator to make this happen, it's all automagic.
"Q. I am experiencing problems with only one VPN Client (for releases 3.3 and earlier) being able to connect through a Port Address Translation (PAT) device. What can I do to alleviate this problem?
A. There was a bug in several Network Address Translation (NAT)/PAT implementations that causes ports less than 1024 not to be translated. On the VPN Client 3.1, even with NAT transparency enabled, the Internet Security Association and Key Management Protocol (ISAKMP) session uses UDP 512. The first VPN Client goes through the PAT device and keeps source port 512 on the outside. When the second VPN Client connects, port 512 is already in use. The attempt fails.
There are three possible workarounds.
Fix the PAT device.
Upgrade the VPN Clients to 3.4 and use TCP encapsulation.
Install a VPN 3002 that replaces all VPN Clients."
We are behind a PAT device, which allows one IPSec connection through successfully (so the NAT Traversal capability of the Cisco VPN Client does not come in to play).
However, when a second person behind the same PAT devices tries their VPN client, they disrupt the first person's connection.
If we could force the VPN Client to use NAT-T, then multiple users behind the one PAT device should be successful?
We cannot use TCP encapsulation as it is a Cisco IOS router, not a VPN Concentrator we are connecting to.
As the bug is listed as 'resolved' it sounds like such a feature was added?
The VPN Client GUI only seems to offer 'Enable transparent tunnelling", not a require/force option.
I'd like to hear about this too. I'm having the same issue. It looks like the client correctly detects NAT and uses NAT-T when the client's IP is an RFC 1918 address, but doesn't detect it when the client address is a non-RFC 1918 (yes, I'm at a site where a non-RFC 1918 is natted to another non-RFC 1918). Sure would be good to have a way to force NAT-T.
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...