High Availability Mode

The ClusterXL Cluster of Check Point Security Gateways that work together in a redundant configuration. The ClusterXL both handles the traffic and performs State Synchronization. These Check Point Security Gateways are installed on Gaia OS: (1) ClusterXL supports up to 5 Cluster Members, (2) VRRP Cluster supports up to 2 Cluster Members, (3) VSX VSLS cluster supports up to 13 Cluster Members. Note: In ClusterXL Load Sharing mode, configuring more than 4 Cluster Members significantly decreases the cluster performance due to amount of Delta Sync traffic. High Availability A redundant cluster mode, where only one Cluster Member (Active member) processes all the traffic, while other Cluster Members (Standby members) are ready to be promoted to Active state if the current Active member fails. In the High Availability mode, the Cluster Virtual IP address (that represents the cluster on that network) is associated: (1) With physical MAC Address of Active member (2) With virtual MAC Address. Synonym: Active/Standby. Acronym: HA. mode provides basic High Availability capabilities in a cluster Two or more Security Gateways that work together in a redundant configuration - High Availability, or Load Sharing. environment. This means that the cluster can provide Firewall services even when it encounters a problem, which on a regular Security Gateway Dedicated Check Point server that runs Check Point software to inspect traffic and enforce Security Policies for connected network resources. results in a complete loss of connectivity. When combined with Check Point State Synchronization Technology that synchronizes the relevant information about the current connections (stored in various kernel tables on Check Point Security Gateways) among all Cluster Members over Synchronization Network. Due to State Synchronization, the current connections are not cut off during cluster failover., ClusterXL High Availability can maintain connections through failover Transferring of a control over traffic (packet filtering) from a Cluster Member that suffered a failure to another Cluster Member (based on internal cluster algorithms). Synonym: Fail-over. events, in a user-transparent manner, allowing a flawless connectivity experience. As a result, High Availability provides a backup (1) In VRRP Cluster on Gaia OS - State of a Cluster Member that is ready to be promoted to Master state (if Master member fails). (2) In VSX Cluster configured in Virtual System Load Sharing mode with three or more Cluster Members - State of a Virtual System on a third (and so on) VSX Cluster Member. (3) A Cluster Member or Virtual System in this state does not process any traffic passing through cluster. mechanism, which organizations can use to reduce the risk of unexpected downtime, especially in a mission-critical environment (such as money transactions).

To achieve this, ClusterXL High Availability mode designates one of the Cluster Members as the Active State of a Cluster Member that is fully operational: (1) In ClusterXL, this applies to the state of the Security Gateway component (2) In 3rd-party / OPSEC cluster, this applies to the state of the cluster State Synchronization mechanism. member, while the other Cluster Members remain in Standby State of a Cluster Member that is ready to be promoted to Active state (if the current Active Cluster Member fails). Applies only to ClusterXL High Availability Mode. mode. The cluster associates the Virtual IP addresses with the physical MAC addresses of the physical interfaces on the Active member (by matching the cluster Virtual IP address with the unique MAC address of the appropriate physical interface). Therefore, all traffic directed at the cluster Virtual IP addresses, is actually routed (and filtered) by the Active Cluster Member Security Gateway that is part of a cluster..

The role of each Cluster Member is chosen according to its cluster state and Cluster Member priority. Cluster Member priorities correspond to the order, in which they appear in the Cluster Members page of the cluster object in SmartConsole Check Point GUI application used to manage a Check Point environment - configure Security Policies, configure devices, monitor products and events, install updates, and so on.. The top-most Cluster Member has the highest priority. You can modify this ranking at any time (requires policy installation and causes a failover).

In addition to its role as a Firewall, the Active Cluster Member is also responsible for informing the Standby Cluster Members of any changes to its cluster state and kernel tables. This keeps the peer Cluster Members up-to-date with the current traffic passing through the cluster.

Whenever the Active Cluster Member detects a problem that is severe enough to prevent this Cluster Member from working correctly, failover occurs in the cluster. One of the Standby Cluster Members (the Cluster Member with the next highest priority) assumes the role of the Active Cluster Member. If State Synchronization is enabled, the new Active Cluster Member recognizes any open connections and handles them according to their last known state.

Upon the recovery of a failed former Active Cluster Member with a higher priority, the role of the Active Cluster Member may or may not be switched back to that Cluster Member. This depends on the cluster object configuration - Maintain current active Cluster Member, or Switch to higher priority Cluster.

It is important to note that Standby Cluster Members may encounter problems as well. In this case, in the event of a cluster failover, the Standby Cluster Members are not considered for the role of a new Active Cluster Member.

Example

This scenario describes a connection from a Client computer on the external network to a Web server behind the Cluster (on the internal network).

The cluster of two members is configured in High Availability mode.

Example topology:

               [Client on]
            [external network]
           {IP 192.168.10.78/24}
            {DG 192.168.10.100}
                     |
                     |
          {VIP 192.168.10.100/24}
          /                    \
         |                      |
{IP 192.168.10.1/24}  {IP 192.168.10.2/24}
         |                      |
     {Active}               {Standby}
     [Member1]-----sync-----[Member2]
         |                      |
 {IP 10.10.0.1/24}      {IP 10.10.0.2/24}
         |                      |
          \                    /
           {VIP 10.10.0.100/24}
                     |
                     |
             {DG 10.10.0.100}
            {IP 10.10.0.34/24}
             [Web server on]
            [internal network]

Chain of events:

The user tries to connect from his Client computer 192.168.10.78 to the Web server 10.10.0.34.
The Default Gateway on Client computer is 192.168.10.100 (the cluster Virtual IP address).
The Client computer issues an ARP Request for IP 192.168.10.100.
The Active Cluster Member (Member1) handles the ARP Request for IP 192.168.10.100.
The Active Cluster Member sends the ARP Reply with the MAC address of the external interface, on which the IP address 192.168.10.1 is configured.
The Client computer sends the HTTP request packet to the Active Cluster Member - to the VIP address 192.168.10.100 and MAC address of the corresponding external interface.
The Active Cluster Member handles the HTTP request packet.
The Active Cluster Member sends the HTTP request packet to the Web server 10.10.0.34.
The Web server handles the HTTP request packet.
The Web server generates the HTTP response packet.
The Default Gateway on Web server computer is 10.10.0.100 (the cluster Virtual IP address).
The Web server issues an ARP Request for IP 10.10.0.100.
The Active Cluster Member handles the ARP Request for IP 10.10.0.100.
The Active Cluster Member sends the ARP Reply with the MAC address of the internal interface, on which the IP address 10.10.0.1 is configured.
The Web server sends the HTTP response packet to the Active Cluster Member - to VIP address 10.10.0.100 and MAC address of the corresponding internal interface.
The Active Cluster Member handles the HTTP response packet.
The Active Cluster Member sends the HTTP response packet to the Client computer 192.168.10.78.
From now, all traffic between the Client computer and the Web server is routed through the Active Cluster Member (Member1).
If a failure A hardware or software problem that causes a Security Gateway to be unable to serve as a Cluster Member (for example, one of cluster interface has failed, or one of the monitored daemon has crashed). Cluster Member that suffered from a failure is declared as failed, and its state is changed to Down (a physical interface is considered Down only if all configured VLANs on that physical interface are Down). occurs on the current Active Cluster Member (Member1), the cluster fails over.
The Standby Cluster Member (Member2) assumes the role of the Active Cluster Member.
The Standby Cluster Member sends Gratuitous ARP Requests to both the 192.168.10.x and the 10.10.0.x networks.

These GARP Requests associate the Cluster Virtual IP addresses with the MAC addresses of the physical interfaces on the new Active Cluster Member (former Standby Cluster Member):
- Cluster VIP address 192.168.10.100 and MAC address of the corresponding external interface, on which the IP address 192.168.10.2 is configured.
- Cluster VIP address 10.10.0.100 and MAC address of the corresponding internal interface, on which the IP address 10.10.0.2 is configured.
From now, all traffic between the Client computer and the Web server is routed through the new Active Cluster Member (Member2).
The former Active member (Member1) is now considered to be "down State of a Cluster Member during a failure when one of the Critical Devices reports its state as "problem": In ClusterXL, applies to the state of the Security Gateway component; in 3rd-party / OPSEC cluster, applies to the state of the State Synchronization mechanism. A Cluster Member in this state does not process any traffic passing through cluster.". Upon the recovery of a former Active Cluster Member, the role of the Active Cluster Member may or may not be switched back to that Cluster Member, depending on the cluster object configuration.