- Products
- Learn
- Local User Groups
- Partners
- More
What's New in R82.10?
10 December @ 5pm CET / 11am ET
Improve Your Security Posture with
Threat Prevention and Policy Insights
Overlap in Security Validation
Help us to understand your needs better
CheckMates Go:
Maestro Madness
Hi all,
Pardon the long winded post, I'm no BGP expert and a bit stuck figuring this out.
We are building out 2 new datacentres with a new ISP peer. I've previously lab'ed this setup at my previous data centre but the ISP peer did things differently. In particular, the /31 I am to broadcast my BGP range from is internal in this new setup, whereas in my lab it was addressable publically. I was initially planning to simply use the /31 to setup a simple Client VPN for me to administer remotely and be able to play with the BGP setup once the Checkpoint is racked/stacked (it's a VM). Below is a basic diagram of what I *thought* it should look like. Direct imgur link: https://i.imgur.com/SgJSrVK.png

There are two ClusterXL Checkpoints (1 per site) running 81.10. My understanding is I cannot use aliases with ClusterXL to assign one of the BGP addresses to the cluster as an alias. Right now, each has it's own mgmt server. Eventually, the ISP will be building a layer 2 circuit between the sites and the plan will be to put them on the same Checkpoint MGMT plane. In the meantime, I need to be able to access both sites independently.
The new ISP peer has given me 2 BGP ranges. (the 82.X.X.X/27s). I envisioned being able to setup BGP at both sites and leverage ASPREPEND to prefer routing to Site 1 (left) unless it goes down, which would then prefer the route to Site 2 (right). In my afromentioned lab, the /31's at each site were publically addressable. I advertised BGP via a NAT Pool. Accessed the checkpoints via the /31 and NAT'ed any customer traffic headed for the /27 BGP range to appropriate back ends. I didn't even need to assign the Checkpoint Cluster any intefaces in the BGP range.
So in this new setup I was hoping to simply rack the kit, use the /31 as my own Client VPN connectivity and tinker with BGP addressing remotely without risking losing connectivity.
However the new ISP peer has just given me the circuit details and they expect my private AS to BGP peer from a 100.64.76.x/31 to their private AS, which they then push to their core.
It now feels like I would have no choice but to marry each BGP range to a site as a result, which is undesirable but I suppose I can find a way to live with it.
But this leads me to the question: How do I go about assigning an address out of my BGP range to the Checkpoint Cluster and expose Client VPN over it? I would usually think to do that as an alias, but that's not supported in Cluster XL. I also need the Checkpoint gateways to talk to the wider internet (for update and such) via one of the BGP addresses.
Any advice and guidance much appreciated. Thanks for reading.
Edit: This seems to have been a similar setup: https://community.checkpoint.com/t5/Security-Gateways/ISP-connection-using-private-IP-with-routed-pu...
Why not associate a route with the loopback interface?
Sorry, could you expand on what you mean?
I think you mean, associate one of the BGP routes I'm advertising to the ISP peer to my loopback interface and then:
1) for external internet access for the ClusterXL members, I setup a NAT rule per gateway (per cluster?)
2) for inbound Client VPN I simply use a static address in the link selection window that belongs in the BGP range?
Before I answer, I think I need clarification on what you mean by "expose Client VPN."
Do you mean have a route for the Office Mode network advertised via BGP?
Note that Office Mode networks should be unique per cluster.
No. In this scenario I have 2 goals at the moment:
1.) Simply use one of the IPs in the BGP block as the public IP I can connect to with Checkpoint Mobile for Windows
Edit: After rereading your reply. I think we are saying the same thing for #1
2.) Use one of the IPs in the BGP block as the source IP for my ClusterXL members for their own internet access. (Even though their ClusterXL VIP on the WAN side is a private address /31 to BGP Peer with)
Further to what @PhoneBoy suggested, starting R81.10 and above you can configure Loopbacks as clustered interfaces which may assist with the VPN target portion if you weren't planning to use the addresses assigned to a DMZ interface of sorts.
It's also straight forward to hide-NAT outbound internet access from internal clients to another address from those BGP ranges.
We also provide the ability documented in SK/ClusterXL admin guide to have the VIP and External interfaces on different subnets (some caveats apply here) but I've not myself tried this where the VIP is a BGP peer.
I've done hide-nat on internal clients for BGP ranges.
I've also referenced the SK you speak of to have the External facing VIP be a private address assigned to me by the ISP (100.x.x.x) whereas the clusterxl member interfaces are in a 172.x.x.x locally.
But how do I get the ClusterXL members themselves to use a BGP address? In my lab, the ClusterXL members always used the External facing VIP to try and communicate with the world for things like updates, but in this case it's a private address.
It sounds like a similar case in this thread: https://community.checkpoint.com/t5/Security-Gateways/ISP-connection-using-private-IP-with-routed-pu...
No, I was talking about the IP range that's assigned to the VPN client when it connects to the gateway.
I've solved this as Chris suggested in the thread I linked (posted by someone else)
My WAN ClusterXL vip is no longer private. I asked the ISP to split one of the /27s into 4x /29s. Used the 1st /29 block to direct peer with to their BGP gateway and advertised the remaining 3 with BGP.
Thank you all
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 26 | |
| 18 | |
| 10 | |
| 8 | |
| 6 | |
| 6 | |
| 6 | |
| 5 | |
| 4 | |
| 4 |
Wed 03 Dec 2025 @ 10:00 AM (COT)
Última Sesión del Año – CheckMates LATAM: ERM & TEM con ExpertosThu 04 Dec 2025 @ 12:30 PM (SGT)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - APACThu 04 Dec 2025 @ 03:00 PM (CET)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - EMEAThu 04 Dec 2025 @ 02:00 PM (EST)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - AmericasWed 03 Dec 2025 @ 10:00 AM (COT)
Última Sesión del Año – CheckMates LATAM: ERM & TEM con ExpertosThu 04 Dec 2025 @ 12:30 PM (SGT)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - APACThu 04 Dec 2025 @ 03:00 PM (CET)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - EMEAThu 04 Dec 2025 @ 02:00 PM (EST)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - AmericasAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY