Global policy blocks a VS7 local permit
A managed security service provider runs a Multi-Domain Management Server with 12 Virtual Systems on one VSX cluster. A Global Policy is assigned to all 12 domains. It contains a rule near the top: 'Block Any -> 172.16.5.10' to protect a shared jump host. VS7's local policy now contains a permit rule for 10.20.30.0/24 to 172.16.5.10 on TCP 443, placed above the cleanup rule. The VS7 policy installation reports success. The tenant still cannot connect. The log for VS7 shows a drop on rule 'Global - Protect jump host', with the destination 172.16.5.10:443. The tenant administrator insists the local permit should override the global block because it is more specific and was installed later.
1. Why does the local permit not take effect? Explain the policy evaluation order and the role of the Install On column.
Read the worked answer
The local rule never gets a chance to match because the Global Policy is evaluated before the local domain policy. Global rules are intended to enforce provider-wide controls across all assigned domains, so a local permit cannot override a global drop simply by being more specific or newer. The Install On column reinforces this: the global block is installed on every VS in the assigned domains, while the VS7 permit is installed only on VS7. The log confirms the actual match: it names the global rule, not the local rule. Policy installation success only means the rulebase compiled and was delivered; it does not mean the tenant flow matches the intended rule. The fix must change the global layer, not add another local rule above the cleanup rule.
2. What change would you make to allow only VS7's tenant without weakening protection for the other 11 VSs?
Read the worked answer
Add a scoped exception in the Global Policy above the global block: source 10.20.30.0/24, destination 172.16.5.10, service TCP 443, and scope it to VS7 only. If the management design does not support per-domain scoping in the global rule, move the jump-host protection into each domain's local policy and keep the VS7 exception local, but that is a larger change with more regression risk. Avoid a global 'Any -> 172.16.5.10 permit' or a broad source exception, because that would open the jump host to every tenant. Also avoid disabling the global rule during the change window. Document the exception, its business owner, and the exact source range, then install the global policy and verify that VS7's log shows the new exception rather than the block.
3. How would you verify the fix and prevent a recurrence?
Read the worked answer
Verify from the tenant source, not from the management server: open a TCP 443 connection to 172.16.5.10 and confirm the VS7 log shows an accept on the scoped exception with the correct NAT and interface. Then test from a host in another VS to confirm the original global block still drops that traffic. Check the global policy installation targets to ensure the exception reached VS7 and not the other domains. For prevention, require a policy-layer review before any local rule is added against a globally protected resource; use 'where used' and impact analysis on global objects; and record whether a control is global or local in the tenant onboarding checklist. If the tenant later needs a different destination or port, require a new scoped exception rather than widening the existing one.