Check Point High Availability – Redundant, Reliable, and Secure

Prerequisites: Basic Networking, IP Addressing, Routing and Check Point Firewall Fundamentals

Imagine a company that depends on its firewall for internet access, internal applications and VPN connectivity.

The company has one Check Point Security Gateway.

One day, the firewall experiences a hardware failure.

Employees lose access to important applications because there is no other firewall available to process their traffic.

How can the organization reduce the risk of this type of outage?

One solution is High Availability (HA).

High Availability uses redundant systems so another device can take over when a device becomes unavailable.

Check Point provides several supported clustering and redundancy options, including ClusterXL High Availability, ClusterXL Load Sharing and Gaia VRRP.

However, these technologies do not all work in the same way.

In this article, you will learn:

• What High Availability means in Check Point
• How ClusterXL works
• The difference between Active/Standby and Load Sharing
• How Load Sharing Multicast and Unicast differ
• What geographically distributed Active-Active means
• How Gaia VRRP works
• How State Synchronization helps preserve connections
• How to configure and verify a supported cluster

What Is High Availability in Check Point?

High Availability (HA) is a design that uses redundant systems to reduce service interruptions when a system fails.

In a Check Point firewall environment, multiple supported Security Gateways can form a cluster.

A cluster is a group of gateways configured to work together.

Depending on the selected mode, the gateways may:

• Provide backup when another gateway fails
• Share traffic-processing workloads
• Synchronize supported connection information
• Maintain a common logical network identity through virtual IP addresses

Important High Availability Terms

High Availability vs Load Sharing

These concepts are related but different.

High Availability

Focuses on redundancy.

In a traditional Active/Standby design, one gateway handles the traffic while another remains available for failover.

Load Sharing

Focuses on distributing traffic processing among multiple active gateways.

Supported ClusterXL Load Sharing modes also provide redundancy when a member fails.

Important — High Availability Is Not Zero Downtime

A High Availability deployment reduces the risk of interruption.

It does not guarantee that every application connection will remain uninterrupted.

Actual failover behavior depends on:

• Cluster health
• Network topology
• Interface monitoring
• State Synchronization
• Routing and switching behavior
• Software and hardware compatibility
• The nature of the failure

ClusterXL — High Availability and Load Sharing

ClusterXL is Check Point’s clustering technology for supported Security Gateways.

It provides several operating modes.

The two most familiar categories are:

• High Availability
• Load Sharing

Check Point also documents a distinct geographically distributed Active-Active mode.

1. ClusterXL High Availability — Active/Standby

In High Availability mode, one cluster member is Active.

Other members remain in Standby state.

The Active member processes the applicable traffic passing through the cluster.

If that member fails, an eligible Standby member can become Active.

Example

A company uses two Security Gateways:

Employees communicate through the shared Cluster Virtual IP.

If Gateway A fails:

1. The cluster detects the failure.
2. Gateway B becomes eligible to take over.
3. Gateway B assumes the Active role.
4. Network traffic is directed through Gateway B.
5. Supported connections may continue if the necessary state information and network conditions are available.

This is called failover.

Cluster Virtual IP Address

A Cluster Virtual IP is a logical address used by the cluster.

For example:

Internal computers can use:

192.168.10.1

as their default gateway.

They do not need to change the default gateway address merely because the Active cluster member changes.

2. What Is State Synchronization?

A stateful firewall tracks connection information.

For example, when an employee establishes a TCP connection to a server, the firewall maintains information about that connection.

If another firewall takes over without the required connection state, the existing session may fail.

State Synchronization helps address this problem.

It exchanges relevant connection information between supported cluster members.

Check Point describes two important synchronization mechanisms:

Full Synchronization

Transfers applicable connection-state information when a member joins or rejoins the cluster.

Delta Synchronization

Transfers updates representing changes to relevant connection information during normal operation.

Is State Synchronization Mandatory?

It depends on the mode.

