Prefilter Fastpath Overrides a Guest Block Rule
A retail chain has guest Wi-Fi on 10.60.20.0/24 and corporate users on 10.60.10.0/24. To reduce load on a Cisco Secure Firewall 2140, the access control policy has a prefilter rule above all others: source 10.60.20.0/24, destination 198.51.100.0/24, a SaaS provider, action Fastpath. The SaaS provider hosts both the approved point-of-sale portal and a newly observed phishing domain at 198.51.100.77. Security adds an access control rule near the top of the ACP to block the phishing domain by URL and by destination IP, with logging. Guests can still reach 198.51.100.77, and the ACP hit counters for the block rule stay at zero. The FTD is in routed mode, TLS 1.2 is used by the phishing site, and no decryption policy exists. The fastpath rule has no application or port restriction. The customer wants to keep the SaaS performance benefit.
1. Why is the ACP block rule not matching, and what is the rule-evaluation order?
Read the worked answer
Prefilter policies are evaluated before the access control policy. A prefilter rule with action Fastpath sends matching traffic directly to egress, bypassing ACP rules, intrusion inspection, file policy, and URL filtering. Because the guest-to-198.51.100.0/24 fastpath rule is first and has no port or application restriction, traffic to 198.51.100.77 matches it and never reaches the ACP block rule. That is why the block rule's hit count is zero: it is not being skipped by a logging bug; it is never evaluated. The prefilter policy is first-match, so a broad fastpath rule high in the list shadows later security rules. This is a design trade-off: fastpath improves performance but deliberately removes inspection. The correct fix is to narrow or precede the fastpath rule, not to move the ACP rule higher, because ACP order cannot override prefilter.
2. Propose a corrected rule design that blocks the phishing domain while preserving fastpath for the approved SaaS portal.
Read the worked answer
Keep the performance benefit but make the fastpath specific. Replace the subnet-wide fastpath with a rule that matches only the approved SaaS portal destination and required ports, or use an application condition if the platform supports it. Above that rule, add a prefilter block rule for destination 198.51.100.77/32, port 443, with logging. Because prefilter is first-match, the block rule must be above the fastpath rule. For broader phishing coverage, let guest traffic to the rest of 198.51.100.0/24 go through the ACP with URL filtering, and add a decryption rule for the guest VLAN if the customer wants URL and file visibility. If URL-based prefilter conditions are unavailable, use destination IPs and maintain a threat-intel feed; do not rely on an ACP URL block for traffic that is still fastpathed. Test the approved portal to confirm it still fastpaths.
3. What verification would prove that both the block and the fastpath requirement are met?
Read the worked answer
Use FMC packet tracer from 10.60.20.50 to 198.51.100.77 on TCP 443 and confirm the prefilter block rule matches, then repeat to the approved portal and confirm fastpath matches. Check prefilter rule hit counters and connection events; the block should log, while the fastpath may not create detailed connection events. Run captures on the guest inside and outside interfaces: the phishing connection should be reset or dropped at the FTD, while the portal session should establish. Verify that ACP block rule counters remain zero for the fastpathed portal, which is expected. Repeat after a policy push and after an HA failover. If TLS 1.2 is used and URL visibility is required, confirm the decryption policy and certificate trust; otherwise IP-based blocking is the reliable control.