×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

CSCdz58488 - force NAT-T NAT transparency

Unanswered Question
Jun 27th, 2006
User Badges:

Hi there, wondering how to force NAT-T transparency on the VPN Client running under Windowsn.


http://www.cisco.com/univercd/cc/td/doc/product/vpn/client/rel4_0/405bclnt.htm says:


###

Caveats Resolved in Release 4.0.5.A


Release 4.0.5.A resolves the following issues:


?CSCdz58488


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)


Thanks for any guidance, Neil.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
gfullage Tue, 06/27/2006 - 17:35
User Badges:
  • Cisco Employee,

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.



converged Tue, 06/27/2006 - 23:40
User Badges:

Hi there,


we need to force the client to use NAT-T, even though it doesn't think it needs to.


We are in the situation described by: CSCdz58488

"Problem: With the Cisco proprietary NAT Transparency, it 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.


Requested: Mechanism per profile to force use of NAT-T even if client/conc.

do not detect that they are behind a NAT/PAT device."


also here:

http://www.cisco.com/en/US/products/sw/secursw/ps2308/products_qanda_item09186a00801c2dbe.shtml#q26

"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.


Many thanks, Neil.

1j.graves Tue, 01/16/2007 - 09:48
User Badges:

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.

Actions

This Discussion