# FTD is two planes. FMC is not in the packet path.

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

Gold lesson: Cisco FTD data plane vs FMC management plane. LINA and Snort handoff, sftunnel TCP 8305, hardware vs FTDv, and FMC Active/Standby HA with official paths and proof.

Quick answer

    Threat Defense (FTD)  is one image with two engines.  LINA  is the ASA-derived data plane — interfaces, routing, NAT, VPN, the connection table, and L3/L4 access control.  Snort  is the inspection engine — IPS, application visibility, URL and file/malware.  Firewall Management Center (FMC)  is the management plane. It never sits in the packet path. The control channel is  sftunnel , a TLS tunnel on  TCP 8305 , with a control channel and an event channel. The same FTD image runs on Secure Firewall / Firepower appliances and as  FTDv  on VMware, KVM, Hyper-V and the major clouds.  FMC HA is Active/Standby  — you promote the standby yourself.

   Say this out loud

   I do not draw FMC as a hop. I draw two rooms. Packets stay in the data plane: LINA classifies, the prefilter can Fastpath, Snort inspects only what is sent to it, LINA forwards or drops. Policy, events, health and upgrades travel in sftunnel on TCP 8305. If users browse and FMC is dark, I check the management plane first.

## 1. Why the one-box story fails

 Interviewers still ask you to “walk a packet through FTD.” Weak answers treat FTD as one monolithic process and FMC as a second firewall in the path. Production tickets punish that picture.

 Official TAC language is blunt: FTD is a unified image with a  LINA engine  and a  Snort engine . A packet enters an interface, LINA handles it, Snort inspects only if policy requires it, Snort returns a permit or block verdict, and LINA drops or forwards. FMC is not on that list.

#### The ticket

 Branch FTD still NATs and routes. FMC Health is red, last deploy failed, Connection Events are empty. That is a dead sftunnel, not a dead data plane.

#### The interview

 “Where does FMC sit in the packet path?” The only correct answer is: it does not. If you put FMC between the user and the server, you already failed the architecture question.

   The lie every L1 repeats

   “If traffic is flowing, management is fine.” The planes are independent. Cisco TAC warns against hairpinning sftunnel  through  the FTD data plane for the same reason — a data-plane event can then black-hole the manager that you need to fix it.

## 2. Mental model — two planes, two engines

 Pre-train the nouns before any runbook. Three objects, not one box.

   Flow 1 · data plane vs management plane

       FTD data plane (LINA and Snort) versus FMC management plane over sftunnel TCP 8305

- Two rooms. Packets never visit FMC. DATA PLANE · FTD image LINA ASA-derived engine interfaces · routing · NAT VPN · conn table · L3/L4 ACL prefilter + flow offload live here CSM_FW_ACL_ Snort inspection engine (Snort 3 default) IPS · AVC · URL · file verdict → LINA drop / forward only if policy sends the flow MANAGEMENT PLANE FMC / FDM / cdFMC policy · events · health · license VDB · SRU · LSP · upgrades sftunnel TCP 8305 · TLS Channel-A CONTROL · Channel-B EVENT not packets User packet path (never leaves the left room) ingress → LINA classify → prefilter Fastpath? → else hand to Snort → verdict → LINA forward / drop Source: Cisco TAC “Clarify FTD Access Control Policy Rule Actions” (Doc 212321) Read left → right. The pink engine is optional. The navy room is never a hop. Pre-train the hard words LINA — ASA-derived data plane. Owns interfaces, routing, NAT, VPN, the connection table, and the global ACL CSM_FW_ACL_ .

- Snort — deep-inspection engine (Snort 3 is the default). IPS, application identification, URL, file/malware. Returns a verdict; it does not own the wire.

- Prefilter — early L3/L4 policy in LINA. Fastpath or Block can keep a flow out of Snort entirely.

- sftunnel — TLS management tunnel on TCP 8305. Two connections: control and events. Carries policy, heartbeats, NTP, events, VDB/SRU, upgrades.

- FDM — on-box manager for supported models. One device. FMC is the off-box manager for fleets. Secure Firewall 6100 requires FMC — it does not support FDM.

- FXOS + FCM — chassis OS and Firepower Chassis Manager on Firepower 4100/9300 (and related chassis workflows). Multi-instance lives here, and now also on 3100/4200.

   Visual · packet stations

   Four stations. If you add a fifth station called FMC, you are drawing the management plane into the data plane. Do not.

## 3. Decision flow — platform, manager, HA

 Flowchart first. Do not start in a datasheet.

   Flow 2 · pick the form factor, then the manager

       Decision flow: hardware versus FTDv, then FDM versus FMC, then FMC HA

- Where does this firewall live? Rack / campus / DC — or cloud VM? Hardware appliance 200 · 1200 · 3100 · 4200 6100 · FP 1000 / 4100 / 9300 FXOS + multi-instance on 4100/9300 FTDv VMware · KVM · Hyper-V AWS · Azure · GCP · OCI min 4 vCPU / 8 GB / 100 GB One box → FDM* · Fleet / HA → FMC Need manager redundancy? FMC HA = Active/Standby same model · same SW + SRU/VDB/LSP · TCP 8305 between peers · add devices only to active *FDM is on-box for supported models only. Secure Firewall 6100 must be FMC-managed. FMCv2 does not support FMC HA. Visual · HW vs VM branch Left branch is a chassis you rack. Right branch is the same FTD image as a VM. License tiers on FTDv cap throughput and RA VPN sessions — they do not resize the vCPU you assigned. ## 4. How to choose hardware vs FTDv Same software image. Different contract with physics. Use the table, then confirm the current model on the Threat Defense Compatibility Guide . Choice Pick it when Do not pick it when Manager / scale notes Secure Firewall 200 / 1200 Branch / small campus. Cost-sensitive, still wants FTD features. You need chassis multi-instance or DC-class clustering. HA yes. Clustering — no on these series (compat guide). FDM or FMC. Secure Firewall 3100 / 4200 Internet edge to mid/high DC. Clustering (8–16 nodes by release). Multi-instance on supported releases. You only have a hypervisor and no rack. IPsec / DTLS flow offload on these platforms. Confirm release notes for your version. Secure Firewall 6100 Ultra-high-end DC / telecom. Modular, clustering (4 nodes in 10.0). You wanted on-box FDM. FMC required. FDM is not supported. Firepower 4100 / 9300 Existing chassis investment. Isolated tenants on one box. You expected a simple “one image, one box” appliance like a 3100. FXOS + Firepower Chassis Manager. Multi-instance / container instances. Hardware flow offload on native instances, not container instances. FTDv Public cloud, lab, burst capacity, or “no truck roll.” Private: VMware, KVM, OpenStack, Nutanix, Hyper-V. Public: AWS, Azure, GCP, OCI, Alibaba, Megaport, Equinix. You need chassis-level offload or FXOS multi-instance. Min 4 vCPU / 8 GB / 100 GB. Performance tiers FTDv5–FTDvU cap rate + RA VPN, not vCPU. Active/Standby HA on listed hypervisors. Clustering on a subset (VMware/KVM/AWS/Azure/GCP — check the DS). FMC form factor Physical (current 1800 / 2800 / 4800 family and earlier 1600–4700), FMCv, or cloud-delivered FMC. You picked two different FMC models for HA. HA peers must be the same model / same device-management capacity. Not supported on FMCv2. Hardware vs FTDv in one sentence Hardware buys deterministic NICs, optional FPGA/SmartNIC offload, and (on chassis) multi-instance. FTDv buys portability. Do not size FTDv by the license tier alone — Cisco’s virtual data sheet says compute (vCPU/RAM) sets session scale; the tier sets the rate limiter and RA VPN sessions. ## 5. Runbook Side A → B → C Side A picks the box. Side B joins the manager. Side C makes the manager redundant. Each block cites one primary source. ### Side A — pick the platform (before you rack anything) Primary source: Secure Firewall Threat Defense Virtual Data Sheet + Compatibility Guide . #### Write the constraint, not the SKU Cloud VPC with no rack → FTDv. Branch with a 1RU budget → 200/1200. DC edge that must cluster → 3100/4200. Isolated tenants on one chassis → 4100/9300 multi-instance. 6100 only if you already accepted “FMC-only.”

- #### Confirm manager support Most appliances accept FDM or FMC. 6100 does not accept FDM. FTDv FDM is supported on VMware/KVM/Nutanix/OpenStack/HyperFlex — not on Hyper-V per the virtual DS matrix. When in doubt, manage with FMC.

- #### Size FTDv from two knobs Assign vCPU/RAM for session scale (official min 4 / 8 GB / 100 GB; max 64 / 128 GB / 500 GB). Then pick the performance tier (FTDv5 = 100 Mbps / 50 RA VPN … FTDvU = no rate limiter / 32k RA VPN). Do not expect the tier to grow the VM.

### Side B — register FTD to FMC (sftunnel)

 Primary source:  Configure, Verify, and Troubleshoot Firepower Device Registration  (Doc 215540).

- #### Open TCP 8305 on the management path FTD management IP ↔ FMC management IP. If FMC is already an HA pair, allow 8305 to both FMC addresses. Do not route this through an FTD data interface unless you have no other path — TAC marks that design as not recommended.

- #### Point the device at the manager On FTD CLISH, when both sides have static IPs: FTD CLISH · registration configure manager add 203.0.113.10 Cisco-123 show managers If one side has no reachable IP, add a NAT ID and use DONTRESOLVE on that side. Registration key is 2–36 characters: alphanumerics, hyphen, underscore, period. There is no keyword key in the command — that is a classic syntax trap.

- #### Add the device only on the active FMC Path: Devices → Device Management → Add → Device . Host = FTD IP (or blank + NAT ID). Display Name. Registration Key must match. Access Control Policy. Licenses. If FMC HA already exists, do not add the device on the standby first — register to the active; the standby inherits.

     https://fmc.example.com/#Devices/DeviceManagement/AddDevice

     Training mock · not live

       Devices → Device Management → Add → Device

### Add Device

          Host  203.0.113.40

          Display Name  br-ftd-01

          Registration Key  Cisco-123

          Access Control Policy  ACP-Branch-Pilot

        Unique NAT ID  leave empty when both IPs are reachable

        Cancel  Register

       Fields from Cisco Doc 215540. Placeholders are RFC 5737 / example.com — not a lab tenant.

    Next click:  Register, then on the FTD run  sftunnel-status  until Channel-A (CONTROL) and Channel-B (EVENT) both show Connected and Registration: Completed.

### Side C — establish FMC HA

 Primary source:  Secure Firewall Management Center Administration Guide 7.6 — High availability .

- #### Meet the peer contract before you click Register Same hardware model (or same FMCv device-management capacity). Same major.minor.maintenance software. Identical intrusion rule update (SRU), vulnerability database (VDB) and Lightweight Security Package (LSP). Unique UUIDs in /etc/sf/ims.conf . TCP 8305 open between the two FMCs . Cisco’s typical bandwidth note for high-latency (~100 ms) peers: at least 5 Mbps. Peers may sit in different data centers.

- #### Empty the intended secondary Export any policies you still need, delete devices from the intended secondary, import policies onto the intended primary, deploy, assign licenses. HA copies the primary’s world onto the secondary. A populated secondary is how people lose devices.

- #### Secondary first, then primary On the intended secondary: Integration → Other Integrations → High Availability → Role = Secondary → Primary host (or NAT ID + registration key) → Register. Then on the intended primary: same page → Role = Primary → Secondary host + the same registration key → Register. After sync, the primary is Active; the secondary is Standby. Configuration is hidden on Standby. Events stream to both.

- #### Promote by hand when Active dies FMC HA is not automatic Active/Active failover. Official language: if the active appliance fails, you must promote the standby. Triggering a switchover during a degraded sync can damage the database — contact TAC, do not “just switch roles.”

     https://fmc-b.example.com/#Integration/OtherIntegrations/HighAvailability

     Training mock · not live

       Integration → Other Integrations → High Availability

### Establish High Availability

        Role for this Firewall Management Center  Secondary

          Primary Firewall Management Center Host  203.0.113.10

          Registration Key  ha-once-37chars-max

        Unique NAT ID  required only if a peer host is DONTRESOLVE / not reachable by IP

        Cancel  Register

       Path and field names from FMC Admin 7.6 “Establish high availability for Firewall Management Center.” Registration key is one-time, up to 37 characters.

    Next click:  Register on the secondary, then repeat on the primary with Role = Primary. Watch the High Availability page until peers show Active / Standby — not two Actives (that is split-brain).

   Flow 3 · FMC HA after it is healthy

       FMC Active/Standby pair with sftunnel to both managers and events to both

