> ## Content Index > Fetch the complete content index at: https://www.pinglabz.com/llms.txt > Use this file to discover other available public pages before exploring further. # FMC Prefilter Policy: Why Fastpath Skips ACP and Snort - URL: https://www.pinglabz.com/fmc-prefilter-policy-fastpath/ - Published: 2026-10-19T09:01:19.000Z - Updated: 2026-10-19T22:18:36.000Z - Description: A broad FMC prefilter Fastpath rule let client-b bypass an explicit ACP block and opened port 8080 for both clients. Real HTTP tests, packet-tracer and Unified Events show why Analyze restored access control in this home lab. - Author: Jaime - Tags: Firewall, Security, Network Security, Troubleshooting, Cisco ![Fault diagram: an FMC prefilter Fastpath rule trusts 10.42.10.0/24 to 10.42.30.0/24, so client-b and port 8080 bypass the ACP and Snort on pl-ftd-edge](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/fmc-prefilter-fastpath-topology.png) Client-b could reach the web server even though Block-Client-B was above Allow-Web in the access control policy. It could also reach TCP/8080, which had no ACP allow rule at all. Client-a gained access to 8080 too. The block had worked before the change. The difference was an FMC prefilter rule named Fastpath-Backup-Net. It matched the entire client subnet, ran before access control, and fastpathed those connections past Snort. Changing its action to Analyze restored the intended policy: client-a could use HTTP on port 80, while client-b and the extra listener stayed blocked. This is another lab in the FMC-managed FTD series, built in my home lab with FMCv 10.0.1, FTDv 10.0.0 and IOL in Containerlab. The recorded run used FMC 10.0.1 Build 1 and Snort 3.9.3.1-61 on 19 October 2026\. This is a nested home lab, not a supported production deployment or a performance benchmark. ## Topology and addressing The data path is client-a/client-b → inside switch → routed FTDv → r-core → server. FMC manages FTD over the management tunnel, separate from these client-to-server links. | Node or interface | Address | Role / security zone | | -------------------------- | -------------- | --------------------------------- | | client-a | 10.42.10.21/24 | Inside test client | | client-b | 10.42.10.22/24 | Client targeted by Block-Client-B | | FTD Ethernet0/0 | 10.42.10.1/24 | inside / PL-INSIDE | | FTD Ethernet0/1 | 10.42.20.1/29 | outside / PL-OUTSIDE | | r-core, FTD-facing link | 10.42.20.2/29 | Next hop from FTD | | r-core, server-facing link | 10.42.30.1/24 | Server LAN gateway | | server | 10.42.30.80/24 | HTTP listeners on TCP 80 and 8080 | FTD's route to 10.42.30.0/24 points through 10.42.20.2 on outside. The server's return route for 10.42.10.0/24 uses 10.42.30.1\. Client tests bind to their data interface, eth1, so the management network cannot supply an alternate path. The [FTD-to-FMC registration lab](https://www.pinglabz.com/register-ftd-to-fmc-containerlab/) covers bringing up the management relationship and a registration-key mismatch. The preceding [FMC static-route lab](https://www.pinglabz.com/ftd-static-route-fmc-next-hop/) uses this routed setup to investigate a dead next hop. For a separate local-management example, see [FTDv bootstrapping with FDM](https://www.pinglabz.com/ftdv-fdm-containerlab-bootstrap/). ## Where prefilter sits before access control For the flows tested here, the important decision order was LINA's prefilter classification, followed by access-control enforcement and Snort processing when Analyze allowed the packet to continue. LINA is FTD's underlying firewall engine. Prefilter made its decision from network conditions before an ACP or Snort verdict could block these fastpathed flows. This is the practical difference between an FTD prefilter policy and an access control policy: a matching Fastpath action can end the security-policy decision before the ACP gets to enforce its rules. Moving Block-Client-B higher within the ACP would not put it ahead of prefilter. | Prefilter action tested | Compiled match in this lab | What happened next | | ----------------------- | -------------------------- | ----------------------------------------------------------- | | Fastpath | advanced trust | Forwarded without an ACP/Snort verdict for the matched flow | | Analyze | advanced permit | Sent to Snort; the ACP could allow or block it | That table describes the observed policy path, not every FTD processing stage. The Fastpath trace still contained route, connection, NAT and other phases. It had no SNORT phase. Analyze added an explicit message that Snort would reach a verdict, then showed that verdict. There is another useful qualification: ACP enforcement does not always wait for a visible SNORT phase. Before the fault, the simple client-b block dropped at LINA's ACCESS-LIST phase. After Analyze matched, the same block appeared as a SNORT firewall verdict. The traces below show both behaviors on this build. The earlier [FTD access control policy lab with FDM](https://www.pinglabz.com/ftd-access-control-policy-fdm-packet-tracer/) explores that distinction in a different setup. ## Baseline: prove Block-Client-B works In **Policies → Access Control → PL-Edge-ACP**, the temporary rule Block-Client-B used source host PL-CLIENT-B, 10.42.10.22, and destination PL-SERVER-NET, 10.42.30.0/24\. Its action was Block, with any destination port and beginning-of-connection logging sent to FMC. It was inserted above Allow-Web. Strictly, it was rule 2: Allow-ICMP remained at rule 1\. Block-Client-B was the first rule relevant to these TCP tests, so the earlier ICMP allow did not explain the HTTP result. ![Saved PL-Edge-ACP places Block-Client-B above Allow-Web, with any destination port.](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/fmc-prefilter-fastpath-shot-04-baseline-block-acp.png) Saved PL-Edge-ACP places Block-Client-B above Allow-Web, with any destination port. Save the ACP, then use **Deploy → Advanced Deploy** to select the FTD and deploy the change. Saving a policy alone does not establish the baseline. The recorded baseline deployment completed successfully in 54 seconds. The client tests requested both http://10.42.30.80/ and http://10.42.30.80:8080/, binding curl to eth1 with a five-second connection timeout. Client-a received HTTP 200 on 80 and timed out on 8080\. Client-b timed out on both. Both clients could still ping the server. At the FTD diagnostic CLI, this client-b simulation identified the block. Output excerpts throughout retain the recorded lines; a standalone `...` marks omitted lines. ```text > packet-tracer input inside tcp 10.42.10.22 40200 10.42.30.80 80 detail ... Phase: 4 Type: ACCESS-LIST Subtype: Result: DROP Elapsed time: 689 ns Config: access-group CSM_FW_ACL_ global access-list CSM_FW_ACL_ remark rule-id 268434436: ACCESS POLICY: PL-Edge-ACP - Mandatory access-list CSM_FW_ACL_ remark rule-id 268434436: L4 RULE: Block-Client-B ... Action: drop Time Taken: 144105 ns Drop-reason: (acl-drop) Flow is denied by configured rule, Drop-location: frame snp_classify_table_lookup:6167 flow (NA)/NA ``` A timeout alone would not identify the cause. Here, packet-tracer named Block-Client-B and ended with acl-drop. For the phase-reading basics, see the [Cisco ASA packet-tracer guide](https://www.pinglabz.com/cisco-asa-packet-tracer/). In **Events & Logs → Analysis → Unified Events**, the newest baseline rows agreed: client-b was blocked by Block-Client-B, client-a's port 80 connection matched Allow-Web, and client-a's 8080 connection hit the default Block. ![Unified Events shows client-b blocked by Block-Client-B, plus client-a Allow-Web and default Block rows.](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/fmc-prefilter-fastpath-shot-09-baseline-unified-events.png) Unified Events shows client-b blocked by Block-Client-B, plus client-a Allow-Web and default Block rows. ## The fault: link a broad Fastpath rule to the ACP The deliberate mistake was a rule whose name sounded narrower than its actual match. Fastpath-Backup-Net did not identify a particular backup application or server port. It matched the whole inside subnet to the whole server subnet. In **Policies → Prefilter**, create PL-Edge-Prefilter and add the following prefilter rule: | Setting | Faulted value | | ------------------------------------- | ------------------------------ | | Name | Fastpath-Backup-Net | | Action | Fastpath | | Source network | 10.42.10.0/24 | | Destination network | 10.42.30.0/24 | | Interfaces, ports and VLAN conditions | Any | | Logging | Beginning and end, sent to FMC | Save the prefilter policy. Then open **PL-Edge-ACP → More → Advanced Settings → Prefilter Policy Settings**, use the pencil, and select PL-Edge-Prefilter. Confirm, save the ACP and deploy. On this FMC 10.0.1 build, the header's Prefilter Rules popover was disabled and displayed None. Advanced Settings was the functioning assignment control; the saved policy readback confirmed the link. The screenshot captures the selection dialog, before confirmation. ![ACP Advanced Settings selects PL-Edge-Prefilter in the Prefilter Policy dialog.](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/fmc-prefilter-fastpath-shot-15-acp-prefilter-assignment.png) ACP Advanced Settings selects PL-Edge-Prefilter in the Prefilter Policy dialog. After the successful deployment, both clients received HTTP 200 from both listeners. This client-b port 8080 response is an excerpt from the endpoint test: ```text HTTP/1.1 200 OK Content-Type: text/plain Connection: close PL-server-port-8080 Exit: 0 ``` | Test | Block baseline | Fastpath fault | Analyze fix | | ---------------------- | -------------- | -------------- | ----------- | | client-a → server:80 | HTTP 200 | HTTP 200 | HTTP 200 | | client-a → server:8080 | Timeout | HTTP 200 | Timeout | | client-b → server:80 | Timeout | HTTP 200 | Timeout | | client-b → server:8080 | Timeout | HTTP 200 | Timeout | The port 8080 result matters as much as client-b's port 80 result. Fastpath bypassed both an explicit block and the default block that had kept the extra listener unreachable. ### Packet-tracer matches prefilter and skips Snort Run the same client-b-to-server simulation at the FTD diagnostic CLI, with a fresh source port. The fault trace matched rule 268434438, Fastpath-Backup-Net: ```text > packet-tracer input inside tcp 10.42.10.22 40201 10.42.30.80 80 detail ... Phase: 3 Type: ACCESS-LIST Subtype: Result: ALLOW Elapsed time: 591 ns Config: access-group CSM_FW_ACL_ global access-list CSM_FW_ACL_ advanced trust ip 10.42.10.0 255.255.255.0 10.42.30.0 255.255.255.0 rule-id 268434438 event-log both access-list CSM_FW_ACL_ remark rule-id 268434438: PREFILTER POLICY: PL-Edge-Prefilter access-list CSM_FW_ACL_ remark rule-id 268434438: RULE: Fastpath-Backup-Net ... Action: allow Time Taken: 782090 ns ``` The compiled action was advanced trust. The full recorded trace contained no SNORT phase and no Block-Client-B verdict. Together with the real HTTP responses and live connection details below, that shows the matched flow bypassed ACP enforcement and Snort inspection. FMC's **Troubleshooting → Tools → Packet Tracer** showed the same fault for client-b source port 40202\. Security bypass and packet transmission were unchecked. The following screenshot is the saved 08:16:33.667 fault trace, reopened after restoration; it is not a new test of the restored policy. ![Saved fault trace at 08:16:33.667 shows ALLOW and the complete phase list without a SNORT phase.](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/fmc-prefilter-fastpath-shot-43-fastpath-saved-trace-loaded.png) Saved fault trace at 08:16:33.667 shows ALLOW and the complete phase list without a SNORT phase. ![The saved fault trace's ACCESS-LIST phase shows advanced trust, PL-Edge-Prefilter and Fastpath-Backup-Net.](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/fmc-prefilter-fastpath-shot-44-fastpath-trust-expanded.png) The saved fault trace's ACCESS-LIST phase shows advanced trust, PL-Edge-Prefilter and Fastpath-Backup-Net. ### ACL order and counters explain the bypass At the diagnostic CLI, show access-list placed the prefilter trust at line 3, ahead of the ACP block at line 16\. These are selected lines from that read: ```text show access-list ... access-list CSM_FW_ACL_ line 1 remark rule-id 268434438: PREFILTER POLICY: PL-Edge-Prefilter access-list CSM_FW_ACL_ line 2 remark rule-id 268434438: RULE: Fastpath-Backup-Net access-list CSM_FW_ACL_ line 3 advanced trust ip 10.42.10.0 255.255.255.0 10.42.30.0 255.255.255.0 rule-id 268434438 event-log both (hitcnt=13) (Last Hit=08:15:46 UTC Oct 19 2026) ... access-list CSM_FW_ACL_ line 14 remark rule-id 268434436: ACCESS POLICY: PL-Edge-ACP - Mandatory access-list CSM_FW_ACL_ line 15 remark rule-id 268434436: L4 RULE: Block-Client-B access-list CSM_FW_ACL_ line 16 advanced deny ip object PL-CLIENT-B object PL-SERVER-NET rule-id 268434436 event-log flow-start (hitcnt=11) (Last Hit=08:10:12 UTC Oct 19 2026) ... access-list CSM_FW_ACL_ line 17 remark rule-id 268434435: ACCESS POLICY: PL-Edge-ACP - Mandatory access-list CSM_FW_ACL_ line 18 remark rule-id 268434435: L7 RULE: Allow-Web access-list CSM_FW_ACL_ line 19 advanced permit tcp ifc inside any ifc outside host 10.42.30.80 object-group HTTP rule-id 268434435 (hitcnt=32) (Last Hit=08:09:54 UTC Oct 19 2026) ... access-list CSM_FW_ACL_ line 20 remark rule-id 268434432: ACCESS POLICY: PL-Edge-ACP - Default access-list CSM_FW_ACL_ line 21 remark rule-id 268434432: L4 RULE: DEFAULT ACTION RULE access-list CSM_FW_ACL_ line 22 advanced deny ip any any rule-id 268434432 event-log flow-start (hitcnt=15) (Last Hit=08:09:58 UTC Oct 19 2026) ``` The trust rule had 13 hits and a last-hit time of 08:15:46 UTC. Block-Client-B was still deployed, but its last hit was 08:10:12 UTC, from before the Fastpath fault. Allow-Web and the default deny also retained older last-hit times. The counters include diagnostic activity; they are not a count of unique client sessions. A held real client-b connection added a separate check: ```text > show conn address 10.42.30.80 detail ... TCP outside: 10.42.30.80/80 inside: 10.42.10.22/40222, flags U , idle 5s, uptime 5s, timeout 1h0m, bytes 0, flow id 100, Snort id -1, rule id 268434438, Rx-RingNum invalid, Internal-Data invalid Initiator: 10.42.10.22, Responder: 10.42.30.80 ``` The connection had flags U, Snort id -1 and rule id 268434438, the prefilter rule. The flag legend identifies U as up and N as inspected by Snort; this connection had no N flag. Its zero-byte snapshot establishes connection state, while the separate HTTP tests establish successful application traffic. ### Unified Events names the prefilter rule Customize the Unified Events table to show **Action**, **Source IP**, **Destination Port**, **Access Control Rule** and **Tunnel/Prefilter Rule**. The fault rows showed Fastpath for both clients on ports 80 and 8080, with Fastpath-Backup-Net in the prefilter column and no ACP rule in those rows. ![Unified Events shows Fastpath for both clients on ports 80 and 8080, attributed to Fastpath-Backup-Net.](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/fmc-prefilter-fastpath-shot-20-fastpath-unified-events.png) Unified Events shows Fastpath for both clients on ports 80 and 8080, attributed to Fastpath-Backup-Net. The Last 1 hour view also contained older baseline events. Read the action, rule and timestamp together. Real traffic and packet-tracer events coexist in this view, so its row count is not a client-request count. FMC displayed UTC-4 times; the CLI and endpoint records used UTC. ![Fix diagram: the same prefilter rule set to Analyze compiles to permit, Snort applies the ACP, client-b is blocked and client-a reaches only port 80](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/fmc-prefilter-fastpath-fig2.png) ## Fix: change Fastpath to Analyze and deploy Open **Policies → Prefilter → PL-Edge-Prefilter**, edit Fastpath-Backup-Net and change its action to **Analyze**. Keep the same source and destination networks. Save the rule, save the policy, then deploy the change to FTD. The recorded deployment completed successfully in 52 seconds. The rule name was retained to make the before-and-after comparison clear. Its action, rather than the word Fastpath in its name, controls the result. ![The saved Fastpath-Backup-Net editor shows Analyze with source 10.42.10.0/24 and destination 10.42.30.0/24.](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/fmc-prefilter-fastpath-shot-29-analyze-rule-full.png) The saved Fastpath-Backup-Net editor shows Analyze with source 10.42.10.0/24 and destination 10.42.30.0/24. FMC automatically cleared this rule's prefilter beginning/end logging and send-to-FMC flags when the action changed to Analyze. ACP logging continued to record the resulting decisions. ### Analyze permits further processing, not the connection The new client-b trace still matched prefilter first. This time it compiled as advanced permit and explicitly said the packet would go to Snort. The later SNORT firewall phase blocked it: ```text > packet-tracer input inside tcp 10.42.10.22 40203 10.42.30.80 80 detail ... Phase: 3 Type: ACCESS-LIST Subtype: Result: ALLOW Elapsed time: 295 ns Config: access-group CSM_FW_ACL_ global access-list CSM_FW_ACL_ advanced permit ip 10.42.10.0 255.255.255.0 10.42.30.0 255.255.255.0 rule-id 268434438 access-list CSM_FW_ACL_ remark rule-id 268434438: PREFILTER POLICY: PL-Edge-Prefilter access-list CSM_FW_ACL_ remark rule-id 268434438: RULE: Fastpath-Backup-Net Additional Information: This packet will be sent to snort for additional processing where a verdict will be reached ... Phase: 14 Type: SNORT Subtype: firewall Result: DROP Elapsed time: 817741 ns Config: Network 0, Inspection 0, Detection 2, Rule ID 268434436 Additional Information: Starting rule matching, zone 1 -> 2, geo 0 -> 0, vlan 0, src sgt: 0, src sgt type: unknown, dst sgt: 0, dst sgt type: unknown, user 9999997, no url or host, no xff Matched rule ids 268434436 - Block ... Action: drop Time Taken: 1125788 ns Drop-reason: (firewall) Blocked or blacklisted by the firewall preprocessor, Drop-location: frame inspect_dp_snort_snp_drop_frame_wcaller:66 flow (NA)/NA ``` That ACCESS-LIST ALLOW was permission to continue processing. It was not the final connection verdict. Rule ID 268434436 was still Block-Client-B, now enforced in the SNORT firewall phase. ![After Analyze, the GUI Packet Tracer SNORT firewall phase drops client-b at Block-Client-B, rule ID 268434436.](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/fmc-prefilter-fastpath-shot-32-analyze-gui-snort-drop.png) After Analyze, the GUI Packet Tracer SNORT firewall phase drops client-b at Block-Client-B, rule ID 268434436. Client-a's port 80 trace reached the different ACP rule, Allow-Web, ID 268434435: ```text > packet-tracer input inside tcp 10.42.10.21 40204 10.42.30.80 80 detail ... Phase: 14 Type: SNORT Subtype: firewall Result: ALLOW Elapsed time: 195211 ns Config: Network 0, Inspection 0, Detection 0, Rule ID 268434435 Additional Information: Starting rule matching, zone 1 -> 2, geo 0 -> 0, vlan 0, src sgt: 0, src sgt type: unknown, dst sgt: 0, dst sgt type: unknown, user 9999997, no url or host, no xff Matched rule ids 268434435 - Allow ... Action: allow Time Taken: 637502 ns ``` Fresh real tests restored the baseline matrix: client-a received HTTP 200 on 80, while its 8080 request and both client-b requests timed out. This is the recorded client-b port 80 result: ```text curl: (28) Connection timed out after 5001 milliseconds Exit: 28 ``` The newest Unified Events rows again named Block-Client-B for client-b, Allow-Web for client-a on 80, and Default Action for client-a on 8080\. Fastpath-Backup-Net still appeared in the prefilter column because the Analyze rule still matched; that column alone does not mean a connection was fastpathed. ![After Analyze, new events show client-b Block-Client-B blocks and client-a Allow-Web/default Block decisions.](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/fmc-prefilter-fastpath-shot-30-analyze-unified-events.png) After Analyze, new events show client-b Block-Client-B blocks and client-a Allow-Web/default Block decisions. ## When Fastpath is reasonable A narrowly defined, trusted bulk transfer is a reasonable candidate when bypassing ACP and Snort inspection is an intentional policy choice. A backup flow between specific endpoints is the sort of use case to assess. The rule in this lab was much broader: any protocol or port between two entire subnets. The risk is visible without a malicious payload. A service on port 8080 became reachable even though the ACP had no rule allowing it, and an explicit host block stopped taking effect. A name such as Backup-Net provides no protection if the conditions match ordinary client traffic too. Use Analyze when those flows still need an ACP decision. This run demonstrated bypass and restored enforcement; it did not measure a throughput benefit, test intrusion signatures, or establish that a particular production backup flow is safe to exclude from inspection. ## How the lab was restored The Analyze fix kept the temporary client-b block in place for verification. Restoration was a separate step: select **Default Prefilter Policy** in the ACP's Advanced Settings, remove Block-Client-B, save, delete PL-Edge-Prefilter and the temporary PL-CLIENT-B object, then deploy. The restoration deployment completed successfully in 55 seconds. The ACP again contained only Allow-ICMP and Allow-Web, with default Block. Both clients received HTTP 200 on port 80 and timed out on 8080\. FMC reported all devices up-to-date; FTD's management control and event channels were connected, and no captures remained. For another case where the simulated verdict needs a real packet check, continue with [FTD packet-tracer allows, but capture shows no SYN-ACK](https://www.pinglabz.com/ftd-packet-tracer-capture-fmc/). The series also covers [FMC deployment history and rollback](https://www.pinglabz.com/fmc-deployment-history-rollback/). 💡 **Running ASA instead of FTD? The ASA packet-tracer workflow covers the same allow-vs-reality checks.** The free [Cisco ASA Field Reference PDF](https://www.pinglabz.com/cisco-asa-cheat-sheet/#pdf-asa-field-reference) puts the packet pipeline, NAT order, capture commands and a troubleshooting decision tree on nine printable pages. [PingLabz Pro](https://www.pinglabz.com/membership/?plz%5Fplacement=pricing:fmc-prefilter-policy-fastpath:mid:v1) unlocks all 68 browser labs, 500 CCNA practice questions and two timed mock exams for $59/year or $7.99/month. Coming soon · planned price $19 ASA Firewall Field Kit A troubleshooting runbook for packet flow, packet-tracer, captures, asp-drop, NAT, failover and IPsec, plus the ASAv Containerlab topologies from the PingLabz ASA labs. It isn't built yet. [See what's planned and join the waitlist](https://www.pinglabz.com/cisco-asa-field-kit/) ## Verification checklist - Confirm the block works before adding prefilter: client-b fails on both ports, while client-a succeeds only on 80. - Check the ACP's assigned prefilter policy, save it and verify deployment success. - During the fault, correlate HTTP 200 results with advanced trust, the prefilter rule ID, no SNORT phase, and Fastpath event actions. - Read ACL order and last-hit times alongside counters; do not interpret cumulative hits as fresh sessions. - After Analyze, confirm the message sending the packet to Snort and the final Block-Client-B verdict, rather than stopping at ACCESS-LIST ALLOW. - Repeat all four client/port tests and compare the newest event rows with the expected matrix. - If restoring this fixture, remove the temporary block too; restored client-b access on 80 is then expected. ## Related firewall labs - [Register FTDv to FMC](https://www.pinglabz.com/register-ftd-to-fmc-containerlab/) — Bring up management and diagnose a registration-key mismatch. - [FTD static route to a dead next hop](https://www.pinglabz.com/ftd-static-route-fmc-next-hop/) — Follow the routed path before blaming access control. - [FTD packet-tracer allows, but capture shows no SYN-ACK](https://www.pinglabz.com/ftd-packet-tracer-capture-fmc/) — Compare a simulated allow with real packet evidence. - [FMC deployment history and rollback](https://www.pinglabz.com/fmc-deployment-history-rollback/) — Follow policy changes through deployment history. - [FTD access control policy with FDM](https://www.pinglabz.com/ftd-access-control-policy-fdm-packet-tracer/) — Read LINA drops and Snort verdicts in a locally managed lab. - [Cisco ASA packet-tracer](https://www.pinglabz.com/cisco-asa-packet-tracer/) — Review command syntax and the meaning of processing phases. - [FTD NAT in FMC: Auto NAT vs Manual NAT](https://www.pinglabz.com/ftd-nat-fmc-rule-order/) — A broad PAT rule in NAT Rules Before changes a static-NAT server's outbound source. - [Cisco FTD twice NAT in FMC](https://www.pinglabz.com/ftd-twice-nat-fmc/) — Swapped Original and Translated Destination objects break both the old and new partner addresses. ## FAQ ### Does an FMC prefilter Fastpath rule bypass the access control policy? For the matching flows in this lab, yes. Fastpath-Backup-Net compiled as advanced trust before the ACP entries. Client-b reached the server despite Block-Client-B, and the trace had no ACP/Snort verdict. Changing that same rule to Analyze restored enforcement. ### What is the difference between prefilter Fastpath and Analyze? Fastpath forwarded these matching flows without Snort inspection. Analyze handed them onward for a verdict: client-b matched the ACP block, while client-a's port 80 flow matched Allow-Web. Analyze's initial ALLOW did not guarantee final access. ### Why does Fastpath-Backup-Net still appear in events after the fix? The rule retained its name and network conditions, but its action changed to Analyze. New rows showed ACP Allow or Block actions alongside that prefilter rule name. Check the action and ACP rule columns as well as the prefilter column. ### Does a missing SNORT phase prove Fastpath caused the result? Not by itself. The baseline client-b block also ended before a SNORT phase, at an ACCESS-LIST drop. In the fault, the evidence was the combination of advanced trust, the named prefilter rule, an allow verdict, live connection details and successful HTTP tests.