Working with OPSEC Certified Clustering Products

Introduction to OPSEC Certified Clustering Products

There are a number of OPSEC certified High Availability (sometimes called as Hot Standby) and Load Sharing (sometimes called Load Balancing) products. These products are used to build highly available Security Gateway clusters and to distribute traffic evenly among the clustered gateways.

Each OPSEC certified clustering application has its particular strengths and capabilities, whether it is monitoring, management, or performance. The role of these clustering applications is to:

1. Decide which cluster member will deal with each connection.
2. Perform health checks. This involves checking the status of a cluster member (for example, Active, Standby, or Down), and checking the status of the member interfaces.
3. Perform failover.

OPSEC certified clustering products use Check Point state synchronization mechanism (described in Synchronizing Connection Information Across the Cluster) to exchange and update connection information and other states between cluster members.

This guide provides general guidelines for working with OPSEC certified clustering products. Configuration details vary for each clustering product. You are therefore urged to follow the instructions supplied with the OPSEC product.

Configuring OPSEC Certified Clustering Products

This procedure describes how to configure an OPSEC certified Security Gateway clustering solution.

Preparing the Switches and Configuring Routing

Follow the instructions in your clustering product documentation for:

• Preparing the switches and routers
• Configuring routing

Preparing the Cluster Member Machines

To prepare the cluster member machines:

1. Define IP addresses for all interfaces on all the cluster members.
2. Connect the cluster network machines, via the switches. For the Synchronization interfaces, a cross-over cable or a dedicated switch is recommended.

   Note - It is possible to run synchronization across a WAN. For details, see Synchronizing Clusters over a Wide Area Network.

3. For IPSO clusters, configure VRRP or IP Clustering before installing Check Point Security Gateway.
4. For OPSEC certified clusters, follow the vendor recommendations.

   After the installation has finished, make sure that the Enable VPN-1/FW-1 monitoring is set to Enable in the IPSO configuration manager. This assures that IPSO will monitor changes in the status of the firewall. For VRRP and IP Clustering in IPSO 3.8.2 and above, the state of the firewall is reported to the IPSO cluster for failover purposes.

5. Install Check Point Security Gateway on all cluster members. During the configuration phase (or later, using the cpconfig Configuration Tool):
   • Install a license for Check Point Security Gateway on each cluster member. No special license is required to allow the OPSEC certified product to work with the Security Gateway.
   • During the configuration phase, enable State Synchronization by selecting Enable cluster membership for this gateway on Unix machines, or This Gateway is part of a cluster on Windows.

SmartDashboard Configuration for OPSEC Clusters

Using SmartDashboard, create the Gateway Cluster object. To define a new Gateway Cluster object, right click the Network Objects tree, and choose New Check Point > Gateway Cluster…. Configuration of the Gateway Cluster Object can be performed using:

• Simple Mode (Wizard) which guides you step by step through the configuration process. See the online help for further assistance.
• Classic Mode, described below.

Classic Mode Configuration

To use Classic Mode configuration with OPSEC:

1. In the General Properties page of the Gateway Cluster object, give the cluster a general IP address. In general, make it the external virtual IP address of the cluster.

   In the list of Check Point Products, ensure ClusterXL is not selected.

2. In the Cluster Members page, click Add > New Cluster Member to add cluster members to the cluster. Cluster members exist solely inside the Gateway Cluster object. For each cluster member:
   • In the Cluster Members Properties > General tab, define a name a Name and IP Address. Choose an IP address that is routable from the Security Management server so that the Security Policy installation will be successful. This can be an internal or an external address, or a dedicated management interface.
   • Click Communication, and Initialize Secure Internal Communication (SIC).
   • Define the NAT and VPN tabs, as required.

   You can also add an existing gateway as a cluster member by selecting Add > Add Gateway to Cluster in the Cluster Members page and selecting the gateway from the list in the Add Gateway to Cluster window.

   If you want to remove a gateway from the cluster, click Remove in the Cluster Members page and select Detach Member from Cluster or right-click on the cluster member in the Network Objects tree and select Detach from Cluster.

3. In the 3rd Party Configuration page, specify the cluster operating mode, and for the 3rd Party Solution, select OPSEC, and check Use State Synchronization.
4. The Topology page is used to define the virtual cluster IP addresses and cluster member addresses.

   For each cluster member, define the interfaces for the individual members.

   For OPSEC certified products, the configuration of virtual cluster IPs is mandatory in several products, while in others it is forbidden. Refer to your cluster product documentation for details.

   Define the synchronization networks. Depending on the OPSEC implementation, it might be possible to "get" the synchronization network from the OPSEC configuration if it is already defined. Refer to the OPSEC documentation to find out if this feature is implemented for a specific OPSEC product.

