# FTD & FMC answers that also name the engine

Source: https://ai.techclick.in/blog_cisco_ftd_fmc_interview_qa
Markdown: https://ai.techclick.in/blog_cisco_ftd_fmc_interview_qa.md
Publisher: Techclick Infosec Pvt Ltd

Cisco FTD and FMC interview questions (2026): a drop on Snort not LINA, prefilter Fastpath vs ACP Trust, NAT Section 1 exemption, FMC Active/Standby HA, and why you run packet-tracer twice on VPN.

Say this out loud

   FTD is one unified image with two engines. A packet hits  LINA  first.  Prefilter  can Fastpath or Block before Snort. An ACP  Allow  hands the flow to  Snort  for IPS and file. ACP matches  real (pre-NAT) IPs . NAT is Section 1 manual, Section 2 auto, Section 3 after-auto. FMC HA is Active/Standby — only the active deploys. For VPN I run  packet-tracer  twice because the first try brings the tunnel up.

## 1. Ticket hook — which engine dropped it

 Night shift: branch users cannot reach the head-office subnet over the new site-to-site VPN. Internet PAT still works. The ACP Allow looks correct. The first packet-tracer on the 5-tuple shows  VPN encrypt → DROP . A junior engineer wants to disable Snort “to see if inspection is the problem.”

 That is the interview. The first tracer is not the verdict. Cisco’s NAT verification note is explicit: run packet-tracer for tunnel traffic  twice , because the first try brings the VPN tunnel up. The second run should hit identity NAT in Section 1 and  VPN encrypt → ALLOW . If it still PATs out the outside interface, you are in the wrong NAT section — not in Snort.

   Hero · who talks to whom

   Notice: FMC does not forward the packet. LINA does. Snort only sees what policy still sends it.

   Hard words, once

    LINA  — the ASA-derived data plane on FTD (interfaces, routing, NAT, VPN, stateful L3/L4 ACL, connection table).  Snort  — the inspection engine (IPS, AVC, URL, file/malware).  Prefilter  — first access-control pass in LINA; actions Fastpath, Block, Analyze.  ACP  — Access Control Policy; first-match after prefilter, SI, and optional decrypt.  Trust  — ACP permit that skips deep inspection.  Fastpath  — prefilter permit that skips Snort entirely.  Identity NAT / exemption  — translate source to itself so VPN selectors still match.  FMC HA  — Active/Standby managers, not device failover.

## 2. Mental model: LINA then Snort

 Official TAC wording: FTD is a  unified image  with two engines. A packet enters the ingress interface and LINA handles it. If policy requires it, LINA sends the packet to Snort. Snort returns a permit-list or block-list verdict. LINA drops or forwards on that verdict.

#### LINA owns

     Interfaces, routing, NAT, VPN termination, the global ACL  CSM_FW_ACL_ , the connection table, and prefilter ACEs. An L3/L4 Block is an early LINA deny — the SYN never reaches Snort.

#### Snort owns

     Application, URL, geolocation, intrusion, and file verdicts. An L7 Block is deployed on LINA as a  permit  so the packet can reach Snort. A few packets may pass until AppID is known.

 That last sentence is the L2 trap. A rule with URL, App, or Geo looks like  permit any any  in  show access-list . That is not an open firewall. Snort still walks its  ngfw.rules  file and can blacklist the flow. Packet-tracer’s ACCESS-LIST phase can show the first L7 permit, not the Geo rule that actually dropped it (Cisco bug CSCwd00446). Quote the  SNORT  phase rule-id.

   Flow 1 · LINA then Snort

       Packet enters LINA; prefilter may skip Snort; Allow sends the flow to Snort

