- Products
- Learn
- Local User Groups
- Partners
- More
What's New in R82.10?
Watch HereWhen the Agents Attack
A Live Look at Agentic Exposure Validation
AI Security Masters E8:
Claude Mythos: New Era in Cyber Security
CheckMates Go:
CheckMates Fest
I'm having trouble identifying if the ClusterXL ipv4 address in the general properties is supposed to match up a VIP under network management.
The deployment I'm working on has the clusterXL IPv4 address different from any of the defined VIPs, and as such isn't tied to any interface, so it doesn't respond to pings and such. The self signed certificates reference this address as well, and I'm unsure if that's what's causing problems with Identity collector and agents.
Is this normal, or should the ClusterXL address be the same as one of the VIPs for a defined interface (i.e internal interface vip)?
Thanks
Okay, I see you issue better now. You are using an IP address for the cluster object that ends with .5. It does not belong to any NIC or VIP. Of course it won't work. Change it to .3
It is a common practice to use the same IP subnet for both physical NIC IPs and VIP. However, you can also use one or more VIPs that belong to some other IP segments.
In such cases you have to make sure the physical machines have static host routes pointing VIP on the member's physical NIC IP address. If you did not do that, you will not be able to ping VIP, and some other networking issues are expected if VIP is being used to connect.
We do follow that practice. All our VIPs are in the same subnet as their physical interfaces.
I think it will be easier to show than explain:


The IPv4 under general properties is the IP address used as the SAN ip address (in the generated self signed certificate in IPSec VPN). This address is not tied to any interface. I'm wondering if it should be changed to the VIP of the related subnet.
Okay, I see you issue better now. You are using an IP address for the cluster object that ends with .5. It does not belong to any NIC or VIP. Of course it won't work. Change it to .3
As this is the Cluster object, should it not be the VIP (.3) and not the .7 that is for one of the physical gateways?
Yes, my mistake, .3 of course. Use VIP for the cluster object. Use physical IP addresses for representing the cluster members.
Just an Update. I've changed the addressing to match the VIP, renewed the L2TP certificates related to it, and everything is working smoothly.
As it should. I am grad you have figured it out
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 80 | |
| 14 | |
| 6 | |
| 5 | |
| 5 | |
| 5 | |
| 4 | |
| 4 | |
| 4 | |
| 3 |
Thu 25 Jun 2026 @ 10:00 AM (PDT)
AI Security Masters E10: READY OR NOT: Securing the AI Enterprise 2/5 - AI Red TeamingThu 02 Jul 2026 @ 06:00 PM (CST)
Revolucionando la Seguridad con IA Generativa: Prevención Inteligente en Tiempo RealThu 09 Jul 2026 @ 11:00 AM (CEST)
The Cloud Architects Series: Check Point Edge Protection SD-WAN & SASETue 14 Jul 2026 @ 10:00 AM (PDT)
AI Security Masters E11: READY OR NOT: Securing the AI Enterprise 3/5 - AI Workforce SecurityThu 30 Jul 2026 @ 10:00 AM (PDT)
AI Security Masters E12: READY OR NOT: Securing the AI Enterprise 4/5 - AI GatewayThu 20 Aug 2026 @ 10:00 AM (PDT)
AI Security Masters E13: READY OR NOT: Securing the AI Ent 5/5 - AI Research & Threat LandscapeThu 25 Jun 2026 @ 10:00 AM (PDT)
AI Security Masters E10: READY OR NOT: Securing the AI Enterprise 2/5 - AI Red TeamingTue 14 Jul 2026 @ 10:00 AM (PDT)
AI Security Masters E11: READY OR NOT: Securing the AI Enterprise 3/5 - AI Workforce SecurityThu 30 Jul 2026 @ 10:00 AM (PDT)
AI Security Masters E12: READY OR NOT: Securing the AI Enterprise 4/5 - AI GatewayThu 20 Aug 2026 @ 10:00 AM (PDT)
AI Security Masters E13: READY OR NOT: Securing the AI Ent 5/5 - AI Research & Threat LandscapeThu 02 Jul 2026 @ 06:00 PM (CST)
Revolucionando la Seguridad con IA Generativa: Prevención Inteligente en Tiempo RealAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY