Static Identity NAT on the ASA: Translating Nothing, On Purpose

Most NAT rules exist to change an address. Identity NAT is the odd one out: it is a rule whose entire job is to make sure an address is not changed. On the Cisco ASA you write it as a static translation from a network to itself, and while that sounds pointless, it is one of the most important rules on a real firewall. It is how you carve exceptions out of a broader NAT policy, and it is what keeps two trusted segments talking with their real addresses instead of translated ones.

This article is part of the Cisco ASA cluster. Here we build a static identity NAT between an inside network and a DMZ, prove it really does translate nothing using show nat detail and packet-tracer from a live ASAv, and explain the two real reasons you reach for it: NAT exemption for VPN traffic, and preserving real client IPs in your server logs.

Translating a Network to Itself

The lab ASAv has an inside network 10.20.10.0/24 and a DMZ 172.20.30.0/24. We want traffic between them to pass through the firewall with its original addresses intact, no translation at all. The rule that does this is a Twice NAT (manual NAT) statement that maps each network to itself:

object network INSIDE-NET
 subnet 10.20.10.0 255.255.255.0
object network DMZ-NET
 subnet 172.20.30.0 255.255.255.0
nat (inside,dmz) source static INSIDE-NET INSIDE-NET destination static DMZ-NET DMZ-NET

Read the NAT line carefully, because the repetition is the whole point. source static INSIDE-NET INSIDE-NET says translate the source INSIDE-NET to INSIDE-NET, the same object twice. destination static DMZ-NET DMZ-NET does the same for the destination. Both the source and the destination map to themselves. This is what engineers mean by twice NAT to itself: a manual NAT rule where the original and translated values are identical on both sides.

One structural detail matters and pays off later. Because this is a manual (twice) NAT statement, it lands in Section 1 of the ASA NAT table, which is evaluated before the auto NAT rules in Section 2. That ordering is deliberate. Exemptions have to be consulted before general translations, or a broad rule would grab the traffic first. The section system does that prioritisation for you, a point worth reading in full in the ASA NAT table order walkthrough.

Proving It Is Really an Identity Translation

Saying a rule translates nothing is easy. Proving it is a two-line check. show nat gives you the rule and its counters; show nat detail adds the crucial Origin and Translated values so you can confirm they are identical:

FW1# show nat
Manual NAT Policies (Section 1)
1 (inside) to (dmz) source static INSIDE-NET INSIDE-NET  destination static DMZ-NET DMZ-NET
    translate_hits = 0, untranslate_hits = 0

FW1# show nat detail
Manual NAT Policies (Section 1)
1 (inside) to (dmz) source static INSIDE-NET INSIDE-NET  destination static DMZ-NET DMZ-NET
    Source - Origin: 10.20.10.0/24, Translated: 10.20.10.0/24
    Destination - Origin: 172.20.30.0/24, Translated: 172.20.30.0/24

There is the proof. Source - Origin: 10.20.10.0/24, Translated: 10.20.10.0/24: same address in, same address out. The destination line tells the same story for the DMZ network. When Origin equals Translated on both source and destination, you are looking at an identity rule. This is the fastest way to confirm an exemption is genuinely exempting and not quietly rewriting something you did not intend.

Watching a Packet Pass Through Unchanged

The counters confirm the config; packet-tracer confirms the behaviour on an actual flow. We simulate an inside host reaching the DMZ web server and look at the UN-NAT phase:

FW1# packet-tracer input inside tcp 10.20.10.100 12345 172.20.30.80 80
Phase: 2
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (inside,dmz) source static INSIDE-NET INSIDE-NET destination static DMZ-NET DMZ-NET
Additional Information:
NAT divert to egress interface dmz
Untranslate 172.20.30.80/80 to 172.20.30.80/80

Compare this to a normal destination NAT, where the untranslate line shows two different addresses (a public IP becoming a private one). Here it reads Untranslate 172.20.30.80/80 to 172.20.30.80/80: the same address on both sides. The ASA runs the UN-NAT phase, matches the identity rule, and hands the packet on with its destination untouched. The firewall still tracks and inspects the flow; it simply does not rewrite the address. That is exactly what you want an exemption to do.

Identity NAT vs No Rule at All

A fair question at this point: if the rule changes nothing, why not simply leave it out and let the traffic pass? The answer is that on a firewall configured with a general translation policy, "no rule" does not mean "no translation." The moment you have a broad PAT or object NAT covering the inside network, any inside-to-DMZ traffic that is not exempted will fall through to that general rule and get translated. Deleting the identity NAT does not give you clean, un-translated traffic; it hands the flow to whatever general rule catches it next.

That is the real reason identity NAT exists as an explicit statement. You are not adding a translation, you are inserting a higher-priority exception that says "for this specific pair of networks, stop here and translate nothing" before the general rules downstream ever get a look. On a firewall with no other NAT at all, you would indeed see the same behaviour with or without the rule. On a real firewall carrying a general policy, the identity rule is what protects the exception.

You can also watch this in the counters over time. Because our lab ASA had no competing general rule for this pair yet, translate_hits and untranslate_hits both read 0 in the capture above. On a busy firewall those numbers climb, and a healthy identity rule shows hits accumulating while the addresses in show nat detail stay identical. If the hits stay flat while inside-to-DMZ traffic clearly flows, the traffic is matching a different rule higher or lower in the table, and that is your cue to check the section ordering.

Why You Would Ever Do This

A rule that changes nothing sounds like a rule you could delete. It is not. There are two concrete reasons identity NAT earns its place, and both come up constantly on production firewalls.

The VPN case is the classic one and the reason identity NAT is often called NAT exemption or no-NAT. Its longer treatment, tied to a working tunnel, lives in identity NAT for VPN traffic. The log-integrity case is quieter but just as real: the moment you translate internal-to-DMZ traffic, you blind every server behind the DMZ to who is actually talking to it.

Placement Is the Point

Notice that we deliberately built this as a manual NAT rule rather than an object NAT rule. That was not stylistic. Manual NAT lands in Section 1, and Section 1 is consulted before the auto NAT rules that do the general translating in Section 2. An exemption has to win the match, and it wins because of where it sits in the table.

This is the general pattern for ASA NAT design: write your specific exemptions as manual (twice) NAT so they land in Section 1, and write your broad, general translations as auto (object) NAT so they land in Section 2. You never have to fight over ordering with an explicit priority number; the section structure enforces it. Get that mental model straight and identity NAT stops feeling like a trick and starts feeling like the obvious tool for the job. The full section-by-section breakdown, including how to prove which rule a real flow hit, is in the NAT table order article.

Key Takeaways

• Identity NAT translates an address to itself, on purpose. The syntax is a twice NAT statement: nat (inside,dmz) source static INSIDE-NET INSIDE-NET destination static DMZ-NET DMZ-NET.
• Prove it with show nat detail. When Origin equals Translated on both the source and destination lines, the rule genuinely changes nothing.
• The packet-tracer shows it too. An identity rule reports Untranslate 172.20.30.80 to 172.20.30.80, the same address on both sides, unlike a real destination NAT.
• You do it for two reasons. NAT exemption so VPN-bound traffic keeps its real addresses and matches the tunnel, and log integrity so DMZ servers see real client IPs.
• Placement does the work. Because it is manual NAT it sits in Section 1 and is consulted before the general auto NAT in Section 2, which is exactly why exemptions are written as manual rules.

Identity NAT is one piece of a larger design. To see how it sits alongside your publishing and PAT rules, and which rule wins when several could match a packet, continue through the Cisco ASA cluster.