- Products
- Learn
- Local User Groups
- Partners
- More
Firewall Uptime, Reimagined
How AIOps Simplifies Operations and Prevents Outages
Introduction to Lakera:
Securing the AI Frontier!
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!
I have a CusterXL HA setup (2 units), And a 2nd small external IP range that I'll be migrating over to our checkpoint firewall.
I only have 1 IP address available to define an interface with on our cluster in that IP range (With future plans to put everything behind a reverse proxy, to free up addresses so I can do a proper HA setup).
Is it okay to add an additional interface on only one of the units (active), and reference that IP in the Proxy ARP ? I'm not sure if this will have any bad interactions with ClusterXL, as all my other interfaces in the cluster are setup properly with VIPs. I don't expect any bad behavior, but I'd like to see if anyone else has done this, and their experiences.
I know this will make the services unavailable if there is a failover, but that has been deemed acceptable for us in the short term.
*edited for spelling
You can. See screenshot below:
Use "Monitored Private" if you want the cluster to failover, should the interface go down, or "Non-monitored Private" if you rather remain on the active member this interface belongs to.
One IP is all you need to setup vIP on the cluster. You can use IPs from different subnet for the physical interfaces and assign your single remaining IP from working range to be the vIP on the cluster.
Only one routable IP address is required in a ClusterXL cluster, for the virtual cluster interface that faces the Internet. All cluster member physical IP addresses can be non-routable.
Configuring different subnets for the cluster IP addresses and the member addresses is useful in order to:
I remember seeing this SK before. I'm reading over the article and it's a bit confusing.
Here's my interpretation of it, simplified into a couple lines:
The switch port that the physical interfaces connect to will still be our external VLAN, but the physical interfaces on the gateway will be defined as an IP in a different subnet, and that subnet is defined within the gateway. I would then use a static route within the gateway to route between the two subnets within the gateway?
Then because, of proxy ARP and VIP, the physical interface on the gateway will still be able to receive and transceiver as the VIP is what is used as the primary address?
Is that kind of the gist of it?
It is pretty much how I read it too.
You may want to look here: Configuring Cluster Addresses on Different Subnets
This seems like a good option that I'd like to implement, however I'd still like to know if my original example would work.
Can I make a non-cluster interface in a clusterXL setup? To have just one of my gateways in the cluster have a unique interface would be nice.
You can. See screenshot below:
Use "Monitored Private" if you want the cluster to failover, should the interface go down, or "Non-monitored Private" if you rather remain on the active member this interface belongs to.
This is what I'm looking for
I'm unfamiliar with this view though. Topology settings menu in r80.10 is different for me, unless this is in the global properties advanced configuration?
In 80.10 I see private, but no mention of monitored on non monitored.
I had to use the R77.30 demo to pull this up for you, as R80.++ does not include clusters or VSXs.
According to documentation:
ClusterXL R80.10 (Part of Check Point Infinity) Administration Guide
Both "Private" and "Monitored Private" are still supported.
Thank you very much for your help Vladimir, very detailed responses. I think I got it from here!
You are quite welcome:)
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
24 | |
16 | |
4 | |
4 | |
3 | |
3 | |
3 | |
3 | |
3 | |
2 |
Tue 07 Oct 2025 @ 10:00 AM (CEST)
Cloud Architect Series: AI-Powered API Security with CloudGuard WAFThu 09 Oct 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: Discover How to Stop Data Leaks in GenAI Tools: Live Demo You Can’t Miss!Thu 09 Oct 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: Discover How to Stop Data Leaks in GenAI Tools: Live Demo You Can’t Miss!Wed 22 Oct 2025 @ 11:00 AM (EDT)
Firewall Uptime, Reimagined: How AIOps Simplifies Operations and Prevents OutagesAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY