11-15-2002 03:15 AM - edited 02-20-2020 10:22 PM
I have a number of PIX firewalls and have encountered a problem with static address translation a number of times, although not consistently.
I apply a static translation to an machine using the command:
static (inside,outside) 193.125.1.1 10.0.0.1 netmask 255.255.255.255 0 0.
more often than not, this command works correctly however, occasionaly I encounter a problem where from the machine assigned the static NAT I cannot access services through the firewall. The sh xlate command informs me that the translation is active, but I still cannot get through the firewall.
If I apply the NAT entry an alternate global address, say 193.125.1.2 then the firewall will pass traffic.
Also a change of the internal/private address of the pc to e.g. 10.0.0.2 resolves the problem.
11-18-2002 01:21 PM
Sounds like it could be a problem with the arp cache. The next time this happens, you might want to check the arp cache, if everything there seems normal, you might want to run a debug/sniffer trace to see what is happening to the TCP traffic.
11-27-2002 01:01 PM
Hello:
I am (currently) experiencing the exact same problem.
The static translation had been working fine ... however, the inside host had been compromised, and one of my technicians removed the static mapping from the config while he addressed the problem of the internal machine. He then put the static mapping back in the PIX, but since then, no traffic to/from the internal machine traverses the firewall.
The xlate table shows the mapping to be good, the arp cache reflects the proper MAC address for the internal machine, the access-list has never changed, so that should not be a problem, but no traffic passes.
We've tried clearing the arp cache and assigning the internal machine a new IP address, but that doesn't work. We are not at liberty to use a "new" global address.
Help!!!!
Thanks
11-27-2002 03:15 PM
Hi guys,
did you try resetting the router on the outside interface of the pix? This router also contain an ARP table that can become corrupt.
Kind Regards,
Tom
11-27-2002 03:52 PM
Did you do a "clear xlate" after recreating the static?
11-28-2002 12:51 AM
I have performed a clear xlate and cleared the arp cache on the firewall but neither of these .
The only thing I havn't tried is a clear arp on the router on the outside interface but i do not have access to this router . A quick reboot would clear the arp cach too but wouldn't the arp entry for the NATed addresses be the same for all addresses i.e. the MAC address of the firewall outside interface.
I have resolved this issue for the moment just by juggling internal and global addresses used in the static translation but will try a router reboot next time I encounter the problem.
Thanks.
11-28-2002 05:31 AM
Yes, I've done a clear xlate. I've also done a clear arp on the adjacent routers as well.
Actually, I ran into this problem last spring when originally deploying this firewall while working with someone from the TAC in conjunction with some other minor problems we were experiencing. The TAC guy (in the UK) knew how to fix this problem, and it worked. The problem is, I didn't take any notes on what we did to fix it and I don't remember what we did. Very frustrating.
And, unlike the original poster on this subject, I don't have the luxury of simply changing IP addresses.
Any help / insight would be greatly appreciated.
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