TTechclick ⚡ XP 0% All lessons
Cisco · Secure Firewall · FTD NATInteractive · L1 / L2 / L3

NAT on Cisco Secure Firewall (FTD) — Auto, Manual & the Section Order

On Cisco Secure Firewall, NAT runs in the LINA data plane and is sorted into three sections that decide which rule wins. This lesson untangles Auto NAT (object NAT) from Manual NAT (twice NAT), walks the Section 1 → 2 → 3 first-match order, covers static / dynamic / PAT and identity NAT — and shows why a missing NAT-exempt rule quietly kills your VPN.

📅 2026-06-18 · ⏱ 15 min · 5 infographics · live packet demo · 🏷 10-Q assessment + AI Tutor inline

⚡ Quick Answer

A clear, interactive guide to NAT on Cisco Secure Firewall Threat Defense (2026): how NAT runs in the LINA data plane, Auto NAT (object NAT) vs Manual NAT (twice NAT), the three rule sections (1 manual before-auto, 2 auto, 3 manual after-auto), static / dynamic / PAT, identity NAT / NAT exemption for VPN, hairpinning, and why Access Control rules use the real pre-NAT IPs.

🎯 By the end you will be able to

Read as:

Pick where you want to start

1

Auto NAT

Object NAT — simple, source-only, Section 2.

 2

Manual NAT

Twice NAT — source + destination, ordered.

 3

Section order

Sections 1 → 2 → 3 and first match.

 4

Types & exempt

Static/dynamic/PAT, identity NAT, hairpin.

🧠 Warm-up — 3 questions, no score

Just notice which ones make you pause. We answer all three inside the lesson.

1. Where does NAT actually run on an FTD device?

Answered in Auto NAT.

2. What does Manual (twice) NAT match that Auto NAT does not?

Answered in Manual NAT.

3. Which IP do FTD Access Control rules use?

Answered in Section order.

Most engineers think…

Most people treat FTD NAT as 'just NAT, like any router' and write a single overload rule for the whole inside network. That works until a VPN appears — then traffic silently vanishes and they blame the tunnel.

On Cisco Secure Firewall, NAT lives in the LINA data plane and is sorted into three ordered sections. Auto NAT (object NAT) is simple and source-only; Manual NAT (twice NAT) matches source and destination and is explicitly ordered. The engine walks Section 1 → Section 2 → Section 3 and stops at the first match. Miss that order — or forget a NAT-exempt rule above your PAT rule — and VPN-interesting traffic gets PATed and never enters the tunnel. Understanding sections and first-match is what separates 'it works' from 'I know why'.

① Auto NAT (object NAT) — the simple case

The first thing to fix: on FTD, NAT runs in the LINA data plane, not in Snort. Auto NAT — also called object NAT — is the easy starting point. You configure it on a network object: open the object, tick a NAT rule, and FTD translates that object's address.

Two limits define Auto NAT. It matches the source only — it cannot care about where the traffic is going — and you get one NAT rule per object. That is fine for the common cases: 'this server is always seen as this public IP' (static) or 'this whole subnet goes out as the outside interface' (PAT).

Auto NAT rules land in Section 2, and FTD automatically orders them most-specific-first — a /32 host rule is tried before a /24 subnet rule — so you do not hand-sort them. Simple in, simple out.

Figure 1 — Auto NAT (object) vs Manual NAT (twice)
Auto NAT is simple and source-only on an object; Manual NAT matches source and destination and is explicitly ordered.Auto NAT (object) vs Manual NAT (twice)Auto NAT (object)Configured on a network objectMatches source onlyOne NAT rule per objectLands in Section 2, auto-sortedManual NAT (twice)Configured as its own ruleMatches source AND destinationMany rules, you control orderLands in Section 1 or Section 3
Auto NAT is simple and source-only on an object; Manual NAT matches source and destination and is explicitly ordered.
Quick check · Q1 of 10 · Remember

Where does NAT execute on a Cisco Secure Firewall (FTD) device?

Correct: b. On the unified FTD image, NAT runs in the LINA data plane — the ASA-style forwarding engine that also runs VPN. Snort handles deep inspection; FMC is the manager, not the data plane.
👉 So far: Auto NAT (object NAT) = configured on a network object, matches source only, one rule per object, lands in Section 2 sorted most-specific-first. It runs in the LINA data plane.

② Manual / Twice NAT — source + destination

Manual NAT — the classic twice NAT — is the powerful one. It matches the source AND the destination (and optionally ports), so you can say 'when host A talks to subnet B, translate it this way; when it talks to subnet C, do something else'. That destination-awareness is exactly what Auto NAT lacks.

