R82 VSNext Design Review: Cross-Environment Transit (VSwitch vs Dedicated VLANs) on Maestro

[andrej_kascak3]

Hi CheckMates Community,

I am currently evaluating two architectural options for a Check Point R82 VSNext deployment on a Quantum Maestro Security Group and would appreciate feedback from anyone running similar topologies in production.

Environment & Requirements:

• Architecture: 3 Virtual Gateways (VGW A, VGW B, VGW C) on R82 VSNext (Maestro SG – connected to LAN infra via singe bond interface).
• Downstream: Citrix NetScaler using Traffic Domains over a shared LACP bond trunk (managed by an external team).
• Upstream: 4 distinct external environments connected over the shared trunked bond (Cisco N9K with 4 VRFs).

• Blades & features - we use only FW blade (with NAT) currently, no dynamic routing. In near future we plan to add Identity Awareness using Identity Collector integrated with Active Directory.

• Key Constraints:
1. No upstream inter-VRF routing interconnect exists, meaning cross-environment transit must be bridged/routed through the firewall chassis.
2. Every flow strictly traverses only 1 VGW (no multi-VGW chaining).

Option 1: 4 Internal Virtual Switches (VSwitches)

• Provision 1 internal VSwitch per environment in Gaia OS and attach each VGW via internal virtual warp (wrp) interfaces.

Option 2: 12 Dedicated Point-to-Point VLANs

• Provision 12 point-to-point subnets.

Looking for Feedback / Community Experience:

1. For those running high-throughput VSNext environments on Maestro, is the performance on wrp interfaces sufficient, or is physical VLAN sub-interfaces performance superior?
2. Are there any hidden operational gotchas with wrp links, internal VSwitches, or Identity Awareness tables across network namespaces in R82 VSNext?

[Chris_Atkinson]

Simplicity & routing were my first thoughts - with that said if you've gone to the trouble of separate VRFs and VS does the VSW impact the isolation you've set to achieve i.e. might it allow admins to establish traffic paths/paterns that shouldn't occur?

Sounds like your target state will avoid this: sk183336: In ElasticXL in VSNext mode, traffic does not pass between Virtual Gateways that are conne...

Some previous discussion on vswitch performance can be found here: Solved: Performance Limitations of Virtual Switches in a V... - Check Point CheckMates which namely identified:

ID	Product	Description
R82 JHF Take 126 - Improvements and Resolved Issues
PRJ-67772, PMTR-119674	SecureXL	In some scenarios, the VSX Gateway may experience poor performance when passing traffic between Virtual Systems through a Virtual Switch with SecureXL User Mode enabled.

[emmap]

It depends a bit on the rest of your network architecture as that is also affected, but in general there shouldn't be any performance penalty in using VSwitches. If it's easier on your routing etc to share VLANs between VSs then I'd go with VSwitches.

[Arne_Boettger]

To make sure I understand correctly:

The result of the constraint "Every flow strictly traverses only 1 VGW (no multi-VGW chaining)" does effectively mean that if two VRFs need to communicate through your setup, the VGW needs a leg in both VRFs. 

Maybe you could clarify how the 4 VRFs map to the 3 VGWs. Is there any inter-VRF traffic expected?