Even when State Synchronization is enabled, every connection is not guaranteed to survive a failure.

Some connections may not be synchronized because of protocol behavior, synchronization settings, timing or other limitations.

3. ClusterXL Load Sharing — Multiple Active Members

In Load Sharing mode, multiple functioning cluster members actively process network traffic.

This can increase total cluster throughput in supported environments.

Unlike Active/Standby, traffic-processing work is distributed across active members.

Check Point provides two traditional Load Sharing methods.

Load Sharing Multicast

In Multicast mode:

1. Cluster Virtual IP addresses are associated with multicast MAC addresses.
2. Relevant packets sent to the cluster can reach all active members.
3. The ClusterXL decision function determines which member processes a packet or connection.
4. The members synchronize the necessary connection information.

A MAC address identifies a network interface at the Ethernet layer.

The Multicast approach requires compatible network equipment and configuration.

Load Sharing Unicast

In Unicast mode:

1. One cluster member acts as the Pivot.
2. The Pivot receives packets sent to the cluster.
3. It uses the ClusterXL decision function to determine which member should process traffic.
4. Applicable packets are forwarded to the selected member.
5. Members maintain the required synchronized connection information.

This design can be useful when the network cannot support the Multicast Load Sharing method.

Multicast vs Unicast Comparison

4. Geographically Distributed Active-Active

Check Point also provides a distinct Active-Active mode intended for supported geographically separated members.

In this mode:

• Members can operate at different sites.
• Each member processes the traffic routed to it.
• Supported connection-state synchronization can be configured.
• Traffic is not automatically balanced between the members.

This is different from ClusterXL Load Sharing Multicast and Unicast.

For example, two geographically separated gateways may each process connections routed to their location.

The amount of traffic handled by each member depends on the network routing design, not an automatic ClusterXL Load Sharing algorithm.

ClusterXL Mode Comparison

The number of supported members and available features depend on the operating mode and platform.

For standard ClusterXL High Availability and Load Sharing, R82.20 documents support for up to five members, subject to relevant limitations. More members do not necessarily mean better performance.

Gaia VRRP — Virtual IP Redundancy

VRRP stands for Virtual Router Redundancy Protocol.

It is a standardized protocol used to provide redundancy for an IP gateway address.

Check Point Gaia supports VRRP in documented configurations.

In the standard Active/Backup design, VRRP uses:

• A Master gateway
• A Backup gateway
• A Virtual Router Identifier (VRID)
• A shared Virtual IP address (VIP)

How VRRP Works

Consider two Gaia Security Gateways.

Gateway A is the VRRP Master.

Gateway B is the Backup.

The Master sends periodic VRRP advertisements.

These messages help the Backup determine whether the Master remains available.

If the Master fails, the Backup can assume ownership of the Virtual IP.

Connected devices can continue using the same configured default gateway address.

What Is a VRID?

A Virtual Router Identifier (VRID) identifies a particular VRRP virtual router group.

For example:

VRID: 5

Virtual IP: 192.168.10.1

Both Gaia devices participating in that VRRP group must have compatible configuration.

Does VRRP Synchronize Firewall Sessions?

VRRP itself is a virtual-router redundancy protocol.

It does not define Check Point firewall connection-state synchronization.

However, Check Point Gaia documents VRRP configurations with:

• ClusterXL enabled
• ClusterXL disabled

In the supported VRRP-with-ClusterXL configuration, Check Point State Synchronization can be enabled.

Therefore, the statement that VRRP never supports session synchronization is incorrect when applied to all Check Point deployments.

Simplified VRRP vs Advanced VRRP

Check Point Gaia offers two configuration methods.

Both are supported options for appropriate environments.

They must not be configured simultaneously on the same member.

Can Gaia VRRP Be Active/Active?

Yes, in a specific supported arrangement.

Check Point documents Active/Active VRRP when ClusterXL is disabled.

In this design:

