An FTD access control policy has rule 3 allowing any internal network to any destination over HTTPS, and rule 9 blocking HTTPS from the Guest network to a known malicious subnet. Guests still reach that subnet. What is the fix?
Select an answer to reveal the explanation.
Short Explanation
Firewall rules are like a line at a coffee shop: whoever's at the front gets served first. A broad allow sitting at rule 3 serves the guest traffic before your block at rule 9 ever gets a look. Specific rules go on top, broad rules go below.
Full Explanation
Access control rules on FTD are evaluated from top to bottom, and the first rule whose conditions match a connection decides its action; later rules are not consulted. Guest traffic to the malicious subnet over HTTPS matches the broad allow rule because the Guest network is part of any internal network, so the specific block rule further down never fires. Moving the narrow block rule above the broad allow, or narrowing the allow, restores the intended behavior. Changing the action to block with reset only changes how a matched connection is terminated, by sending a reset instead of silently dropping; it does not change which rule matches first. Intrusion policies cannot be attached to block rules, and even on an allow rule they apply only to traffic that the rule itself matches, so they cannot reach back and influence an earlier rule. Logging records matches and helps with diagnosis, but it has no effect on evaluation order. Exam caveat: the management center can flag rules that are shadowed by earlier rules, and that warning is a strong hint of this exact error. Operational check: reorder the rules, deploy, generate a test connection from a Guest host to the subnet, and confirm in connection events that it now matches the block rule rather than the broad allow.