- Products
- Learn
- Local User Groups
- Partners
- More
Call For Papers
Your Expertise, Our Stage
Ink Dragon: A Major Nation-State Campaign
Watch HereAI Security Masters E5:
Powering Prevention: The AI Driving Check Point’s ThreatCloud
The Great Exposure Reset
AI Security Masters E4:
Introducing Cyata, Securing the Agentic AI Era
CheckMates Go:
CheckMates Fest
Hello All,
I've read somewhere, that would be possible to have a VSX Gateway inside a specific Domain (MDM environment) and create VS from that VSX Gateway in different Domains.
Is this something feasible ?
Inside the domain where i want to create the VS, i can see the VSX Gateways that reside in different domains, so i would guess its possible.
Is this something that someone already tried ?
Pros/Cons would be grateful.
Thanks in advance !
Bruno Petrónio
If the VSX is managed from a MDS setup then far as I'm aware the VSX appliances should be managed via the main domain, in this way this can then be seen by customer domains.
Main Domain, implies that only one Domain could have the VSX Gateway ?
If i need 2 VSX Gateway (not cluster), is it possible/make sense to have it in different domains ?
The short explanation is this is how VSX and Provider-1 are meant to be used together in a managed service provider context. You, the service provider, own the MDS and the VSX chassis. You then provision a Customer Management Add-on for the customer, and a VS (or several) to go with it.
Thanks for clarifying that.
We are not running different customers, but have business related needs and we are running VSX for the virtualization fun/benefits 🙂
Saying that, make sense to have VSXs together in one domain and all VSs spread by different Domains, right ?
No Pros having VSX and VSs per Domain, i would say.
As stated already one reason was separation in provider/customer scenario.
But this was also a best practice to have a separate domain for the VSX gateways, as changes to a VS also locked the domain of VSX gateway (before R80) and so you separated it.
We have many VSX and their vs separated in different CMA. I don't really see a disadvantage of doing that if there is a need to do so.
You mean, many VSX in one domain (called main domain), and their VS inside the several other domains ?
I've written something on this subject some time ago for R77.30
Perhaps you'd find it useful.
Yes, we have several VSX one domain and their VS inside several other domains. We really have some vsx in a domain called main but several others in different domains.
I believe VSX clusters in the main domain can be shared with other CMAs. VSX Clusters controlled by a customer CMA, are only usable within that domain and not visible to other customer domains.
If you decided to implement a global level VPN then having a mixed installation may not work (Never done this but thought its worth considering if you ever intended to use this feature in MDS).
Hello, how we can verify that a domain is the "main"?
Also the "virtual switch" can be shared with two or more CMA?
Thanks
I'm not sure what you mean by "main". I would translate that to "the DMS that should have the VSX appliances and the virtual switches". However all depends on your setup.
In general I would say the first DMS created is where the VSX appliance should be managed. The virtual switches would be created here and would then be available for other DMS's to use.
Now keep in mind the DMS that controls the _VSX policy would generally be where you manage you VSX platform from.
HOST POLICY DATE
localhost POLICY_VSX 1Apr2023 22:39:44 : [>bond1] [<bond1] [>bond2] [<bond2]
Additionally you could have other VSX appliances controlled from Customer DMS, but they would be totally isolated to that customer.
Hello, OK, thanks a lot. Your explanation is clear.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 35 | |
| 21 | |
| 18 | |
| 12 | |
| 9 | |
| 9 | |
| 8 | |
| 8 | |
| 8 | |
| 7 |
Tue 17 Mar 2026 @ 03:00 PM (CET)
From SASE to Hybrid Mesh: Securing Enterprise AI at Scale - EMEATue 17 Mar 2026 @ 02:00 PM (EDT)
From SASE to Hybrid Mesh: Securing Enterprise AI at Scale - AMERWed 18 Mar 2026 @ 10:00 AM (CET)
The Cloud Architects Series: An introduction to Check Point Hybrid Mesh in 2026 - In Seven LanguagesThu 19 Mar 2026 @ 11:00 AM (EDT)
Tips and Tricks 2026 #2: AI Security Challenges and SolutionsTue 17 Mar 2026 @ 03:00 PM (CET)
From SASE to Hybrid Mesh: Securing Enterprise AI at Scale - EMEATue 17 Mar 2026 @ 02:00 PM (EDT)
From SASE to Hybrid Mesh: Securing Enterprise AI at Scale - AMERWed 18 Mar 2026 @ 10:00 AM (CET)
The Cloud Architects Series: An introduction to Check Point Hybrid Mesh in 2026 - In Seven LanguagesThu 19 Mar 2026 @ 11:00 AM (EDT)
Tips and Tricks 2026 #2: AI Security Challenges and SolutionsTue 24 Mar 2026 @ 04:00 PM (CET)
Maestro Masters EMEA: Hyperscale Firewall Architectures and OptimizationTue 24 Mar 2026 @ 06:00 PM (COT)
San Pedro Sula: Spark Firewall y AI-Powered Security ManagementThu 26 Mar 2026 @ 06:00 PM (COT)
Tegucigalpa: Spark Firewall y AI-Powered Security ManagementAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY