Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
dphonovation
Collaborator

Using BGP address for Client VPN possible on R81.10?

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...

0 Kudos
8 Replies
PhoneBoy
Admin
Admin

Why not associate a route with the loopback interface?

0 Kudos
dphonovation
Collaborator

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?

0 Kudos
PhoneBoy
Admin
Admin

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.

0 Kudos
dphonovation
Collaborator

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)


0 Kudos
Chris_Atkinson
Employee Employee
Employee

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.

 

 

CCSM R77/R80/ELITE
0 Kudos
dphonovation
Collaborator

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...

0 Kudos
PhoneBoy
Admin
Admin

No, I was talking about the IP range that's assigned to the VPN client when it connects to the gateway.

0 Kudos
dphonovation
Collaborator

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.

Upcoming Events

    CheckMates Events