|
|
|
In This Section: |
There are a number of OPSEC certified High Availability and Load Sharing products. These products are used to build highly available Security Gateway clusters and to distribute traffic evenly among the clustered Security 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:
OPSEC certified clustering products use Check Point state synchronization mechanism to exchange and update connection data and other states between cluster members.
This section is general guidelines for working with OPSEC certified clustering products. Configuration details vary for each clustering product. Follow the instructions supplied with the OPSEC product.
This procedure describes how to configure an OPSEC certified Security Gateway clustering solution.
Follow the instructions in your clustering product documentation for:
To prepare the cluster members:
|
After the installation completes, make sure that 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.
cpconfig utility):Using SmartDashboard, create the Cluster object. To define a new Cluster object, right click the Network Objects tree, and choose New Check Point > Cluster Configuration of the Cluster Object can be performed using:
To use Classic Mode configuration with OPSEC:
In the list of Check Point Products, ensure ClusterXL is not selected.
You can also add an existing Security Gateway as a cluster member by selecting Add > Add Gateway to Cluster in the Cluster Members page and selecting the Security Gateway from the list in the Add Gateway to Cluster window.
If you want to remove a Security 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.
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.
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.
The synchronization mechanism, or the OPSEC certified clustering product, must identify valid non-sticky connections. This is necessary to allow these connections to go through the cluster.
Find out whether or not the OPSEC certified clustering product can identify valid non-sticky connections.
If the
Hide Cluster Members' outgoing traffic behind the Clusters IP Address
option is enabled, enable Support non-sticky connections to support outgoing connections from a standby member (unless specifically directed by OPSEC certified clustering product guide).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 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 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 Topology tab. Refer to your clustering product documentation for additional information.
|
Note - When you create an IPSO VRRP or IPSO IP cluster with version 3.9 and later, You must deactivate monitor fw state before the first Policy installation. If you do not do this, the Get Interfaces operation in the Topology section of the Gateway Cluster Properties window fails. After Policy installation, the monitor fw state feature can be re-enabled. |
This section describes the behavior of specific command lines in OPSEC clusters.
|
Note - For details of the |
The behavior of the cphastart and cphastop 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.
In OPSEC clusters, the cphaprob 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 -d <device> -t <timeout(sec)> -s {ok|init|problem} [-p] register
cphaprob -f <file> register cphaprob -d <device> [-p] unregister cphaprob -d <device> -s {ok|init|problem} report
cphaprob [-l] [-ia] [-e] list cphaprob state cphaprob [-a] if |
cphaprob state: When running this command, the member state is only Check Point status and is not really a member 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 member (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 member.)