I ran into an issue after setting up a firewall with 8.3. Hosts on the inside that have static translations to public IPs configured within their object network configuration are being PATd instead of using the static nat translation. It's not until we setup a nat translation separate from the static nat within the object that hosts appeared as their public IPs instead of a PATd IP. This was an issue for smtp relays, for example, needing a reverse DNS entry. Here's is the config we used as a work around.
object network HBG-MARSHAL_172.21.4.67
nat (inside,outside) static 220.127.116.11
nat (inside,outside) source static HBG-MARSHAL_172.21.4.67 HBG-MARSHAL_18.104.22.168
nat (inside,outside) source dynamic obj-All_Networks interface
We put the translation above the PAT line, the last line and it works now, but based on my understanding of the following excerpt from the 8.3 admin guide, and my past experience with nat and the ASA, I shouldn't need that line, but maybe there's a nat precedence order I'm missing between object nat and the explicit nat like nat (inside,outside) source static HBG-MARSHAL_172.21.4.67 HBG-MARSHAL_22.214.171.124
"Static NAT creates a fixed translation of a real address to a mapped address. Because the mapped address
is the same for each consecutive connection, static NAT allows bidirectional connection initiation, both
to and from the host (if an access rule exists that allows it)."
The order of nat rules is explained as
"•Order of NAT Rules.
– Network object NAT—Automatically ordered in the NAT table.
– Twice NAT—Manually ordered in the NAT table (before or after network object NAT rules)."
Indeed, Twice NAT rules will be evaluated (first match) before Network Object NAT. This is why the PAT rule from Section 1 was taking precedence over the static NAT rule from Section 2.
I have not had much experience with the 8.3 version of NAT, but I found this on here:
By default Twice Nat is put before Network object NAT. However from the looks of it these are both Network Object rules in which case the the static should have been read first, but again I have not had much experience with 8.3. As far as I can tell you are right, but maybe the a, b, and c rules came into effect in your situation.