5. Now go back to the 3rd Party Configuration page.

   A non-sticky connection is one in which packets from client to server and from server to client pass through different cluster members. Non-sticky connections are a problem because they can lead to out-of-state packets being received by the cluster member. The Security Gateway will reject out-of-state packets, even if they belong to a valid connection.

   Either the synchronization mechanism, or the OPSEC certified clustering product need to be able to identify valid non-sticky connections, so that the Security Gateway will allow those connections through the cluster.

   Find out whether or not the OPSEC certified clustering product can identify valid non-sticky connections.

   • If the clustering product cannot identify valid non-sticky connections, the synchronization mechanism can do so instead. In that case, check Support non‑sticky connections.
   • If the clustering product can identify valid non-sticky connections, the synchronization mechanism does not have to take care of this. In that case, uncheck Support non-sticky connections. Usually it is safe to uncheck this option in High Availability solutions (not in Load Sharing). Clearing this option will lead to a slight improvement in the connection establishment rate.

     If the Hide Cluster Members' outgoing traffic behind the Clusters IP Address option is checked, Support non-sticky connections should also be checked to support outgoing connections from a standby machine (unless specifically directed by OPSEC certified clustering product guide).

6. Many gateway clusters have a virtual cluster IP address that is defined in Topology page of the cluster object, in addition to physical cluster member interface addresses. The use of virtual cluster IP addresses affects the settings in the 3rd Party Configuration page.

   When a client behind the cluster establishes an outgoing connection towards the Internet, the source address in the outgoing packets, is usually the physical IP address of the cluster member interface. If virtual cluster IP addresses are used, the clustering product usually changes the source IP address (using NAT) to that of the external virtual IP address of the cluster.

   This corresponds to the default setting of Hide Cluster Members' outgoing traffic behind the Cluster's IP address being checked.

   When a client establishes an incoming connection to the external virtual address of the cluster, the clustering product changes the destination IP address (using NAT) to that of the physical external address of one of the cluster members.

   This corresponds to the default setting of Forward Cluster's incoming traffic to Cluster Members' IP addresses being checked. In the Topology page, define the interfaces for the individual members. In most OPSEC solutions, cluster IPs should not be added to the individual member's Topology tab. Refer to your clustering product documentation for additional information.

7. Define the other pages in the cluster object as required (NAT, VPN, Remote Access, and so on).
8. Install the Security Policy on the cluster.

   Note - When defining an IPSO VRRP or IP cluster of IPSO version 3.9 and later, the monitor fw state feature should be disabled before the first policy installation. Failing to do so impedes the setting of the cluster IP addresses, and consequently the Get Interfaces operation in the Topology section of the Gateway Cluster Properties window will fail. After policy installation, the monitor fw state feature can be re-enabled.

CPHA Command Line Behavior in OPSEC Clusters

This section describes the behavior of specific command lines in OPSEC clusters.

The cphastart and cphastop Commands in OPSEC Clusters

The behavior of the cphastart and cphasstop commands on ClusterXL clusters are described in The cphastart and cphastop Commands.

On OPSEC clusters, the cphastart command may not cause the cluster member to start working. On IPSO clusters the behavior is the same as with ClusterXL clusters.

The cphastop command may not cause failover on OPSEC clusters. On IPSO IP Clustering clusters (but not on VRRP clusters), the behavior is the same as with ClusterXL clusters.

As with ClusterXL clusters, these commands should only be run by the Security Gateway, and not directly by the user.

The cphaprob Command in OPSEC Clusters

Use the cphaprob command to verify that the cluster and the cluster members are working properly. This command is relevant only for IPSO IP clustering and IPSO VRRP.

In non-IPSO OPSEC clusters the command output is either empty or the command does not have any effect.

To produce a usage printout for cphaprob that shows all the available commands, type cphaprob at the command line and press Enter. The meaning of each of these commands is explained in the following sections.

cphaprob state: When running this command, the machine state is only Check Point status and is not really a machine status. The command only monitors full sync success, and if a policy was successfully installed. For IP clustering, the state is accurate and also includes the status of the IPSO Cluster. For VRRP, the status is accurate for a firewall, but it does not correctly reflect the status of the IPSO machine (for example, it does not detect interface failure).

cphaprob [-a] if: Shows only the relevant information - interface name, if it is a sync interface or not. "Multicast"/"Broadcast" refers to the cluster control protocol and is relevant only for the sync interface. Note that the status of the interface is not printed since it is not monitored. (This also applies in the IPSO machine.)