An organization has a security policy that requires all outbound HTTP traffic from the 'Corporate' zone to the 'Internet' zone to be inspected by the URL Filtering profile. However, the administrator notices that some users can still access blocked categories. What is the most likely cause?
Trap 1: The firewall is configured to use DNS sinkholing, which bypasses…
DNS sinkholing rewrites DNS responses to redirect malicious domains; it does not intercept HTTP sessions, so URL Filtering still applies to permitted traffic. It is tempting because sinkholing also blocks access, but it operates at the DNS resolution layer, not the HTTP inspection layer the policy requires.
Trap 2: The rule is placed too low in the rulebase and a higher rule allows…
Palo Alto evaluates rules top-down and stops at the first match, so a permissive rule above the URL Filtering rule lets that traffic through uninspected. Administrators assume rule order is irrelevant once the profile exists; reordering would be the fix, but the stem's symptom points to precedence, not placement.
Trap 3: The rule uses a source zone of 'Corporate' but the users are in a…
If users sit in a different zone, the rule's source zone match fails entirely, so no URL Filtering profile is applied to their sessions. It is tempting because zone mismatches do cause policy misses, but the stem specifies outbound Corporate-to-Internet traffic, implying zone matching is already correct.
- A
The firewall is configured to use DNS sinkholing, which bypasses URL filtering.
Why it fails: DNS sinkholing rewrites DNS responses to redirect malicious domains; it does not intercept HTTP sessions, so URL Filtering still applies to permitted traffic. It is tempting because sinkholing also blocks access, but it operates at the DNS resolution layer, not the HTTP inspection layer the policy requires.
- B
The rule is placed too low in the rulebase and a higher rule allows traffic without URL filtering.
Why it fails: Palo Alto evaluates rules top-down and stops at the first match, so a permissive rule above the URL Filtering rule lets that traffic through uninspected. Administrators assume rule order is irrelevant once the profile exists; reordering would be the fix, but the stem's symptom points to precedence, not placement.
- C
The rule uses a source zone of 'Corporate' but the users are in a different zone.
Why it fails: If users sit in a different zone, the rule's source zone match fails entirely, so no URL Filtering profile is applied to their sessions. It is tempting because zone mismatches do cause policy misses, but the stem specifies outbound Corporate-to-Internet traffic, implying zone matching is already correct.
- D
The URL Filtering profile is set to 'alert' instead of 'block' for the relevant categories.
An 'alert' action logs and allows matching URL categories, so traffic still reaches blocked sites. Setting the profile to 'block' for those categories enforces the policy, denying outbound HTTP from Corporate to Internet as intended.