PAT and static - 'portmap translation creation failed' errors

[bill.james]

I'm trying to combine a static (inside,outside) mapping for a machine, and also use the same outside address for PAT. Originally I made the mistake of using the old form of the static command, which I guess allocated all the ports from the start, and gave rise to the errors. However, having read the docs again and started using the new static commands to map just those ports I want, I was surprised to get the same symptom. I have done 'clear xlate' (much to everyone's joy!), but no luck so far.

The error occurs for all internal machines except the wholly statically mapped ones. Snippet from

config follows:

Also, does DNS get fixed up by the port static mapping like it does for the old version? I added it to every line for good measure.

William

-----------------------------------------------

! Allow all inside machines to go outside, masquerading as larynx

! We have to be explicit about incoming ports on larynx for the Port Address Translation

! to work.

global (outside) 1 larynx netmask 255.255.255.240

nat (inside) 1 0.0.0.0 0.0.0.0 0 0

static (inside,outside) tcp larynx ssh larynx_inside ssh dns netmask 255.255.255.255 0 0

static (inside,outside) tcp larynx ftp larynx_inside ftp dns netmask 255.255.255.255 0 0

static (inside,outside) tcp larynx ftp-data larynx_inside ftp-data dns netmask 255.255.255.255 0 0

static (inside,outside) tcp larynx www larynx_inside www dns netmask 255.255.255.255 0 0

static (inside,outside) udp larynx domain larynx_inside domain dns netmask 255.255.255.255 0 0

static (inside,outside) tcp larynx domain larynx_inside domain dns netmask 255.255.255.255 0 0

! Other machine addresses are mapped through for all ports

static (inside,outside) voxweb voxweb_inside dns netmask 255.255.255.255 0 0

static (inside,outside) heptode heptode_inside dns netmask 255.255.255.255 0 0

[jmia]

Hi Bill,

Have you got any syslog messages please...

Thanks - Jay.

[bill.james]

Here's a sample:

Sep 22 17:42:20 172.19.50.1 %PIX-3-305006: portmap translation creation failed for tcp src inside:172.19.50.5/4872 dst outside:voxweb/80

Sep 22 17:42:20 172.19.50.1 %PIX-3-305006: portmap translation creation failed for udp src inside:larynx_inside/2331 dst outside:193.164.97.11/53

Sep 22 17:42:24 172.19.50.1 %PIX-3-305006: portmap translation creation failed for udp src inside:larynx_inside/2331 dst outside:193.164.99.83/53

[jmia]

Bill -

Which version of PIX IOS are you running?

I'm checking the above log, also in the meantime check the following document:

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a0080094aad.shtml#topic9

Thanks - Jay

[bill.james]

Jay,

Version 6.3(1).

The document example is what I've tried to model my config on. I have no ACL's on the inside.

Bill

[scoclayton]

Based on the info provided thus far, I can't see any reason why this is occuring. Kinda interesting. As a possible work-around and to avoid any confusion, can you change your global command to use your outside interface instead of larynx? Something like:

global (outside) 1 interface

Scott

[bill.james]

Scott,

I'll try something more in the morning (I'm 8 hours ahead of you). I have switched the NAT to another PAT on an unused external address, and this works OK, but we really need to NAT to the larynx address.

Is 'clear xlate' sufficient to restart everything in this area, or is a more dramatic reload of the config needed?

William

[scoclayton]

Understandable and I think I gave you some bad advice earlier with trying the interface address. This will not work for what you are trying to do and you will need to use the same address for both the statics and the global commands. Send me a full config off-line (sclayton@cisco.com) as well as a 'sh x debug' (might be 'sh x detail' - I can't remember) tomorrow and I will have a look. And yes, a 'cl x' should do the trick but is interesting to note that a different PAT address in the global works.

Scott

[bill.james]

Good morning Scott!

I've tried all sorts of variations 'overnight' with no luck. Finally I reset my original config, and rebooted, and everything works! This was the first reboot I had tried because of operational constraints. I guess we would hope it not to be necessary, but I think I see another recent conversation about that.

Almost un-related - while I was staring at the logs, I persuaded myself that the ftp-data connections are wrongly tagged with the direction (we use PORT):

Built inbound TCP connection 2874227 for outside:10.131.18.86/34107 (10.131.18.86/34107) to inside:192.168.50.137/20

Port 20 always builds the connection!

Bill

[scoclayton]

Bill,

Glad to hear everything is now working. I would still be curious to see a 'sh x debug' when it is not working as a 'cl x' should have been enough to clear everything out and a reboot unnecessary. Anyway, good deal

As for your other question about the FTP, I am afraid I do not follow. The syslog message is telling you that we built a conn from the outside host (10.13.18.86) to an inside host on 192.168.50.137 on port 20. If you are hung up on the "inbound" part, we always show these connections as being built in the same direction that the original control channel was built. I would assume that 192.168.50.137 is an ftp server?

Scott

[bill.james]

Scott,

Yes, it was the "inbound" that had me wondering. I had assumed that it really meant the direction of the TCP/IP connection. If you were to read just this portion of the log, you might mistake this for PASV protocol, which we did and which amazed us!

Thanks for your help.

Bill