Cisco ASA NAT Order of Operations Cheat Sheet

Most Cisco ASA NAT outages are not "the rule does not work". They are "the rule works, but the wrong rule fires first". The ASA evaluates NAT rules in a fixed order, and once a packet matches, evaluation stops. If you do not know that order cold, you will eventually waste an afternoon staring at a configuration in which every rule looks correct but traffic is still going to the wrong place.

This article is the cheat-sheet reference for the ASA NAT order of operations on software 9.x. It is grounded in real show nat detail output from the PingLabz reference lab. For the cluster context, see the Cisco ASA pillar; for the broader picture, see Cisco ASA NAT Explained.

The Three Sections, in Order

The ASA divides every NAT rule into one of three sections. Order is fixed and not user-configurable except by deciding which section a rule lives in.

For every packet that needs NAT, the ASA scans Section 1 top to bottom; if no match, scans Section 2 top to bottom by Cisco's tie-breaking rules (more on that below); if still no match, scans Section 3. First match wins. No more evaluation after that.

Why the Order Exists

Three reasons NAT is split this way, instead of one flat list:

1. Specific overrides general. Manual NAT in Section 1 lets you write a high-priority "this specific (source, destination) pair gets translated this way" rule that beats whatever broad auto NAT lives in Section 2.
2. Auto NAT is the default chassis. Section 2 is where the bulk of "translate this subnet to that pool" rules live. They are co-located with the network objects, easy to read, and Cisco gives them sensible automatic ordering.
3. Section 3 is the safety net. Manual NAT after-auto is for catch-all rules that should only fire if nothing else did. Rare in practice, common in service-provider edge configurations.

Real show nat detail Output

Here is the live state of the PingLabz lab ASA, which has all three section types populated except Section 3:

ASA-PERIM# show nat detail

Manual NAT Policies (Section 1)
1 (inside) to (outside) source static INSIDE-NET-FULL INSIDE-NET-FULL  destination static REMOTE-VPN-NET REMOTE-VPN-NET no-proxy-arp route-lookup
    translate_hits = 1, untranslate_hits = 1
    Source - Origin: 10.10.0.0/16, Translated: 10.10.0.0/16
    Destination - Origin: 10.99.99.0/24, Translated: 10.99.99.0/24
2 (inside) to (outside) source dynamic INSIDE-NET INSIDE-PARTNER-PAT  destination static PARTNER-NET PARTNER-NET
    translate_hits = 1, untranslate_hits = 1
    Source - Origin: 10.10.10.0/24, Translated: 198.51.100.99/32
    Destination - Origin: 172.20.0.0/24, Translated: 172.20.0.0/24

Auto NAT Policies (Section 2)
1 (dmz) to (outside) source static DMZ-WEB 198.51.100.10
    translate_hits = 0, untranslate_hits = 7
    Source - Origin: 192.168.50.10/32, Translated: 198.51.100.10/32
2 (inside) to (outside) source dynamic INSIDE-TRANSIT interface
    translate_hits = 0, untranslate_hits = 0
    Source - Origin: 10.10.0.0/24, Translated: 203.0.113.2/30
3 (inside) to (outside) source dynamic INSIDE-NET interface
    translate_hits = 46, untranslate_hits = 0
    Source - Origin: 10.10.10.0/24, Translated: 203.0.113.2/30

The header for each section is the diagnostic. Manual NAT Policies (Section 1) is two rules. Auto NAT Policies (Section 2) is three rules. Section 3 is empty (no header printed).

Within Section 1, the order printed is the order evaluated. Within Section 2, the order is sorted by Cisco's tie-breaking rules, not by configuration order, and the printed order is what actually fires.

How Section 1 Orders Itself

Manual NAT is evaluated top-to-bottom in the order the rules appear in the running config. Newly entered rules go to the end by default. Two ways to control position:

• Add an explicit line number on the nat command: nat (inside,outside) 1 source static .... The "1" here is the position within Section 1. New rules with that number push existing ones down.
• Use nat (inside,outside) source static ... after object SOMENAME or after-object options on a few rule types to position relative to a named object.

The default for an unnumbered manual NAT rule is "append to the end of Section 1". That is usually fine until you have several manual rules, at which point order matters.

How Section 2 Orders Itself

Auto NAT (object NAT) does not respect configuration order. The ASA sorts Section 2 rules into a deterministic priority order using these criteria, in this order:

1. Static rules before dynamic rules. A static auto NAT (nat (...) static ...) outranks any dynamic auto NAT (nat (...) dynamic ...).
2. More-specific source object first. A /32 host object outranks a /24 subnet, which outranks a /16, etc. Quantitatively: the higher the prefix length, the higher the priority.
3. Alphabetical object name. If specificity ties, the lexicographically lower object name wins.

Look at the lab output again. Section 2 has three rules. Why are they ordered the way they are?

