Configure ClusterXL High Availability on Check Point R81.20

Before you run this

This guide builds a ClusterXL High Availability (Active/Standby) pair from two Check Point gateways: two physical or virtual firewalls share one set of virtual IPs, and if the active member fails, the standby takes over the traffic and the connections. Its purpose is redundancy, not more throughput — HA mode passes traffic through one member at a time.

A few things to be honest about before you touch anything:

• This is expert-level, privileged work. On each gateway you configure Gaia as admin (Gaia's superuser) through the First Time Configuration Wizard and clish. In SmartConsole you need a management account with permission to create gateways, edit topology, and install policy. The commands that force failover on a live member are run as admin/expert on the gateway.
• A wrong cluster topology or a bad policy will drop production traffic and can strand the standby. Cluster VIPs, sync, and the state machine are unforgiving of mismatched interfaces or missing SIC. Treat this as a change that can take the site offline.
• Keep an out-of-band path open. Have console/ILO/serial access to both members, or at least a physically separate management interface, before you start. If a policy install goes wrong you do not want your only way in to be the data path you just broke.
• Back up first. On each Gaia member take a snapshot (add snapshot), and in SmartConsole your policy is already versioned as a database revision. Snapshots and revisions are your rollback.
• Do this in a maintenance window, on lab gateways first if you have never built a cluster. The First Time Wizard's "part of a cluster" choice and the topology definitions are things you want to have made once on a test pair before doing it for real.

I'm assuming: two identical gateways (same appliance model or same VM spec, same interface layout) running Gaia R81.20, a separate Security Management Server also on R81.20, SmartConsole on a Windows admin workstation, and a dedicated interface on each gateway wired directly to the other for sync.

Plan the addressing before you log in

For each production interface that will carry traffic you need three IPs on the same subnet: one cluster virtual IP (the address hosts and routes point at) and one member IP per gateway. Write these out first — the topology step goes wrong when people improvise IPs at the keyboard.

You also need one sync network — a subnet used only for state synchronisation between the two members, ideally on that directly-connected interface. Give it its own /30 or /24 with a member IP on each side and no VIP.

Example scheme (substitute your real addresses):

Role	Cluster VIP	Member A	Member B
External (eth1)	203.0.113.10	203.0.113.11	203.0.113.12
Internal (eth2)	10.0.10.1	10.0.10.2	10.0.10.3
Sync (eth3)	—	192.168.99.1	192.168.99.2

Step 1 — Run the First Time Wizard on each member

On each gateway, complete the Gaia First Time Configuration Wizard (WebUI on https://<member-ip> or clish). The two settings that matter here:

• Set the product as a Security Gateway.
• On the cluster question, choose "Unit is a part of a cluster, the type is: ClusterXL."
• Set a SIC activation key (one-time password). You'll use it in SmartConsole to trust the member.

Configure each interface with its member IP (the per-gateway address from your table, not the VIP). Do this identically in interface layout on both boxes — eth1 external on both, eth3 sync on both.

Step 2 — Create the cluster object in SmartConsole

In SmartConsole, from the object tree: New → Cluster → Cluster (this launches the wizard; the classic path is New → More → Network Object → Gateways and Servers → Cluster). In the wizard:

1. Name the cluster and give it the external cluster VIP as its main address.
2. Choose ClusterXL and High Availability as the mode.
3. Add both members. For each member, enter its member IP and click to initialize SIC with the activation key you set in Step 1. A successful trust shows the certificate state as communicating/initialized.

If the wizard's guided flow doesn't expose everything, finish the object and open its General Properties and Network Management (topology) pages directly to complete the next step.

Step 3 — Define the topology

Open the cluster object → Network Management. For every interface listed you set:

• The network role / type: a data interface is a cluster interface and gets its cluster VIP plus each member's IP; the sync interface is set to role Sync.
• Whether it faces External or Internal (Interior).

Assign eth3 (or your chosen link) as Sync. Assign eth1/eth2 as cluster interfaces with the VIPs from your table. Do not put a VIP on the sync network.

This page is where mistakes hide. If SmartConsole flags a topology mismatch between members, stop and fix the member IPs — a mismatch will fail the policy verification, which is the safe outcome you want.

Step 4 — Install policy

Create or reuse an access policy with the cluster object as the install target, then Install Policy onto the cluster. The management server pushes the identical policy to both members and enrols them into the ClusterXL state machine.

Verify it worked

Everything below is read-only except the forced-failover test. Run these in expert mode on a member (type expert).

Check cluster state — you want one Active and one Standby:

cphaprob state

Check the monitored interfaces and that the required number are up on each member:

cphaprob -a if

Check the list of critical devices (pnote) — all should report OK:

cphaprob list

Confirm state synchronisation is actually flowing between the members:

cphaprob syncstat

If cphaprob state shows both members Active, you have a split brain — usually the sync link is down or the two members can't see each other's Cluster Control Protocol. Check the sync cabling and that eth3 is up on both before doing anything else.

Test failover (in your maintenance window)

The supported way to prove failover without pulling cables is to administratively fail the active member. On the active member, in expert mode:

clusterXL_admin down

Watch cphaprob state on the other member flip to Active, confirm production traffic still passes, then bring the first member back:

clusterXL_admin up

clusterXL_admin down marks that member's admin state as down so the peer takes over; up restores it. Without a persistence flag the state does not survive a reboot — check the ClusterXL Administration Guide for the exact persistent-mode option before relying on it.

Rolling back

• Undo a member's admin-down: clusterXL_admin up as shown above.
• Undo a bad policy: in SmartConsole, install the previous database revision, or open an earlier revision and reinstall. The management server holds every published version.
• Undo Gaia-level changes on a member: revert the snapshot you took first. In clish, show snapshots to list, then set snapshot revert <snapshot-name> (this reboots the member into the saved image).
• Remove the cluster entirely: this is a rebuild, not a click — you'd delete the cluster object, and each gateway must be reconfigured (First Time Wizard) as a standalone gateway. Plan that as its own maintenance window.

For the exact meaning of every cphaprob field, the sync-mechanism details, and the persistent admin-down flag, use Check Point's ClusterXL Administration Guide for R81.20 (sk-referenced from Check Point's support portal) — it is the authoritative source and tracks the version-specific wording better than any third-party page.