Common interview slip
Many candidates say 'FTD is just the ASA firewall with FirePOWER bolted on as a separate module'. That answer costs marks in any serious Cisco interview.
FTD — Secure Firewall Threat Defense — is one unified image that runs two engines together: LINA, the ASA-derived data plane that owns interfaces, routing, NAT, VPN, stateful L3/L4 ACL and the connection table; and Snort (Snort 3 by default) for deep inspection — IPS, application visibility, URL filtering and file/malware. It is managed centrally by FMC, on-box by FDM, or from the cloud by CDO, and fed threat intelligence by Talos. Knowing which engine does what — and the order traffic flows through them — is exactly what interviewers test.
① Architecture & management — the unified image and its two engines
Q: What is FTD and what are its two engines?
Model answer: FTD — now branded Cisco Secure Firewall Threat Defense — is a single unified image that combines two engines on the same device. LINA is the ASA-derived data plane — it owns interfaces, routing, NAT, VPN, stateful L3/L4 access control and the connection table. Snort is the deep-inspection engine — IPS, application visibility & control (AVC), URL filtering and file/malware inspection. Snort 3 is the default. The clean one-liner: FTD = LINA (fast stateful firewall/VPN) + Snort (deep inspection), in one image, fed by Talos threat intel.
Q: Who does what — LINA vs Snort?
Model answer: LINA handles everything an ASA does: physical/virtual interfaces, static and dynamic routing, NAT, IPsec/SSL VPN termination, the stateful connection table, and the L3/L4 access decision. When a flow needs more than L3/L4, LINA redirects the packet to Snort. Snort then does the L7 work — intrusion (IPS), application identification, URL category lookup and file/malware analysis — and returns a verdict. Most flows touch LINA; only flows that need deep inspection are sent to Snort, which is why placing rules well matters for performance.
Q: FMC vs FDM vs CDO — when do you use each?
Model answer: FMC (Secure Firewall Management Center) is the central, multi-device manager — one console for many FTDs, shared policy, correlation, reporting and RBAC; the default for any real estate. FDM (Firewall Device Manager) is the on-box, single-device manager — good for one or a handful of firewalls with no FMC. CDO (Cisco Defense Orchestrator) is the cloud-delivered manager for FTD (and other Cisco security devices) without standing up your own FMC. Pick FMC for scale, FDM for a single box, CDO when you want cloud management. Gotcha: FDM and FMC are mutually exclusive on a device — moving a box from FDM to FMC wipes the on-box config, so plan the management model up front.
Q: What hardware and virtual platforms run FTD, and what are routed vs transparent mode?
Model answer: FTD runs on the Secure Firewall 1200, 3100 and 4200 Series appliances (the current 2026 line), the older Firepower 1000/2100, the high-end Firepower 4100/9300 chassis (FXOS-managed, supporting multi-instance and clustering), and as FTDv (virtual) in VMware, KVM and the public clouds, sized by performance tier. Each box can run FTD or ASA software — same hardware, different image. Deployment-wise, a device is either routed mode (an L3 hop with its own interface IPs, NAT and routing — the default) or transparent mode (an L2 bump-in-the-wire bridging two segments in the same subnet, invisible as a hop). On top of that, individual interfaces can run as inline pairs or inline-with-tap for IPS-only insertion, or passive (SPAN) for monitor-only. The current default inspection engine across all of these is Snort 3.
Q: Describe FTD Smart Licensing tiers and what stops working when a subscription lapses.
Model answer: FTD uses Cisco Smart Licensing — the FMC registers to a Smart Account / virtual account (via Smart Software Manager, or a satellite/on-prem SSM in air-gapped sites). Every device needs a base license — Essentials (formerly Base) — which covers routing, NAT, VPN and L3/L4 access control. On top sit three term subscriptions you enable per device: IPS (intrusion + Security Intelligence), Malware Defense (file policy / Secure Malware Analytics), and URL Filtering (category/reputation lookups). A separate Carrier license covers SP features (GTP/SCTP/Diameter). What breaks on lapse: the base firewalling keeps running, but the FMC marks the device out of compliance and the subscription features degrade — without IPS you cannot deploy an intrusion policy; without URL Filtering, category lookups stop and you fall back to manual URL objects; without Malware Defense, file/malware inspection stops. The data plane does not drop traffic, but your NGFW protections quietly stop being enforced — a classic gotcha to call out.
Q: Walk through the FMC deployment workflow — what does a deploy actually push, and when does Snort restart?
Model answer: Changes you make in FMC are staged, not live — the device shows Pending until you click Deploy. FMC builds the new LINA config and Snort config, you can preview the diff per device, and the Inspect Interruption column warns you when a change will restart the Snort process and briefly interrupt traffic/inspection. On deploy, FMC pushes both packages; if either fails it rolls back so the device is never left half-configured. Key distinction: most policy edits (access rules, NAT, objects) deploy without a Snort restart, but certain changes do force a restart — adding/removing detection features, some advanced/file settings, VDB updates, switching Snort 2↔3, or MTU/inline-set changes. Best practice: deploy in a change window, read the Inspect-Interruption warning, and use per-device deploy so one box's change does not push pending edits on others.
When asked what FTD is, anchor your answer with 'one unified image running two engines — LINA, the ASA-derived data plane for interfaces/routing/NAT/VPN/L3-4 ACL, and Snort for deep inspection (IPS/AVC/URL/file), Snort 3 by default'. That single line proves you understand the architecture, not just the marketing name.
Which engine inside FTD owns NAT, VPN termination and the connection table?
② Policy & inspection order — ACP, Trust vs Allow, Snort 3 base policies
Q: Walk me through the Access Control Policy processing order.
Model answer: A packet enters on the ingress interface in LINA. First the Prefilter policy can fast-path or block early (and handles tunnelled traffic). Then optional TLS/SSL decryption. Next, Security Intelligence drops known-bad IPs, URLs and domains from Talos feeds. Then the Access Control rules are evaluated top-down, first-match. If a matching rule says Allow, the flow is handed to Snort for intrusion and file/malware inspection; if it passes, it is forwarded out the egress interface. Knowing this order — Prefilter → decrypt → SI → AC rules → Snort → egress — is the most common policy question.
Q: What is the difference between Trust and Allow?
Model answer: Both permit the traffic, but they differ on inspection. Allow permits the flow and can still run an intrusion policy and a file policy via Snort — deep inspection happens. Trust permits the flow but skips deep Snort inspection entirely — no IPS, no file policy — so it is faster but blind. Use Trust for high-volume, known-good traffic you do not need to inspect (e.g. backup replication); use Allow when you still want IPS/file protection on permitted traffic.
Q: What are the Snort 3 intrusion base policies?
Model answer: An intrusion policy starts from a Talos-curated base policy and you attach it to an Allow rule. The four tiers, from most permissive to most aggressive, are Connectivity over Security, Balanced Security and Connectivity (the usual starting point), Security over Connectivity, and Maximum Detection. Higher tiers enable more rules — better detection but more performance cost and more false positives. You tune from a base rather than hand-pick thousands of rules.
Q: Go deeper on Snort 3 intrusion policies — Firepower Recommendations, rule states and variable sets.
Model answer: After picking a base policy you tune three ways. First, each rule has a rule state: Generate Events (alert only), Drop and Generate Events (block — only effective when the device is inline, not passive), or Disabled. Second, Firepower (Secure Firewall) Recommendations correlate the host/OS and app data the system has discovered against the rule set and suggest enabling rules that match your real environment and disabling ones that do not — so you protect what you actually run without drowning in noise. Third, variable sets define values like $HOME_NET and $EXTERNAL_NET that rules reference; set $HOME_NET to your real internal ranges so directional rules fire correctly — leaving it as any is a common tuning miss. Gotcha: 'Drop and Generate' silently only alerts if the interface set is passive — interviewers love that one.
Q: Prefilter policy vs Access Control policy — what is each for?
Model answer: The Prefilter policy runs first, in LINA, before the Access Control policy and before Snort. It has two jobs: Fastpath / Block rules that handle bulk or trusted flows early with no deep inspection (great for high-throughput elephant flows), and tunnel rules that match outer encapsulation — GRE, IP-in-IP, Teredo, GTP — so you can rezone or inspect the inner traffic. The Access Control policy is the main L3–L7 rulebase (Security Intelligence, then top-down Allow/Trust/Block rules with intrusion, file and URL inspection). Rule of thumb: use Prefilter to cheaply offload or pre-handle traffic; use the ACP for the actual security decision. A Prefilter Fastpath beats everything below it, so an over-broad fastpath rule can accidentally skip all inspection — keep it tight.
The ASA-derived data plane in FTD — interfaces, routing, NAT, VPN termination, stateful L3/L4 ACL and the connection table. It redirects flows needing deep inspection to Snort.
The deep-inspection engine (Snort 3 by default) — intrusion/IPS, application visibility (AVC), URL filtering and file/malware analysis. Only flows on an Allow rule are sent here.
Secure Firewall Management Center — the central multi-device manager: one console for many FTDs, shared policy, correlation, reporting and RBAC. The default for any real estate.
Cisco's threat-intelligence group — feeds Security Intelligence block lists, intrusion rule sets and the base policies that an FTD intrusion policy starts from.
A classic error is saying the Trust action still inspects traffic. It does not — Trust permits the flow and skips deep Snort inspection (no intrusion, no file policy). Allow is the action that can still run intrusion and file policies. Mixing these up is an instant red flag in a Cisco interview.
In the Access Control Policy, which step happens immediately before traffic is handed to Snort for intrusion and file inspection?
③ NAT & VPN — auto vs manual NAT, exemptions, VTI and Secure Client
Q: Explain auto (object) NAT vs manual (twice) NAT and the section order.
Model answer: Auto NAT (object NAT) translates a single object's source OR destination — simple one-thing rules. Manual NAT (twice NAT) translates source AND destination together for context-aware translation. FTD evaluates NAT in three sections, in order: Section 1 = manual NAT (top), Section 2 = auto NAT, Section 3 = manual NAT (bottom / after-auto). Two critical exam points: Access Control rules match on the real (pre-NAT) IPs, not the translated ones; and VPN interesting traffic needs a NAT exemption — an identity manual NAT placed high in Section 1 — so the traffic enters the tunnel un-translated instead of being NATed out to the internet.
Q: Why exactly does VPN traffic need a NAT exemption?
Model answer: If a general internet auto-NAT rule matches your LAN, traffic destined for the remote VPN subnet gets translated and never matches the tunnel's interesting-traffic / crypto selectors, so the tunnel is bypassed. A NAT exemption (identity NAT, source=dest) at the top of Section 1 keeps the VPN-bound traffic un-translated so it matches the tunnel and is encrypted. It is the single most common 'site-to-site VPN traffic is leaking out the internet' fix.
Q: Route-based VTI vs policy-based, and how does RA VPN work?
Model answer: Policy-based site-to-site VPN selects interesting traffic with crypto ACLs — rigid. Route-based VTI (Virtual Tunnel Interface) makes the tunnel a routable interface, so you steer traffic with routing (static or dynamic) — cleaner, scalable, and the modern recommendation. For remote-access (RA) VPN, users connect with Cisco Secure Client (the rebrand of AnyConnect) over SSL or IKEv2; you define connection profiles, group policies and address pools, and authenticate with AAA — RADIUS/LDAP or SAML SSO.
Q: Configure RA VPN with Cisco Secure Client on FTD via FMC — what are the moving parts?
Model answer: In FMC the Remote Access VPN wizard (Devices ▸ VPN ▸ Remote Access) ties together six pieces. (1) A connection profile (tunnel group) — the connection users select, holding the AAA and address-assignment settings. (2) AAA — a RADIUS or LDAP/AD realm, or SAML to an IdP for SSO, very often with MFA (Duo/ISE) layered in. (3) A client address pool (or DHCP/RADIUS-assigned) for VPN clients, with matching routing back to the pool. (4) A group policy controlling split tunneling (tunnel-all vs tunnel-specified-networks), DNS, banner and the Secure Client profile. (5) The Secure Client images (per-OS packages) FMC pushes to clients. (6) An identity certificate on the outside interface for the SSL/IKEv2 listener. The classic gotcha: add a NAT exemption for VPN-pool-to-inside traffic (same Section 1 identity-NAT pattern as site-to-site), and if clients must reach the internet through the firewall, enable hairpin NAT (NAT the pool out the outside interface) — otherwise users connect but cannot reach anything.
Q: What is FlexConfig and when must you use it?
Model answer: FlexConfig is an FMC feature that lets you push raw ASA-style CLI to an FTD for features FMC does not yet expose in its GUI. You build FlexConfig objects (optionally with system variables) and attach them via a FlexConfig policy; the CLI is deployed alongside the normal config. Two legitimate uses: (1) ASA-to-FTD migration, to carry over a compatible feature FMC cannot configure natively, and (2) a feature simply not surfaced in the current FMC version. Important gotchas: use it only as a last resort after confirming there is no native policy or Smart CLI for it; FMC does not validate FlexConfig CLI deeply, so a bad command can fail or break a deploy; and when an FMC upgrade adds native support for that feature, you must migrate off the FlexConfig and delete it — deprecated commands can cause deployment failures. In a 2026 interview, naming FlexConfig as the escape hatch and stressing 'remove it once natively supported' is the strong answer.
Two facts interviewers love to probe together: Access Control rules match on the real (pre-NAT) addresses, and the NAT order is Section 1 manual → Section 2 auto → Section 3 manual. State both and you also explain why a VPN exemption goes high in Section 1 — so VPN traffic is checked before any broad auto-NAT translates it.
▶ Watch FTD decide a packet — and find why one gets dropped
Step through how a packet moves from LINA into Snort and out. Press Play for the healthy Allow path, then Break it to see the classic NAT-vs-VPN mistake.
Site-to-site VPN traffic between two LANs is leaking out to the internet instead of entering the tunnel. What is the standard FTD fix?
④ Operations & advanced — failover, clustering and troubleshooting drops
Q: Active/standby failover vs clustering — and why a state link?
Model answer: Active/standby failover is a two-unit HA pair: one unit forwards, the other waits to take over — redundancy, not extra throughput. Clustering joins multiple units into one logical firewall that load-shares traffic, so you get HA and scale-out throughput. Both keep a stateful failover / state link that replicates the connection table (and xlate/VPN state) between members, so when a unit fails, existing sessions stay up instead of every connection resetting. Without the state link you would still fail over, but users would drop their sessions.
Q: A user says 'my traffic is being dropped on the firewall.' How do you troubleshoot it?
Model answer: Start with packet-tracer — simulate the exact 5-tuple and it tells you which phase and which engine dropped it: a LINA phase (ACCESS-LIST / NAT / ROUTE-LOOKUP / VPN) or the handoff to Snort. That instantly separates a LINA ACL/NAT problem from a Snort intrusion/AC-rule drop. Then confirm with captures on ingress/egress, the connection events and intrusion events in FMC, and the Health Monitor. If it is HTTPS being blocked unexpectedly, check the SSL/TLS decryption policy (resign vs known-key) — a bad decryption rule silently breaks sessions. The interview gold line: packet-tracer first to localise the phase, then captures and FMC events to confirm.
Priya at NovaBank in Hyderabad faces this
After a new branch goes live, the head-office team can reach the branch app servers, but the branch cannot reach the head-office subnet over the site-to-site VPN. Some branch users instead get out to the internet fine. Priya manages the pair from FMC and cannot send an engineer to the branch.
A broad outbound auto-NAT (PAT) rule on the branch FTD is translating the branch LAN before the VPN selectors are checked, so head-office-bound traffic is NATed to the internet and never enters the tunnel. There is no NAT exemption for the VPN.
In FMC run packet-tracer for branch-LAN → head-office-subnet: the NAT phase shows the outbound PAT rule matching instead of an identity rule, and VPN never triggers. Connection events confirm the flow egresses the outside interface in the clear.
FMC ▸ Devices ▸ Packet Tracer ▸ NAT phase ▸ Policies ▸ NAT ▸ Section 1In FMC add a NAT exemption (manual identity NAT, source=branch LAN, destination=head-office subnet, do-not-proxy-ARP / route-lookup as needed) at the top of Section 1 on the branch FTD, above the broad PAT rule, and deploy. AC rules already match the real pre-NAT IPs, so the permit rule is unchanged.
Re-run packet-tracer: the NAT phase now hits the identity rule and the VPN phase encrypts the flow. Branch users reach the head-office subnet, internet traffic still PATs normally, and the tunnel's encrypt/decrypt counters climb.
A user reports traffic is dropped on the firewall and you must find whether LINA or Snort dropped it. What is the fastest first tool?
🤖 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.
🧠 In your own words
Type one line: what are the two engines inside FTD, and which one owns NAT, VPN and the connection table? Then compare with the expert version.
🗣 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
- FTD (Secure Firewall Threat Defense)
- Cisco's unified firewall image that runs two engines — LINA (data plane) and Snort (deep inspection) — on one device, managed by FMC, FDM or CDO.
- LINA
- The ASA-derived data plane in FTD: interfaces, routing, NAT, VPN termination, stateful L3/L4 access control and the connection table. It redirects deep-inspection flows to Snort.
- Snort
- FTD's deep-inspection engine (Snort 3 by default): intrusion/IPS, application visibility (AVC), URL filtering and file/malware analysis on flows handed over by LINA.
- FMC / FDM / CDO
- Managers for FTD: FMC (Secure Firewall Management Center) is central multi-device, FDM (Firewall Device Manager) is on-box single-device, and CDO (Cisco Defense Orchestrator) is cloud-delivered.
- Access Control Policy order
- Ingress (LINA) → Prefilter → TLS decryption → Security Intelligence → Access Control rules (top-down first match) → if Allow, Snort intrusion/file inspection → egress.
- Trust vs Allow
- Both permit traffic, but Trust skips deep Snort inspection (no IPS/file) while Allow can still run an intrusion policy and a file policy.
- Snort 3 base policies
- Talos-curated intrusion starting points — Connectivity over Security, Balanced, Security over Connectivity, Maximum Detection — attached to an Allow rule and then tuned.
- NAT sections / exemption
- FTD evaluates NAT as Section 1 manual → Section 2 auto → Section 3 manual; AC rules match real pre-NAT IPs. A VPN NAT exemption is an identity NAT high in Section 1 so VPN traffic stays un-translated.
- VTI / Cisco Secure Client
- VTI is a route-based VPN tunnel interface steered by routing (preferred over policy-based). Cisco Secure Client (formerly AnyConnect) is the RA VPN client over SSL/IKEv2 with connection profiles and AAA (incl. SAML).
- Failover vs clustering
- Active/standby failover is a two-unit HA pair (redundancy); clustering joins multiple units into one logical, load-sharing firewall (HA + throughput). Both use a stateful state link so sessions survive a failover.
📚 Sources
- Cisco — Cisco Secure Firewall Threat Defense (FTD): unified image, LINA and Snort architecture. cisco.com/go/secure-firewall
- Cisco — Secure Firewall Management Center (FMC) configuration guide: Access Control, intrusion and file policies. cisco.com/c/en/us/support/security/secure-firewall-management-center
- Cisco — FTD NAT: auto vs manual NAT, the three NAT sections and NAT exemption for VPN. cisco.com (Secure Firewall config guide)
- Cisco — Site-to-site VTI and remote-access VPN with Cisco Secure Client (SSL/IKEv2, SAML). cisco.com (Secure Firewall VPN config guide)
- Cisco Talos — Threat intelligence, Security Intelligence feeds and Snort 3 rule sets / base policies. talosintelligence.com
- Cisco Learning — Securing Networks with Cisco Firepower (SNCF 300-710) exam topics and study resources. learningnetwork.cisco.com
What's next?
Done with the interview prep? Go deeper on Cisco Secure Firewall design — how to size FTD appliances, plan FMC domains and high availability, build a clean Access Control + intrusion policy, and roll out RA VPN with Cisco Secure Client and SAML across a real estate.