R82 – Install ElasticXL Cluster

[HeikoAnkenbrand]

Overview

ElasticXL is a new cluster technology that enables simplified operation with a single management object with automatic configuration and software synchronisation between all cluster members.

ElasticXL is expected to be delivered with R82 or later versions. ElasticXL is based on similar technology to Maestro, but without MHOs. It is based on Check Point's SP versions for a scalable platform that allows you to increase the performance of the security gateways almost linearly.

I have tested it with the R82 EA version.

You can find more information about ElasticXL in this article:  R82 ElasticXL 

Install first ElasticXL gateway

1) Run the GAIA installation wizard on the appliance and select "ElasticXL" for clustering.
     If you want to use VSNext (replacement for the classic VSX), click the checkbox "Install as VSNext".

 

2) Assign a SIC one-time password.

3) After installation, you will find the ElasticXL Gateway under the "Cluster Management" menu item.

4) Create a new gateway object (not CLusterXL object) in the SmartConsole.
5) Now establish a SIC connection to the ElasticXL gateway IP from the SmartDashboard.
6) Afterwards, install a policy on the gateway.

Add more ElasticXL gateways to the cluster.

1) Wire the next appliances via the switch infrastructure so that all sync interfaces are connected to same network.
     Normally the ElasticXl sync interface is the eth1 interface.

2) Start the appliance and do not run the installation wizard.

3) Log in to the appliance via console cable or via LOM interface.  
    You are now in the gclish (global clish). Execute the following command:
    g> show cluster member info

    Copy the "Request ID" to the clipboard or to a text file.

4) Open a SSH session to the previously installed appliance and add the appliance with the following command in the gclish:
     g> add cluster member method request-id identifier 5aac9e10de7cd0e34cdf7fa368076b37 site-id 1 format json

5) The appliance should be installed automatically after approx. 5 minutes.
     The access policy is automatically synchronised by the first ElasticXL gateway (SMO).

6)  Both gateways should now be shown in the GAIA portal under the side 1.

    

7) Open an SSH session on the first gateway and check if the ElasticXL cluster is working.
    You can check this with the following command in the expert mode:
# asg monitor

[Peter_Elmer]

Hello @Oliver_Fink ,

I see the comment added later by @RamGuy239 , who edited interface naming configuration file. In the presentation held in Vienna I mentioned that running an EA version of R82 on open servers and VMware is challenging. These days the R&D team is looking for feedback related installations of the R82 EA on appliances.

The R&D team is focused these days achieving best customer experience for EA versions of R82 ElasticXL and VSNext on appliances: note "these days". 

As development is ongoing the feedback from @HeikoAnkenbrand is important and I will bring this certainly to the attention of the relevant colleagues in R&D. 

best regards

pelmer

[RamGuy239]

Thanks for the reply! It might be too early, but does this mean we don't expect any support for ElasticXL and/or VSnext for virtual installations with R82?

So far, I have yet to run into any noticeable issues running VSnext on VMware ESXi after dealing with the interface mapping. I have to say that VSnext looks like a significant improvement! It is some new logic to get accustomed to, but overall, I will say managing it all makes far more sense.

From what I've seen, ElasticXL looks like a no-brainer compared to ClusterXL. I can't see any reason to opt for ClusterXL over ElasticXL. You can even do "regular" High Availability using one gateway "per site". Unless there are some fundamental limitations, this looks like a ClusterXL replacement. Removing VIP and needing three IPs per subnet will make it more attractive for remote sites, where public IP addresses are often limited.

[Peter_Elmer]

Hello @RamGuy239 ,

I am sorry that your tests have encountered issues, but that's what is testing a release under development is: going along with challenges. 

The R&D team is working on R82 and in our EMEA presales team we are using appliances for testing. We certainly understand that virtual environments are required to scale the learning and training experiences and are exploring options here.

I am looking forward exploring more the advantages of ElasticXL and the value it provides to customers achieving resilient active/active environments. I am looking forward holding the dialog about these values here 😀

Greetings

pelmer

[RamGuy239]

@Peter_Elmer, I think you misread me. I have not encountered any issues after fixing the interface mapping. It's looking really solid so far. It's been a very good experience!

[PhoneBoy]

ElasticXL is meant to run in VM according to the various R82 slides from CPX:

