Solved: Win2k NAT'd by 1650 to a PIX 515 - Not working

mksmith · ‎12-10-2002

Hello

:

I have a working VPN config on my 515 (6.2.2) and can tunnel from a host with a valid external IP with no problem. But, with a NAT'd client, nothing seems to work.

I am using TACACS to authenticate after using a group password. Here's the succession of events.

1) Client machine as a 10.0.0.1 address, NAT'd to a public address, coming in the 'outside' port.

2) Client connects, user enters TACACS password and is connected.

3) User tries to browse any service and cannot.

4) If user switches DNS to an outside server, the internet portion of the split tunnel works great, but the internal is still broken.

5) Clients with static IP addresses that are publically routable get connected and can perform all internal and external split tunnel activities.

Here are config snippets. Am I doing something wrong?

sysopt connection permit-ipsec

no sysopt route dnat

crypto ipsec transform-set noaset esp-des esp-md5-hmac

crypto dynamic-map dynnoamap 10 set transform-set noaset

crypto map noamap 10 ipsec-isakmp dynamic dynnoamap

crypto map noamap client authentication harpy

crypto map noamap interface outside

isakmp enable outside

isakmp identity address

isakmp policy 10 authentication pre-share

isakmp policy 10 encryption des

isakmp policy 10 hash md5

isakmp policy 10 group 2

isakmp policy 10 lifetime 86400

vpngroup noagroup address-pool noapool

vpngroup noagroup dns-server 66.119.192.1

vpngroup noagroup wins-server 66.119.192.4

vpngroup noagroup default-domain noanet.net

vpngroup noagroup split-tunnel vpn-ips

vpngroup noagroup idle-time 3600

vpngroup noagroup password ********

Help and thanks in advance.

Mike

gfullage · ‎12-10-2002

You're not doing anything wrong. The problem is that NAT (actually PAT, port address translation) and IPSec don't work very well, and a lot of PAT devices can't PAT IPSec traffic at all (PIX included until 6.3 release).

The trouble is that PAT relies on using the TCP or UDP source port number as a way to differentiate between all the different sessions, seeing as they're all PAT'd to the same source IP address. IPSec however (ESP at least), runs right on top of IP, in other words, it's NOT a TCP or UDP protocol, and therefore has no port number associated with it. This breaks most PAT devices.

The reason you can build your tunnel initially is that this is all done by ISAKMP, which is a UDP protocol, so this can be PAT'd fine. Once the tunnel is built however, all encrypted data is sent in ESP packets, which as I said, is not a TCP or UDP protocol.

Static NAT trnalsations work cause they don't rely on using the port number, they just change the source address which works fine with ESP.

There's not a whole lot you can do about this. If you were terminating the VPN into a VPN3000 concentrator, it has a feature called IPSec thru NAT, which encapsulates all the ESP packets into a UDP packet which can then be PAT'd properly. The PIX, unfortunately, doesn't have this feature. The only other workaround is to get a NAT device that handles IPSEc properly. Surprisingly some of the cheaper devices on the market do handle it, but you'd have to check with each manufacturer to be sure.

View solution in original post

gfullage · ‎12-10-2002

You're not doing anything wrong. The problem is that NAT (actually PAT, port address translation) and IPSec don't work very well, and a lot of PAT devices can't PAT IPSec traffic at all (PIX included until 6.3 release).

The trouble is that PAT relies on using the TCP or UDP source port number as a way to differentiate between all the different sessions, seeing as they're all PAT'd to the same source IP address. IPSec however (ESP at least), runs right on top of IP, in other words, it's NOT a TCP or UDP protocol, and therefore has no port number associated with it. This breaks most PAT devices.

The reason you can build your tunnel initially is that this is all done by ISAKMP, which is a UDP protocol, so this can be PAT'd fine. Once the tunnel is built however, all encrypted data is sent in ESP packets, which as I said, is not a TCP or UDP protocol.

Static NAT trnalsations work cause they don't rely on using the port number, they just change the source address which works fine with ESP.

There's not a whole lot you can do about this. If you were terminating the VPN into a VPN3000 concentrator, it has a feature called IPSec thru NAT, which encapsulates all the ESP packets into a UDP packet which can then be PAT'd properly. The PIX, unfortunately, doesn't have this feature. The only other workaround is to get a NAT device that handles IPSEc properly. Surprisingly some of the cheaper devices on the market do handle it, but you'd have to check with each manufacturer to be sure.