Why you reach for it

Manual NAT is what you use for identity NAT / NAT exemption, for policy NAT that depends on the destination, and any time order matters. Unlike Auto NAT, you place these rules explicitly: they go into Section 1 (before the auto rules) or Section 3 (after them), and within a section they run top-down, first match wins. You own the ordering.

Figure 2 — The three NAT sections, in order
FTD walks Section 1, then 2, then 3, stopping at the first matching rule.The three NAT sections, in orderSection 1 — Manual (before auto)Twice NAT, top-down first matchSection 2 — Auto NATObject NAT, auto most-specific-firstSection 3 — Manual (after auto)Twice NAT, top-down first match
FTD walks Section 1, then 2, then 3, stopping at the first matching rule.
📦
Auto NAT (object)
tap to flip

Configured on a network object, matches source only, one rule per object, lands in Section 2 sorted most-specific-first. The simple case.

🔀
Manual / twice NAT
tap to flip

Matches source AND destination (and ports), explicitly ordered into Section 1 or Section 3, top-down first match. The powerful, policy-aware case.

🧭
Section order
tap to flip

FTD walks Section 1 (manual before-auto) → Section 2 (auto) → Section 3 (manual after-auto) and stops at the first match.

🛡️
Identity NAT (exempt)
tap to flip

Translates an address to itself so VPN-interesting traffic is NOT PATed. Place it in Section 1, above the dynamic PAT rule.

Object vs twice — say it in one breath

In an interview, separate them cleanly: Auto/object NAT is on a network object, source-only, one rule per object, Section 2, auto-sorted. Manual/twice NAT is its own rule, source + destination, explicitly placed in Section 1 or 3, first match. Naming the section each lands in is the detail that signals real FTD knowledge.

Quick check · Q2 of 10 · Understand

What can Manual (twice) NAT do that Auto (object) NAT cannot?

Correct: a. Auto NAT matches the source only. Manual/twice NAT matches both source and destination (and ports), which is what makes destination-aware policy NAT and explicit ordering possible.
👉 So far: Manual NAT (twice NAT) = matches source AND destination (and ports), explicitly placed in Section 1 (before auto) or Section 3 (after auto), top-down first match.

③ NAT order — Sections 1, 2, 3 & first match

This is the section that wins interviews. FTD does not evaluate NAT rules in the order you happened to type them — it evaluates them by section. Section 1 = Manual NAT placed 'before auto' (top-down, first match). Section 2 = all Auto NAT, auto-sorted most-specific-first. Section 3 = Manual NAT placed 'after auto' (top-down, first match). The engine walks 1, then 2, then 3, and stops at the first matching rule.

That order is why NAT-exempt rules go in Section 1: they must be hit before the broad dynamic PAT rule that lives in Section 2, or the exemption never gets a chance.

The gotcha you must remember

FTD Access Control rules use the REAL (pre-NAT) IP addresses, not the mapped ones. So you permit the inside host by its private address even though it is being PATed to a public one. New engineers write ACP rules against the public IP, see drops, and chase the wrong thing.

Figure 3 — Dynamic PAT translation path
An inside host is multiplexed onto the outside interface IP by source port, then the reply is un-translated back.Dynamic PAT translation pathInside host10.1.1.20 -> internetMatch Sec 2dynamic PAT rule hitsTranslatesrc -> outside IP :portForwardout the outside ifaceUn-NAT replyport maps back to host
An inside host is multiplexed onto the outside interface IP by source port, then the reply is un-translated back.
Writing ACP rules against the mapped IP

FTD Access Control rules use the REAL (pre-NAT) IP, not the translated one. The classic mistake is permitting the public/mapped address in the access policy, then seeing drops. Permit the host by its real private address — NAT happens around the policy, not before it.

▶ Watch an inside packet get dynamic-PATed out — then break the VPN

How one outbound packet is translated, and the classic VPN failure caused by a missing NAT-exempt rule. Press Play for the healthy path, then Break it.

① Inside sendsHost 10.1.1.20 opens a session to a website out on the internet through the FTD.
▼
② Match Section 2No Section 1 manual rule matches, so LINA falls to Section 2 and hits the dynamic PAT (overload) rule for the inside network.
▼
③ TranslateThe source is PATed to the outside interface IP with a unique source port, and the flow is forwarded out the outside interface.
▼
④ Un-NAT the replyThe reply comes back to that IP:port; LINA maps it back to 10.1.1.20 and delivers it. Plain internet access works perfectly.
Press Play to step through the healthy dynamic-PAT path. Then press Break it.
Quick check · Q3 of 10 · Apply

