- Products
- Learn
- Local User Groups
- Partners
- More
What’s New in Identity and Trust?
11 November @ 5pm CET / 11am EST
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!
What’s New in Agentic Network Orchestration
CheckMates Go:
Fun Ding
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 |
|---|---|
| 30 | |
| 15 | |
| 13 | |
| 8 | |
| 7 | |
| 4 | |
| 4 | |
| 4 | |
| 4 | |
| 4 |
Tue 10 Nov 2026 @ 06:00 PM (IST)
Under the Hood: Introducing Check Point Cloud Firewall as a ServiceTue 10 Nov 2026 @ 08:00 PM (IST)
Check Point Mobile Security | Extending Zero Trust with NetskopeThu 12 Nov 2026 @ 11:00 AM (EST)
Tips and Tricks 2026 #15: Check Point MDR and Incident ResponseTue 10 Nov 2026 @ 06:00 PM (IST)
Under the Hood: Introducing Check Point Cloud Firewall as a ServiceTue 10 Nov 2026 @ 08:00 PM (IST)
Check Point Mobile Security | Extending Zero Trust with NetskopeThu 12 Nov 2026 @ 11:00 AM (EST)
Tips and Tricks 2026 #15: Check Point MDR and Incident ResponseTue 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