Access Control List (ACL) Scenarios

Log to Cloud

Why it fails: Access Control Rule logging writes events locally to the appliance's own log; there is no cloud logging destination in the Logging tab. It is tempting because cloud logging exists elsewhere in Firepower, but the tab's two settings are Log at Beginning and Log at End, governing connection events only.

Log every packet

Why it fails: Access Control Rule logging records connection events, not individual packets; packet-level capture belongs to the packet capture feature. It is tempting because 'Log every packet' sounds like maximum visibility, but the Logging tab's two settings are Log at Beginning and Log at End, which log connection start and close.

Log at Middle

Why it fails: Access Control Rule logging offers only 'Log at Beginning' and 'Log at End' connection events, so 'Log at Middle' does not exist. It is tempting because middle logging sounds like a granular midpoint, but the actual axis is connection setup versus teardown, with no intermediate position available.

URL

Why it fails: A URL field matches web addresses or categories, not the application itself, so it cannot identify Facebook as an App-ID. It is tempting because URL filtering is the classic way to block websites, and would be correct when the requirement is to deny a specific domain or URL category rather than an application.

Zones

Why it fails: Zones define source and destination security areas, not applications, so they cannot single out Facebook. It is tempting because zones are mandatory in every Access Control rule, and would be correct when the requirement is to restrict traffic between interfaces, such as blocking guest-to-internal access, rather than identifying an application.

Ports

Why it fails: Ports match TCP/UDP numbers, not application identities, so Facebook traffic over 443 cannot be isolated from other HTTPS sites. It is tempting because port-based rules are the traditional firewall method for permitting or denying services, and would be correct when blocking a specific protocol or service port rather than a named application.

In Objects > Object Management > Access Control > SGT Objects.

Why it fails: SGT Objects under Object Management only define and name Security Group Tags; they do not attach an SGT condition to a rule. It is tempting because SGTs are the correct matching criterion, but that object page is for creating reusable tag definitions, not for placing the condition in the rule wizard.

In the Platform Settings policy under Identity Sources.

Why it fails: Platform Settings configures device-level options such as identity source integration, not per-rule matching conditions, so it cannot block traffic for the Contractors SGT. It is tempting because pxGrid identity sources are configured there, but the SGT condition belongs in the Access Control rule's Users tab.

In the Access Control Rule, navigate to the Networks tab and select Security Groups.

Why it fails: The Networks tab matches source and destination IP addresses, not Security Group Tags, so selecting Security Groups there does not filter by the Contractors SGT. It is tempting because SGTs are carried in the packet, but the correct location is the rule's Users tab.

FMC Captive Portal

Why it fails: Captive Portal authenticates users through an FMC-hosted web page for guest or BYOD access, generating its own mappings; it does not ingest the VPN concentrator's existing IP-to-user sessions, so VPN users stay unresolved. It would be correct where unauthenticated endpoints must be challenged before network access.

Terminal Services Agent (TS Agent)

Why it fails: TS Agent captures IP-to-user mappings on terminal servers hosting multiple sessions, not remote access VPN clients, whose mappings require the VPN integration such as the Cisco AnyConnect or ISE identity source. It is tempting because TS Agent does resolve shared-IP user mappings, but only for terminal services environments.

SNMP polling of the DHCP server

Why it fails: SNMP polling of the DHCP server retrieves lease data for DHCP-assigned endpoints, but remote access VPN clients receive addresses from the VPN pool, not DHCP, so no mapping exists to poll. It would be correct for resolving wired or wireless users whose addresses come from DHCP leases.

Intrusion Policy Signatures

Why it fails: Intrusion policy signatures are inspected after a rule permits traffic, so they cannot match traffic within the rule itself. They tempt because intrusion policies are configured alongside access control, but matching occurs on source/destination, applications, ports and URLs instead.

Device Platform Settings

Why it fails: Device Platform Settings are endpoint attributes used in identity or posture policies, not match criteria in an FMC access control rule. They tempt because platform-based conditions exist elsewhere in Cisco security, but FMC rules match on zones, networks, ports, applications and URLs.

Objects > Object Management > Diff Viewer

Why it fails: Object Management's Diff Viewer compares object definitions between the FMC and managed devices, covering objects only, not access control rule edits. It is tempting for spotting drift, yet the stem requires reviewing all pending configuration changes, which the Deploy menu's pending-changes view lists.

Analysis > Audit > Pending

Why it fails: The Audit log records user activity and configuration events, not the set of undeployed configuration changes awaiting push to FTD. It is tempting because auditing sounds like change review, and it would be the right place to trace who altered a rule after the fact.

System > Updates > Pending Changes

Why it fails: System > Updates handles software and vulnerability database updates, not configuration changes queued for deployment. It is tempting because 'pending changes' appears in the path, but that section concerns update packages, not access control or object edits awaiting a deploy.

Block

Why it fails: Block drops the connection outright, so users never see a warning page offering the choice to continue. It is tempting because Block is the correct action when the requirement is a hard deny of the category, such as for malware or command-and-control URLs where no override should exist.

Allow

Why it fails: Allow passes traffic with no warning page and no user interaction, so the requested interstitial is bypassed entirely. It is tempting because Allow is correct for categories that should be silently permitted, such as Business and Economy, where no user decision is required.

Monitor

Why it fails: Monitor logs the URL category match without presenting any end-user warning page, so the requested interstitial never appears. It is tempting because Monitor is genuinely for auditing or validating policy behaviour before enforcement, which would suit a pilot phase where you want visibility of hits without affecting browsing.

Port Object

Why it fails: A Port Object defines a single protocol-and-port pair, so it cannot contain other port objects; grouping TCP 80, 443 and 8080 requires a Port Group Object. It is tempting because individual ports are themselves port objects, but the container for aggregation is the group type.

Protocol Object

Why it fails: A protocol object holds a single protocol number, so it cannot group TCP 80, 443 and 8080 into one reusable container. It is tempting because protocol objects are the right choice when a rule must match a protocol such as ICMP or GRE rather than specific ports.

Application Filter Object

Why it fails: Application Filter Objects match traffic by application signatures or cloud identifiers, not by aggregating pre-defined port objects, so they cannot hold TCP 80, 443 and 8080 as members. They are the right choice when policy must identify an application regardless of port.

Interactive Block

Why it fails: Interactive Block drops the session but prompts the user with a block page, so no TCP RST is sent; it suits user-warned web filtering. The RST-generating action is Block, which silently resets the client connection.

Block

Why it fails: Block silently discards matching packets without returning any TCP response, so the client sees a timeout rather than a reset. Reject is the action that drops traffic and sends a TCP RST; Block suits scenarios where you want no response disclosed to the sender.

Trust

Why it fails: Trust permits matching traffic to bypass further inspection, so it cannot drop packets or emit TCP resets. It is tempting because trust rules are used to exclude known-good flows from intrusion or file policy, which is correct when you want to whitelist traffic rather than block it.

Traffic is inspected by IPS

Why it fails: The Trust action permits matching traffic without further inspection, so it bypasses intrusion prevention rather than invoking it. It is tempting because trusted flows often skip deep inspection, but IPS inspection is applied by an Allow rule with intrusion prevention enabled, not by Trust.

Traffic is blocked

Why it fails: Trust permits the connection to pass; blocking is the Block action, and Drop silently discards without notification. Trust is used for traffic known to be safe, such as internal backups, where inspection would waste resources, but it never denies the flow.

Traffic is decrypted

Why it fails: Decryption is performed by SSL policy rules, not Access Control Policy actions; a Trust action permits traffic matching the rule to pass without further inspection. It is tempting because trust and decryption are both rule actions within Cisco FTD policies, but decryption requires an SSL policy with a Decrypt action applied to the connection.

Devices > Device Management > Apps

Why it fails: Application filters are created under Policies > Access Control > Application Filters, not under device management. The Devices menu configures managed devices and their interfaces, so it cannot hold reusable application filter objects. It is tempting because device settings do relate to FMC administration, but the filter is a policy object.

System > Configuration > Application Database

Why it fails: System > Configuration manages global FMC settings, not policy objects. The Application Database entry only handles application detector updates and signatures, so no custom filter can be created there. It is tempting because the application database underpins application identification, but filters are policy objects created under Policies > Access Control.

Policies > Access Control > Applications

Why it fails: Access Control holds rules and policy objects, but application filters live under Policies > Access Control > Application Filters, not the Applications submenu. The Applications node lists individual applications for rule matching, not the custom filter containers. It is tempting because filters are consumed in Access Control rules.

The traffic is dropped

Why it fails: Interactive Block does not silently drop traffic; it returns a block page giving the user the option to proceed. It is tempting because Block drops traffic outright, but that is the separate Block action, which provides no user interaction or override prompt.

The traffic is automatically allowed

Why it fails: Interactive Block presents a user-facing block page allowing the user to continue, so traffic is not automatically allowed. It is tempting because Allow is the action that permits traffic, but that is a distinct rule action chosen deliberately, not the outcome of Interactive Block.

The rule is ignored

Why it fails: Interactive Block actively intercepts matching sessions and displays a block page, so the rule is enforced rather than ignored. It is tempting because a rule can be disabled or bypassed by policy ordering, but that is a configuration state, not the behaviour of this action.

Security zones replace IP address objects entirely in all rule configurations.

Why it fails: Security zones are match criteria that supplement, not replace, network objects in access control rules. It is tempting because zones abstract interfaces, but rules still require address or object definitions; zones merely constrain which interfaces traffic traverses.

Security zones are used exclusively in NAT translation rules.

Why it fails: Security zones are referenced in access control rules as source and destination matching criteria, not confined to NAT. It is tempting because zones also appear in NAT configurations, but the rule here evaluates inter-zone traffic, so zones act as match conditions.

Security zones are assigned globally in device platform settings, not in access rules.

Why it fails: Zones are selected as source and destination match criteria inside the Access Control rule itself, so this misstates where they are applied. Platform settings only define and name the zone objects. The option tempts administrators who configure interfaces and zone membership at device level, which is genuinely where zones are created, not where rules reference them.

FMC requires an active eStreamer connection to ingest guest identities because pxGrid only supports Active Directory domain accounts.

Why it fails: pxGrid fully supports guest identities as long as the session topic is correctly subscribed.

Guest users must manually log into a captive portal hosted on the FTD data plane before ISE can share their identity.

Why it fails: Identity propagation is handled entirely by ISE pxGrid; captive portal on FTD is not required for ISE-authenticated guests.

The FTD identity policy must be configured with a RADIUS server group instead of pxGrid to support guest VLANs.

Why it fails: pxGrid is the preferred and fully functional method for consuming ISE identity context for all user types.

It bypasses decryption

Why it fails: Decryption bypass is configured through SSL or decryption policy settings, not by attaching an IPS policy. It tempts because encrypted traffic cannot be inspected until decrypted, but the IPS policy only defines intrusion inspection; it neither enables nor bypasses decryption.

It blocks traffic based on IP

Why it fails: Blocking by IP address is performed by the rule's source and destination network conditions, not by an IPS policy. The option tempts because IPS can drop malicious traffic, but it acts on intrusion signatures and protocol anomalies after the rule permits the connection, not on IP-based matching.

It disables the rule

Why it fails: Applying an IPS policy enables intrusion inspection within the rule's allowed traffic; it never disables the rule. Disabling is tempting because rule state is a separate Access Control Policy setting, but the IPS policy field only selects which intrusion policy inspects matching flows.