From the various internal documentation I'm reading, it appears this should work without renaming the interfaces, though it will rename eth0.
Possible this is not in the EA version you're using yet.
Having said that, this is something I expect we'll support in GA (or even in the upcoming Public EA).

[Oliver_Fink]

Are you quite sure, ClusterXL is not installable in VM? Or do you mean, it ist not supported? I am quite sure to remember that I did some lab installations of ClusterXL on VMware… 😉

[_Val_]

Yeah, that slide needs a bit of tuning. AFAIK, you can run ClusterXL on VMware, but it may not be supported, since there is/was virtual edition for VMware native.

[PhoneBoy]

Getting it to work in the lab and supported in production are two different things 🙂

R82 is still EA code and, from other information I've heard since posting, the ultimate "supported" status for this feature on VM is still under discussion.

[RamGuy239]

@PhoneBoy Seems like this has changed with the latest R82 EA build. When applying it to my production environment, I used a previous one after the EA team ran into an issue with the newest build. So, I decided to use the same for my home/LAB. I just tested with the latest build, and with this build, I didn't have to do anything regarding interface mapping on VMware ESXi. Network Adapter 1 becomes Mgmt and a part of the MAGG bonding group, and Network Adapter 2 becomes eth1-Sync and SYNC bonding group. All that needs to be done is to ensure these two network adapters are placed in the correct VLAN.

Everything is working great, and I'm enjoying the new ElasticXL experience!

We might be tempted to re-install our appliances in production to have them run ElasticXL instead of ClusterXL. I suppose this will be more valuable to the R82 EA experience. VSnext used a lot of RAM when I was testing on VMware, so I won't opt for that on our appliances as they only feature 8GB RAM.

[HeikoAnkenbrand]

@RamGuy239  There is a hack with which you can currently use ElasticXL under VMWare.



But I don't want to write this in the public forum unless @_Val_ or @PhoneBoy  would agree that I can make this public.

Ask your local Check Point SE. He can certainly give you a tip.

[RamGuy239]

@HeikoAnkenbrand, You could always toss me some tips on PM. 🙂

I've asked my EA contact for details but haven't received any.

I'm not entirely sure what hacks/tips this might involve. Using the latest build, I don't seem to have any issues with simply using the ISO to install and activate ElasticXL and/or VSnext during the first-time wizard to get it all working.

The only issue I'm currently facing is having multiple gateways active in an ElasticXL group, which is causing traffic issues. But I don't think this is Check Point, ElasticXL, or R82 causing issues, and it seems like my Ubiquiti UniFi switches are having problems with VSLS. I had the same problem when running R81.20. I had to force it back to ClusterXL HA mode, running VSLS, and my networking would go all over the place when rebooting a member. Regular HA mode works just fine.

[Yasushi_Kono1]

Hi RamGuy,

interface mapping seems to be key and challenging alike. Before installing ElasticXL, you can modify the mapping to some extent in dhe /etc/udev/rules.d/00-OS-XX.rules file. But after the EXL-Installation, the file has been changed so that those aforementioned modifications are no longer available. I am talking about a VMware environment.
What files could be edited in order to correct the mapping of interfaces other the editing the 00-OS-XX.rules file?

Thanks a lot in advance!

[_Val_]

Just in case, @Yasushi_Kono1 , ElasticXL is not supported on any virtual platform so far

[patones1]

Hello

Probably, officially ElasticXL is not supported by any virtual platform.
But in the real life, it is supported by VMWare Workstation. This is because VMWare Workstation supports VMAC addresses and ElasticXL uses VMAC addresses. For a simple test, you can activate VMAC in a clusterXL and it is not going to work with ESXs. But it is going to work with Workstation.

Best regards

Miguel

 

 

[_Val_]

@patones1 Let's be clear. You can play with it in VMWare environment. However, you should not be using it for any production deployment. VMAC is not an issue, discovery and provisioning protocols are. 

Most importantly, any issues you might have with this deployment type will get no support from our TAC.

[patones1]

Hello,

That's for sure. I have never thought about using virtualization for gateway's deployment. In my case this is about testing on LAB. I think it is the case for most of the guys who talk about virtualization on ElasticXL

Maybe in the future, Check Point will support virtualization for production environments. Maybe in the future in collaboration with WMWare, Check Point will produce appliances where  it will be possible to install Gaia in several VMs for production environments. Let's see.

Have a nice weekend

Miguel

[PhoneBoy]

We are planning to support it in the future.

[patones1]

👍

[Jeff]

Will it be possible to add gateways via the GUI?

[Peter_Elmer]

Hello @Jeff ,

in the current software - even before public EA - all ElasticXL functions are managed by Gaia WebUI, Gaia CLI or Gaia API. Adding a new node to an existing ElasticXL cluster is done by a single command or Gaia WebUI action: you cable the new appliance to the mgnt and sync network and power it on. Once R82 has started, the machine will use LLDP to advertise itself to existing ElasticXL nodes 'hey, I am new, you can join me to the cluster'

On the existing ElasticXL you then just run the 'add node' command. Then the new node is getting software JHFs, configuration and security policy.

On the SmartConsole you only need one regular gateway object. Using this object, all physical nodes forming the ElasticXL cluster are managed. It's the Single-Management-Object principle that applies here and make things so easy.

greetings

peter

[Jeff]

Thank you for detailed comment. I'd like to clarify, for adding a new node to ElasticXL cluster via GUI I should use "Action" button? I don't see any buttons to add nodes in GUI in the screenshot. The fact is that the solution taken from Maestro is a brilliant. But we often receive negative feedback from customers that the syntax of commands in CLI is not clear, and it is not convenient to use part of the functionality in the GUI and another part in the CLI. Recently, the customers prefer products with more clear and friendly interface without using the CLI. 

[Peter_Elmer]

Hello @Jeff,

for CPX we ran a video and I share a screenshot here. You see a new member is pending and when you click on it, you can join the pending member to the existing or a new site.

Please stay tuned for more details as the development of R82 proceeds. 

best regards

peter 

[Robert_Gilbert]

Hi there,

Many thanks for this. Will mix-and-match of appliance models in a Security Group be supported in any capacity under ElasticXL, as it is for Maestro deployments to an extent (sk162373)?

[Peter_Elmer]

Hello @Robert_Gilbert ,

by the time of CPX Vienna mix-and-match was not planned being supported on ElasticXL. By that time, it was seen as a Maestro specific capability. To my observation this is the case even now - the time of this writing 27-June-2024. 

Certainly you can contact your local Sales representative and raise a request for enhancement on the topic. RFE's are driving R&D plans and that's why all my comments here need to be seen in the context of the time they are made.

best regards

peter

[GigaYang]

Has anyone successfully set up ElasticXL in an ESXi environment? In my Lab, two Cluster members will take turns competing for  Active member.

[_Val_]

As stated above, not supported

[GigaYang]

Hi Val,

Thanks for your kindly help.

[patones1]

Hello,

ElasticXL in an ESXi environment will not work because ElasticXL uses VMAC and ESXi is not compatible with it. It looks like ESXi has its own VMAC which it is conflict with the Check Point VMAC. 
This is the same issue I had when activating VMAC on ClusterXL on my ESXi LAB. I could never make it work. Communication to inside and outside the FW was broken.
This time, with ElasticXL, I didn't even need to add the second node to know it was not going to work. Already the firs node was not communicating. It was showing a MAC @ different that the one of the ESXi interface. It was a Check Point MAC address 00:1c:7f...., so a VMAC.

This is the VMAC of the ESXi interface. A ESXi VMAC (00-0c-29 ......)

The good news is that now VMWARE Workstation is free. Using VMWARE Workstation, there should be no issue. I always got to make VMAC work on ClusterXL when working under VNWARE Workstation. I will try to deploy ElasticXL on it. I'll let you know the results.
With VMWARE Workstation , you will need a lot of memory in the workstation. You can have 2 physical network cards on your ESXi, so you can keep using ESXi for your SMS and WindowsPC (management network). You will only need VMWARE Workstation to deploy the two firewalls.

I hope it helps

Miguel

 

[Tobias_Moritz]

@patones1 : You should be able to get ElasticXL VMAC to work in ESX just like you get ClusterXL VMAC (optional there, I know) to work: Change the policies of the distributed port group on the distributed vswitch in vCenter to allow what is needed:
https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-942BD3AA-731B-4A0...

[patones1]

Hello Tobias,

I didn't want to write the whole history but I have already tried changing the 3 security settings on each vSwitch as I thought it could work after reading the article bellow. I set the 3 settings as "Accept";......  without success.

https://support.checkpoint.com/results/sk/sk101214

I wonder if another combination of setting (ex: 2 settings in accept and one in Reject), could work

Thanks for your help

Miguel