FTD access control rules are evaluated from top to bottom, first match wins. To allow an exception within a blocked range, the specific permit rule must be placed *before* the general block rule. If the block rule is first, it will match and deny the server’s traffic before the permit rule is ever evaluated.

For inbound decryption (to servers you manage), the ‘Decrypt – Known Key’ action is used. This requires the FTD device to possess the web server’s certificate and private key. The FTD uses this ‘known key’ to decrypt the traffic passively, acting as a man-in-the-middle with prior knowledge of the server’s secret.

A ‘Malware Cloud Lookup Timeout’ means the file was sent for advanced analysis (Dynamic Analysis or Retrospective Security Intelligence), but a verdict was not returned before the configured file policy timeout. This doesn’t mean the file is bad or good. The administrator should review the file locally or adjust the ‘Blocking with Cloud Lookup Timeout’ setting in the file policy.

The rule state ‘Drop and Generate Events’ is a performance-optimized state. It allows the Snort engine to use a faster method to block the traffic matching the rule’s pattern without performing the full, resource-intensive inspection required by the ‘Generate Events’ state. This maintains the security benefit (blocking) while reducing CPU load.

The failover link is critical for stateful failover. It is used to synchronize configuration, operating system updates, and most importantly, state information (like TCP session tables, NAT translations, and VPN tunnels) from the active unit to the standby unit. This allows the standby to seamlessly take over with minimal disruption to existing connections.

By default, access control rules log only at the end of a session. To see when an SSH session starts (a connection event), you must explicitly configure the rule to ‘Log at Beginning of Connection’. This is crucial for auditing initial login attempts to critical infrastructure.

Security intelligence whitelists (or Do Not Block lists) are designed for this exact scenario. You can add a specific domain, URL, or IP address to a whitelist, and the system will skip the security intelligence check for that item, allowing it to be evaluated by the subsequent access control or intrusion policies. This is more precise than a broad access rule.

The symptom (encrypted out, no decrypted in) points to an asymmetric failure in the IKEv2/IPsec Phase 2 negotiation. The proxy IDs define which traffic is protected by the tunnel. If the peer’s proxy ID (e.g., its local network definition) does not match what the FTD expects, the peer will encrypt traffic but the FTD will drop it because it doesn’t match its security association, and vice-versa.

Prefilter policies handle traffic before it reaches the main access control policy. A ‘Fast-Path’ rule is a hard bypass—traffic matching this rule skips ALL subsequent layers (Access Control, IPS, Malware, etc.). A ‘Monitor-Only’ rule forwards the traffic to the Access Control Policy and beyond for full inspection and potential logging, but the prefilter policy itself will not block it, allowing you to analyze tunneled traffic.

FTD access control rules are evaluated from top to bottom, first match wins. To allow an exception within a blocked range, the specific permit rule must be placed *before* the general block rule. If the block rule is first, it will match and deny the server’s traffic before the permit rule is ever evaluated.0