- Ingress LINA data plane route · NAT · VPN · ACL Prefilter match? Fastpath / Block / Analyze Fastpath Skip Snort LINA only Analyze Decrypt optional TLS Sec Intel Talos lists ACP first-match Allow / Trust / Block Snort verdict only if still sent LINA egress forward or drop What each action does to Snort Prefilter Fastpath = LINA only. Prefilter Block = LINA deny, no Snort. ACP Trust = permit, skip deep IPS/file (a few packets may still hit Snort for SI / AppID). ACP Allow = LINA permit + send to Snort. L7 Block = LINA permit, Snort deny. Prefilter ACEs sit above ACP ACEs in CSM_FW_ACL_. First match wins. Source: Clarify FTD Access Control Policy Rule Actions (Doc ID 212321). Read the diamond first. Fastpath never asks Snort. Allow always does. Trust is the middle verb — do not call it Fastpath. Path · five stations Notice: Snort is station four, not station one. A LINA ACL drop never prints a Snort verdict. ## 3. Prefilter versus ACP Flowchart first. Official comparison: prefilter and ACP can both block and “trust,” but prefilter’s trust is called Fastpath because it skips more inspection. Prefilter is first. If you never built a custom prefilter, early ACP Block/Trust only approximates it — it does not replicate Fastpath. Decision · two paths Path A is cheap LINA handling (Fastpath / Block). Path B is ACP + Snort. An over-broad Fastpath is how backup replication “works” and malware rides the same subnet. Prefilter policy Access Control policy When First. Assigned under the ACP. Default tunnel/priority policy already exists. After prefilter, optional TLS decrypt, and Security Intelligence. Headers Outer header on tunnels (GRE, IP-in-IP, IPv6-in-IP, Teredo 3544). Tunnel rules can tag inner traffic. Inner session. App, URL, user, geo, file, intrusion. Actions Fastpath, Block, Analyze Allow, Trust, Monitor, Block, Block with Reset, Interactive Block Snort Fastpath / Block never send the flow. Analyze continues into ACP. Allow sends every packet (typical). Trust fast-forwards after a few packets. L3/L4 Block dies in LINA. Direction Unidirectional. Return path often needs its own Fastpath or the ACP default deny eats the reply. Stateful after the first packet creates a LINA connection. Choose when Elephant flows, ASA-migration ACEs, outer-header tunnels. The actual security decision and any L7 inspection. Common miss Calling ACP Trust “the same as Prefilter Fastpath.” Fastpath is early LINA and skips SI, identity, decrypt, ACP, and Snort. Trust still lives in the ACP. With SI / identity / QoS enabled, Trust still hands a few packets to Snort, then PERMITLIST / fast-forward. On 4100/9300, a LINA trust ACE (SI off) can offload with no Snort packets at all — that is a different deploy, not a different word. ## 4. How to choose NAT, FMC HA, tracer Interviewers stack these on purpose. Keep the verbs separate: translate, manage, prove. ### NAT sections Auto NAT and manual (twice) NAT live in one table with three sections. Section 1 first, then 2, then 3, stop at first match. There is also a hidden Section 0 for system rules. You cannot edit it. Flow 2 · NAT sections and VPN exemption NAT Section 1 manual, Section 2 auto, Section 3 after-auto; VPN exemption sits in Section 1 Packet 5-tuple Section 1 · Manual NAT first match · put specific + identity here Match in Sec 1? stop if yes NO Section 2 · Auto NAT object NAT · static then dynamic Section 3 · After-auto manual NAT · most general VPN exemption Manual identity NAT src = dest = real nets Insert: Section 1, above PAT ACP still uses real IPs Then packet-tracer twice If Section 2 PAT wins, the tunnel never matches Translated source no longer equals the crypto/protected network. Traffic PATs to the internet. Sources: FDM NAT rule order; Configure and Verify NAT on FTD (Doc ID 212702). Section 1 is where identity NAT lives. Auto PAT in Section 2 is the usual “VPN leaked to the internet” cause. ### FMC HA is not FTD failover FMC high availability is Active/Standby . One appliance manages devices. The standby does not. Event data streams to both , so monitoring survives a manager failure. You must promote the standby — it is not an automatic data-plane failover. Peers can sit in different sites. Port 8305 must be open between them. Same model, same major/minor/maintenance, same SRU, VDB, and LSP. Split-brain: both peers think they are active (usually after you promoted the standby and the original active comes back). Resolving it wipes device registrations and unique policies on the intended standby . Export first. Degraded sync is not split-brain — do not switch roles in that state. FMC HA FTD device HA / cluster Job Keep a manager. Deploy and events. Keep forwarding. Stateful sessions. Roles Primary/secondary at setup; Active/Standby at runtime. Active/Standby pair, or a cluster of units. Who deploys Active FMC only. Standby GUI hides config. The pair/cluster is the target of that deploy. Failover Manual promote (disaster recovery). Device failover / cluster redistribution. Path Integration → Other Integrations → High Availability Devices → Device Management → High Availability / Cluster ## 5. Do: packet-tracer twice + NAT proof Side A is the FMC Packet Tracer the interviewer expects you to open. Side B is the CLI the TAC note uses. Side C is how you close the window without clearing every xlate. Primary source: Configure and Verify NAT on FTD (Doc ID 212702) — Task 3 NAT exemption and the “run it twice” note. ### Side A — FMC Packet Tracer (training mock) Path: Devices → Troubleshoot → Packet Tracer . Use the real (pre-NAT) inside host and the remote protected network, not the PAT address. https://fmc.lab.example/devices/troubleshoot/packet-tracer Training mock · not live Devices / Troubleshoot / Packet Tracer ### Packet Tracer Device FTD-BR01 Ingress interface inside Protocol TCP Source port 1111 Source IP (real) 192.0.2.14 Destination IP 198.51.100.10 Destination port 80 Clear Trace Training mock · path from Configure and Verify NAT on FTD (Devices → Troubleshoot → Packet Tracer). RFC 5737 addresses only. Run the same 5-tuple twice on VPN. ### Side B — CLI: exemption, then tracer twice #### Confirm the three NAT sections show nat prints Manual (Section 1), Auto (Section 2), Manual after-auto (Section 3). The exemption must be the Section 1 identity rule, not a later PAT. FTD LINA · NAT table show nat show run nat

- #### Place identity NAT in Section 1 FMC path: Devices → NAT → Threat Defense NAT → Add Rule . Type Manual, Static, Insert in Section 1. Original source = inside net, translated source = same object. Original destination = remote protected net, translated destination = same. That is the exemption.

- #### Trace internet PAT (once) and VPN (twice) FTD · Cisco NAT verification (Doc ID 212702) packet-tracer input inside tcp 192.0.2.14 1111 203.0.113.80 80 packet-tracer input inside tcp 192.0.2.14 1111 198.51.100.10 80 packet-tracer input inside tcp 192.0.2.14 1111 198.51.100.10 80 First internet trace should hit dynamic interface PAT. First VPN trace often shows Type: VPN / Subtype: encrypt / Result: DROP while the SA comes up. Second VPN trace should show identity NAT and VPN encrypt ALLOW .

- #### If the drop is not NAT/VPN, read the engine ACCESS-LIST DROP with no “sent to snort” = LINA. SNORT Result DROP / “Blocked by the firewall preprocessor” = Snort. Then confirm in Analysis → Connections and Analysis → Intrusions. Live L7 rules: system support trace (filter it; do not leave it running).

     https://fmc.lab.example/devices/nat/threat-defense

     Training mock · not live

       Devices / NAT / Threat Defense NAT / Add Rule

### Manual NAT · identity exemption

          NAT Rule  Manual NAT Rule

          Type  Static

          Insert  In Section 1

          Interface objects  inside → outside

          Original source  Net_192.0.2.0_24

          Translated source  Net_192.0.2.0_24

          Original destination  Net_198.51.100.0_24

          Translated destination  Net_198.51.100.0_24

         Cancel
         OK · Deploy

   Training mock · field names from Configure and Verify NAT on FTD, Task 3. Same object on original and translated = identity NAT. Deploy, then tracer twice.

   Unsafe shortcut

    clear xlate  /  clear conn  on the whole box “so NAT takes.” That drops every translated session. Clear the matching conn, or wait for timeout. Do not disable Snort to prove a VPN leak. Do not Fastpath the inside subnet “temporarily.”

### Side C — Close the change window

 Say this: Section 1 identity NAT is first in  show nat . Internet still hits interface PAT. First VPN tracer brought the SA up; second tracer is ALLOW on VPN encrypt. I did not clear the global xlate table. Connection events show the pre-NAT addresses.

## 6. Runtime path after go-live

 Once the LINA connection exists, later packets follow the flow. That is why a new ACP rule “does nothing” until the conn ages out — and why the second packet-tracer looks different from the first.

- Next packet of the same 5-tuple hits FLOW-LOOKUP, not a full first-packet walk.

- Prefilter Fastpath flows never visit Snort. Trust flows may already be PERMITLIST / offloaded.

- Allow + IPS still sends packets to Snort. An L7 Block can blacklist after AppID on packet 3–10.

- NAT stays the xlate created on the first packet. Editing Section 1 does not rewrite an existing PAT.

- FMC HA: if the active manager dies, devices keep forwarding. You promote the standby to deploy again. Events were already landing on both.

- Do not switch FMC roles during a deploy or while HA sync is degraded.

   Ops · proof desk

   Close the ticket with a second tracer ALLOW and a Section 1 hit-count bump, not with “I disabled inspection.”

## 7. Eight interview scenarios

 Each one is a production ticket. Answer with the direct line, then the evidence. Weak answers reboot, Fastpath the whole inside, or treat FMC HA as device failover.

### Q1 · Scenario — LINA allowed it, the user still fails

   ACP Block uses application HTTP.  show access-list  shows a  permit  for those hosts. The SYN is forwarded. The GET dies. Who dropped it?

    Direct answer
Snort. L7 conditions cannot be decided in LINA, so the ACE is a permit that redirects to Snort. After AppID = HTTP, Snort returns block-list. Capture trace shows ACCESS-LIST ALLOW, then SNORT DROP, drop-reason firewall preprocessor.

    Why production cares
A few packets always leak on L7 blocks (often 3–10) so AppID can finish. Those packets still take the “Intrusion Policy used before Access Control rule is determined.”

    Weak answer / trap
“The ACL is permit any, so FTD is wide open.” That is the LINA view of an L7 rule.

#### Strong framing (say this)

 I quote the SNORT phase rule-id, not the first permit in CSM_FW_ACL_.

#### Evidence to name

  show capture … trace  SNORT phase;  system support trace ; Analysis → Connections / Intrusions. Doc 212321 Scenario 2 and Doc 218196.

### Q2 · Compare — Fastpath versus Trust versus Allow

   Nightly backup is 8 Gbps between two known subnets. You do not want IPS or file policy on it. Which action, and why not the other two?

    Direct answer
Prefilter  Fastpath  on those L3/L4 tuples (both directions). It never engages Snort. ACP Trust still sits after prefilter and, with SI/identity on, still hands early packets to Snort. Allow inspects the whole flow.

    Why production cares
On 4100/9300, Fastpath is how you get hardware offload for elephant flows. A Trust rule is the wrong verb in the interview.

    Weak answer / trap
Fastpath 10.0.0.0/8. That skips SI, decrypt, and IPS for every inside user.

#### Strong framing (say this)

 Fastpath is early and blind. Trust is ACP-cheap. Allow is inspect. I write the return Fastpath too — prefilter is unidirectional.

#### Evidence to name

 Policies → Access Control → Prefilter;  show access-list  PREFILTER remarks above ACP; Doc 212700 Task 3; Doc 212321 Fastpath section.

### Q3 · Architecture — L7 permit-any on LINA

   Geo and URL Block rules sit above a specific L4 Allow.  show access-list  shows those L7 rules as  permit any any . Does traffic stop at the first Geo ACE?

    Direct answer
No. LINA must permit so Snort can see the packet. Snort walks  ngfw.rules  until the Geo/URL/App rule matches. Packet-tracer’s ACCESS-LIST phase may name the first L7 permit, not the Geo rule that blacklisted the flow.

    Why production cares