- FMC-A · ACTIVE you configure devices here Smart License registrant FMC-B · STANDBY config UI is hidden promote by hand if A fails sftunnel TCP 8305 FTD (each unit) CONTROL + EVENT to A and to B · show managers lists both Events go to both FMCs. Policy writes only on Active. Two Actives = split-brain — stop and read the traps section before you click anything. ## 6. Runtime — packet path + sftunnel After go-live you operate two live systems that fail independently. ### Data plane (every user packet) Ingress on a data interface → LINA. Prefilter Fastpath or an L3/L4 Block can finish the story inside LINA. Otherwise LINA redirects to Snort. Snort may PASS every packet (Allow + inspection), PERMITLIST / fast-forward the rest of the flow (Trust, some SSL-without-decrypt cases), or BLOCKLIST. LINA executes the verdict. On 4100/9300 native instances (and related offload-capable platforms), a trusted or Fastpath’d flow can leave software entirely — show conn flag o , show flow-offload flow . ### Management plane (never a user hop) sftunnel keeps two TLS sockets on TCP 8305. Channel-A is CONTROL (policy, keepalives, upgrades). Channel-B is EVENT. Either side can initiate a channel depending on who has a reachable IP. Heartbeats, NTP, connection/IPS/file events, identity mappings, HA/cluster state, SI/TID, VDB/SRU and software bundles all ride this tunnel. If Channel-B dies you still deploy but events go dark. If both die, Health goes red and deploys fail — while LINA keeps forwarding the last installed policy. Proof the management plane is actually up sftunnel-status show managers show network ! Management port : 8305 pmtool status ! sftunnel (system) - Running Green looks like this Registration: Completed on show managers . ChannelA Connected: Yes type CONTROL and ChannelB Connected: Yes type EVENT. On FMC HA, show managers lists two Manager hosts, both Completed. On the FMC High Availability page: one Active, one Standby — never two Actives. ## 7. Traps + proof checklist Symptom Wrong first move Actual cause Proof / fix Users browse. FMC has no events. Deploy fails. Reboot LINA / “restart Snort.” sftunnel down (ACL, NAT, MTU, process, clock). sftunnel-status , capture-traffic on TCP 8305, configure network mtu if DF-bit handshake fails. Open 8305 to both FMCs in HA. FMC HA will not form. Force Register anyway. SW / SRU / VDB / LSP mismatch, different models, 8305 blocked between FMCs, or FMCv2. Appliance Information widget: versions identical. netstat -an | grep 8305 on both. Same model. Not FMCv2. Both FMCs show Active. Keep configuring on both. Split-brain after a failed peer came back. Pick the intended Active. The intended Standby loses device registrations and policy deltas. Export/unregister from the loser first (Admin 7.6 split-brain note). Backup / replica traffic is “trusted” and malware lands. “Trust means inspect less but still inspect.” Prefilter Fastpath or hardware flow offload never sends the flow to Snort. Use Fastpath only for known-good L3/L4. Container instances do not offload. Recheck show flow-offload flow / show asp packet-profile . FTD unregisters after a chassis bootstrap change. Re-click Register forever. 4100/9300 bootstrap from FCM (CSCvn45138 class). Do not use FCM bootstrap except disaster recovery. Delete and re-register. Keep NTP identical on FCM and FMC — 41xx/93xx take time from the chassis. Ops · proof desk Green is not “users can browse.” Green is Channel-A + Channel-B Connected, Registration Completed, and FMC HA showing one Active. Pilot checklist before you call it production Packet-tracer (or a real capture with trace) shows LINA → optional Snort → forward on a pilot Allow rule.

- sftunnel-status shows CONTROL + EVENT; show managers is Completed (two lines if FMC HA).

- A test deploy from the active FMC succeeds; the standby does not offer a conflicting edit.

- A test Fastpath / offload flow is one you intended to skip Snort — and it is documented.

- FMC HA page is Active/Standby. You have a written promote step. You have not switched roles during a degraded sync.

## Knowledge check

   Six judgment questions. Map each miss back to the section in the reason.

       Q1
       A branch FTD still NATs and routes HTTPS. FMC Health is red, the last deploy failed, and Connection Events are empty. What do you check first?

           Restart the LINA process — forwarding is clearly broken.
           TCP 8305 sftunnel between the FTD management IP and both FMC management IPs.
           Disable Snort so events start flowing again.
           Add a default ACP Trust rule for the whole site.

       Correct:  b . Data plane and management plane fail independently. Users browsing while FMC is dark is the textbook dead-sftunnel ticket. Re-read §1 and §6.

       Q2
       You are building FMC HA. Where do you register the first FTD?

           Only on the intended active FMC. The standby inherits the device after HA forms.
           On both FMCs independently, then form HA.
           Only on the standby, because it has spare capacity.
           On FDM first, then import the manager list.

       Correct:  a . Official registration and HA guides: add devices only to the active (or intended active). Dual-add creates pending/split registrations. Re-read Side B and Side C.

       Q3
       Workloads live in Azure. There is no rack and no truck roll. What do you deploy?

           A Firepower 4115 shipped to the Azure region.
           A Secure Firewall 3105 as a native Azure appliance SKU.
           FXOS chassis manager as a marketplace image.
           FTDv from the cloud marketplace, sized on vCPU/RAM, licensed with a performance tier.

       Correct:  d . FTDv is the same FTD image as a VM. Official public-cloud list includes Azure (plus AWS, GCP, OCI, and others). Hardware SKUs are not Azure images. Re-read §4.

       Q4
       An interviewer asks how a packet moves through the two engines. Which sentence is accurate?

           Snort inspects first; LINA only NATs the packet after the verdict.
           FMC inspects the packet, then FTD forwards it.
           LINA handles the packet first; prefilter may Fastpath it; otherwise Snort inspects and LINA forwards or drops on the verdict.
           FXOS inspects every packet on every platform.

       Correct:  c . TAC Doc 212321: enter LINA → optional Snort → verdict → LINA drop/forward. FMC is not a hop. FXOS is the chassis OS on 4100/9300, not a packet engine on a 1200. Re-read §2 and §6.

       Q5
       Two FMCs ping each other. HA still will not establish. What is the contract you missed?

           A Cluster Control Link between the FMCs.
           Same major.minor.maintenance software, identical SRU/VDB/LSP, same model, and TCP 8305 between the two FMCs.
           Identical serial numbers burned into FXOS.
           An FTD failover LAN link reused as the FMC HA link.

       Correct:  b . FMC Admin 7.6 HA requirements. CCL is an FTD cluster construct, not FMC HA. Serials need to be unique, not identical. Re-read Side C.

       Q6
       You Fastpath backup replication for throughput. A week later malware rode that port unseen. Why?

           Prefilter Fastpath and hardware flow offload keep the flow out of Snort. Speed is a deliberate inspection skip.
           FMC HA split-brain silently disabled IPS.
           LINA stops routing once Fastpath is configured.
           You must disable Smart Licensing for offload to work, which removed AMP.

       Correct:  a . Fastpath / offload is Early Access Control — the flow never reaches Snort. That is the feature, and the blind spot. Re-read §6 and the traps table.

       Check answers
       Reset

## Sources

- Clarify FTD Access Control Policy Rule Actions — LINA + Snort handoff, prefilter Fastpath, Trust vs Allow, flow offload (Doc 212321)

- Configure, Verify, and Troubleshoot Firepower Device Registration — sftunnel TCP 8305, control/event channels, configure manager add , FMC HA registration (Doc 215540)

- FMC Administration Guide 7.6 — High availability — Active/Standby, same model/SW/SRU/VDB/LSP, port 8305, split-brain, Integration → Other Integrations → High Availability

- Troubleshoot for FMC HA — peer reachability and netstat on 8305

- Secure Firewall Threat Defense Virtual Data Sheet — private/public platforms, min 4 vCPU / 8 GB / 100 GB, performance tiers, HA/clustering matrix

- Cisco Secure Firewall Threat Defense Compatibility Guide — hardware vs virtual vs cloud, HA/clustering by platform

- Threat Defense / Management Center Release Notes 10.0 — Secure Firewall 200 and 6100, FMC 1800/2800/4800

- Cisco Secure Firewall Management Center data sheet — physical, virtual and cloud-delivered manager form factors

- Secure Firewall Threat Defense documentation landing

- Threat Defense Command Reference — sftunnel-status

 Related:  FTD / FMC fundamentals  ·  Deployment and interface modes  ·  Snort 3 IPS  ·  FTD HA, clustering and troubleshooting  ·  FTD / FMC interview Q&A

---
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