ASA: NAT Concepts and Rule Evaluation

Overview

Network Address Translation (NAT) rewrites addresses in a packet’s header as it crosses the firewall, and the ASA decides which rewrite applies by walking a rule table in a fixed order. When that order surprises you, nothing announces it: a site-to-site VPN dies the day someone adds a translation rule, or a published web server answers nothing from the internet. When an unintended rule matches successfully, there is no error to see: the ASA reports the flow it translated, because it cannot know the rule it chose was not the one you meant. Naming the rule that won takes show nat detail or packet-tracer. This lesson gives you the vocabulary, the two rule types, the section order, and the translation patterns — the models that make ASA NAT predictable before you ever touch the CLI. The next two lessons build and verify three of those patterns on the module lab’s firewall using exactly these models.

Terminology: Local vs. Global Addresses

Cisco’s four NAT terms are two words — Local and Global — applied to a host on either side of the firewall. Local is the address as seen from the inside network; Global is the address as seen from the outside. TechNote 4606 is the source document, and the graphic below puts all four on one topology:

Enlarge figure: NAT terminology on one topology: an employee and a mainframe on the inside network, a web server and an admin host on the far side of the internet, with the firewall's terminology table listing each host's Inside Local, Inside Global, Outside Global, and Outside Local addresses

Capture note: the addressing in this terminology graphic and the edge-design graphic further down is illustrative — read 192.168.1.0/24 as “the inside network,” 209.5.6.x as “the firewall’s public side,” and 100.64.1.x as “hosts out on the internet” — illustrative stand-ins, not addressing you’d deploy (100.64.1.x in particular is RFC 6598 carrier-grade NAT space, not internet space). The pattern board’s mapped side, 203.0.113.x, is documentation space. The lab lessons that follow use the lab’s own addressing.

The graphic draws two flows. Flow 1 is the employee browsing WEB-01: the employee’s real 192.168.1.10 (Inside Local) leaves the firewall as 209.5.6.103, the firewall’s own outside interface address (Inside Global). That is interface PAT, and it is why the mainframe’s row shows the same Inside Global: every inside host that goes out shares the interface address. Flow 2 is the admin reaching the mainframe. The admin host out on the internet owns a real 100.64.1.x address (Outside Global). A rule translates that address as the admin’s traffic enters the firewall, so the mainframe sees it as 192.168.1.200 (Outside Local). The mainframe is why the rule exists: it has no Layer 3 gateway and only answers hosts on its own subnet (it can ARP, not route), so the admin host has to look like one of them.

Outside Local is the address inside hosts use for an outside host. It equals Outside Global unless a rule translates that outside host’s address. That’s why the web server’s row in the graphic shows the same address in both columns, while the remapped admin host’s row differs. (Publishing your own inside server translates the inside pair, not this one.)

The CLI uses a second vocabulary for the same split, and you’ll type it constantly in the next two lessons: the real address is what the host actually has; the mapped address is what NAT substitutes. Per the 9.23 NAT chapter, the real address is “the address that is defined on the host, before it is translated.”

Rule Types: Object NAT vs. Manual NAT

There are exactly two ways to write an ASA NAT rule, and the choice decides what you can match and where the rule lands in the table:

• Object NAT (also called network object NAT, or Auto NAT) — the translation is a property of one network object: this object, crossing from this interface to that one, translates like so. It pairs that one object with its mapped address or pool and never with a destination; the table below gives the direction details.
• Manual NAT (also called twice NAT) — a standalone nat command that can match source and destination together and can translate both in one rule — hence “twice.” You decide where it sits.

Three guidelines from the 9.23 NAT chapter prevent most object NAT surprises:

• One rule per object. “You can only define a single NAT rule for a given object” — to change an object’s translation, edit or remove the rule it already has. Need two translations for one IP? The guide’s own answer: create two objects with different names and the same address.
• No group objects. Object NAT hangs off a single network object; you cannot attach a NAT rule to an object-group. Manual NAT rules can reference groups.
• after-auto belongs to manual NAT only. The keyword exists in the standalone nat command to push a manual rule after every object rule. Inside an object network block it is not valid syntax — a widely copied wrong example, and the parser rejects it.