You add a dynamic PAT rule and a NAT-exempt rule for VPN traffic. Where must the exempt rule go so it wins?

Correct: d. FTD evaluates Section 1 → 2 → 3 and stops at first match. The broad PAT rule is Auto NAT in Section 2, so the identity/exempt rule must sit in Section 1 to be hit first.
👉 So far: Order = Section 1 (manual before-auto) → Section 2 (auto) → Section 3 (manual after-auto), first match wins. And FTD Access Control uses the real (pre-NAT) IP.

④ Static, dynamic, PAT, identity NAT & hairpinning

Four translation types cover almost everything. Static NAT is a fixed 1:1 mapping, bidirectional — a published server keeps the same public IP both ways. Dynamic NAT hands out addresses from a pool, one real address to one mapped address at a time. Dynamic PAT (overload) is the workhorse: many hosts to one IP, multiplexed by source port — this is how a whole branch shares the outside interface address.

Identity NAT / NAT exemption translates an address to itself. Its job is to keep traffic out of PAT — critically for VPN-interesting traffic, which must reach the tunnel with its real source IP. Put the exemption (a twice/manual identity rule) in Section 1, above the PAT rule.

Finally, hairpin (U-turn) NAT lets traffic come in and go back out the same interface — handy when inside users reach a server by its public name, or two VPN spokes talk via the hub.

Figure 4 — The NAT types at a glance
One LINA NAT engine offers four translation styles for different needs.The NAT types at a glanceLINA NATFTD data planeStatic — 1:1Dynamic — poolDynamic PAT — overloadIdentity — to itselfHairpin — U-turn
One LINA NAT engine offers four translation styles for different needs.
Figure 5 — Why VPN traffic needs NAT exemption
Without an identity-NAT rule in Section 1, VPN-interesting traffic is PATed in Section 2 and never enters the tunnel.Why VPN traffic needs NAT exemptionVPN trafficto remote subnetNo exemptSection 1 emptyHits PATSection 2 overloadWrong src IPno tunnel matchAdd exemptidentity in Sec 1
Without an identity-NAT rule in Section 1, VPN-interesting traffic is PATed in Section 2 and never enters the tunnel.

Vikram at a Hyderabad MSP faces this

He brings up a new site-to-site VPN to a partner. The tunnel negotiates fine, but no traffic to the partner's 192.168.50.0/24 subnet ever works.

Likely cause

The inside network has a broad dynamic PAT rule (Auto NAT, Section 2), and there is no NAT-exempt rule above it, so VPN-interesting traffic is PATed and stops matching the tunnel's interesting-traffic ACL.

Diagnosis

Run packet-tracer for inside-host to 192.168.50.10: it shows the packet being PATed to the outside interface IP instead of being marked NAT-exempt and sent into the VPN.

FMC ▸ Devices ▸ NAT ▸ (policy) ▸ Add Manual NAT, place in Section 1
Fix

Add a Manual (twice) identity-NAT rule — source inside-subnet, destination partner-subnet, translate each to itself, with 'no proxy ARP' and route-lookup as needed — placed in Section 1, above the PAT rule.

Verify

Re-run packet-tracer: the flow is now NAT-exempt and routed into the tunnel; the partner subnet is reachable and the tunnel shows encrypts/decrypts climbing.

Prove it with packet-tracer, not a guess

Never assume a NAT rule fires. Run packet-tracer (FMC ▸ device ▸ Packet Tracer, or 'packet-tracer' on the CLI) with the real source, destination and port. It tells you exactly which NAT section and rule matched and whether the packet was exempted or PATed — that single read settles most NAT tickets.

Quick check · Q4 of 10 · Analyze

A branch of 200 PCs must all reach the internet through the single outside interface IP. Which NAT type?

Correct: c. Dynamic PAT (overload) multiplexes many inside hosts onto one address using source ports — exactly how a whole branch shares the outside interface IP. Static is 1:1; a pool needs many addresses; identity NAT does not translate.
👉 So far: Types: static (1:1), dynamic (pool), dynamic PAT (overload, many->one). Identity NAT exempts VPN traffic from PAT (place in Section 1); hairpin/U-turn turns traffic on one interface.

🤖 Ask the AI Tutor

Tap any question — instant, scoped to this lesson. No login, no waiting.

Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.

📝 Wrap-up assessment — six more

You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end.

Q5 · Remember

Auto NAT (object NAT) matches on which field(s)?

Correct: b. Auto/object NAT is configured on a network object and matches the source only. Matching source AND destination is the defining feature of Manual/twice NAT.
Q6 · Understand

In what order does FTD evaluate NAT rules?