Operators “fix” a block by deleting the permit-any ACE. That ACE is the redirect, not the hole.

    Weak answer / trap
“First match in show access-list is the security decision.” First match of the  deployed LINA ACE  is not always the Snort verdict.

#### Strong framing (say this)

 LINA ACE vs Snort rule-id. I prove with live traffic or  system support trace , not with packet-tracer alone on Geo.

#### Evidence to name

 Doc 218196; SNORT phase  Firewall: block rule, id … ; CSCwd00446.

### Q4 · Compare — NAT sections on a leaking VPN

   Inside 192.0.2.0/24 PATs to the outside interface (auto NAT). New site-to-site protected net is 198.51.100.0/24. Branch users reach the internet, not the tunnel. Where does the exemption go?

    Direct answer
Manual identity NAT, Section 1, above the PAT: original/translated source = 192.0.2.0/24, original/translated destination = 198.51.100.0/24. ACP already matches real IPs — do not rewrite the Allow to the PAT address.

    Why production cares
Section 2 auto PAT wins if Section 1 has no identity rule. Translated source no longer matches the tunnel selectors.

    Weak answer / trap
Put identity NAT in Section 3 “after auto” and hope order does not matter. Or disable NAT globally.

#### Strong framing (say this)

 Section 1 specific identity, Section 2 object NAT, Section 3 general after-auto. First match stops the walk.

#### Evidence to name

  show nat  section headings; Devices → NAT Insert In Section 1; Doc 212702 Task 3; FDM NAT rule-order table.

### Q5 · Troubleshoot — packet-tracer twice

   You added the Section 1 exemption. First  packet-tracer input inside tcp 192.0.2.14 1111 198.51.100.10 80  shows VPN encrypt DROP. The change-control manager says the tunnel is broken. First move?

    Direct answer
Run the same command again. Cisco’s NAT lab note: run tracer twice for VPN traffic because the first try brings the tunnel up. First run: identity NAT, then VPN encrypt DROP. Second run: identity NAT, VPN encrypt ALLOW, ipsec-tunnel-flow ALLOW.

    Why production cares
Declaring failure on the first DROP is how good exemptions get ripped out in the change window.

    Weak answer / trap
Disable Snort, bounce the outside interface, or clear every crypto SA on both peers as step one.

#### Strong framing (say this)

 Same 5-tuple, twice. I quote both VPN phases before I touch IKE.

#### Evidence to name

 Doc 212702 “run it twice since the first try brings the VPN tunnel up”;  show crypto ipsec sa  encrypt counter; second tracer Action: allow.

### Q6 · Evidence — prove LINA versus Snort

   User: “HTTPS is dropped.” You must say which engine, with a field, not a feeling. What do you open first?

    Direct answer
 packet-tracer  (or capture with trace) on the real 5-tuple. LINA: ACCESS-LIST / NAT / ROUTE-LOOKUP / VPN DROP and no “sent to snort.” Snort: Type SNORT Result DROP, Verdict BLOCKLIST, drop-reason firewall preprocessor or IPS. Then FMC Connection Events and Intrusion Events.

    Why production cares
The wrong engine means the wrong change: another Allow will not fix a Geo blacklist, and another IPS tune will not fix Section 2 PAT.

    Weak answer / trap
Reboot standby. Set the intrusion base policy to Connectivity over Security as a diagnostic.

#### Strong framing (say this)

 Phase name, then rule-id, then the FMC event. Tracer first, captures to confirm.

#### Evidence to name

 Devices → Troubleshoot → Packet Tracer;  show capture CAPI packet-number 1 trace ; Analysis → Connections. Doc 212321.

### Q7 · Architecture — FMC HA after a manager failure

   The active FMC is dark. Sensors still pass traffic. The standby GUI is read-only. How do you get a deployable manager back, and what must you not confuse this with?

    Direct answer
Promote the standby on  Integration → Other Integrations → High Availability  (switch peer roles). FMC HA is Active/Standby management. It is not FTD device failover. Events were already streaming to both. Configuration is hidden on standby until you promote. If the old active returns while this one is active, you have split-brain — pick one intended active before you register anything else.

    Why production cares
Devices keep forwarding without an FMC. What you lose is deploy, new policy, and a writable GUI — not the data plane.

    Weak answer / trap
“HA will fail over the firewalls automatically.” Or switch roles during a deploy / degraded sync.

#### Strong framing (say this)

 Same model, same version/SRU/VDB/LSP, port 8305, only active deploys, events on both, promote by hand.

#### Evidence to name

 FMC Administration Guide 7.6 High availability; Integration → Other Integrations → High Availability; health of HA sync.

### Q8 · Unsafe shortcut — Fastpath one way

   You Fastpath 192.0.2.0/24 → 198.51.100.0/24 so backups skip Snort. Echo-request leaves. Echo-reply dies. ACP default is Block all. What did you miss?

    Direct answer
Prefilter rules are unidirectional. The return packet does not inherit the Fastpath. It hits the ACP default deny in LINA. Add a second Fastpath for the reverse tuple (Doc 212700 Task 3).

    Why production cares
This is the lab that makes people say “FTD is not stateful.” It is. Your Fastpath never created a Snort-bypass for the reply.

    Weak answer / trap
Change the ACP default to Trust any any. That turns off the safety net for every other flow.

#### Strong framing (say this)

 Two Fastpath rules, tight subnets, then capture-trace the reply ACCESS-LIST remark PREFILTER.

#### Evidence to name

 Doc 212700 return-packet trace (flow found, then ACL DROP on default); second Fastpath ACE in  show access-list .

## 8. Traps and proof checklist

      Trap  What you actually do  Proof

       “FTD is ASA plus a FirePOWER module.”
       One unified image, two engines: LINA + Snort.
       Doc 212321 background figure.

       Trust = Fastpath
       Fastpath is prefilter/LINA. Trust is ACP.
       Prefilter vs ACP table;  show access-list  remarks.

       L7 permit-any means allow
       LINA redirect; Snort still decides.
       SNORT phase rule-id; Doc 218196.

       VPN exemption in Section 2/3
       Identity manual NAT in Section 1.
        show nat ; first NAT phase in tracer.

       First VPN tracer DROP = broken IKE
       Run the same 5-tuple again.
       Doc 212702 twice note; second Action allow.

       FMC HA fails over FTD
       Promote the manager. Device HA is separate.
       Integration → Other Integrations → High Availability.

       One-way Fastpath
       Write the reverse prefilter rule.
       Return capture-trace ACL remark.

       ACP on PAT addresses
       ACP matches real, pre-NAT IPs.
       Doc 212702 “usage of real IPs.”

   Pilot checklist

- show nat lists the identity rule first in Section 1.

- Internet 5-tuple still hits interface PAT.

- VPN 5-tuple: first tracer brings the SA; second is ALLOW on VPN encrypt.

- L7 drop quotes SNORT rule-id, not only ACCESS-LIST permit.

- Prefilter Fastpath exists in both directions if you used it.

- FMC HA page: one Active, one Standby, sync not degraded.

