A retail payments team enables an intrusion policy that blocks connections on the access control rule allowing traffic to the card processing tier. Within the hour, users report that sessions stop mid-transfer, and connection events show the flows blocked by the firewall even though the access control rule permits the subnet. Which statement explains how that block is enforced across the Threat Defense engines?

One Threat Defense image runs two engines, and the hand-off between them defines enforcement. The Lina engine handles ingress, routing, address translation, prefiltering and connection state, while the Snort engine evaluates the access control rules; when the matching rule calls for intrusion inspection, inspectors normalize traffic and the rules produce a permit or block result. Snort returns that verdict, and the Lina engine drops or forwards the packets accordingly, so a blocked session appears as a firewall drop while the access control rule still permits the subnet. Placing the intrusion rule inside the Lina engine misreads the division of labor, because Lina runs network processing and state, not intrusion rules. Letting Snort drop packets on the wire assumes Snort sits inline, but the inspection process only returns verdicts and never forwards packets. Pushing the block as an access control entry misrepresents deployment, because the Management Center builds access control and intrusion policy separately, so an intrusion action never becomes an ACL line. Exam caveat: the on-wire behavior depends on the configured rule action, so do not memorize whether the channel ends in a reset or a silent drop. Practical check: open the connection event and confirm the blocking intrusion rule while the access control rule still shows permit.