FTD Access Control Policy — first match, then prove it

1. Why first-match burns tickets

Monday you add INSIDE-to-OUTSIDE-HTTPS-IPS as an Allow with Balanced Security and Connectivity. Tuesday someone “temporarily” parks a Trust any-any at the top of Mandatory so a backup job can finish. HTTPS still works. Intrusion events stay empty. Hit count on your IPS rule is zero.

The Device Configuration Guide is blunt: the system matches traffic to access control rules in the order you specify and, in most cases, handles the flow according to the first rule where all conditions match. A later, more specific Allow cannot steal a session that already matched Trust.

Hero · first matching card wins

2. Mental model: match, then action

Memorize two questions. Mixing them is why Trust gets used as a cheap Allow.

Does this traffic match? Zones, networks, ports, applications, URLs, users, time — all configured conditions must match. What happens if it matches? That is the action: Monitor, Trust, Block / Block with reset, Interactive Block, or Allow (optionally with file and intrusion policies).

Access control is not the first station. Prefilter, optional decryption, identity work, and Security Intelligence run earlier. A Trust ACP rule does not rewind those steps. If you needed the flow to skip Snort entirely from the first packet, that is a prefilter Fastpath conversation, not a Trust checkbox.

Journey · stations before the rule

3. Rule order, Monitor, default action

Open Policies → Access Control heading → Access Control, then edit the policy assigned to the device. Each device uses one ACP. Rules are numbered from 1. The system evaluates top-down. Categories and the Mandatory / Default sections do not change that numbering.

Monitor is the exception. It forces connection logging and lets evaluation continue. The next non-Monitor match (or the default action) actually handles the traffic. The connection event Action field is therefore never Monitor — it shows Allow, Trust, Block, Default Action, and so on, plus up to eight Monitor rule names beside the handler.

Decision · Trust, Allow, or Block

The default action handles traffic that was not fastpathed, not Security Intelligence-blocked, not blocked by the decryption policy, and that matched no non-Monitor access control rule. Official options:

4. Trust vs Allow vs Block

Pick the action for the job, then place the specific rule above any broader cousin. Cisco’s own caution: application-control rules should sit lower than simple L3/L4 rules because application identity takes packets. Specific networks and IPs belong above general application or URL rows so they are not shadowed.

5. Runbook: zones, rules, logging

Primary source for this block: Cisco Secure Firewall Management Center Device Configuration Guide 7.4, chapters Access Control Policies and Access Control Rules.

Side A — Zones and objects (outside the rule editor)

1. Name the security zones

   A security zone is a named group of interfaces. You assign the zone on the interface (Devices → Device Management → edit the device → Interfaces). Rules then match Source Zones and Destination Zones — INSIDE to OUTSIDE — instead of raw interface names. Same-zone traffic needs an explicit rule if you intend to allow it.

2. Build the network and port objects you will reuse

   Objects → Object Management. Keep RFC 1918 / lab objects named for the ticket (NET-USERS-10-0-1-0, H-WEB-10-0-2-20). Access Control uses the real (pre-NAT) addresses — do not write the PAT public IP as the destination on an inside-to-outside browse rule. That NAT lesson is next in this course.

3. Confirm the device already has this ACP

   Each managed device uses one access control policy. On the policy list, open Targeted: n devices and assign before you add rules you will never deploy.

Side B — Policy, rules, actions, logging

1. Open the policy

   Policies → Access Control heading → Access Control → Edit. Lock the policy if someone else might save over you. New Policy asks for Name and an initial default action (Block all traffic, Intrusion Prevention, or Network Discovery).

2. Add the specific rule first

   Click Add Rule. Give it a ticket-readable name. Set Action. Fill only the conditions you mean — empty “any” on every tab is how Trust any-any is born. Place specific Block / Allow-with-IPS rows above broad Trust or Allow rows. Application and URL conditions belong lower than simple network/port rows.

3. Attach inspection only on Allow (or Interactive Block)

   On an Allow rule, select an intrusion policy (and variable set) and, if needed, a file policy. You cannot hang a file policy on the default action. Encrypted payloads skip intrusion and file inspection by default unless you decrypt first.

4. Turn logging on for the handler

   On the rule: Log at beginning of connection, Log at end of connection, or both. Send events to Firewall Management Center (and syslog if that is the shop standard). Blocked traffic is usually beginning-only — the session never has a useful end. Monitor forces logging even if the eventual handler is quiet.

5. Set and log the default action

   Bottom of the rule list: pick Access Control: Block All Traffic unless you have a written reason not to. Cog → enable beginning-of-connection logging. If you inherited a Trust-all default from a lab policy, change it before the first production deploy.

Side C — Deploy, hit counts, first packet

1. Save and deploy

   Deploy configuration changes to the targeted device. A saved rule that never deployed is a comment in the GUI. Established connections keep the old match until they close (or you clear them with clear conn on FTD — only if tearing those sessions is acceptable).

2. Read hit counts

   In the policy editor, Analyze → Manage Rule Hit Counts. Zero on the new specific rule plus rising counts on the broad rule above it is the shadow, not a routing problem.

3. Generate one pilot flow

   From a host in INSIDE (example 10.0.1.50) open HTTPS to a known responder. Then go prove it in connection events — next section — before you call the change done.

6. Prove it: connection events

Primary source: Cisco Secure Firewall Management Center Administration Guide — Connection Logging and Connection and Security-Related Connection Events.

Connection events appear when a connection matches an access control rule or default action that has logging enabled. They also appear for prefilter, decryption, and Security Intelligence blocks. If logging is off on the handler, the session can succeed or fail in silence.

Ops · verification desk

Read these fields on every pilot:

• Access Control Policy (syslog ACPolicy) — the policy you think you deployed.
• Access Control Rule (syslog AccessControlRuleName) — the handler, plus any Monitor names.
• Action (syslog AccessControlRuleAction) — Allow, Trust, Block, Fastpath, Interactive Block, Default Action. Blank usually means the session closed before a rule could be identified.
• Reason (syslog AccessControlRuleReason) — why the system logged it (including Security Intelligence blocks).
• Ingress / Egress Security Zone — confirms the zone match you wrote.
• Initiator IP / Responder IP — real addresses on the wire as the ACP saw them (pre-NAT for the access-control decision).

Access Control Policy : ACP-CAMPUS
Access Control Rule   : INSIDE-to-OUTSIDE-HTTPS-IPS
Action                : Allow
Ingress Zone          : INSIDE
Egress Zone           : OUTSIDE
Initiator IP          : 10.0.1.50
Responder IP          : 203.0.113.80
Application Protocol  : HTTPS

7. Traps and pilot checklist

Sources

• Cisco Secure Firewall Management Center Device Configuration Guide, 7.4 — Access Control Policies (one policy per device; default actions; logging starts disabled; Block default logs beginning only; inheritance)
• Cisco Secure Firewall Management Center Device Configuration Guide, 7.4 — Access Control Rules (first-match order; Monitor / Trust / Block / Interactive Block / Allow; file-then-IPS; rule-order caution)
• Cisco TAC — Clarify FTD Access Control Policy Rule Actions (212321) (LINA vs Snort; Trust vs Allow vs Block vs prefilter Fastpath; L7 Block lets early packets pass)
• Cisco Secure Firewall Management Center Administration Guide — Connection Logging (log connections that match a rule or default action; beginning vs end)
• Cisco Secure Firewall Management Center Administration Guide — Connection and Security-Related Connection Events (fields: Access Control Rule, Action, Reason, zones, initiator/responder)
• Cisco Secure Firewall — Logging best practices (connection events when logging is enabled on the matching rule or default action)

Related: FTD / FMC fundamentals · Interface modes · FTD NAT · Snort 3 IPS · FTD session factory · FTD evidence desk · FTD interview Q&A