Correct: c. FTD walks Section 1 (manual before-auto), then Section 2 (auto, most-specific-first), then Section 3 (manual after-auto), and stops at the first matching rule.
Q7 · Apply

Two VPN spokes must talk to each other through the hub, entering and leaving the hub's same outside interface. Which NAT feature enables this?

Correct: a. Hairpin (U-turn) NAT lets traffic enter and exit the same interface, which is what spoke-to-spoke-via-hub traffic needs. The other options do not address same-interface turning.
Q8 · Analyze

A published web server must always be reachable at one fixed public IP, both inbound and outbound. Which NAT type fits best?

Correct: d. Static NAT gives a fixed, bidirectional 1:1 mapping, so the server keeps the same public IP for inbound and outbound traffic. PAT and pools are dynamic; identity NAT does not change the address for publishing.
Q9 · Evaluate

Your VPN tunnel is up but no data crosses, and packet-tracer shows traffic being PATed to the outside IP. Best fix?

Correct: b. The symptom is VPN-interesting traffic being PATed before it can match the tunnel. The fix is a Section 1 identity (twice) NAT exemption for the source↔destination subnets so it keeps its real IP and enters the tunnel.
Q10 · Evaluate

Which IP addresses do FTD Access Control rules use when permitting inside-to-internet traffic?

Correct: a. FTD Access Control policy is evaluated against the real, pre-NAT addresses. Permit the inside host by its private IP; NAT is applied around the access decision, not before it.
Lesson complete — saved to your profile.
Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again".

🧠 In your own words

Type one line: why can a perfectly negotiated FTD VPN tunnel still carry no traffic? Then compare with the expert version.

Expert version: Because NAT runs in LINA and is evaluated by section — Section 1 (manual before-auto), Section 2 (auto), Section 3 (manual after-auto), first match wins. If the inside network has a broad dynamic PAT rule in Section 2 and there is no NAT-exempt (identity) rule above it in Section 1, the VPN-interesting traffic gets PATed to the outside IP and stops matching the tunnel's interesting-traffic ACL, so it is never encrypted. The fix is a Manual/twice identity-NAT rule for the source↔destination subnets placed in Section 1. And remember Access Control rules use the real pre-NAT IP, so you permit the inside host by its private address — confirm the whole thing with packet-tracer.

🗣 Teach a friend

Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.

📖 Glossary

LINA data plane
The ASA-style forwarding engine inside the unified FTD image. NAT and VPN both run here; Snort handles deep inspection separately.
Auto NAT (object NAT)
NAT configured on a network object, matching the source only, one rule per object, placed in Section 2 and auto-sorted most-specific-first.
Manual NAT (twice NAT)
A standalone NAT rule matching source AND destination (and ports), explicitly placed in Section 1 (before auto) or Section 3 (after auto).
NAT sections
The three ordered buckets FTD evaluates: 1 manual before-auto, 2 auto, 3 manual after-auto. The engine stops at the first matching rule.
Dynamic PAT (overload)
Many inside hosts translated to one IP, multiplexed by source port — how a whole branch shares the outside interface address.
Identity NAT / NAT exemption
Translating an address to itself so traffic is not PATed — used to keep VPN-interesting traffic on its real source IP, placed in Section 1.
Hairpin / U-turn NAT
NAT that lets traffic enter and leave the same interface, e.g. inside users reaching a server by its public IP or spoke-to-spoke via a VPN hub.
Real (pre-NAT) IP
The original address before translation. FTD Access Control rules are written against the real IP, not the mapped/post-NAT address.

📚 Sources

  1. Cisco — Cisco Secure Firewall Management Center Device Configuration Guide: Network Address Translation (NAT). cisco.com
  2. Cisco — Secure Firewall Threat Defense: Auto NAT, Manual NAT and NAT rule order (Sections 1-3). cisco.com
  3. Cisco — FTD/FMC NAT: dynamic PAT, static NAT and identity NAT / NAT exemption for VPN. cisco.com
  4. Cisco — Secure Firewall: Access Control rules use real (pre-NAT) IP addresses. cisco.com
  5. Cisco — Use the packet-tracer tool to verify NAT and access decisions on Threat Defense. cisco.com
  6. Cisco Live / Tech Notes — Configure NAT exemption for site-to-site and remote-access VPN on FTD. cisco.com

What's next?

Got NAT? Next, go deep on VPN — site-to-site IKEv2/IPsec (policy-based vs route-based VTI), the IKE phases, and Remote Access with Cisco Secure Client — and see exactly where that NAT-exempt rule has to sit so the tunnel actually carries traffic.

Next · All interview lessons → Practice on exam.techclick.in →