Tenant isolation model for a 14-customer VSX consolidation
An MSSP is consolidating 14 SMB customers onto a two-member VSX cluster running R81.20. The VSX license includes 10 Virtual Systems. Nine customers require their own security policy, separate administrator accounts, and independent logging. Three customers do not need separate security policy or administration; they only need routing separation because they all use 10.0.0.0/8 internally, and they will be covered by one common outbound policy. Two customers require a dedicated public IP and inbound NAT for HTTPS, and they also require separate administrator accounts and separate rulebases. The project manager proposes creating one Virtual System per customer and 'sorting out the license later.' The security architect is asked to choose between Virtual Systems and Virtual Routers, and to justify the design before the maintenance window.
1. How should the 14 customers be mapped to Virtual Systems and Virtual Routers? Show the count and the license implication.
Read the worked answer
Start from the security boundary, not the customer count. The nine customers that need separate policy, admins, and logs require nine Virtual Systems. The two NAT customers also need separate admin and rulebases, so they require two more Virtual Systems. That is 11 VSs before the routing-only customers. The three routing-only customers share one outbound policy, so they should not get individual VSs; place them in one shared Virtual System and separate their overlapping 10.0.0.0/8 routing with Virtual Routers or equivalent per-tenant routing separation inside that shared context. Total design: 12 VSs. The 10-VS license is therefore short by two, not by four. Do not merge the two NAT customers into one VS just to fit the license unless they truly share admin and policy; inbound NAT alone is not the boundary. The correct decision is to license 12 VSs or reduce scope with the business, not to 'sort it out later.'
2. What security risk arises if the three routing-only customers are placed in one Virtual Router without their own policy?
Read the worked answer
A Virtual Router provides routing separation, not a security boundary. If the three customers share one policy and one logging context, a permissive rule for one customer's server can expose another customer's overlapping 10.0.0.0/8 address space. Overlapping IPs also make troubleshooting ambiguous: the same source and destination addresses can exist in multiple routing domains, so an ARP entry or NAT rule in the wrong context can silently redirect traffic. The design must keep VLANs, routing tables, and policy scoping aligned, and it must deny cross-customer traffic explicitly rather than relying on the absence of a route. Logging must still identify which tenant generated a flow. If the business needs per-customer audit or delegated administration, those three customers need VSs after all; routing separation alone is insufficient.
3. After deployment, how would you prove that the two NAT customers are isolated from each other and from the shared VS?
Read the worked answer
Verify the design at three layers. First, confirm each VS has a distinct context ID and that its interfaces, routing table, and NAT rules are visible only in that context. Use vsx stat -v and inspect the VS topology in SmartConsole. Second, test cross-tenant traffic in both directions from test hosts: traffic from NAT customer A to customer B's public or private address should hit an explicit drop rule, and the log should name the correct VS. Third, inspect logs and fw monitor per VS during a controlled connection to confirm the SYN, NAT translation, and reply all occur in the same VS and on the expected interface. Also test the shared VS: a routing-only customer must not be able to reach a NAT customer's internal address. If any test passes only because no route exists, add an explicit deny rule so the isolation is intentional and auditable.