## Knowledge check

   Six judgment items. Same facts as the promise. Check answers, then re-read the named section if you miss.

       Q1
       An ACP Block matches application HTTP.  show access-list  shows permit ip host A host B. The SYN is forwarded; the GET is dropped. What is the correct first statement?

           LINA is misconfigured — a Block must always be a deny ACE, so deploy failed
           LINA permitted so Snort could identify HTTP; the SNORT phase blacklisted the flow
           FMC dropped the packet in the management plane before LINA saw it
           Prefilter Fastpath overrode the Block after the handshake

       Correct:  b . L7 Blocks deploy as LINA permits. Snort returns the deny after AppID. Re-read Mental model + Q1.

       Q2
       You must bypass Snort completely for a tight L3/L4 backup flow on a 4100. Which action is the official early-control tool?

           ACP Allow with no intrusion policy
           ACP Monitor so the flow is logged and then permitted
           Prefilter Fastpath (and a reverse Fastpath)
           ACP Trust — it is documented as identical to Fastpath

       Correct:  c . Fastpath is the prefilter action that skips Snort. Trust is not the same verb. Re-read Prefilter versus ACP + Q2.

       Q3
       Site-to-site interesting traffic is being PATed to the outside interface. Where does the identity exemption belong?

           Manual identity NAT in Section 1, above the auto PAT
           Auto NAT in Section 2, because object NAT always wins
           Manual NAT in Section 3 after-auto, so PAT can still create xlates first
           On the ACP destination, rewrite the Allow to the PAT address

       Correct:  a . First match in Section 1 stops the walk before Section 2 PAT. ACP uses real IPs. Re-read NAT sections + Q4.

       Q4
       After adding the exemption, the first VPN  packet-tracer  shows Type VPN / encrypt / DROP. What do you do before you change IKE?

           Disable Snort and trace again — encrypt DROP means inspection
           Run the identical 5-tuple a second time; the first try brings the tunnel up
           Clear xlate globally so the identity NAT can install
           Promote the standby FMC — the active cannot build SAs

       Correct:  b . Cisco’s NAT verification note: run tracer twice for tunnel traffic. Re-read the runbook + Q5.

       Q5
       The active FMC is unreachable. FTD units still forward. What is true?

           Device HA already failed over every firewall to its peer automatically
           The standby FMC is already writable; just deploy
           Events were only on the dead FMC, so history is gone
           Promote the standby; only the active manages; events were streaming to both

       Correct:  d . FMC HA is Active/Standby management with events on both and a manual promote. Re-read FMC HA + Q7.

       Q6
       You publish an inside host with static NAT. Which statement is official?

           ACP destination must be the mapped address, because NAT runs before policy
           ACP matches real (pre-NAT) addresses; NAT does not replace the access decision
           Prefilter Fastpath is required or static NAT will not untranslate
           You must place static NAT in Section 3 so auto NAT can reserve the mapped IP first

       Correct:  b . Cisco’s NAT lab: Access Control uses real IPs; static NAT is bidirectional. Re-read NAT sections + runbook.

       Check answers
       Reset

## Sources

- Clarify FTD Access Control Policy Rule Actions — unified image, LINA then Snort, ACP vs Prefilter actions, Trust vs Allow vs Fastpath, L7 Block as LINA permit

- Understand how Lina Rules Configured with Snort Features Are Handled — L7/URL/Geo/App deployed as permit-any on LINA; Snort rule-id is the verdict

- Configure and Operate FTD Prefilter Policies — Fastpath/Block/Analyze, outer vs inner headers, unidirectional Fastpath, return-path ACE

- Firepower Management Center Device Configuration — Prefiltering vs Access Control — Fastpath skips more inspection; prefilter is first

- Prefilter vs access control policy — official comparison table

- Configure and Verify NAT on FTD — Section 1/2/3, identity exemption, real IPs on ACP, packet-tracer twice on VPN

- Firewall Threat Defense Configuration Guide — NAT rule order — Auto vs manual NAT; Section 1 then 2 then 3; Section 0 system rules

- Secure Firewall Management Center Administration Guide 7.6 — High availability — Active/Standby, events on both, promote, split-brain, port 8305, version/SRU/VDB/LSP match

- Configure High Availability on FMC — HA pair setup example

- Decode Secure Firewall Terminology — LINA as ASA code on FTD; Snort as inspection

 Related:  FTD &amp; FMC fundamentals  ·  Access Control Policy  ·  FTD NAT  ·  FTD VPN  ·  HA / clustering / troubleshooting  ·  Snort 3 IPS  ·  Architecture &amp; platforms  ·  Cisco Secure Firewall hub

---
Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees.
Browse all lessons: https://ai.techclick.in/blogs
AI index: https://ai.techclick.in/llms.txt