• Different VRIDs can have different Master gateways.
• One gateway may be Master for one VRID and Backup for another.
• Only static routes are supported on the applicable VRRP interfaces.
• Check Point Firewall monitoring by VRRP must be disabled as documented.

This is not the same as ClusterXL Load Sharing.

It should not be presented as unrestricted load balancing of individual connections.

VRRP and Mixed-Vendor Environments

VRRP is a standards-based protocol.

However, this does not mean that an arbitrary Check Point firewall and another vendor’s firewall form a fully supported, state-synchronized security cluster.

VRRP protocol interoperability is different from firewall policy consistency, connection synchronization and official product support.

For production Check Point firewall HA, use a supported Check Point clustering design and verify the relevant compatibility requirements.

ClusterXL vs Gaia VRRP

Configuration, Verification and Troubleshooting

Creating a High Availability deployment requires planning before any configuration changes are made.

This section provides a beginner-friendly setup overview and safe verification procedures.

Part 1 — Plan the Cluster

Consider a two-member ClusterXL High Availability design.

Example Topology

These are illustrative lab addresses.

203.0.113.0/24 is reserved for documentation, not for real internet-facing production deployments.

Prerequisites

Confirm:

• Two compatible, supported Security Gateways
• Suitable software versions and licenses
• Correct interface and IP planning
• Compatible routing and switching infrastructure
• Required management connectivity
• A supported synchronization-network design
• SmartConsole administrative access
• Appropriate backups and change approval

Part 2 — Configure ClusterXL High Availability

Step 1 — Prepare the Cluster Members

Install and configure Check Point Gaia on both devices.

During the supported First Time Configuration Wizard, choose the appropriate Security Gateway installation type and clustering option.

Configure the required interfaces and establish connectivity to the Security Management Server.

Step 2 — Create a Cluster Object

In SmartConsole:

1. Connect to the Security Management Server.
2. Open the Objects menu.
3. Navigate to More object types → Network Object → Gateways and Servers → Cluster → New Cluster.
4. Select Wizard Mode for a supported installation.
5. Enter a unique cluster name.

For example:

SG_HA_Cluster

Step 3 — Add Cluster Members

Add both gateways.

For each member, provide the required:

• Member name
• Management IP address
• SIC activation information

SIC (Secure Internal Communication) establishes trusted communication between the Security Management Server and the managed gateway.

Verify that trust is established for both members.

Step 4 — Configure Cluster Interfaces

Define the relevant:

• Cluster interfaces
• Cluster Virtual IP addresses
• Synchronization interface
• Interface topology

The example cluster uses:

External VIP: 203.0.113.1

Internal VIP: 192.168.10.1

The synchronization network is separate:

10.255.255.0/30

Step 5 — Select High Availability Mode

Open the cluster properties.

Navigate to:

ClusterXL and VRRP

Select the supported:

High Availability and ClusterXL

configuration.

Review the applicable synchronization and failover settings.

Step 6 — Review State Synchronization

For ClusterXL High Availability, State Synchronization is optional but recommended when supported connection preservation is required.

Verify that the synchronization interface is configured correctly.

Check Point recommends a dedicated synchronization network.

Also consider how the configured synchronization delay may affect short-lived connections.

Step 7 — Publish and Install Policy

Publish the SmartConsole changes.

Install the applicable Access Control Policy on the cluster.

Confirm that policy installation completes successfully.

Step 8 — Verify Cluster Status

Do not consider the deployment ready merely because the policy installation succeeds.

Confirm the actual cluster state, interface health and synchronization status.

Part 3 — Read-Only ClusterXL Verification

The following commands are documented for supported ClusterXL environments.

Run these checks from an authorized cluster member.

Check 1 — Display Cluster State

In Expert mode:

cphaprob state

Or in Gaia Clish:

show cluster state

These commands display information such as:

• Cluster mode
• Cluster members
• Member states
• Member identifiers
• Relevant health information

For a healthy two-member High Availability cluster, expect:

The exact displayed state labels may vary according to the cluster’s condition and configuration.

Check 2 — Display Cluster Interface Status

In Expert mode:

cphaprob -a if

Review:

• Cluster interface availability
• Relevant monitored interfaces
• Synchronization interface information
• Cluster Virtual IPs where displayed

An unhealthy monitored interface can affect cluster status.

Check 3 — Review Synchronization Statistics

In Expert mode:

cphaprob syncstat

This command displays synchronization-related statistics.

Review the output for indications of synchronization problems.

Not every nonzero counter necessarily indicates an active failure; interpret statistics using the documented meanings and current cluster conditions.

Check 4 — Review Critical Devices

In Expert mode:

cphaprob list

This displays registered critical devices and their status.

Check Point uses critical-device monitoring, commonly called PNotes, to help determine whether a member is healthy enough to participate in the cluster.

Verification Command Summary

These are read-only checks.

They do not intentionally force a failover or modify the cluster configuration.

Part 4 — Verify Gaia VRRP

For a supported Gaia VRRP deployment, open Gaia Clish.

Run:

show vrrp

You can also review summary information:

show vrrp summary

Confirm the expected VRID, Master/Backup roles and Virtual IP information.

Where VRRP is deployed together with Check Point ClusterXL state synchronization, use the applicable supported cluster-status commands as well.

Part 5 — Practical Failover Verification

Common High Availability Problems

Best Practices

• Use a supported and compatible cluster design.
• Verify licensing and platform requirements.
• Configure a dedicated synchronization network where recommended.
• Keep relevant member configurations consistent.
• Monitor cluster and critical-device status.
• Verify interface health before making failover changes.
• Review routing and ARP behavior during troubleshooting.
• Test redundancy using controlled procedures.
• Keep backups of configuration and management data.
• Document operational and recovery procedures.

Key Takeaways

High Availability Fundamentals

• High Availability reduces the risk of service interruption.
• ClusterXL provides supported Check Point firewall redundancy and Load Sharing.
• High Availability and Load Sharing are different operating approaches.
• Virtual IP addresses provide a consistent logical cluster address.
• State Synchronization helps preserve supported connections during failover.

ClusterXL Operating Modes

• High Availability normally uses Active/Standby operation.
• Load Sharing Multicast uses multiple Active members with multicast-based packet delivery.
• Load Sharing Unicast uses a Pivot member to distribute traffic.
• Geographically distributed Active-Active processes traffic routed to individual members without automatic Load Sharing.
• Synchronization requirements differ between cluster modes.

Gaia VRRP

• VRRP provides virtual-IP redundancy.
• Traditional VRRP uses Master and Backup roles.
• Gaia supports VRRP with ClusterXL enabled or disabled in documented configurations.
• Restricted Active/Active VRRP configurations are possible when ClusterXL is disabled.
• VRRP interoperability does not automatically provide supported cross-vendor firewall session synchronization.

Verification

• cphaprob state checks ClusterXL member status.
• cphaprob -a if reviews cluster interfaces.
• cphaprob syncstat shows synchronization statistics.
• cphaprob list reviews critical-device status.
• show vrrp displays Gaia VRRP information.
• HA readiness requires testing, not just successful configuration.

Check Point High Availability provides different ways to improve the resilience of firewall environments.

ClusterXL High Availability uses redundant gateways to support failover.

ClusterXL Load Sharing allows multiple members to process traffic in parallel while providing supported redundancy.

Gaia VRRP provides virtual-router redundancy using Master and Backup roles, with additional supported Check Point clustering options.

Geographically distributed Active-Active is another distinct design and should not be confused with automatic ClusterXL Load Sharing.

The correct approach depends on the network topology, desired performance, platform compatibility and session-continuity requirements.

Administrators should validate cluster health, synchronization, interfaces and routing before relying on a High Availability deployment for business-critical traffic.

Useful Links and References

SanchitGurukul Static Resources

Official External References