> ## 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. # FTD File Policy in FMC: Why ZIP Downloads Pass Until It's Attached - URL: https://www.pinglabz.com/ftd-file-policy-fmc/ - Published: 2026-10-20T19:46:13.000Z - Updated: 2026-10-20T20:10:54.000Z - Description: A ZIP block policy existed in FMC, but Allow-Web did not use it. This home lab follows the full download, empty File Events, policy attachment, and verified ZIP resets while PDF and TXT stayed intact. - Author: Jaime - Tags: Firewall, Security, Troubleshooting, Cisco, Network Security ![FTD file policy in FMC not attached: Allow-Web has File Policy None, the ZIP downloads with a matching SHA-256 and File Events shows No Records](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/ftd-file-policy-fmc-topology.png) The ZIP downloaded in full. Its SHA-256 matched the server copy, curl exited successfully, and FMC File Events showed **No Records**. Yet PL-File-Block already existed in FMC with a rule to block ZIP downloads. The missing setting was on Allow-Web: **File Policy None**. Creating the file policy under **Malware & File** had saved its instructions without making the matching access control rule use them. Attaching PL-File-Block to that rule and deploying reset both ZIP attempts. PDF and TXT downloads still completed with matching hashes. This Cisco FTD file policy lab was built in my home lab with FMCv 10.0.1 build 1, FTDv 10.0.0 build 140, and an IOL router in Containerlab. FTD used Snort 3.9.3.1-61\. It is a nested home lab, not a supported production deployment; the results below describe the recorded October 20, 2026 run. ## Topology and addressing The data path is client-a → FTD inside → FTD outside → r-core → web-srv. Client-a connects directly to FTD inside. FMC manages FTD over a separate management tunnel and is outside the HTTP forwarding path. | Node or interface | Address | Role | | ------------------ | -------------------------- | ------------------------------------------------ | | client-a eth1 | 10.42.10.21/24 | Inside client; server subnet through 10.42.10.1 | | FTD Ethernet0/0 | 10.42.10.1/24 | inside; security zone PL-INSIDE | | FTD Ethernet0/1 | 10.42.20.1/29 | outside; security zone PL-OUTSIDE | | r-core Ethernet0/1 | 10.42.20.2/29 | Transit toward FTD | | r-core Ethernet0/2 | 10.42.30.1/24 | Server LAN gateway | | web-srv eth1 | 10.42.30.80/24 | HTTP on TCP/80; client subnet through 10.42.30.1 | | FMCv | Management tunnel endpoint | Configuration, deployment, and events | FTD routes 10.42.30.0/24 through 10.42.20.2 outside. The router's startup configuration includes the return route for 10.42.10.0/24 through 10.42.20.1\. No NAT policy is assigned, so the server sees the original client address. A missing return path is a separate fault, covered in the [FTD static-route next-hop lab](https://www.pinglabz.com/ftd-static-route-fmc-next-hop/). Registration is already complete here; [registering FTDv to FMC](https://www.pinglabz.com/register-ftd-to-fmc-containerlab/) covers that step. The earlier [FTDv bootstrap with FDM](https://www.pinglabz.com/ftdv-fdm-containerlab-bootstrap/) uses local management and is a separate setup. I generated three harmless files for this test: a ZIP containing text, a minimal PDF with harmless padding, and a text file. There was no malware, EICAR, or external test payload. The server served them under /files/. | File | Server size | Purpose | | ------------ | ------------ | ------------------------------------ | | pl-notes.zip | 64,171 bytes | Type selected for blocking | | pl-notes.pdf | 11,619 bytes | File type absent from the block rule | | pl-notes.txt | 64,049 bytes | Additional download control | ## Where an FMC file policy takes effect: the Allow rule An access control policy, or ACP, decides which rule handles the connection. Here PL-Edge-ACP has an enabled Allow-Web rule for PL-INSIDE → PL-OUTSIDE, destination 10.42.30.80, HTTP on TCP/80\. Its action is Allow, with end-of-connection logging to FMC. The default ACP action is Block All Traffic. The file policy hangs off that Allow rule. Once the connection matches, the attached policy supplies the file inspection and blocking instructions. The policy name appearing under Malware & File does not establish that association. A saved ZIP block rule can remain unused while the ACP continues to allow the transfer. If the policy is attached and the transfer still passes, check the file rule itself: [an FTP-scoped ZIP rule let HTTP downloads finish](https://www.pinglabz.com/fmc-file-policy-protocol-mismatch/). If you are looking for an **Inspection** tab, this build needs a small navigation correction: the native FMC 10.0.1 rule editor used here exposes **Intrusion Policy** and **File Policy** directly in the rule panel. There was no separate Inspection tab in this run. [Cisco's 10.x procedure](https://www.cisco.com/c/en/us/td/docs/security/secure-firewall/management-center/device-config/100/management-center-device-config-10-0/advanced-access-file.html?ref=pinglabz.com) marks the **Inspection** step as legacy UI only. Before testing, Allow-Web still referenced PL-IPS-Lab from the previous intrusion lab. I cleared that attachment and left **Intrusion Policy None in both runs**, so the file-policy comparison stood on its own. That matters when comparing this result with [Snort 3 Detection mode in an FMC intrusion policy](https://www.pinglabz.com/fmc-intrusion-policy-snort3-detection/). There, the policy was attached and a Block rule logged Would block because the policy was in Detection. Here, the file policy was never attached during the fault. Changing an intrusion inspection mode would not repair the missing file-policy association. ## License and file-rule settings The evaluation license had 88 days remaining. The device page showed **IPS Yes**, **Malware Defense No**, and Snort 3\. Basic Block Files saved, deployed, and blocked the ZIP with that state. ![Device settings show IPS Yes, Malware Defense No, and the Snort 3 inspection engine.](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/ftd-file-policy-fmc-shot-16-device-ips-license.png) Device settings show IPS Yes, Malware Defense No, and the Snort 3 inspection engine. There is an easy label trap: the registration wizard's Includes column calls Malware Defense “File Policy.” In this lab, that wording did not mean Malware Defense had to be enabled for the Block Files action. The observed gate was satisfied with IPS enabled. Cisco's 10.x license table matches: blocking files by type needs the IPS license, and Malware Defense is required only for Malware Cloud Lookup, Block Malware and stored files ([FMC file policy licensing](https://www.cisco.com/c/en/us/td/docs/security/secure-firewall/management-center/device-config/100/management-center-device-config-10-0/advanced-access-file.html?ref=pinglabz.com)). This run does not establish licensing or behavior for cloud malware lookup or malware analysis; neither was tested. To create the rule in this build, I used **Policies > Security policies > Malware & File > New File Policy**, named it PL-File-Block, saved it, and added one rule: | Setting | Value used | | --------------------- | --------------------------------------------- | | Application Protocol | HTTP | | Direction of Transfer | Download | | Selected type | ZIP (PKZIP archive file) | | Action | Block Files | | Reset Connection | Checked by default after choosing Block Files | | Store files | Unchecked | ![The file rule selects HTTP Download and ZIP only, with Block Files and Reset Connection checked.](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/ftd-file-policy-fmc-shot-07-file-rule-editor.png) The file rule selects HTTP Download and ZIP only, with Block Files and Reset Connection checked. ZIP was an individual selected type within Archive; I did not select the whole category. PDF was absent from the selection. This is a content-type selection, rather than a filename-extension filter. The tests used the original generated files and names; I did not run extension-renaming tests or test other archive formats. After saving, FMC displayed the action as **Block Files with Reset**. It also supplied the clue that explained the fault: **No access control policies use this Malware & File policy**. ![PL-File-Block contains ZIP HTTP Download with Block Files with Reset, and FMC says no access control policies use it.](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/ftd-file-policy-fmc-shot-08-unused-file-policy.png) PL-File-Block contains ZIP HTTP Download with Block Files with Reset, and FMC says no access control policies use it. ## Fault: Allow-Web still has File Policy None I saved and deployed the baseline with the file policy unattached. Allow-Web remained enabled, matched the server's HTTP service, and had both Intrusion Policy None and File Policy None. Its Log Files control was disabled and unchecked; end logging to FMC remained enabled. ![Faulted Allow-Web has Intrusion Policy None and File Policy None for the HTTP destination 10.42.30.80.](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/ftd-file-policy-fmc-shot-18-fault-policy-none.png) Faulted Allow-Web has Intrusion Policy None and File Policy None for the HTTP destination 10.42.30.80. From client-a, I requested ZIP, PDF, and TXT in that order. These are the actual curl summaries, byte counts, and SHA-256 results. Whole intervening lines have been omitted. Each request used curl with a 12-second limit, a separate output filename, and a summary containing the HTTP code, downloaded size, elapsed time, and local address and port. Afterward, the client checked the saved file's byte count and SHA-256\. The server hashes were collected separately. That gives the comparison two ends: what the server offered and what the client actually saved. The local ports below belong to the real connections, rather than values supplied to a simulation. Keep them with the results when checking FMC: a different Allow event to the same server can belong to a control download or Packet Tracer. The fault downloads ran around 18:05:30–18:05:32 UTC, after the baseline deployment completed. ```text HTTP=200 size=64171 total=0.038838 local=10.42.10.21:36638 curl_exit=0 64171 /tmp/pl-fault-0.zip 2a4fc48caff1f73d34d4d13a06082dd7826b6d8c2f54db70bcc7bb7cf92348a7 /tmp/pl-fault-0.zip ... HTTP=200 size=11619 total=0.011389 local=10.42.10.21:36652 curl_exit=0 11619 /tmp/pl-fault-1.pdf 592bd5ff730cc6a53fde6518ba4d091597bb6120ed549e2549419bb71258ee57 /tmp/pl-fault-1.pdf ... HTTP=200 size=64049 total=0.010742 local=10.42.10.21:36664 curl_exit=0 64049 /tmp/pl-fault-2.txt 41a5845b43970307edc691bf5e150782355826ec6e664328808f931e6fe74b85 /tmp/pl-fault-2.txt ``` All three returned 200 with curl exit 0, the expected full size, and a matching server hash. The server-side reference hashes were: ```text 2a4fc48caff1f73d34d4d13a06082dd7826b6d8c2f54db70bcc7bb7cf92348a7 /srv/www/files/pl-notes.zip 592bd5ff730cc6a53fde6518ba4d091597bb6120ed549e2549419bb71258ee57 /srv/www/files/pl-notes.pdf 41a5845b43970307edc691bf5e150782355826ec6e664328808f931e6fe74b85 /srv/www/files/pl-notes.txt ``` This is stronger evidence than a browser appearing to finish. For the ZIP, the client received all 64,171 bytes and the same SHA-256 as the source. The block rule had not interrupted delivery. In **Events & Logs > Analysis > Unified Events**, the real ZIP connection used source port 36638\. Its expanded details showed Allow, Allow-Web, PL-Edge-ACP, Files 0, Intrusion Events 0, and HTTP Response Code 200\. The URL identified /files/pl-notes.zip. Under **Events & Logs > Files > File Events**, File Summary showed No Records. The visible time window included the fault downloads. ![File Events File Summary shows No Records in a time window covering the fault downloads.](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/ftd-file-policy-fmc-shot-26-fault-file-events-empty.png) File Events File Summary shows No Records in a time window covering the fault downloads. An empty event view alone would leave several questions open. Here it sits beside a full client download, the matching ACP rule, and an explicitly empty File Policy selector. Together they point to the missing association without requiring a change to the file rule itself. The device's deployed access-control readback also showed file logging disabled for Allow-Web. This excerpt comes from FTD's show access-control-config output: ```text ----------------[ Rule: Allow-Web ]----------------- Action : Allow Source ISE Metadata : Dest ISE Metadata : Source Zones : PL-INSIDE Destination Zones : PL-OUTSIDE Destination Networks : 10.42.30.80 Destination Ports : HTTP (protocol 6, port 80) Users Logging Configuration DC : Enabled Beginning : Disabled End : Enabled Files : Disabled Safe Search : No Rule Hits : 0 Variable Set : Default-Set ``` ## Fix: attach PL-File-Block and deploy I opened **Policies > Security policies > Access Control > PL-Edge-ACP**, then double-clicked Allow-Web. In the File Policy selector I chose PL-File-Block, leaving Intrusion Policy None. ![FTD file policy attached in FMC: the ZIP GET reaches web-srv but FTD resets the transfer with 0 body bytes, while the PDF and TXT still download](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/ftd-file-policy-fmc-fig2.png) ![Allow-Web now has a selected file policy; the label is clipped in the selector, and Intrusion Policy remains None.](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/ftd-file-policy-fmc-shot-30-fixed-policy-attached.png) Allow-Web now has a selected file policy; the label is clipped in the selector, and Intrusion Policy remains None. Selecting the policy automatically checked **Log Files**. I checked the logging popover: Log Files, Log at end of connection, and Firewall Management Center were all checked. Then I applied the rule, saved the ACP, and used **Deploy > Advanced Deploy** to deploy the device. The deployment reached Completed before the fixed downloads began. ![The deployment view shows Completed for the FTD device after the file-policy attachment was deployed.](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/ftd-file-policy-fmc-shot-34-fixed-deploy-success.png) The deployment view shows Completed for the FTD device after the file-policy attachment was deployed. Saving the rule and deploying it are separate steps. A correct selection in FMC describes the intended configuration; the completed deployment and the device readback establish what was sent to FTD. [FMC deployment history and rollback](https://www.pinglabz.com/fmc-deployment-history-rollback/) covers that distinction in more detail. The file-policy editor now reported **Used by 1 access control policy**. FTD's readback named PL-File-Block under Allow-Web and changed Files from Disabled to Enabled: ```text ----------------[ Rule: Allow-Web ]----------------- Action : Allow Source ISE Metadata : Dest ISE Metadata : Source Zones : PL-INSIDE Destination Zones : PL-OUTSIDE Destination Networks : 10.42.30.80 Destination Ports : HTTP (protocol 6, port 80) Users Logging Configuration DC : Enabled Beginning : Disabled End : Enabled Files : Enabled Safe Search : No Rule Hits : 0 File Policy : PL-File-Block Variable Set : Default-Set ``` Between the two tests, I did not change the file rule, files, interfaces, routes, NAT assignment, or intrusion policy. The repair was the association between Allow-Web and the existing file policy, followed by deployment; file logging came on with that attachment. ## Fixed downloads: ZIP resets, PDF and TXT pass The first fixed ZIP request used source port 52492\. Curl recorded HTTP 200 but zero downloaded body bytes, then reported a reset: ```text HTTP=200 size=0 total=0.029595 local=10.42.10.21:52492 curl: (56) Recv failure: Connection reset by peer curl_exit=56 wc: /tmp/pl-fixed-0.zip: No such file or directory sha256sum: can't open '/tmp/pl-fixed-0.zip': No such file or directory ``` Curl's result was **curl\_exit=56**. No ZIP output file existed afterward. The byte-count and hash checks failed because there was no file to inspect; this was not a saved zero-byte ZIP with a hash. The surrounding collection's shell exit 1 came from those follow-up checks, not from curl's own exit status. The controls still worked. PDF and TXT returned their full sizes and exactly the same hashes as before: ```text HTTP=200 size=11619 total=0.008346 local=10.42.10.21:52506 curl_exit=0 11619 /tmp/pl-fixed-1.pdf 592bd5ff730cc6a53fde6518ba4d091597bb6120ed549e2549419bb71258ee57 /tmp/pl-fixed-1.pdf ... HTTP=200 size=64049 total=0.231823 local=10.42.10.21:52520 curl_exit=0 64049 /tmp/pl-fixed-2.txt 41a5845b43970307edc691bf5e150782355826ec6e664328808f931e6fe74b85 /tmp/pl-fixed-2.txt ``` That comparison matters. A broken route or stopped HTTP listener would not explain the selected ZIP failing while the two control transfers completed through the same Allow-Web rule. PDF was absent from the ZIP-only block rule, and it passed in the measured test. A second ZIP request used a new connection, source port 57184, and also failed: ```text HTTP=200 size=0 total=0.009531 local=10.42.10.21:57184 curl_exit=56 curl: (56) Recv failure: Connection reset by peer wc: /tmp/pl-fixed-3.zip: No such file or directory sha256sum: can't open '/tmp/pl-fixed-3.zip': No such file or directory ``` The fixed state therefore blocked two actual ZIP attempts. Neither produced a downloaded ZIP to hash. ## HTTP 200 does not prove a completed download The fixed requests received the HTTP response headers before the connection reset. A 200 status says the server supplied a successful response status; it does not establish how much response body reached the client or whether the transfer completed. The server capture makes the sequence visible. This excerpt from the fixed capture decode shows the first ZIP GET, the server's 200 response and body data, then the reset. The last line is the reset for the repeat ZIP connection: ```text 2026-10-20 18:11:16.968411 IP 10.42.10.21.52492 > 10.42.30.80.80: Flags [P.], seq 1:94, ack 1, win 56, options [nop,nop,TS val 726802218 ecr 2645199931], length 93: HTTP: GET /files/pl-notes.zip HTTP/1.1 ... 2026-10-20 18:11:16.970481 IP 10.42.30.80.80 > 10.42.10.21.52492: Flags [P.], seq 1:195, ack 94, win 56, options [nop,nop,TS val 2645199942 ecr 726802218], length 194: HTTP: HTTP/1.0 200 OK 2026-10-20 18:11:16.971321 IP 10.42.30.80.80 > 10.42.10.21.52492: Flags [.], seq 195:1563, ack 94, win 56, options [nop,nop,TS val 2645199943 ecr 726802218], length 1368: HTTP ... 2026-10-20 18:11:16.980733 IP 10.42.10.21.52492 > 10.42.30.80.80: Flags [R.], seq 94, ack 1563, win 0, length 0 ... 2026-10-20 18:11:19.996240 IP 10.42.10.21.57184 > 10.42.30.80.80: Flags [R.], seq 94, ack 1563, win 0, length 0 ``` The capture point was web-srv eth1\. It saw the GET arrive and response bytes leave the server. The RSTs appear **from the client address**, 10.42.10.21, toward the server for both ZIP connection tuples. That is exactly what the server-side pcap shows; it does not show a reset sourced from an FTD interface address. Server-side transmission does not prove those bytes reached curl. The client results and FMC file-block events establish the blocked outcome. Likewise, the server access log recorded 200 for the ZIP requests even when the response was blocked. Counting those log entries as successful downloads would have reversed the result. The capture recorded 169 packets with zero kernel drops. This was a server capture, with no temporary capture installed on FTD. The separate [FTD Packet Tracer and capture lab](https://www.pinglabz.com/ftd-packet-tracer-capture-fmc/) uses another failure to show why the capture location matters. ## FTD file events after attachment File Summary now showed **Category Archive**, **Type ZIP**, **Action Block**, and **Count 1**. Disposition was blank. There was no malware verdict to report or infer from that empty field. ![File Summary shows Category Archive, Type ZIP, blank Disposition, Action Block, and Count 1.](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/ftd-file-policy-fmc-shot-35-fixed-file-events-summary.png) File Summary shows Category Archive, Type ZIP, blank Disposition, Action Block, and Count 1. The expanded File event in Unified Events named PL-File-Block and pl-notes.zip, with File Type ZIP and Category Archive. Its direction was server 10.42.30.80:80 → client 10.42.10.21:52492, matching a download response. To follow the same evidence in FMC, open Unified Events, select Last 1 hour, refresh, and expand the relevant row. Check Event Type before interpreting its direction: the File row describes the downloaded response, while the associated Connection row identifies the client-initiated connection. For the first fixed attempt, client port 52492 joins those views to the curl result and server capture. File Summary supplies the aggregate count; the expanded rows supply the policy, filename, and connection reason. The connection records explained both attempts: | ZIP attempt | Client source port | Connection action | Reason | Files | | ----------- | ------------------ | ----------------- | ----------------- | ----- | | First | 52492 | Block | File Block | 1 | | Repeat | 57184 | Block | File Resume Block | 0 | ![The repeated ZIP connection is Block with reason File Resume Block, source port 57184, and Files 0.](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/ftd-file-policy-fmc-shot-42-fixed-resume-block.png) The repeated ZIP connection is Block with reason File Resume Block, source port 57184, and Files 0. There was **one File event for two blocked attempts**. The second connection's Files 0 did not mean the repeat download succeeded: its reason was File Resume Block, and curl independently reported a reset with zero body bytes. Read that counter with the event type, action, reason, and connection tuple. That pattern fits [Cisco's HTTP note](https://www.cisco.com/c/en/us/td/docs/security/secure-firewall/management-center/device-config/100/management-center-device-config-10-0/advanced-access-file.html?ref=pinglabz.com): Block Files rules block new HTTP sessions for the same file, URL, server and client application for 24 hours after the first attempt. Unified Events displayed UTC−4 while the command collections and pcap timestamps used UTC. The first fixed ZIP appears around 14:11:16 in FMC and 18:11:16 in the capture. Account for that offset before matching events to packets. ## Why FTD Packet Tracer allowed both stages CLI and GUI Packet Tracer both allowed the simulated TCP flow before and after attachment. They matched Allow-Web in the SNORT firewall phase. Those simulations carried no HTTP response or ZIP payload, so they did not exercise the file-control decision made during the real download. Here is the fixed diagnostic CLI trace, trimmed to the command, payload classification, and final result: ```text > packet-tracer input inside tcp 10.42.10.21 40803 10.42.30.80 80 detail packet-tracer input inside tcp 10.42.10.21 40803 10.42.30.80 80 detail ... service: (0), client: (0), payload: (0), misc: (0) ... Result: input-interface: inside(vrfid:0) input-status: up input-line-status: up output-interface: outside(vrfid:0) output-status: up output-line-status: up Action: allow ``` The simulations also used different source ports from curl: CLI 40801 and GUI 40802 during the fault, then CLI 40803 and GUI 40804 after the fix. Their allowed connection events must not be mistaken for successful ZIP transfers. The [ASA Packet Tracer walkthrough](https://www.pinglabz.com/cisco-asa-packet-tracer/) introduces the phase-by-phase approach, and the [FTD access control lab with FDM](https://www.pinglabz.com/ftd-access-control-policy-fdm-packet-tracer/) compares access-list and Snort decisions. In this FMC run, the final allow verdict answered the simulated packet question. Actual file delivery still needed the payload test. Other FMC faults sit at different points in the path: [prefilter Fastpath](https://www.pinglabz.com/fmc-prefilter-policy-fastpath/) skips the ACP, while [FTD NAT rule order](https://www.pinglabz.com/ftd-nat-fmc-rule-order/) and [twice NAT destination objects](https://www.pinglabz.com/ftd-twice-nat-fmc/) concern translation. This run had no NAT assignment and used Default Prefilter Policy; the observed repair was attaching the file policy. One scope note: FMC device health was red before cleanup despite connected, deployed, working traffic; the health-module cause was not established. 💡 **Running ASA instead of FTD? The packet-tracer and capture checks carry over; the file policy does not.** 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:ftd-file-policy-fmc: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 real connection matches the intended ACP Allow rule, destination, zones, and HTTP service. - Open that rule's File Policy selector. A policy listed under Malware & File can still be unused. - Check the observed license state; this run used IPS Yes and Malware Defense No for Block Files. - Verify HTTP, Download, ZIP only, and the saved action Block Files with Reset. - Check Log Files and the FMC logging destination after attachment. - Apply, save, deploy, wait for Completed, and read back the deployed rule. - Download the blocked file and allowed controls. Compare curl exit status, body size, and hashes for completed files. - Correlate File Events and connection reasons with the actual client ports and the display time zone. - Treat HTTP 200, server-side response packets, and a Packet Tracer allow as partial evidence; verify client delivery. ## Related firewall labs - [Register FTDv to FMC](https://www.pinglabz.com/register-ftd-to-fmc-containerlab/) — A registration-key mismatch with a reachable management path. - [FMC intrusion policy and Snort 3 Detection](https://www.pinglabz.com/fmc-intrusion-policy-snort3-detection/) — An attached Block rule logs Would block in Detection mode. - [FMC prefilter Fastpath](https://www.pinglabz.com/fmc-prefilter-policy-fastpath/) — Follow traffic that skips the ACP. - [FTD Packet Tracer and capture in FMC](https://www.pinglabz.com/ftd-packet-tracer-capture-fmc/) — An allowed simulation beside a capture with no SYN-ACK. - [FMC deployment history and rollback](https://www.pinglabz.com/fmc-deployment-history-rollback/) — Trace deployed policy changes and rollback. - [FMC file policy protocol mismatch](https://www.pinglabz.com/fmc-file-policy-protocol-mismatch/) — An attached ZIP rule scoped to FTP let HTTP downloads finish until the rule used HTTP. - [FTD NAT rule order in FMC](https://www.pinglabz.com/ftd-nat-fmc-rule-order/) — See broad manual PAT take an outbound flow before static Auto NAT. - [Cisco FTD twice NAT in FMC](https://www.pinglabz.com/ftd-twice-nat-fmc/) — Swapped Original and Translated Destination objects break both partner addresses. - [FTD transparent mode in FMC](https://www.pinglabz.com/ftd-transparent-mode-fmc/) — One bridge member in the wrong security zone let ARP pass while ping and HTTP hit the default block. ## FAQ ### Why is my FMC file policy not working even though it blocks ZIP? In this lab, the matching Allow-Web rule had File Policy None. PL-File-Block existed but was unused. Attaching it to Allow-Web and deploying changed the result from a complete, hash-matching ZIP download to a reset with zero downloaded body bytes. ### Does FMC Block Files need a Malware Defense license? No. [Cisco lists IPS](https://www.cisco.com/c/en/us/td/docs/security/secure-firewall/management-center/device-config/100/management-center-device-config-10-0/advanced-access-file.html?ref=pinglabz.com) for Block Files and Block with Reset by file type. This device showed IPS Yes and Malware Defense No, and the ZIP block worked. Malware lookup and analysis were outside the test. ### Why does the blocked ZIP still show HTTP 200? Curl received the response headers before the reset. Both fixed ZIP requests recorded HTTP 200, curl exit 56, zero downloaded body bytes, and no output file. A status code alone cannot establish a completed download. ### What does File Resume Block mean in FMC? In this lab it was the reason on the repeat ZIP connection: Block, File Resume Block, Files 0, while the first attempt logged File Block with Files 1 and the only File event. Cisco documents that Block Files rules block new HTTP sessions for the same file, URL, server and client application for 24 hours after the first attempt ([Cisco](https://www.cisco.com/c/en/us/td/docs/security/secure-firewall/management-center/device-config/100/management-center-device-config-10-0/advanced-access-file.html?ref=pinglabz.com)), which fits a blocked repeat without a second File event. Both curls failed.