A web client times out and a packet capture on the egress interface of a Secure Firewall Threat Defense device shows nothing. The access control rule allows the traffic, and an inline intrusion policy attached to that rule logged an event just before the failure. Which factor in the Snort and Lina processing path explains where the packet was stopped?

Threat Defense processes packets using both the Lina engine and Snort. Lina performs initial packet processing, and traffic subject to inline inspection is passed to Snort for access control and intrusion inspection. Snort returns a verdict, and Lina applies it before forwarding or dropping the packet. That ordering explains your empty capture: the packet reached Snort, Snort rejected it, and Lina dropped it before egress, so nothing reached the capture point. Reversing the order misstates the pipeline, because Snort does not run ahead of Lina's initial processing. The claim that Lina rejected it before handing traffic to Snort conflicts with the logged intrusion event for this traffic. The mirrored-copy model describes monitor or tap deployment, where a copy is inspected for alerts only, but your intrusion policy was attached inline, so the drop verdict stops forwarding. An allow action in the access control rule does not override an inline intrusion drop. Practical check: compare the event timestamp with the egress interface counters and confirm the intrusion policy is set to inline for that rule.