Virtual System Management and Policy
Management and Policy tests how VSX is administered centrally: who owns which rule base, how global policy differs from local policy, and how installation and logging are scoped to the correct VS.
Management scopes
- With a Security Management Server, the VSX gateway and its VSs share one management server; each VS still has a distinct policy package and log context.
- With a Multi-Domain Server, each Domain Management Server administers its domain. The Global domain holds global policy that can be assigned to multiple domains.
- Global policy is a baseline enforced alongside local policy. Do not assume a global Accept overrides a local Drop or vice versa; design rules knowing both are evaluated, and test precedence in your version.
- Policy installation targets matter: select the VS object, not just the VSX gateway. A gateway-level install can affect multiple VSs, so confirm the target list before clicking Install.
- Logs are per VS. SmartConsole log views should be filtered or opened in the correct VS context; otherwise you will diagnose another tenant’s traffic.
Worked example
A global rule blocks known command-and-control IP addresses. A lab VS needs a temporary exception for testing. Add the exception in the lab VS local policy, not in the Global domain, and document why. Install the global policy to the relevant domains, then install the lab VS policy to that VS. Verify the log entry shows the lab VS and the expected rule, and confirm other VSs still block the address.
Traps that cost marks
- Editing a local rule in the Global domain and expecting it to affect one VS only.
- Installing global policy directly to a VS instead of the domain.
- Assuming all VSs share one log file or one policy installation status.
- Forgetting that a VS policy package can be attached to the wrong VS object.
- Treating the VSX gateway object as the tenant’s rule base.