Cisco VPN Client and NAT-T

[sawosankung]

I have a Cisco VPN client behind 2 NAT devices and trying to connect to a VPN server. The client however seem to be detecting only one NAT device as a second client fails to connect once one is online already. Also, when I looked at a trace of the communication from the server end, I noticed that for the second client the IPSec packet is lost/dropped at the second NAT device (upstream to the clients) and hence the ISAKMP exchange fails.

How can the client and server be forced to detect more than two NAT devices between them ?

I am using a Cisco vpn client ver 5.0.0.6

Thanks

sankung

[Federico Coto Fajardo]

Hi,

I know that NAT-T auto detects a NAT device (i'm not sure about two)... have you tried IPsec/TCP instead of NAT-T?

Federico.

[Jennifer Halim]

It really depends on which NAT you are using. For outbound VPN, you can use dynamic NAT, however, for inbound VPN connection, you would need to have static NAT as dynamic NAT does not typically work for inbound connection, especially if your NAT device is ASA for example.

[sawosankung]

Here is the schematics:

Client----------NATdev#1-------------------NATdev#2--------------------------Internet--------------------------PIX-FW(VPNServer)---------------------LAN

One client can connect to the vpn server without any problems. However, a second client cannot connect as the IPSec/ESP packet is dropped at NATdev#2. I say this because I can see the packet leave the VPNServer but it is not received at the second client.

NB: NATdev#2 is at the ISP and so I have no access to it.

Thanks

sankung

[Federico Coto Fajardo]

When the client and server are configured for NAT-T, NAT-T should automatically detect if there's a NAT device in the path.

It establishes the tunnel using ISAKMP (UDP 500) and then encapsulates ESP in UDP 4500.

You can try enabling IPsec/TCP on both client/server to see if it works.

Federico.

[sawosankung]

Hi Federico,

NAT-T is enabled on both Client and Server and works fine on a path where there is only two NAT devices: eg

Client------------NATdev#1-----------------------Internet---------NATdev#a-------------VPNServer

What does NOT work is:

Client------------NATdev#1----NATdev#2-----Internet----------NATdev#a-------------VPNServer

However, remember that IKE (ISAKMP) Main Mode (MM 1 and 2) the client and server first exchange vendor IDs to determine that they can support NAT-T and then subsequently exchange NAT Discovery (NAT-D) hash messages to detect actual NAT devices between them. As I understand from the tech guide, the number of hash messages exchanged corresponds to the number of NAT devices detected. Also, the client sends the server end NAT-D hash message first and then its own (source). The NAT-D payloads are supposed to be in the 3rd and 4th ISAKMP messages, etc.

Now, I can see the ISAKMP MM message exchanges in a sniffer trace. Apparently the vpn server doesn't follow the client when it sends the second hash for the second NAT and instead it sticks to the first one - client sends two payloads/messages with different port addresses indicating two NAT devices. Thus since the server doesn't acknowledge the second NAT-D message, the Quick Mode negotiation fails and hence the IPSec tunnel is not built.

So I wonder whether there is a configuration to be done on the vpn server (PIX FW) in order to force it to detect more than one NAT device, or just follow the client on NAT-D  until completed.

Thanks.

sankung

[Federico Coto Fajardo]

I'm not aware of anything you can configure on the VPN server (assuming an IOS or PIX/ASA) to tell it that the client is behind two NAT devices.

Question.. what kind of NAT is performed by both devices (PAT, static NAT, dynamic NAT)?

The question here is why the server won't respond to the second NAT-D message.

I was suggesting as a test to try IPsec/TCP (I understand this does not fix the problem, but might allow the client to work in the same scenario).

A better suggestion could be opening a TAC case for further investigation since this is not a common scenario.

Federico.

[sawosankung]

Hi Federico,

The Client is doing IPSec/UDP and PIX also is NAT-T aware. Further to my message and on inpsecting the trace, I noticed that in fact after sending the Vendor ID (for NAT awareness), the PIX starts to send its IPSec parameters immediately - it doesn't send any NAT-D packets at all. Unfortunately I don't have access to the PIX but that's what is causing the problem, it doesn't go into NAT-D message exchange with the client. Thus with the default NAT port only one IPSec Client is able to connect to it from the Clients' location.

What is the additional command on the PIX to ensure NAT-D discovery ?

Thanks

sankung 

[Federico Coto Fajardo]

I don't think there are any commands to tell the PIX/IOS/ASA that there are more than one NAT devices in the path or that there are more than one remote client coming through NAT.

As long as the PIX is configured for NAT-T and accepts a remote client, it should accept more because NAT-T encapsulates ESP in UDP 4500 and the PIX should differentiate based on source port each client.

So, you can have one, two or more remote clients connecting to the same VPN server (thru a PAT device) connecting fine using NAT-T (as long as NAT-T is configured on the client and server side.

The PIX is relatively old and might have this weird behavior with NAT-T... which version are you running on the PIX and what kind of NAT is being done in the path exactly?

Federico.

[sawosankung]

Problem could not be resolved - ie to make the PIX FW to do multiple NT-D discovery.

However, I finally decided to eliminate the second NAT stage by configuring the device to operate in BRIDGE mode. This way the link was made symmetrical in terms of NATing and thus multiple clients are now able to connect to the IPSec hub.

Now, case laid to rest.

Thanks for all those who helped.

sankung

[Federico Coto Fajardo]

Thank you for the feedback!

Federico.