NAT on FTD: Order of Operations Demystified

By Taylor Thomas · 2026-08-30

A classic NAT problem on Secure Firewall Threat Defense is not a syntax problem at all: the rule that “doesn’t work” is a correct rule that traffic never reaches, because another rule matched first. FTD compiles every NAT rule — however it was configured — into a single table with a fixed evaluation order, and matching is first-match: the first rule matched by the first packet of a new connection is the one that translates it (later packets ride the established connection state), and traffic that matches no rule passes untranslated. Learn the shape of that table and NAT stops being trial and error.

Two Ways to Write a Rule, One Table

FTD offers two configuration models. Auto NAT — object NAT in ASA vocabulary — lives inside a network object: the object defines the real address, and the NAT statement attached to it defines the translation. It is compact and hard to get wrong, but it is built around that one object’s real address — it cannot match a source-and-destination pair, so it cannot make a translation depend on where the traffic is going. (A static object rule is still bidirectional: traffic toward the mapped address gets its destination untranslated.)

Manual NAT — twice NAT in ASA terms — is a standalone rule that can match source and destination together. That is the capability that earns its complexity: translate this source to X, but only when it talks to that destination. Manual NAT is also the only kind whose position you control directly.

Both models feed one unified table, and the table, not the configuration screen, is what the packet meets.

The Three Sections

The table has three sections, evaluated in order. Section 1 holds manual NAT rules, in the order the administrator placed them. Section 2 holds every auto NAT rule. Section 3 holds manual NAT rules explicitly configured as after-auto. Evaluation walks the sections top to bottom and stops at the first match — there is no fall-through: after one rule matches, no later NAT rule is evaluated for that connection.

Inside section 2, ordering is not under administrator control. Static rules are evaluated before dynamic rules, and among rules of the same type, objects with fewer real addresses — the more specific translations — come before broader ones, with remaining ties broken by lowest real IP address and then object name. In practice this means well-scoped auto NAT rules rarely collide, which is exactly why the general guidance holds: put the routine translations in auto NAT, put the exceptions and destination-dependent cases in section 1, and use section 3 for the broad catch-alls that must lose to everything above them.

The classic self-inflicted outage inverts that guidance: a general dynamic PAT written as a section 1 manual rule. It sits above the entire auto NAT section and absorbs traffic that more specific rules below were meant to handle. The fix is placement, not more rules.

Identity NAT and the VPN Exemption

Some traffic must not be translated at all — most commonly traffic meant for a site-to-site VPN when a general PAT rule would otherwise catch it, because NAT is considered before VPN encryption: in a policy-based tunnel, an unintended translation can keep the packet from matching the crypto selectors, so it never enters the tunnel at all. The mechanism is identity NAT: a manual rule, placed before the general rules, that translates the interesting source and destination pair to itself. The rule matches first, “translates” the addresses to their own values, and evaluation stops before the dynamic PAT below can touch the packet. If a tunnel carries pings in one direction but real traffic dies, an absent or misplaced exemption rule is one item worth checking early.

NAT and the Access Control Policy

One ordering question matters more than the rest: which addresses does the access control policy see? For network criteria, Secure Firewall evaluates the real addresses — the source before translation, the destination after untranslation — behavior carried over from the post-8.3 ASA lineage that ASA vs FTD traces. Write network criteria for the addresses hosts actually own, not their mapped representations, and changing only a mapped address normally will not require rewriting them. The qualifier that keeps this honest: rules also match on security zones, ports, and applications, and a destination NAT that changes where traffic routes can still change which zones a connection traverses.

When prediction fails anyway, stop reading rules and ask the box. Packet-tracer walks a synthetic packet through the firewall’s processing phases and names the exact NAT rule it hit — the fastest honest answer to “why is this translating wrong.”

NAT design sits squarely on the certification path: the SNCF 300-710 blueprint’s Configuration domain covers device configuration with Secure Firewall Management Center, network settings — NAT, QoS, and routing — included (objective 2.5). The exam-ready skill is the one this guide builds: given a table of rules, say which one the packet hits, and why. The courses drill exactly that against live gear.

Frequently Asked Questions

What is the difference between auto NAT and manual NAT on FTD?

Auto NAT is configured inside a network object and is built around that one object's real address — it cannot match a source-and-destination pair, so the translation cannot depend on the destination (though a static rule is bidirectional and untranslates the destination of inbound traffic). Manual NAT is a standalone rule that can match source and destination together in one statement and can be placed before or after the auto NAT section and ordered explicitly against the other manual rules in its section. Use auto NAT for the routine one-object translations and reserve manual NAT for the cases that need destination awareness or explicit ordering.

Why is my NAT rule never matching traffic?

A common cause: an earlier rule matched first. Evaluation is first-match across the three-section table: manual rules before auto, then auto NAT, then manual rules placed after auto. A broad manual rule in section 1 — a general dynamic PAT is the classic case — silently absorbs traffic you intended for a specific rule below it. Check what the packet actually hits with packet-tracer before assuming the rule itself is wrong.

Do I write access control rules for the real or the translated addresses?

The real addresses — the source before source translation, and for destination NAT the real destination the firewall obtains by untranslating the mapped address a packet arrives with. Secure Firewall inherits this from the post-8.3 ASA, so changing only a mapped address normally does not require rewriting a rule's network criteria; changing a real address does. Rules also match on security zones, ports, and applications — a destination NAT that changes where traffic routes can still shift which zones a connection traverses.