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

[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

 

[ShaiF]

Hi @patones1,

Can you clarify exactly what is not working? You able to run FTW on SMO and do not see the other member for joining it?
Did you make sure network adapter 2 (Sync network) is correlate with the original mac address of eth1-Sync and eth1 on the other member? To see SMO eth1-Sync original mac use ethtool -i eth1-Sync.

Regards,

Shai.  

[patones1]

Hello,

As I said before: "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". Just after installing the first node, I realized that it was not communicating with the data networks even thought the management interface was always communicating. On other words, the firewall was not able to ping nodes located inside and outside. At this point it was useless to add the second node and to see if the eth1-Sync interfaces communicate.
In this moment I have already installed the first node of ElasticXL in VMWARE Workstation. The first thing I did is checking the connectivity of the data interfaces; even before adding the node in the SMS. Everything communicates. From the firewall, I can ping the nodes inside and outside the firewall.

Regards

Miguel

[patones1]

Hello,

Finally I could deploy ElasticXL on VMWARE Workstation.

Configuring the interfaces is not as simple as on ESXi. It is not strait await, so before going to the SmartConsole, first make sure the connectivity is OK. If not, try changing the virtual networks (VMnetx) on the adapter.

If somebody need help about interfaces configuration, just let me know. I'll show what I did.

Best regards

Miguel

 

[ShaiF]

You can simplify adding the member by using hostname/serial-number method. This way you will not need any console access to the other member in order to get the request-id.

[the_rock]

Will send what it gives me as soon as I reinstall, should be fast.

[Jeff]

Hello everyone. Where should we connect our networks? WAN, DMZ, LAN? I mean, without orchestrator. Another question, all gateways connect each other via switch (need some requirements, vlans) ?

[ShaiF]

Hi Jeff,
Lab cabling is exactly the same as you connect regular ClusterXL.

you should connect all gateways with all cabling to external switches (aka , Mgmt, Sync, and data interfaces).
Regards,

Shai.

[Niels_van_Sluis]

Hi @HeikoAnkenbrand,

Thanks for sharing. Great stuff!

Step 3 and 4 don't seem to be necessary anymore. If you wire the appliance you want to add correctly, it will automatically  will appear in the GAiA portal as a pending gateway.

This makes it a lot easier.

Have fun,

     --Niels

[patones1]

Hello Champion,

I have just a simple question. I have an ElasticXL cluster on a VMWare Workstation host (yes, it woks on this).
When Typing cphaprob stat, I see the first member (SMO) with an state of ACTIVE(P)

 Then I switch the member on administrative down state by entering: g_clusterXL_admin -b 1_01 down

 Now the ACTIVE(P) state is in the second member. When I switch the firs member to administrative UP, the ACTIVE(P) state comes back to it.
Question: that (P) besides the ACTIVE state means that it is the SMO ?

Thanks for your help

Miguel

[ShaiF · Accepted solution]

Hi @patones1,

The P letter stands for Pivot. This means this member get all the traffic and distribute to other members for enforcing security.
SMO and Pivot are tasks which currently in R82 both managed by first active members in the active site.

So the bottom line is we can say Pivot is SMO.

Regards,

Shai.

[patones1]

Hello Shai,

Thanks a lot for the confirmation that the P is the SMO. Sure it is mainly the Pivot. I was thinking the P was for "primary", but Pivot is a better term on load sharing.
I looked everywhere about this P on ElasticXL and I didn't find anything. Now I understand it was probably in the information about ClusterXL in load sharing (or in Maestro). I had only done ClusterXL in HA.

Best regard

Miguel

[PhoneBoy]

Less than 10% of ClusterXL installs involve Load Sharing, so you're not alone 🙂

[patones1]

Thanks 🙂

[CEEJAY]

Hello, Shai. I just want to ask if the Primary Gateway is the SMO and also the Pivot. What if the the Primary Gateway goes down, the Pivot will be changed and it will be the secondary gateway, does it mean that it will also be the SMO? 

[patones1]

Sure. SMO and MHO roles goes together.
Just to remember:
"The gateways acting as an SMO, simultaneously assume the role of maestro's MHO, but uses pivot-based unicast load sharing, similar to ClusterXL's classic unicast load sharing mode".

 

[TINTIN8]

Is it same for the VSNext , using Openserver?

[Tymdrake]

Hi HeikoAnkenbrand

One question, I started to study about Elastic Cluster I just want to know how is the physical connections for the cluster members, I mean if I have two members, thats must be connected to diferents switches for reduce point of failure or has redundancy?

Thanks for your comments.

[patones1]

Hello

In any kind of cluster or single gateway, It is a good practice to use different switches to isolate each kind of traffic.
As you are starting with ElasticXL, you should take in account the information bellow regarding the interfaces:

The ElasticXL cluster requires at least 4 interfaces on each ElasticXL cluster member. One internal interface, one external interface, and:

• A dedicated management interface: during the initial configuration, the “Mgmt” port is automatically added in the WebUI. This interface becomes a subordinate interface of the link, called “magg1” with the “management” address.
• A dedicated synchronization interface: the "Sync" port is also automatically added. This interface is renamed "eth1-Sync" and becomes a subordinate interface of the "Sync" link. The IP address of the synchronization network is 192.0.2.0/24 (automatically configured). Gaia's WebUI does not display the "Sync" link interface.  It is visible via "show cluster info interfaces". 
  With a simple "show interfaces", you will see the "eth1-Sync" interface.

 

I hope it helps

Miguel Paton de Escalada

CCSE