- Products
- Learn
- Local User Groups
- Partners
- More
What’s New in Identity and Trust?
AI Security Masters
Security in the Pace of AI:
From Threat to Force Multiplier
CPX is Back!
Join us in Las Vegas, Vienna, and/or Bangkok!
Check Point Named a Leader
The Forrester Wave:
Enterprise Firewall Solutions, Q4 2026
What’s New in Agentic Network Orchestration
CheckMates Go:
Fun Ding
Today, we have an internal cluster with two 9100 devices, and everything is working fine.
Now, we are planning to implement two new clusters:
Cluster Y
Two SMB 1575 devices
Only one fixed ISP IP
Cluster Z
Two 9100 devices
Only one fixed ISP IP
My question is: how can the clusters communicate using only one public IP?
You may also wish to consider ElasticXL with R82 as another option (for non Spark) as it doesn't have the same IP address requirements as traditional ClusterXL.
https://youtu.be/Ctx9Su0y-e0?feature=shared
I have same issue to solve here.
You may also wish to consider ElasticXL with R82 as another option (for non Spark) as it doesn't have the same IP address requirements as traditional ClusterXL.
https://youtu.be/Ctx9Su0y-e0?feature=shared
Using the R82 for non-Spark scenarios seems like the best approach. In the case of Spark with 3 valid IPs, will it work? Is this the best practice in this situation? I’m considering requesting additional IPs from the ISP.
Thks Chris, it solves our problem.
The traditional method:
Hi,
Note that on locally managed Spark appliances running R81.10.15, you can just configure routable IP as VIP and physical (private) IPs from different subnet without the need to implement Cluster IP Addresses on Different Subnets.
Thanks.
Yes, for other customers, we handle this through local management in Spark and work fine. However, in this case, the manager will operates centrally.
Unfortunately, we recently have closed a ticket about this, and the solution is:
Quantum Spark Appliances in Centrally Managed mode DO NOT fully support the configuration with Single Routable IP and interfaces on different network even if it's confirmed by documentation (https://sc1.checkpoint.com/documents/SMB_R81.10.X/AdminGuides_Centrally_Managed/EN/Content/Topics/Co...), this seems to be available only for Quantum Force and higher (https://sc1.checkpoint.com/documents/R81.10/WebAdminGuides/EN/CP_R81.10_ClusterXL_AdminGuide/Topics-...).
You can try to configure a new "local transport network" between gateway and router so you can have as many IP as you want to configure in each interface. In this case you cannot access directly each cluster member from internet, but you can do so via DNAT.
Something like that:
Router External: 1.1.1.1
Router Internal: 192.168.1.1/24
Checkpoint External: 192.168.1.2/24
Checkpoint External gateway: 192.168.1.1
Hoping to be useful
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 3 | |
| 3 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
Tue 17 Nov 2026 @ 08:30 AM (EST)
Bogota Breakfast & Hack: IA bajo control y ataques en vivo con Workspace SecurityTue 17 Nov 2026 @ 05:00 PM (CET)
AI Security Masters: Security in the Pace of AI: From Threat to Force MultiplierTue 17 Nov 2026 @ 11:00 AM (EST)
Under the Hood: Check Point SASE | Troubleshooting Like a ProTue 24 Nov 2026 @ 01:30 PM (GMT)
La nueva realidad de los ataques DDoS: autonomía, escala y el futuro de la defensaTue 17 Nov 2026 @ 05:00 PM (CET)
AI Security Masters: Security in the Pace of AI: From Threat to Force MultiplierTue 17 Nov 2026 @ 11:00 AM (EST)
Under the Hood: Check Point SASE | Troubleshooting Like a ProTue 24 Nov 2026 @ 01:30 PM (GMT)
La nueva realidad de los ataques DDoS: autonomía, escala y el futuro de la defensaWed 02 Dec 2026 @ 03:30 PM (GMT)
The New DDoS Reality: Autonomy, Scale, and the Future of DefenseTue 17 Nov 2026 @ 08:30 AM (EST)
Bogota Breakfast & Hack: IA bajo control y ataques en vivo con Workspace SecurityAbout CheckMates
Learn Check Point
Advanced Learning
WE SECURE YOUR AI TRANSFORMATION