03-23-2006 03:33 PM - edited 02-21-2020 02:19 PM
Hi all,
Im 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 any other dsl connection, however, I cannot connect to the remote site from our main office which is protected by a PIX 506e. The PIX 506e is also configured for RAS VPN.
Cisco VPN Client (v4.x.x)--->PIX506<--->Internet--->Destination PIX501--->Local
When I view the syslog from the pix 506e which is protecting my connection, Im 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
Any assistance is appreciated
Don
03-28-2006 02:18 PM
The following was taken from ASK THE EXPERT DISCUSSION FORUM with Glenn Fullage of Cisco.
Ive 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 pixs 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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide