In article , Darren Green wrote: :I was looking at the Cisco WWW site a few minutes ago for some NAT reference :material. One of the articles I review stated:
:'With static NAT, translations exist in the NAT translation table as soon as :you configure static NAT command(s), and they remain in the translation :table until you delete the static NAT command(s)'. NB This referred to a :router not a PIX.
I don't know what happens in IOS, with or without Reflexive ACLs or the Firewall Feature Set. I can, though, say that on the PIX that static translations do no get an entry in the xlate table until the first time they are used, after which they stick until they are cleared.
I have seen hints that the operation of "local-host" on the PIX may not work the same way, or perhaps was not expected to work the same way. A "local-host" is the PIX mechanism for dealing with the
10 or 50 user license agreement found only in the PIX 501 model (PIX 4 and early PIX 5 supported -connection- limits on some models, which wasn't the same.) A "local-host" may be built before first use of the static involving that host... and whether it does or not might depend on the exact software release. It is also not documented as to what the interaction is between local-host counts and policy nat or policy static.
:In the Sybex book for exam 642-521 one of the test questions states that :configuring static mapping does not automatically use a slot in the table. :The XLATE table holds only active entries.
:I take it that the translation table and XLATE table mentioned above are :either:
:Two different tables
The static table is a table of -potentials-. Such-and-such an IP is allowed to communicate as such an such an IP [under such and such a condition?]. However, a static is not a connection. The translate table is largely connection based: such and such an IP and such and such a port is to be translated to this other IP and port *for this particular connection*. If interior port 1038 is currently mapped to a global IP at port 1433 because that's what got randonly assigned by PAT, then that doesn't mean that any system anywhere that happens to be probing for port 1433 will get connected to the interior port 1038: it is restricted by context. [See, though, the PIX documentation on the 'established' command for the ways in this can be surprising.]
It -could- all be implimented in a single table, but it's probably easier not to.