Most engineers think…
Most people imagine that 'turning on IPS' means every packet gets fully scanned by one big monolithic firewall process. That picture hides the two-engine reality and the very real blind spots you can create.
Inside one FTD image, LINA and Snort split the work. LINA classifies and forwards; the prefilter can fast-path a flow so it never reaches Snort, and on supported platforms hardware flow offload can push a flow past inspection for speed. That is great for throughput — and a blind spot if you offload something you actually needed to inspect. Understanding the handoff is what keeps you fast and safe.
① LINA vs Snort — division of labour & the handoff
One FTD image, two engines, one clean split. LINA — the ASA-derived data plane — owns the L3/L4 world: interfaces, routing, NAT, VPN, the stateful connection table, flow offload and the 5-tuple part of access control. Snort — the inspection engine (Snort 3 by default) — owns the payload: NGIPS, application visibility (AVC), URL filtering and file/malware.
How a packet is handed over
LINA classifies the packet first. The prefilter policy decides fast-path versus inspect: a flow that is trusted or fast-pathed stays entirely in LINA, while a flow that needs inspection is handed to Snort. Snort deep-inspects, returns a verdict, and LINA enforces it and forwards. On supported appliances, established trusted flows can be offloaded to hardware for raw throughput — bypassing Snort by design.
The interview line: LINA classifies and forwards; prefilter decides fast-path vs inspect; Snort inspects and verdicts back to LINA.
Do not just say 'FTD does IPS'. Say: LINA classifies the packet, the prefilter decides fast-path versus inspect, flows needing inspection are handed to Snort, and Snort returns a verdict LINA enforces. Describing the handoff — including fast-path and flow offload — shows you understand the architecture, not just the marketing.
▶ Watch a packet handed from LINA to Snort and back
How one flow is classified, inspected and forwarded inside the two-engine FTD. Press Play for the healthy path, then Break it to see the classic blind spot.
Which engine deep-inspects the packet payload for IPS, AVC and URL?
② The management plane — FMC & sftunnel
The data plane (LINA/Snort) moves packets; the management plane configures and monitors the device. In an enterprise that plane is FMC, which centrally owns policy, events and reporting for many FTDs.
FMC reaches each managed device over a dedicated, encrypted control channel called sftunnel, which runs on TCP 8305. Everything between FMC and the FTD — policy deployments, event streaming, health and licensing — travels inside sftunnel. If 8305 is blocked between FMC and the device, the device stops getting policy and stops sending events, even though traffic may still flow.
The interview line: FMC is the management brain; sftunnel on TCP 8305 is the secure channel that carries config and events between FMC and FTD.
LINA is the ASA data plane (L3/L4, NAT, VPN, routing, flow offload); Snort is the inspection engine (NGIPS, AVC, URL, malware). One image, two engines.
The prefilter decides fast-path vs inspect. Fast-pathed/offloaded flows stay in LINA; flows needing inspection are handed to Snort, which verdicts back.
The encrypted FMC-to-FTD device channel. Carries policy deploys, event streaming, health and licensing. Block 8305 and management breaks.
The 4100/9300 run the FXOS chassis OS (managed by Firepower Chassis Manager) and support multi-instance — several isolated FTD logical devices on one box.
A classic failure: FTD passes traffic fine but will not take a policy deploy or show events in FMC. The cause is almost always TCP 8305 (sftunnel) blocked between FMC and the device by a firewall or ACL in the management path. Management and data planes are separate — fix 8305 reachability.
FMC manages each FTD over a secure channel called sftunnel. Which TCP port?
③ Hardware appliances — 1000–4200 and 4100/9300 on FXOS
The same FTD image runs across a hardware family that scales by throughput. The Secure Firewall 1000/1100, 2100, 3100 and 4200 series cover small branch up to large campus and data-centre edge, with the 3100 and 4200 adding hardware flow offload and higher throughput.
The high-end chassis
The Firepower 4100 and 9300 are high-end chassis that run a chassis operating system, FXOS, managed by Firepower Chassis Manager (FCM). On these you can run multi-instance (container) deployments — several isolated FTD logical devices on one box. The 9300 in particular targets service-provider and very high throughput.
The interview line: 1000–4200 are appliances; 4100/9300 are FXOS chassis managed by FCM that support multi-instance — throughput scales with the platform.
Which platforms use the FXOS chassis OS and support multi-instance (container) deployments?
④ Virtual & cloud — FTDv and scaling
You do not need hardware to run FTD. FTDv is the virtual firewall: the same FTD image as a VM on VMware and KVM on-prem, and on AWS, Azure, GCP and OCI in the cloud. It is licensed by performance tier and managed by the same FMC/CDO.
You scale in two directions. Up: pick a bigger appliance, or a 4100/9300 chassis with multi-instance to carve one box into several FTDs. Out: deploy more FTDv instances (often behind a load balancer or cloud auto-scale) so capacity grows with demand. Throughput always tracks the platform you choose; FMC stays the single management plane across all of them.
The interview line: one image everywhere — appliances, FXOS chassis with multi-instance, or FTDv on VMware/KVM/AWS/Azure/GCP/OCI — scaled up by platform or out by instances, all under one FMC.
Arjun at a Mumbai data centre faces this
An internal server-to-server flow is clearly malicious in logs elsewhere, but FTD never raised an IPS event on it even though the IPS policy is enabled.
An aggressive trust/prefilter rule plus hardware flow offload sends that established flow straight through LINA, so Snort never inspects it — a blind spot, not a missing signature.
Trace the connection: it shows as offloaded/fast-pathed in the connection table, which means it bypassed Snort by design.
FMC ▸ Policies ▸ Prefilter / Access Control ▸ review trust & offload for that flowRemove the trust/fast-path rule (or exclude that flow from flow offload) so the flow is handed to Snort for full inspection instead of being offloaded.
Re-test: the flow now shows as inspected in the connection events and the IPS engine raises the expected intrusion event.
Never assume a flow is being scanned just because IPS is enabled. Check the connection event: if it shows trust/fast-path or hardware offload, Snort never touched it. Read the connection table to prove inspection rather than trusting that the policy 'should' apply.
You need to run FTD in Azure with no physical appliance. What do you deploy?
🤖 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: how is a packet handed from LINA to Snort, and where can it skip Snort entirely? 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
- LINA
- The ASA-derived data plane inside FTD: interfaces, routing, NAT, VPN, the connection table, flow offload and stateful L3/L4 access control.
- Snort
- The deep-inspection engine inside FTD (Snort 3 by default): NGIPS, application visibility (AVC), URL filtering and file/malware defence.
- Prefilter / fast-path
- An early LINA policy that decides whether a flow is fast-pathed (kept in LINA, skipping Snort) or handed to Snort for inspection.
- Flow offload
- Pushing an established, trusted flow to the platform fast path/hardware so it bypasses software inspection for throughput — a potential blind spot.
- sftunnel (TCP 8305)
- The encrypted FMC-to-FTD management channel carrying policy deploys, events, health and licensing — separate from the data plane.
- FXOS
- Firepower eXtensible Operating System — the chassis OS on the 4100/9300 that hosts FTD logical devices and manages the hardware.
- Firepower Chassis Manager (FCM)
- The web UI on FXOS (4100/9300) for managing chassis interfaces, logical devices and multi-instance deployments.
- Multi-instance
- Container instances on the 4100/9300: several isolated FTD logical devices on one chassis, each with dedicated resources.
- FTDv
- Virtual FTD — the same FTD image as a VM on VMware and KVM and on AWS, Azure, GCP and OCI, licensed by performance tier.
📚 Sources
- Cisco — Cisco Secure Firewall Threat Defense architecture: LINA and Snort data path. cisco.com/go/secure-firewall
- Cisco — Secure Firewall Management Center: device management and the sftunnel channel (TCP 8305). cisco.com
- Cisco — Secure Firewall 1000/2100/3100/4200 appliance data sheets. cisco.com
- Cisco — Firepower 4100/9300 with FXOS, Firepower Chassis Manager and multi-instance. cisco.com
- Cisco — Cisco Secure Firewall Threat Defense Virtual (FTDv) for VMware, KVM, AWS, Azure, GCP and OCI. cisco.com
- Cisco — Prefilter, fast-path and flow offload in Secure Firewall Threat Defense. cisco.com
What's next?
Got the architecture and platforms? Next, go deep on deployment and interface modes — routed vs transparent firewall mode, inline pair vs inline tap, passive/SPAN and ERSPAN, and how security zones group interfaces for policy.