• Rule 1 is a static auto NAT (DMZ-WEB). Rules 2 and 3 are dynamic. Static beats dynamic, so DMZ-WEB sorts first.
• Rules 2 and 3 are both dynamic /24 subnets, same specificity. INSIDE-TRANSIT (object name starts with "INSIDE-T") sorts before INSIDE-NET? No, that is alphabetical: "INSIDE-N" < "INSIDE-T", so the lab actually got rule 2 = INSIDE-TRANSIT and rule 3 = INSIDE-NET in that order. Read the output again carefully: Section 2 rule 2 is INSIDE-TRANSIT, rule 3 is INSIDE-NET. The rule numbering printed by show nat detail uses the ASA's evaluation order, which is the alphabetical ordering on the object name when other criteria tie. Tie-breaker: T comes after N alphabetically, so INSIDE-NET should sort first.

If that does not match what you see, run show nat detail and trust the printed order over any guessed mental model. The ASA prints what it actually does.

Walking a Packet Through the Sections

Let us trace what the ASA does for an outbound packet from inside (10.10.10.50) to a partner network (172.20.0.50):

1. Section 1, Rule 1 (Identity NAT for VPN). Source 10.10.10.50 is in 10.10.0.0/16 (matches), destination 172.20.0.50 is not in 10.99.99.0/24 (no match). Move on.
2. Section 1, Rule 2 (Twice NAT for partner). Source 10.10.10.50 is in 10.10.10.0/24 (matches), destination 172.20.0.50 is in 172.20.0.0/24 (matches). Both halves match. Apply: source rewrites to 198.51.100.99, destination unchanged. Stop.

The packet never reaches Section 2. The auto NAT PAT rule that would have rewritten the source to the outside interface IP (203.0.113.2) does not fire because Section 1 already produced a match.

Now trace a different packet: inside (10.10.10.50) to the open internet (8.8.8.8):

1. Section 1, Rule 1. Source matches (10.10.0.0/16), destination 8.8.8.8 does not match REMOTE-VPN-NET. No match.
2. Section 1, Rule 2. Source matches INSIDE-NET (10.10.10.0/24), destination 8.8.8.8 does not match PARTNER-NET. No match.
3. Section 2, Rule 1 (DMZ-WEB static). Source 10.10.10.50 is not 192.168.50.10. No match.
4. Section 2, Rule 2 (INSIDE-TRANSIT PAT). Source 10.10.10.50 is not in 10.10.0.0/24. No match.
5. Section 2, Rule 3 (INSIDE-NET PAT). Source 10.10.10.50 is in 10.10.10.0/24. Match. Apply: source rewrites to outside interface IP 203.0.113.2.

That is the path for a normal outbound flow. Section 1 had no match because no manual rule had both source and destination matching, and Section 2 fell through to the catch-all PAT rule.

Order-Related Diagnostics

When you suspect a rule is not firing in the expected order, two commands answer the question quickly:

• show nat detail prints every rule with its hit counters and section number. Look at translate_hits and untranslate_hits. A rule with zero hits when you expect non-zero is either not matching the traffic at all (object scope wrong) or another rule earlier in the order is winning.
• packet-tracer input ... ... tells you which rule fires for a specific source/destination pair. Phase 1 (UN-NAT) and Phase 2 or 3 (NAT) both reference the rule that matched. If those phases reference a rule you did not expect, that is the answer.

For the deeper troubleshooting walk, see Cisco ASA packet-tracer Command and Cisco ASA ACL Troubleshooting with packet-tracer.

The Cheat Sheet

And the simple rule that explains every NAT outage: the ASA evaluates Section 1 top-to-bottom, then Section 2 in priority order (static before dynamic, more-specific before less-specific, then alphabetical), then Section 3 top-to-bottom. First match wins.

Where to Go Next

• Cisco ASA NAT Explained for the broader auto/manual/object/twice taxonomy.
• Cisco ASA Dynamic PAT for Internet Access for the standard outbound auto NAT.
• Cisco ASA Static NAT for DMZ Servers for inbound auto NAT.
• Cisco ASA Twice NAT Explained for Section 1 manual rules.
• Cisco ASA Identity NAT for VPNs for the most common Section 1 use case.
• Cisco ASA packet-tracer Command for the diagnostic walk.
• Cisco ASA pillar for the cluster index.

Key Takeaways

• NAT rules live in three sections: 1 = Manual (twice) NAT, 2 = Auto (object) NAT, 3 = Manual after-auto. Evaluated in that order; first match wins.
• Section 2 sorts itself by static-vs-dynamic, then specificity, then alphabetical name. Configuration order does not matter.
• Most ASA NAT outages are ordering bugs: the wrong rule fires first. show nat detail hit counters and packet-tracer are the two commands that solve these in seconds.
• If you need a high-priority specific rule, write it as manual NAT (Section 1). If you need a default catch-all, write it as object NAT (Section 2). Section 3 is rarely needed.