This is strange - have you done a bug check on the image? It is possible also to clear only the connection in question using 'clear xlate Global xxx.xxx.xxx.xxx Local 192.168.162.37' as clear xlate on large networks for the full table can be drastic! Re-booting the pix is an option but shouldn't be necessary. I suggest a bug check, is this possible? I have never come accross such an issue...
Thanks for the help. I'll try a bug check, I already have a TAC case open, but the standard answer is to upgrade the software. We're only using the basic features of the PIX and I can't believe something like this would be fix when I ran the same scenario on our older 6.0.1 PIX and had no issues after the clear xlate.
Here is something else weird:
Global 22.214.171.124 Local 192.168.11.146
I had an old entry with the static command mapping 11.146 to 119.29. This command has been REMOVED last night and a clear xlate done several times. My xlate timeout is 03:00:00 (3 hrs, right?)
I come in this morning and ping the 126.96.36.199 address just to see what would happen, sure enough, the PIX built the translation again!
Well, the last resort solution would have been a restart of the PIX, but I wouldn't be able to do this until the weekend.
It turns out the "clear local-host" command solves the issue of clearing the cached old static! I was able to flip between the old inside and new inside address several times. The clear xlate command had NO EFFECT clearing the previous static entry.
Weird. Then again, I am running an old version of the software 6.3.1.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...