Rule Order: Three Sections, First Match

Beyond the card’s two sort keys for Section 2, the 9.23 NAT chapter adds two tie-breakers: equal address counts sort by the lower IP address, and the same address sorts by object name, alphabetically. So renaming an object can move its rule.

Here is the order running twice on the same source host, with one manual rule in Section 1 and two object rules in Section 2:

Packet: inside host → branch subnet across the VPN
  Section 1   manual: "inside → branch: do not translate"      MATCH → stop
  Section 2   (not evaluated)
  Section 3   (not evaluated)

Packet: inside host → the internet
  Section 1   manual: "inside → branch: do not translate"      no match
  Section 2   object: the DMZ server's rule                    no match
              object: the inside network's rule                MATCH → stop
  Section 3   (not evaluated)

Design Choice: Which Translation Pattern

Rule type decides how you write the rule; translation type decides what the rule does to the addresses. There are five patterns: static NAT, dynamic NAT, dynamic PAT, static PAT and identity NAT. The first four differ in three ways, and the board below puts them side by side: how long a mapping lasts, who may start a connection through it, and what gets rewritten.

Enlarge figure: Four translation patterns in four columns, each answering the same three questions, with illustrative addresses. Static NAT: one real address, one mapped, for example 192.168.1.20 is 203.0.113.20; a permanent mapping; the outside may start connections too; the address only is rewritten; used to publish a whole host. Dynamic NAT: hosts borrow pool addresses, one host per address; held until idle, then returned; only the real host starts; address only; used for applications that break under PAT. Dynamic PAT: many hosts, one address, told apart by port; held until idle, then returned; only the real host starts; address and TCP/UDP port rewritten; workstations to the internet. Static PAT: one address and port, fixed, for example 192.168.1.20:8888 is 203.0.113.21:8888; permanent; the outside may start too; address and one port; publish one service. A bar underneath reads: static publishes, dynamic shares, and identity NAT, the fifth pattern, exempts.

Static NAT is a permanent one-to-one mapping, and the translation applies in both directions from the moment it’s configured (routing and access rules still decide whether traffic is allowed). That two-way property is why, when NAT publishes a server, inbound connections need a static rule: static NAT, or static PAT for a single service. (Manual static rules can be made unidirectional, which the guide calls “mainly useful for testing purposes.”) Each translated host has its own mapped address, permanently.

Dynamic NAT assigns each inside host a whole address from a pool, first come, first served, held until the translation idles out — the same host reuses its entry across connections while it stays active. No ports are rewritten, so one pool address serves one host at a time — which suits applications that break under port translation or policies that want one mapped address per host.

Dynamic PAT (Port Address Translation) translates TCP and UDP source ports as well as addresses, so hundreds of hosts share one address or a small pool, told apart by port; for ICMP, the ASA translates the query identifier instead. The original source port is kept where it can be and reassigned where it can’t.

Static PAT is its permanent sibling: it maps one address, protocol and port to another, so you publish a single service instead of a whole host. TCP and UDP on the same port number are separate mappings.

One timing fact applies to the dynamic patterns: changing a rule does not move existing dynamic translations or established connections onto the new mapping. They keep their old state until they expire or you clear them from the translation table (clear xlate), and clearing an entry interrupts the connections using it.

Identity NAT is the last pattern. Remember the no-match rule from the section order: the 9.23 NAT chapter says “If you do not configure NAT for a given set of traffic, that traffic will not be translated, but will have all of the security policies applied as normal.” So identity NAT is not needed just to leave traffic untranslated; it is for when an explicit rule must match that traffic, most commonly to carve it out of a broader rule:

You will build exactly that rule in the lab in ASA: NAT — Identity Rules, Verification and Troubleshooting, in Section 1, above the PAT rule the next lesson builds.

