- Products
- Learn
- Local User Groups
- Partners
- More
Quantum Spark Management Unleashed!
Check Point Named Leader
2025 Gartner® Magic Quadrant™ for Hybrid Mesh Firewall
HTTPS Inspection
Help us to understand your needs better
CheckMates Go:
SharePoint CVEs and More!
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 |
---|---|
17 | |
10 | |
6 | |
6 | |
6 | |
6 | |
6 | |
4 | |
3 | |
3 |
Tue 16 Sep 2025 @ 02:00 PM (EDT)
Securing Applications with Check Point and AWS: A Unified WAF-as-a-Service Approach - AmericasWed 17 Sep 2025 @ 04:00 PM (AEST)
Securing Applications with Check Point and AWS: A Unified WAF-as-a-Service Approach - APACWed 17 Sep 2025 @ 03:00 PM (CEST)
Securing Applications with Check Point and AWS: A Unified WAF-as-a-Service Approach - EMEAThu 18 Sep 2025 @ 03:00 PM (CEST)
Bridge the Unmanaged Device Gap with Enterprise Browser - EMEAThu 18 Sep 2025 @ 02:00 PM (EDT)
Bridge the Unmanaged Device Gap with Enterprise Browser - AmericasTue 16 Sep 2025 @ 02:00 PM (EDT)
Securing Applications with Check Point and AWS: A Unified WAF-as-a-Service Approach - AmericasWed 17 Sep 2025 @ 04:00 PM (AEST)
Securing Applications with Check Point and AWS: A Unified WAF-as-a-Service Approach - APACWed 17 Sep 2025 @ 03:00 PM (CEST)
Securing Applications with Check Point and AWS: A Unified WAF-as-a-Service Approach - EMEAThu 18 Sep 2025 @ 03:00 PM (CEST)
Bridge the Unmanaged Device Gap with Enterprise Browser - EMEAThu 18 Sep 2025 @ 02:00 PM (EDT)
Bridge the Unmanaged Device Gap with Enterprise Browser - AmericasAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY