FTD (Firepower Threat Defense, branded Cisco Secure Firewall Threat Defense) is one NGFW image. LINA is the ASA code: interfaces, routing, NAT, VPN, the connection table, and L3/L4 access control. Snort (Snort 3 by default; Snort 2 is deprecated from 7.7) is the inspection engine: IPS, AVC, URL, file/malware. FMC is the multi-device manager that owns the config. FDM is the on-box GUI for one device. Security Cloud Control (formerly CDO) is the cloud manager, including cloud-delivered FMC. Registering to FMC disables FDM. The management channel is sftunnel on TCP 8305.
1. Why “ASA plus IPS” burns interviews
Monday a junior enables an intrusion policy. Tuesday HTTPS still works but a file download dies and Connection Events say the access-control rule allowed it. He opens the LINA diagnostic CLI, sees a built connection, and declares “the firewall is fine.” The drop was Snort, not LINA. If your mental model is “one ASA ACL,” you debug the wrong engine for an hour.
Cisco TAC’s own terminology note is blunt: FTD is a next-generation firewall that runs on two engines, LINA and Snort. FTD is very similar to ASA, with added functionality. There is no second chassis to cable. There is one image, two jobs, one verdict LINA enforces.
FTD
Cisco Secure Firewall Threat Defense. One unified NGFW software image you deploy on the appliance or as FTDv.
FMC
Cisco Secure Firewall Management Center (formerly Firepower Management Center). Multi-device manager. Owns the device config.
FDM
Cisco Secure Firewall Device Manager. On-box web GUI for a single device. No extra server. One FDM manages one FTD.
SCC / CDO
Cisco Security Cloud Control, formerly Cisco Defense Orchestrator. Cloud manager. Can run cloud-delivered FMC. Interviews still say “CDO.”
2. Mental model: one image, two engines
Three hard words before any menu. LINA (Cisco TAC expands it as Linux-based Integrated Network Architecture) is the ASA data plane living inside FTD. Snort is the inspection process. FXOS is the chassis operating system on some platforms (always visible on 4100/9300; limited on 1000/1200/3100). You do not manage FTD the way you managed classic ASA from ASDM alone.
LINA owns moving and permitting: physical and logical interfaces, routing, NAT, site-to-site and remote-access VPN, the stateful connection table, and the 5-tuple part of access control. Snort owns looking inside: NGIPS (Talos rules), application visibility and control (AVC), URL category/reputation, and file/malware. When an access-control rule says inspect, LINA hands the flow to Snort. Snort returns a verdict. LINA enforces it.
Read top → bottom. If Q1 or Q2 on the quiz feels wrong, come back here. LINA moves. Snort inspects. The manager does not sit in the packet path.
LINA is the ASA muscle. Snort is the inspection brain. One image. LINA hands the flow over only when a rule says inspect.
Regular FTD prompt is > (CLISH). system support diagnostic-cli attaches to LINA (then enable). expert then sudo su is Linux root. connect fxos is chassis. On 4100/9300 you start in FXOS and connect ftd. Source: Cisco TAC “Decode Secure Firewall Terminology.”
3. Packet path: LINA then Snort
Draw the flow before you open any policy. A packet hits a data interface. LINA does L3/L4 work. Prefilter can fast-path or block early. Security Intelligence (Talos IP / URL / DNS lists) can drop known-bad before deep inspection. Then the access control rule matches. If that rule is allow-with-inspection, LINA hands the flow to Snort. Snort runs IPS, AVC, URL, and file policy. LINA applies the verdict on egress.
This is why two tickets look the same and are not. “No connection in LINA” is a routing / NAT / ACP 5-tuple problem. “Connection built, payload blocked” is a Snort / SSL / file / IPS problem. Debug the engine that owns the symptom.
Read left → right. Diamond in your head at step 3: inspect or not. If Q6 (fail-open) feels wrong, re-read the pink box — fail-open is for inline sets, Busy and Down are separate checkboxes.
4. How to choose FMC vs FDM
The Threat Defense image is the same. The manager is the decision. Cisco’s Device Configuration Guide is explicit: use Firewall Management Center when you want a multi-device manager and you require all features. FMC owns the configuration. You are not allowed to configure that FTD directly and bypass FMC.
FDM is on-box, one device, no extra license for the manager itself. Security Cloud Control (still called CDO in most interviews) is Cisco’s cloud manager. Cloud-delivered FMC lives there. You can use FDM together with Security Cloud Control in some onboarding designs. You cannot use FDM and on-prem FMC on the same device at the same time.
Read the first diamond. Forty firewalls is never FDM. One branch with no manager VM is FDM. If Q3 or Q5 feels wrong, stay on this figure.
| Manager | What it is | Pick when | Do not pick when |
|---|---|---|---|
| FMC | Separate hardware or virtual manager. Full policy, events, health, updates. Owns the FTD config. | More than one FTD, or you need the full feature set, correlation, and a single deploy. | You have no place to run the manager and the ticket is one small standalone box. |
| FDM | On-box web UI baked into the Threat Defense image. Manages exactly one device. | Single branch / lab / proof-of-concept. No extra server. | You already registered the device to FMC, or you need multi-device objects and analysis. |
| Security Cloud Control | Cloud manager (ex-CDO). Can onboard FDM-managed devices or run cloud-delivered FMC. | Cloud-first ops, many sites, no on-prem FMC to host. | You treat it as “FMC plus FDM at once.” Cloud-delivered FMC still owns the device like on-prem FMC does. |
FDM is not a baby FMC. Feature coverage is smaller, logging is local, and the day you need a second firewall you start over. Interviewers bait “we will grow into FMC later” — switching managers is a rebuild, not an export. Cisco documents a switch procedure; it is not a side-by-side dual-manage mode.
5. Runbook: first boot and register
Work the device first, then the manager. If you click Register on FMC before configure manager add is on the FTD, you watch TCP RSTs on 8305 for twenty seconds at a time. Primary source for this block: Cisco Secure Firewall Management Center Device Configuration Guide 7.6 — Device Registration, plus TAC 215540.
Side A — Initial setup on the FTD (FDM or CLI)
For most models except Firepower 4100/9300 you can finish first boot in FDM or CLISH. FDM default inside is https://192.168.95.1, username admin, default password Admin123 (you must change it). The setup wizard asks for outside addressing, management DNS / hostname, NTP, then Start 90 day evaluation period without registration. For a later FMC join, pick Standalone, not Cloud Management.
If you use FDM for that first setup, Cisco keeps the outside/inside interface work when you later switch to FMC. If you use only the CLI setup, only Management and manager-access settings survive — the default inside is not retained. That one sentence saves a midnight “where did Ethernet1/2 go?” ticket.
First login → Device setup wizard (Skip device setup is allowed)
Complete Initial Configuration
Do not Smart-License the FTD itself if FMC will own it. All licensing is performed on the Management Center. Next prompt: Cloud Management or Standalone — pick Standalone for on-prem FMC.
Click next: Finish → Standalone → Got It. Then either stay on FDM or switch managers with configure manager delete / configure manager add. Source: FMC Device Config 7.6 — Complete initial configuration using Firewall Device Manager.
Side B — Point the FTD at FMC
On the FTD CLISH:
> configure manager add 203.0.113.10 Cisco-123 Manager successfully configured. Please make note of reg_key as this will be required while adding Device in FMC. > show managers Host : 203.0.113.10 Registration Key : **** Registration : pending
Syntax from TAC 215540: configure manager add <FMC Host> <Registration Key> [NAT ID]. Host can be IPv4, IPv6, hostname, or DONTRESOLVE. Registration key is a shared secret, 2–36 characters, alphanumerics plus hyphen / underscore / period. NAT ID is required when one side cannot specify a reachable IP (PAT). NAT ID must be unique per device. If the FMC is not addressable, use DONTRESOLVE plus NAT ID.
Side C — Add the device on FMC and assign licenses
On FMC: Devices → Device Management → Add → Device (7.6 also has a wizard). Fill Host (FTD management IP, or leave blank and use Unique NAT ID), Display Name, the same Registration Key, an Access Control Policy, Domain / Group if you use them, and the Smart License checkboxes the features need. Click Register. Then assign entitlements under System → Licenses → Smart Licenses if they are not already on the Add Device form.
Devices → Device Management → Add → Device
Add Device
Registration Key must match the FTD CLI. Host uses RFC 5737 training addresses — never invent a live VIP. Leave Host blank and set Unique NAT ID when the FTD is behind PAT.
Click next: Register → wait for the device to go green → Deploy the assigned access control policy. Confirm show managers flips from pending to registered. Source: TAC 215540 + FMC Device Config 7.6 Add a Device Using a Registration Key.
Essentials covers the firewall base. Threat (IPS), URL Filtering, and Malware Defense are add-on entitlements you assign per device. If Priya ticked intrusion and URL on the policy but Smart Licenses still show only Essentials, deploy fails or those engines stay dark. Check System → Licenses → Smart Licenses, do not guess from the ACP checkboxes.
6. Runtime: sftunnel and CLI planes
After Register, FTD and FMC build sftunnel — a TLS channel (current 7.6 guide: TLS 1.3) on TCP 8305 by default. It carries heartbeats, time sync, events, malware lookups, health, identity mappings, HA / cluster state, SI / TID, policy bundles, VDB, and LSP/SRU rule packs. There are two channels: control and event. Cisco recommends at least 5 Mbps, low loss, and a simple path — do not stuff sftunnel through a site-to-site VPN “for extra security.” If that VPN dies, you also lose the manager.
> show managers > show version > system support diagnostic-cli firepower> enable firepower# show conn firepower# show asp drop ! detach: Ctrl-a then d > expert admin@firepower:~$ sudo su root@firepower:/home/admin#
Time skew is a classic registration killer (TAC 215540 item 5). So is a registration-key mismatch, blocked 8305, incompatible software, a down sftunnel process, and path MTU. On the FTD, capture-traffic on the management interface shows the SYN/RST loop if FMC is not yet listening.
7. Traps and proof checklist
| Symptom | Likely cause | First proof |
|---|---|---|
| Device stays Registration pending | Key mismatch, blocked TCP 8305, or you never clicked Register on FMC | show managers + capture-traffic on management. Same key both sides. |
| FTD registered then FDM URL dies | Expected. FMC registration disables on-box FDM. | Not a fault. Use FMC. To go back: unregister, configure manager delete, configure manager local. |
| ACP allowed the 5-tuple, file still blocked | Snort (file / IPS / URL), not LINA | FMC Connection / File / Intrusion events. LINA show conn will still show a built flow. |
| Inspected traffic drops during deploy | Snort restart; Fail Open Down is disabled (default fail-close) | Inline set Advanced → Snort Fail Open Busy / Down. Routed mode is not the same control. |
| IPS / URL policy will not deploy | Only Essentials entitlement on the device | System → Licenses → Smart Licenses. Assign Threat / URL / Malware, then deploy. |
| Manager lost after a data-plane outage | sftunnel hairpinned through this FTD’s own inside/outside | Management path must not depend on the traffic you are about to break. TAC 215540 calls this out. |
show managersshows the FMC host as registered, not pending.- Devices → Device Management shows the device healthy; last deploy succeeded.
- TCP 8305 is established (control + event). Time is in sync.
- A test flow that should be L3/L4-only appears in LINA
show conn. - A test flow that should be inspected appears in FMC Connection Events with the Snort reason you expect.
- Smart Licenses list the entitlements the ACP actually uses.
Knowledge check
Six judgment items. Each one maps to a promise bullet. Check answers, then reset and retry the ones you missed.
Sources
- Cisco TAC 222238 — Decode Secure Firewall Terminology (FTD = LINA + Snort; FDM vs FMC; cannot use both; CLISH / diagnostic-cli / FXOS / expert)
- Cisco Secure Firewall Management Center Device Configuration Guide, 7.6 — Device Registration (FMC owns config; TLS 1.3 management channel; TCP 8305; NAT ID; FDM vs CLI first boot; switch managers)
- Cisco TAC 215540 — Configure, Verify, and Troubleshoot Firepower Device Registration (
configure manager add; Devices → Device Management → Add → Device; sftunnel contents; do not hairpin through the FTD data plane) - Cisco FMC Device Config — Inline Sets and Passive Interfaces (Snort Fail Open Busy / Down; not the same as Hardware Bypass)
- Cisco Firepower Release Notes 7.0 / later notes (Snort 3 default engine; Snort 2 deprecated in 7.7+ and blocks upgrade)
- Cisco — What’s New for Security Cloud Control (CDO renamed Security Cloud Control; cloud-delivered FMC)
- Cisco TAC 215838 — FMC and FTD Smart License Registration (System → Licenses → Smart Licenses)
Related: LINA + Snort session factory · Architecture and platforms · Interface modes · Access control policy · Snort 3 IPS