Design Choice: Objects Do the Heavy Lifting

Every rule in the next two lessons leans on the network objects you built in ASA: Objects & Object Groups — object NAT literally lives inside them. The design payoff shows up at the edge: in the graphic below, the entire perimeter needs just two NAT rules — one dynamic PAT rule sending the inside network out, one static rule publishing the DMZ mail server — while object groups keep the companion access rules readable by bundling the outside web and DNS servers each rule refers to.

Enlarge figure: Two NAT rules cover the edge. An ASA in the centre. Rule 1, dynamic PAT written (inside,outside): the inside network 192.168.1.0/24 goes out through the ASA to the outside servers, sharing one address. Rule 2, static NAT written (dmz,outside): traffic from the outside comes in through the ASA to SMTP-01 in the DMZ at 192.168.2.25, which the rule publishes. A note says WEB and DNS are object groups for the access rules, not the NAT rules.

One boundary to respect from the guidelines above: the NAT rules themselves attach to single objects (object NAT takes no groups) — the groups earn their keep in the access rules and in manual NAT matching. Two rules, a handful of objects, and the whole design fits on one screen. That’s the target state for the lab you’re about to build.

🔬 See It in the Lab

You don’t have to take the section model on trust. This is show nat detail on the module lab’s ASA-EDGE-01 once the NAT lessons are finished (the prompt reads /pri/act because the module ends as a failover pair). The command also prints a Section 0 of implicit rules the ASA writes for its own management SSH; they are cut here:

ASA-EDGE-01/pri/act# show nat detail
...
Manual NAT Policies (Section 1)
1 (inside) to (outside) source static HQ-INSIDE HQ-INSIDE  destination static BRANCH-NET BRANCH-NET no-proxy-arp route-lookup
    translate_hits = 0, untranslate_hits = 0
    Source - Origin: 10.10.1.0/24, Translated: 10.10.1.0/24
    Destination - Origin: 10.20.1.0/24, Translated: 10.20.1.0/24

Auto NAT Policies (Section 2)
1 (dmz) to (outside) source static SRV-WEB-01 198.51.100.111 
    translate_hits = 0, untranslate_hits = 6
    Source - Origin: 172.16.1.10/32, Translated: 198.51.100.111/32
2 (inside) to (outside) source dynamic INSIDE-NET pat-pool PAT-POOL
    translate_hits = 6, untranslate_hits = 0
    Source - Origin: 10.10.1.0/24, Translated (PAT): 198.51.100.100-198.51.100.110

Every model from this lesson is on the screen:

• Section 1 holds the one manual rule: an identity exemption (HQ-INSIDE to itself) that applies only toward BRANCH-NET. It sits above everything else because it is manual, which is the whole point of an exemption. Its two trailing keywords are exemption hygiene: no-proxy-arp stops the ASA answering ARP for the rule’s mapped addresses, and route-lookup picks the egress interface from the routing table instead of the rule. ASA: NAT — Identity Rules, Verification and Troubleshooting explains both when you build the rule.
• Section 2 is sorted by the device: the static rule publishing SRV-WEB-01 comes before the dynamic PAT rule, as the sort order says, regardless of which was typed first.
• The static rule names two addresses, and access rules use only one. Since ASA 8.3, an access rule for traffic to a translated host names the real address: the permit for the web server matches 172.16.1.10, never 198.51.100.111, because the ASA un-translates the destination before the access check. ASA: Global ACLs shows that phase in a packet-tracer run.
• The hit counters tell you direction. The static rule has 6 untranslate_hits (traffic to the published address, translated back to the real address inbound) and no translate_hits; the PAT rule has the opposite. The counters are cumulative, so to attribute one test flow to a rule, read them before and after it, or run packet-tracer.

Up next: you haven’t opened a CLI session yet, and that’s deliberate. ASA: NAT — Static NAT and Dynamic PAT puts these four models to work on ASA-EDGE-01: it publishes the DMZ web server and builds the PAT pool that gets your workstations online, verifying each from both sides of the wire.