How to get around Double NAT

phlitservices · ‎03-18-2006

Hi all,

I have a slight problem, any assistance is appreciated. I have a dsl connection coming into a cisco adsl router which does NAT (10.10.10.0), from the router the connection then goes into the a PIX 506e which also does NAT(192.168.1.0).

I've configure the PIX for a RAS VPN using the cisco cpn client. The remote clients can connect to the pix, but cannot browse inside hosts. When I look at the syslogs, I see the packets are being denied in from the outside client. I think its because of the double NATTING. How do I get around this??

Thanks in advance

Don

bertels.p · ‎03-18-2006

Don,

Your situtation sounds a little different than one I had about 2 years ago... I too was on this forum looking for assistance....

Look into isakmp nat-traversal

http://seclists.org/lists/firewall-wizards/2004/Dec/0105.html

Good luck..

Peter

jackko · ‎03-19-2006

providing the remote host was able to connect to the pix via vpn, the issue may be related to the configuration. please post the entire config with public ip masked, if possible, include the router config as well.

phlitservices · ‎03-19-2006

Hi,

Thanks for you help. Attached are the two config.

jackko · ‎03-19-2006

1. udp 4500 also needs to be forwarded from the router to the pix. e.g. ip nat inside source static udp 10.10.10.3 4500 interface Dialer1 4500

2. the command "isakmp identity address" needs to be configured on the pix.

3. the vpn client pool should never be overlapped with the pix inside subnet.

phlitservices · ‎03-20-2006

Hi Jackko,

Thanks for you help, its working perfectly now. I’m also trying to connect to a remote site that is protected by a PIX 501 using the cisco vpn client. I can connect to the remote site if I go through a dialup or via my dsl at home. I can’t connect from our main office which is protected by the same PIX 506e that you help me with.

Cisco VPN (v4.x.x)--->PIX506<--->Internet--->Destination PIX501--->Local

When I view the syslog from the pix 506e, I’m getting the following message “%PIX-3-305006: portmap translation creation failed for protocol 50 src inside 172.16.1.132 dst outside:remote pix outside interface”

What is this message indicating ?

Thanks again

Don

mgarciar · ‎03-28-2006

The following was taken from ‘ASK THE EXPERT DISCUSSION FORUM’ with Glenn Fullage of Cisco.

I’ve cut and pasted here for you to read, I believe you are facing the problem mentioned below:

Question:

Hi Glenn,

Is the following possible?

I have vpn client on my PC, my LAN is protected by a pix. I can initiate the vpn client to connect to remote pix. The vpn client authenticates and the remote pix issues my PC with the appropriate assigned ip address from its ip pool.

The problem I am facing is that, I can not ping anything on the other side of the remote pix from my PC which is behind my pix. Can you please guide me to what I need to do for this to work, if at all possible?

My PC has a static ip address assigned with the appropriate default gateway pointing to my pix’s inside interface.

Thanks very much for any help provided in advance.

Reply from Glenn:

First of all make sure the VPN connection works correctly when the remote PC is NOT behind a PIX. If that works fine, but then breaks when put behind a PIX, it's probably that the PIX is doing PAT, which generally breaks IPSec. Add the following command onto your PIX that the VPN client is behind:

fixup protocol esp-ike

See http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_sw/v_63/cmdref/df.htm#wp1067379 for details.

If that still has issues, you can enable NAT-T on the remote PIX that is terminating the VPN, the client and the remote PIX will then encapsulate all the IPSec packets into UDP which your PIX will be able to PA correctly. Add the following command on the remote PIX:

isakmp nat-traversal

See http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_sw/v_63/cmdref/gl.htm#wp1027312 for details.

NAT-T is an IETF standard for encapsulation of IPSec packets inot UDP packets.

IPSec ESP (the protocol that your encrypted data packets use) is an IP protocol, in that it sits right on top of IP, rather than being a TCP or UDP protocol. For this reason it has no TCP/UDP port number.

A lot of devices that do Port Address Translation (PAT) rely on a unique TCP/UDP source port number to do the PAT'ing. Because all traffic is PAT'd to the same source address, there needs to be some uniqueness about each session, and most devices use the TCP/UDP source port number for that. Because IPSec doesn't have one, a lot of PAT devices fail to PAT it correctly, or at all, and the data transfer fails.

When NAT-T is enabled on both end devices, they will determine during the tunnel build that there is a PAT/NAT device in between them, and if they detect that there is, they automatically encapsulate all the IPSec packets into UDP packets with a port number of 4500. Because there's now a port number, PAT devices are able to PAT it correctly and traffic passes normally.

Hope that helps.

Marco.