portmap translation creation failed for tcp src

[mooey]

errorortmap translation creation failed for tcp src Webarea:167.x.x.129/51733 dst IntServers:10.10.10.124/4321

Please help, I can't get my head around this problem. This is another guys network, he's on hols and he has made a lot of changes to it since I last worked on it.
Traffic is coming from a remote SSG that connects to a central web switch which is uplinked to the ASA Webarea int where the problem resides. This traffic is not NATed coming from the SSG so it presents on the ASA with its real src address.
The acl has been removed from the Webarea interface(Security100) and policy NAT has been introduced for some remote hosts that come thru Webarea to 3rd party servers that require different source addresses per port connections, these all appear to be working fine. I have performed a capture on the Webarea int and can see the SYN traffic coming in but get the above error before it is passed off to the IntServers int(Security0)

Src host 167.x.x.129(remote app subnet via Webarea zone)
Dest host 10.10.10.124(IntServers zone)

1) I have NATed the dest address to the same global address going to the IntServers:

static (IntServers,Webarea) 10.10.10.124 10.10.10.124 netmask 255.255.255.255

2)Added a static route :
route Webarea 10.10.10.124 255.255.255.255 192.x.x.236 1(IntServer next hop)

Is anything else needed ? Will a stateful rule be created for return traffic on the IntServers int, It's been so long since I worked in a prod envir with no ACL on an internal web int I can't remember what happens. I added a rule to the IntServers acl just in case

access-list IntServers_in extended permit tcp host 10.10.10.124 host 167.x.x.237 eq 4321

Apparently a NAT 0 statement is req'd for this traffic but this is a connection to a new 3rd party server where only one port will ever be targetted and its come from an existing server here, so this does not sound right to me.

The fact that there is no longer an acl on the Webarea int and the comment that all traffic now coming from Webarea needs NAT 0 is throwing me off, I ignored it all until I got the above error. The xlate table was not cleared down after a lot of NAT/Global changes were made to the ASA so that could be causing an issue too.
Do I need to NAT the source 167.x.x.129 to the same address globally:

static (Webarea,IntServers) 167.x.x.129 167.x.x.129 netmask /32

There are static/global and Nat 0's in place for the source host going to hosts on other int's but nothing to the IntServers Int host 10.10.10.124 address so those other NATs should not affect this.

I greatly appreciate any help that can be shed on this subject. The config is pretty long and very customer specific so I don't want to post it publicly in case the customer sees it.

Thanks

 

[desperado618]

There is no need to nat the source address.
Looks like this traffic is comming from a lower security level interface to a higher one. With that said an ACL is needed and must be bound to the ingress interface (where 167.x.x.129 resides). The acl you supplied in your notes is not sufficient.

Do the following:

sh route | grep 167. (were looking for the interface that 167.x resides behind).
show nameif (will show the security levels of the ingress and egress interface)
sh access-group (show run access-group, if using 7.x)
look for the line that has the interface listed in the route command above. That line will also have an acl specified.

type the following acl:
access-list <acl name from above> permit tcp host 167.x.x.237 host 10.10.10.124 eq 4321

For traffic comming from a lower to higher security interface an ACL is needed. If there is no acl on your access-group command, one will need to be created and bound to that interface.

http://www.NetLeets.com

IT Security news and information
In plain English