Check Point ClusterXL

We now take a look at the Check Point ClusterXL clustering solution. ClusterXL FP3 can actually be configured to work in three different modes. Each mode provides different functionality and has differences in the underlying clustering mechanisms:

• HA New mode New mode gateways maintain online, unique IP addresses in addition to Virtual IP (VIP) addresses that are shared over the cluster. Traffic for the VIP is handled by the master gateway only.

• HA Legacy mode (as available in previous versions of ClusterXL) Provides HA by providing standby gateways configured with the same addresses as the master gateway. The standby gateway interfaces remain disabled unless the master fails, and the gateway is promoted to master.

• Load Sharing mode As with HA New mode, all gateways have unique IPs and shared VIPs. However, all gateways are "live" and share the traffic load.

We begin by looking at HA New mode.

Configuring ClusterXL in HA New Mode

In this section, we describe how to configure Check Point FireWall-1 ClusterXL in HA New mode. In this example, we set up a two-member HA cluster using ClusterXL. Before we proceed with configuring the cluster, we need to make sure that we are starting from a point at which all the other essential tasks have already been completed.

Prerequisites for Installing ClusterXL in HA New Mode

Before configuring the cluster for HA New mode, you need to complete the following tasks:

• Design your cluster and know all the IP addresses and VIP addresses that your cluster will have. (You need one VIP per connected network other than the sync net. For details, see the "How Does ClusterXL HA New Mode Work?" section of this chapter).

• Plug all your multihomed hosts together using hubs (or switches) and checked IP connectivity between them.

• Make sure that your routers and adjacent hosts on either side of your cluster have default routes set to the adjacent VIP of the cluster (even though the IP address does not exist yet!).

• Make sure that you have added host names that resolve to IP addresses in the hosts files on all the hosts that will be part of the cluster—including the host that will be the management station.

• Your firewall modules should be installed and ready to communicate with your firewall management station (SmartCenter Server).

• Make sure that your management station is operating correctly. You can connect with the SmartDashboard GUI and see the object for your management station.

• If you're working on the Solaris platform, it is strongly recommended that you configure the network interfaces to use unique MAC addresses (they are the same by default). This can be done using the command:

  eeprom local-mac-address?=true

• You would then need to reboot the Solaris host for the change to take effect. Type ifconfig –a. You should see that each interface now has a unique MAC address. This step will simplify testing and prevent problems that might occur if you are using switches.

Once this process is completed, you should have something similar to Figure 21.12. In our example, hubs have been used, so obviously no special switch configuration is required.

Figure 21.12: A Simple Topology for ClusterXL in HA New Mode

Configuration of ClusterXL HA New Mode

There are a number of ways in which you can create the cluster configuration and end up with the same results. When creating a new cluster in NG FP3, you can decide to create your firewall modules first and then add them to a cluster object, or you can create the cluster object first and define the firewall modules directly in the cluster object. Usually, if you are setting everything from scratch, it is probably quicker to create all your modules and trusts directly in the cluster object.

In this example, we create a cluster object first and define our first module (referred to as fw1 in this example) and make sure we can push a policy just to this new cluster object. We then configure the second module (referred to as fw2) as a stand-alone module, set up the trust, and push a policy to that. The final stage is to add the fw2 module to the cluster and then install the policy.

The following steps will enable us to achieve this goal.

Step 1: Creating a Gateway Cluster Object and Setting Up the Trust

Our first configuration steps aim to build a cluster consisting of just one enforcement module and test it by installing a policy:

1. In SmartDashboard, create a Gateway Cluster object (Manage | Network Objects | New | Check Point | Gateway Cluster. You will see the Gateway Cluster Properties window pop up, as shown in Figure 21.13.

   
   Figure 21.13: Gateway Cluster Properties Screen

2. Fill in the name of the cluster. In our example, we called it fwcluster. We gave the object primary IP as the external VIP address—195.166.16.130. We then checked the boxes for FireWall-1 (which is mandatory), VPN-1 Pro (because we plan to set up VPNs), ClusterXL (because we want to use the Check Point cluster solution), and SecureClient Policy Server (because we want to use SecureClients).

3. Click Cluster Members on the left side of the screen. This is where we add the enforcement modules into our new cluster (see Figure 21.14).

   
   Figure 21.14: The Cluster Members Screen Before Any Members Have Been Added

4. Clicking the New button will allow you to define a new firewall enforcement module that will be part of the cluster. In the Name field, enter the host name of this module. The IP address is the one chosen as the primary IP for that module, and the host name should resolve to this address consistently across all modules. Usually, the primary IP is that of the Internet-facing interface. In our example, the name is fw1 and the address is 195.166.16.131, as shown in Figure 21.15. Note that it would not be possible to use the external IP as the primary address if you were using HA Legacy mode, because the module's only unique address is that of the secured interface.

   
   Figure 21.15: Defining the Cluster Member

   Warning

   Always use the member host name as the object name and then use the Get address button to test that the management station resolves the member host name correctly. If it does not, investigate this problem before proceeding further.

5. You now need to establish communication with the module. Click the Communication button. Clicking this button will pop up the window shown in Figure 21.16, in which you need to enter the secret password that you used when you installed this enforcement module. (Make sure that the module is started at this point.) Use this password in the Activation Key field and the Confirm Activation Key field. At first the trust state is Uninitialized. Click the Initialize button to set up the trust between the management station and the firewall enforcement module. Wait a short while, and then you should then see the window change to update the trust state to Trust established, as shown in Figure 21.17. Once trust has been established, click the Close button.

   
   Figure 21.16: Uninitialized Trust between the Management Module and a Cluster Member

   
   Figure 21.17: Trust Established between the Management Module and a } Cluster Member

   Note

   It's a good idea to click the Test SIC Status button to ensure that the trust is working. When you click this button, you should get a pop-up window that reads, "SIC Status for fw1: Communicating." If you do not, you have a problem with the management station communicating with the firewall enforcement module and this situation will need to be rectified. Check routing and any intermediate firewall policies. If you manage intermediate firewalls from this management station, you should save the new cluster object without configuring communication, and then push a policy to those firewalls.

6. Click the Topology tab of the cluster, and click Get topology. This step should get the topology of your module, including IP addresses, netmasks, and IP addresses behind interfaces, where appropriate; an example is shown in Figure 21.18. Click the Accept button once you are happy with the topology obtained. Now select the interface that you are going to use as your sync interface—referred to as the Secured Network in the Check Point manuals. In our example, our sync network is on 192.168.11.131, on interface hme0. Double-click this interface. You will be presented with a new pop-up window, as shown in Figure 21.19.

   
   Figure 21.18: Module Topology

   
   Figure 21.19: Defining the Secured Interface on One Member of the Cluster

   In the pop-up window, make sure that you uncheck the Cluster Interface check box so that the firewall module knows that this network will not have a VIP address. If you don't uncheck this box, you will receive a warning later in the configuration.

   Click the Topology tab of this window. This allows you to define antispoofing for this interface. Select Network Defined by the interface and netmask for this example (see Figure 21.20).

   
   Figure 21.20: Antispoofing Properties of the Secure Interface of a Module

   Click OK when finished. You should now be on the Topology tab of the Cluster Members Properties window. Don't worry about the VPN and NAT details for now. Click OK again, and you should be looking at the Cluster Members screen (see Figure 21.21). You should see that the first cluster member has been defined.

   
   Figure 21.21: Cluster Members Screen After First Member Has Been Defined

   At this stage, you could add further cluster members using the New button, but we will use the Add button later to add an existing firewall enforcement module to the cluster.

7. Click ClusterXL on the left side of the screen. This screen shows you the mode that ClusterXL will work in (see Figure 21.22). In this example, the defaults are High Availability in New mode, which we have selected. We have also left the "Upon Gateway recovery" setting at Maintain current active gateway. This means that when a member in the cluster fails and then the member returns, all the traffic will still go through the second firewall member. The effect of this choice is that failback is a manual process.

   
   Figure 21.22: Configuring the ClusterXL Mode of Operation

8. Now click the Synchronization tree item. This screen, as shown in Figure 21.23, allows you to define the sync network. The cluster members should have interfaces on this network that are not cluster interfaces (defined in the cluster member interfaces details). It is possible to define multiple sync networks here in order to provide resilience. In our example, we define a sync network 192.168.11.0, subnet mask 255.255.255.0. To do so, click the Add button. A pop-up window will appear (see Figure 21.24). Enter the network name (of your choice), network address, and subnet mask. Click OK when you're done. Once this process is completed, you should see something similar to Figure 21.25.

   
   Figure 21.23: Defining the State Synchronization Network

   
   Figure 21.24: The State Synchronization Window

   
   Figure 21.25: Our Completed Synchronization Network Definition

   Warning

   State synchronization must be used if connection resilience is required (in other words, connections are maintained during a cluster failover).

9. We now need to define the cluster's network topology. This is where you define the cluster's VIP addresses. Click the Topology item on the left side of the screen (see Figure 21.26). Click the Add button. A pop-up window (see Figure 21.27) will appear to allow you to create a VIP address and provide it with a netmask.

   
   Figure 21.26: The Topology Screen of Cluster Before Topology Has Been Defined

   
   Figure 21.27: Cluster Topology Definition: Defining the External Virtual IP Address

10. Next, click the Topology tab of the Interface Properties window (see Figure 21.28). Select this as the external interface because this is the Internet-facing VIP address on our cluster and we need to make sure that antispoofing is enabled.

    
    Figure 21.28: Topology of Cluster: External Interface Definition of the Cluster

11. Select the Member Network tab of the Interface Properties window (see Figure 21.29). This tab determines which interfaces the VIP address will function on. By default, it picks up the network and subnet mask of any interfaces you have already defined in the same subnet. However, the VIP address and the physical interfaces that the VIP address will "listen" on do not have to be the same subnet. In our example, the VIP address is in the same subnet as our external interfaces.

    
    Figure 21.29: The Member Network Tab of the Cluster's Interface Properties

12. Click OK when you have defined the network. Doing so brings you back to the screen in Figure 21.26, but this time, you will have the external VIP address of the cluster defined. You need to repeat steps 9–11 for all the interfaces of the cluster. In our example:

    • DMZ, Virtual IP = 192.168.12.130, internal, network defined by this IP address and subnet, member network = 192.168.12.0, subnet = 255.255.255.0.

    • Internal, Virtual IP = 192.168.1.130 , internal, network defined by this IP address and subnet, member network = 192.168.1.0, subnet = 255.255.255.0.

    When this process is completed, the cluster topology screen should look like Figure 21.30.

    
    Figure 21.30: The Completed ClusterXL Topology Definition

13. This completes the definition of the cluster module for just one cluster member. Click OK to complete the creation of the Cluster Gateway object. When you click OK, you will see the message shown in Figure 21.31. An IKE certificate is being created for the cluster object itself. Note that this would replace any IKE certificates that existed for any enforcement modules if we had added them to the cluster.

    
    Figure 21.31: The IKE Certificate Message Displayed When You Click OK

Step 2: Installing a Simple Security Policy to the New Cluster

Create a simple policy—perhaps even "Any source, any destination, any service, accept, log." At this point, we won't try any NAT or VPNs or otherwise run before walking. As we installed Policy Server on the module, we will also create a simple "open" desktop security policy. These policies are clearly insecure; don't connect the cluster to untrusted networks yet, but do keep all its interfaces "up." The idea here is to create a very simple rule base for testing the cluster:

1. Once the policies are ready, click the Policy | Install menu, as shown in Figure 21.32. The new cluster object should appear in the possible targets. Select the cluster object (only) and click OK. The FireWall-1 SmartCenter Server will then proceed to compile and install the policy to each cluster member (of which there is only one defined at present!).

   
   Figure 21.32: Policy Install to the Cluster: Single Member Only

2. Hopefully the policy will install successfully. If it does not, possible causes could be a configuration error in the cluster object (although this is usually indicated at the time of configuration) or connectivity to the cluster. Assuming all went well, you now have configured a one-member ClusterXL HA New mode cluster. At this point, it is a good idea to check the cluster's health. You can start the SmartView Status client, and you should be able to see the status, as shown in Figure 21.33. Check that the cluster member is active and that all the components in the cluster object show a green tick, which indicates that they are functioning correctly. You might see a warning against ClusterXL; possible causes are that an interface is down or HA is not enabled on the cluster member. In addition, take note of the working mode stated in the ClusterXL Details window. It should say High availability.

   
   Figure 21.33: SmartView Status Showing Cluster with Single Member

Step 3: Adding a Second Enforcement Module to the Cluster

We are now in a position where a Gateway Cluster object has been defined and has one member, and all appears to be working fine.

In our example, let's add an existing enforcement module to the cluster. If there were no existing module, we would add a new enforcement module to the cluster, following the same steps we used to add the first member. We will then push a policy to our newly expanded cluster.

Our existing enforcement module object is shown in Figure 21.34. Before proceeding, it is important to be happy that this module is working fine as a stand-alone gateway. Ensure that the Check Point products installed on this gateway (in reality and on the object!) match those of the new cluster object.

Figure 21.34: Existing FireWall-1 Gateway Object

1. To start the process of adding the existing gateway into our cluster, edit the Gateway Cluster object. Click Cluster Members in the left side menu. Click the Add button to add an existing firewall module to the cluster. Select our existing fw2 gateway module and click OK (see Figure 21.35).

   
   Figure 21.35: Adding a Firewall Gateway to a Cluster Object

   Warning

   You might not see an existing gateway object when you attempt to add a gateway into the cluster. This could be due to the gateway being a member of a VPN community. The procedure of adding the gateway to a cluster removes the gateway VPN configuration, so this is not allowed while the gateway is a community member. You must remove the gateway from the community using VPN Manager before adding the gateway to the cluster.

2. When you select OK, you will receive the warning shown in Figure 21.36. Click Yes to proceed.

   
   Figure 21.36: fw2 Adding to Cluster Warning Message

   Warning

   Adding the gateway to the cluster will remove the gateway VPN configuration. Restoring the VPNs will require configuration of the cluster VPN settings, but it could also require reconfiguration at the remote VPN end points. They will need to refer to your VPN gateway using the new VIP address of the cluster, and if the VPN is certificate based, the new IKE certificate must be distributed.

3. We need to identify which of this member's interfaces is on the secured network. Edit the member and click the Topology tab. Double-click the interface that is going to be on your secured network (in this example, hme0, which is on 192.168.11.132). Make sure you uncheck the Cluster Interface check box (see Figure 21.37).

   
   Figure 21.37: Selecting the Interface That Will Be the Secured Network

4. Your Cluster Members screen should now have two modules as members (fw1 and fw2), as shown in Figure 21.38. Note that if you click one, you can then promote or demote its priority in the cluster. This determines which one will be online initially.

   
   Figure 21.38: A Cluster Gateway Showing Two Cluster Members

5. Click OK. You can now install the test policy to the cluster gateway module, which now has two members.

   Warning

   It is recommended that you reboot the module that you have just added. After pushing a policy to a stand-alone module that requires that it becomes a cluster member, the ClusterXL module might not fully configure itself immediately. You could find that the active online member complains about the status of this new inactive member of the cluster (use the cphaprob state command on the online member or the SmartView Status GUI). Rebooting the offline member should remedy this situation.

   Note

   A new installation of an NG FP3 module inherits a full license for a 15-day trial period. It could well be that we have gotten this far in installation and configuration without actually adding a valid purchased license. Now is a good time to use the SmartUpdate management client to attach your purchased licenses to the cluster members, rather than forget and get a nasty surprise in 15 days.

Testing ClusterXL in HA New Mode

Once you have ClusterXL in HA New mode up and running, you will want to test it to ensure that it is functioning properly. There are many ways in which you can do this; we now look at three simple tests that you can perform.

Test 1: Pinging the Virtual IP Address of Each Interface

With ClusterXL in HA New mode, you should be able to ping the VIP address of each network from an adjacent host—providing that your security policy allows such an action. This is a useful test for a number of reasons:

• It tests that the VIP address is up and running.

• It identifies which of the members is replying to your ping. Look at the MAC address that you receive in your local workstation ARP cache. To view the ARP cache, use the command arp –a.

In our example (based on Figure 21.12), we log on to the host on IP 192.168.1.200 (PDC) and ping the VIP of 192.168.1.130. If host fw1 is active (therefore fw2 is on standby), we would expect to see the MAC address of 08:00:20:ca:64:fb in the ARP cache of 192.168.1.200. The reason why we know that fw1 is active is that the MAC address 08:00:20:ca:64:fb is the internal interface (qfe3) MAC address for fw1. If there was a failover to fw2, we would see the MAC address of the internal interface of member fw2 (08:00:20:a4:99:ef).

Test 2: Using SmartView Status to Examine the Status of the Cluster Members

When using ClusterXL, we use the SmartView Status GUI to monitor what each member in our cluster is doing. We are also able to stop and start the ClusterXL module on a member from this GUI. This tool can be used to manually fail over from the active member, perhaps before performing some maintenance. For example, in Figure 21.39, we can see that member fw2 is active. If we right-click fw2 and select Stop Member, we will force fw1 to switch to active. This assumes that fw1—or another cluster member—is available. Be sure to check this status before stopping the current active member!

Figure 21.39: SmartView Status GUI Showing ClusterXL HA New Mode with Member fw2 Active

Take note of the Running Mode field, which states whether the member is active.

Note

Note that if a member has been disabled using "Stop member," the ClusterXL Details pane might still show the member as active. This is because we have lost contact with the ClusterXL module on that member, and the GUI is still displaying the last known status. It is worth checking the last updated time for the ClusterXL status and forcing an update (right-click ClusterXL and select Update).

A stopped member can be revived by right-clicking the member name and selecting Start Member. Note that it will stay in Standby mode irrespective of its priority if Maintain Current Active gateway is set in the cluster object.

Test 3: FTP Session Through the Cluster When an Interface Fails

As with all cluster solutions, the best tests are those simulating real-world failure. Physically damaging cluster members is probably the most challenging test but probably not a popular option, either. A more acceptable test is disconnecting a network cable from the current master member during a file download through the cluster.

In our example, we initiate a command-line FTP session from the internal host on 192.l68.1.200 to 192.168.12.133 (refer to Figure 21.12). The default gateway of host 192.168.1.200 will be the cluster VIP address for that subnet (192.168.1.130). The default gateway for 192.168.12.133 will be VIP 192.168.12.130.

We will use the ftp hash command in order to display the blocks downloaded so we can see the download's progress. A large file should be chosen that will take at least a minute to download; that gives us time to test failover.

If you pull out the external interface of the active member (for example, if member fw1 were active, removing the Ethernet cable from qfe0 would cause a fail condition), you should see member fw2 become active and the FTP session should continue, probably after a pause of a few seconds. This particular test is useful because it tests the following things:

• The hosts communicating have the correct default gateway.

• The hubs and switches are working correctly in an HA environment.

• The firewall members are failing over correctly.

• The hosts on the local subnet respond to the failover gratuitous arp.

• The firewall members' state tables are fully synchronized.

Command-Line Diagnostics on ClusterXL

Let's take a look at some useful command-line tools that can be used to monitor ClusterXL.

fw hastat

The fw hastat command can be used to check the basic status of each cluster member locally or remotely. The fw hastat command has the following syntax:

fw hastat <hostname / or IP address>

A typical response if this command is run on a local firewall cluster member module is:

   HOST        NUMBER       HIGH AVAILABILITY STATE        MACHINE STATUS localhost1       1                 active                       OK

cphaprob

The cphaprob command is probably the most versatile command that can be used to monitor and manipulate ClusterXL. Here we cover just a few of the common syntaxes of this command, but it can do a lot more than merely show information about the cluster. This command can be used in order to integrate tailored status checking—maybe checking hardware health of a member.

The command can be used on either of the cluster members (not on the firewall management module). Running cphaprob state on either of the firewall cluster members should tell you the status of each of the cluster members from the point of view of the cluster member you are running the command on. Here is an example output:

Working mode: Active up (unique IPs)     Number        Unique Address          State     1             192.168.11.132          active 2 (local)          none*              standby

Note

If you see none in the unique address for one of the cluster members, you need to reboot the module, and then run the cphaprob state command again. It can also mean that the member is not correctly configured in the SmartDashboard GUI and that no secured interface exists on the member.

You can also use this command with different arguments to provide details of interfaces. The syntax for examining the interfaces on the local member is cphaprob -a if. The command will tell you the status of each interface and the virtual cluster IP addresses.

In this example, the local cluster member is in Standby mode:

Required interfaces: 3 Required secured interfaces: 1     hme0       UP                            (secured, unique) qfe0       DOWN (2505.8 secs)            (non secured, unique) qfe2       UP                            (non secured, unique) qfe3       UP                            (non secured, unique)     Virtual cluster interfaces: 3     qfe0           195.166.16.130        qfe2           192.168.12.130        qfe3           192.168.1.130

In this example, we can see that the interface qfe0 is down—probably a cable or interface problem. Looking at the information further down, we see that qfe0 is associated with the VIP address of 195.166.16.130, the external interface, so that is where we should start looking for network problems. Until this problem is resolved, we expect this member to stay in Standby mode; hopefully another member in the cluster will be active.

cpstat ha

The cpstat ha command gives detailed status details from the local member—similar information to that displayed by the SmartView Status GUI. Run without arguments, the output to this command is something like:

Product name: High Availability Version:      NG Feature Pack 3 Status:       OK HA installed: 1 Working mode: High availability HA started:   yes

More usefully, you can use the syntax cpstat –f all ha to get this:

Product name:        High Availability Major version:       5 Minor version:       0 Service pack:        3 Version string:      NG Feature Pack 3 Status code:         0 Status short:        OK Status long:         OK HA installed:        1 Working mode:        High availability HA protocol version: 2 HA started:          yes HA state:            active HA identifier:       1         Interface table ---------------------------------------------------- |Name|IP            |Status|Verified|Trusted|Shared| ---------------------------------------------------- |hme0|192.168.11.131|Up    |       0|      1|     0| |qfe0|195.166.16.131|Up    |     500|      0|     0| |qfe2|192.168.12.131|Up    |       0|      0|     0| |qfe3| 192.168.1.131|Up    |       0|      0|     0| ----------------------------------------------------     Problem Notification table ------------------------------------------------ |Name           |Status|Priority|Verified|Descr| ------------------------------------------------ |Synchronization|OK     |       0|     198|     | |Filter         |OK    |       0|     188|     | |cphad          |OK    |       0|       0|     | |fwd            |OK    |       0|       0|     | 

How Does ClusterXL HA New Mode Work?

In HA New mode, on each member of the cluster, each interface that will share a VIP address will keep its existing MAC address. No additional shared MAC addresses are used. When a client that is on the nonsecured network ARPs for the virtual IP (which will be the client's default gateway IP address), the cluster member that is active will reply with its MAC address and so will receive the through routed traffic.

Note that a client should still be able to connect to any of the valid IP addresses of the cluster on the same local subnet, regardless of which member is active (assuming that the interface is not down, the OS hasn't crashed, or the local firewall policy does not prevent it).

Because all members are "live" but only one handles traffic, HA New mode could be seen as load sharing but with 100 percent of the traffic going through one member only and all other members on standby having 0 percent of the traffic. This is opposed to traditional HA solutions in which the standby members are "offline" and unreachable.

If we consider the diagram in Figure 21.40, we can see that member fw1 is active and fw2 is in Standby mode.

Figure 21.40: Active Traffic Routing Through the Active Cluster Member

All network traffic should be routed through firewall member fw1—but only if its default gateway is set to the VIP address of 192.168.1.130.

If we take an example in which host 192.168.1.200 initiates a connection to a host out on the Internet and we are using Hide NAT behind the external cluster IP of 195.166.16.130, it will first ARP for the default gateway IP address. Host fw1 should respond because it is the active member in the cluster, with its internal interface MAC address of 08:00:20:ca:64:fb. This will be put in the ARP cache table of host 192.168.1.200, and a TCP connection—source IP 192.168.1.200, destination IP = 216.238.8.44, destination MAC 08:00:20:ca:64:fb—will originate from the host.

It is normal to use Hide NAT when internal hosts access the Internet, and this also makes it easy for replies to get back to your site. When the packet from host 192.168.1.200 leaves host fw1, the source IP will be address translated to 195.166.16.130 (and the source port will also change). The packet will then be routed out toward the ISP router (based on the default gateway of member fw1).

The reply packet will come back through the ISP router, which will ARP for a MAC address for 195.166.16.130. The fw-1 member is active and will respond with its external interface MAC of 08:00:20:ca:64:f8. The ISP router adds this into its ARP cache and sends the reply packet for the session back to 195.166.16.130, MAC address 08:00:20:ca:64:f8.

Member fw-1 then uses its stateful inspection to address translate the existing Hide NAT session so that the destination IP is changed from 195.166.16.130 to 192.168.1.200. The reply is then sent from interface qfe3 on fw1, source MAC address 08:00:20:ca:64:fb, to the host on 192.168.1.200.

ClusterXL HA New Mode Failover

On failover from the active cluster member to the standby member, adjacent routers and hosts still maintain the MAC address for the failed member in their ARP caches. Packets sent at this point arrive at the failed host and probably go no further. The cluster member that has just come active resolves this problem by issuing a "gratuitous ARP." The ARP is broadcast on the local subnet of all interfaces that have a VIP and will have the MAC address for the local interface of the new active member in the cluster. This should mean that adjacent routers will learn the new MAC addresses for the VIP addresses.

Note

Under some circumstances in NG FP3, there is a problem where the cluster member that comes online does not always issue a gratuitous ARP. This should be resolved in hotfix releases. It is a good idea to obtain and apply the latest released hotfix.

Let's now look in detail at what happens if the active member fails. If we consider the diagram in Figure 21.40, we can see that traffic is routing through the active member, and Hide NAT is being done to hide the internal host of 192.168.1.200 behind the cluster IP address of 195.166.16.130. Should an interface fail (as shown in Figure 21.41, for example), all traffic from 192.168.1.200 will not be able to get through to the qfe3 interface on member fw1, and traffic that is coming back will not get back to 192.168.1.200 because the interface is down.

Figure 21.41: Interface Failure on Active Member

At this point, fw2 will notice that fw1 is not responding on the qfe3 interface and will take note of this situation. If the interface stays down for a period of time, fw2 will start running its pre-online tests. These pre-online tests allow fw2 to determine if it is healthy enough to take over from host fw1. (We discuss these tests in more detail in the "Nokia Failover Conditions" section of this chapter.) Once fw2 has determined that it is able to take over from fw1, it will issue a gratuitous ARP on all its interfaces that have a VIP address (see Figure 21.42).

Figure 21.42: Gratuitous ARP by fw2 to Take Over from fw1 on Failure

This will be cached by all devices on the local subnet of the interfaces of the firewall cluster, and they will update their ARP tables appropriately. This means that host 192.168.1.200 will now have a MAC address of 08:00:20:a4:99:ef in its ARP cache for IP address 192.168.1.130, so current through connections—perhaps an FTP session—should be able to continue.

On the external interface of the cluster, the ISP router would also have received a gratuitous ARP, updating its ARP table for 195.166.16.130 with MAC address 08:00:20:a4:99:ec—the external MAC address of qfe0 of fw2. At this point, fw1 will have considered itself offline in the SmartView Status GUI, stating that interface qfe3 is down.

Once the FTP session recovers (which will only be the case if the gratuitous ARP is issued by fw2 and if state table sync is enabled between member fw1 and fw2), all traffic will continue to go through member fw2, as shown in Figure 21.43.

Figure 21.43: ClusterXL in HA New Mode, with Maintain Current Active Gateway Set After Failover

Should member fw1 recover, the cluster can be configured to either fail back to fw1 (which will have the highest priority) or continue working through fw2, which could have a lower priority. This can be configured in the Cluster Gateway Object | Cluster XL Screen (see Figure 21.22).

ClusterXL Failover Conditions

There are a number of conditions in which failover from one member to another will occur:

• An interface or cable fails.

• Security policy is uninstalled.

• The machine crashes.

• Any process or device that specified with the cphaprob command (such as the fwd process) fails.

These conditions can be listed using the command cphaprob list.

But how does fw2 know to take over from fw1 when one of these conditions is met? How does a member in the cluster know that it can take over? These questions are answered when you analyze the CPHA protocol packets that each member sends to other members on each interface that has a VIP address.

Tip

Ethereal, a free network protocol analyzer, can decode the CPHA protocol from v0.9.8 upward. This can be very useful when investigating low-level ClusterXL issues. Ethereal is available at www.ethereal.com.

When a member of a cluster comes online, it issues an IGMP packet in order to advertise its membership of a multicast group. Connected switches with IGMP snooping ability can use this feature when deciding how to forward multicast traffic.

Status updates are sent from each member at regular intervals. Analysis shows the following properties of the update traffic for NG FP3, HA New mode:

• At the data link layer (Layer 2 of the OSI model), the originating MAC address is always 00:00:00:00:fe:<member number>, where member 1 in the cluster would be 00 and member 2 in the cluster would be 01—member number - 1 is the last digit in the source MAC address.

• The destination MAC address is the multicast MAC for that VIP. For example, 01:00:5e:26:10:82 is the destination MAC seen on the external interface of our example network. The last two digits represent the VIP address's last two octets (16.130 where the entire VIP is 195.166.16.130).

• At Layer 3, we see that the source IP is always 0.0.0.0 and the destination IP is the network address (195.166.16.0 in our example).

• Layer 4 shows that the transport is UDP with the source and destination port of 8116. The payload of the UDP packet is CPHA, which contains the following information:

  • Source machine ID is the same as last octet in the source MAC address of the packet.

  • Protocol version is 530 for NG FP3.

The rest of the UDP payload determines whether the member is sending out its status as a member on the cluster (there are other types). This includes each member's status as perceived by the member originating the packet and the last time it heard from the other members. This mechanism allows all members of the cluster to share their system status information.

Warning

The multicast groups selected for intercluster communications are based on the last three octets of the VIP address. With this in mind, avoid using VIPs that end in the same three octets as other VIPs in the same broadcast domain.

Note

CPHA protocol in NG FP2 (HA Legacy mode) is different from NG FP3 HA New mode in a number of ways. For one, the destination MAC address is a broadcast, not a multicast.

Once an interface stops sending out status updates to the other members of the cluster, actions will start to be taken so that the highest-priority member that is active can then take over. When a member stops seeing status updates from the other member (or all the other members), it starts running a series of tests to determine the problem.

It will see if it can reach any other hosts that are valid on its subnet by ARPing for a selected range of IP addresses. A response suggests its own networking is good; no response could mean that it is disconnected from the network itself. It will attempt to ping the cluster IP address to see if it can receive any response from an active member; it will also attempt to ping the physical real IP of the other cluster member members. (For example, member 195.166.16.132 would ping 195.166.16.131 to see if it gets a response.) The member will also ping its default gateway.

Once these tests have completed, the member will make a decision as to whether it might be eligible for being a master and announces that it is active—and that the other member is dead—via the CPHA protocol.

The final step is that the member then issues a gratuitous ARP to the local subnets for the VIP (195.166.16.130 on qfe0 and 192.168.1.130 on qfe3 in our example)—and hopefully traffic resumes normally through this new active member.

Note

Now that you know that the firewall member that is in standby will issue ICMP echo requests to the default gateway—and other hosts on the local subnet as well as to the cluster IP and the other members in the cluster—it is a good idea to make sure that there are no access control lists (ACLs) on neighboring equipment on the same subnet that would block ICMP. The FireWall-1 policy on the cluster members themselves will not be a problem, because this CPHA module traffic bypasses the firewall filtering.

In Figure 21.44, we can see that the CPHA packet originated from the primary member. We can deduce this because the last octet in the MAC address source is 00. This is also confirmed in the CPHA protocol at a higher level, where the packet identifies the Source Machine ID as 0.

Figure 21.44: Breakdown of a CPHA Packet from Our Example

Other areas to take note of are the source and destination MAC addresses, the IP addresses, and the port numbers used by the CPHA protocol.

The "Machine states" field shows what member 0 in the cluster thinks the status of the other members in the cluster is. Of course, member 0 could be incorrect.

Special Considerations for ClusterXL in HA New Mode

As with all clustering solutions, ClusterXL requires that you must always take into account some special considerations. These are usually based on the way that the clustering solution functions and can cause limitations when attempting to use certain functions of the firewall.

Network Address Translation

When using NAT on a cluster, you have to consider carefully how you are address translating and how it will be affected by the way the cluster works—especially when failover to another member occurs.

In ClusterXL in HA New mode, the original MAC addresses of the physical interfaces are used. When using static destination NAT, this will cause a problem if you have manual proxy ARP entries for the NAT addresses. This causes a problem because each member in the HA cluster would be advertising its own physical MAC address, and all may respond when an adjacent router ARPs for the NAT address. There is no control over which of the members will receive traffic for the NAT address.

Warning

Manual proxy ARP entries in the ARP table of a cluster member's operating system will not work with HA New mode.

In Figure 21.45, we can see the types of problems that manually added static ARP entries for Manual NAT might cause. In Figure 21.45, each member in the cluster is proxy ARPing its own local MAC address for the qfe0 interface for the NAT IP address of 195.166.16.133, which the firewall modules will have a NAT rule to translate to the real IP address of 192.168.12.133.

Figure 21.45: Possible Scenario If Manual ARP Entries Are Used for NAT

This will cause undesirable effects in an HA environment. You have no easy way of determining which MAC address the ISP router will have cached for the IP address 195.166.16.133. If you are unlucky, it could be the member that is in Standby mode.

In this scenario, and if the member in standby is "fit" and there are no faults, the packet will travel through the member as normal (even though it is on standby) and reach the internal host 192.168.12.133. However, because the default gateway of host 192.168.12.133 is the DMZ VIP of 192.168.12.130, the www host will have the MAC address of qfe2 of member fw1 in its ARP cache, so the reply packet would travel via member fw1. This means that you have asymmetric routing occurring.

If we take this scenario one step further, where qfe2 fails (as shown in Figure 21.45), the NATed packet would not get through at all. What are the alternatives to manual ARP entries?

With Manual NAT Rules

If you want to keep using Manual NAT rules, you only have one option, which is to enter routes on the adjacent router(s). This would be a static host route entry forcing the NAT IP address to forward to the cluster VIP. For example, in our ClusterXL example, if you had a manual static destination NAT rule to NAT 195.166.16.133 to 192.168.12.133, you would add a route on the ISP router that looks something like:

195.166.16.133 , netmask 255.255.255.255 gateway 195.166.16.130

This states that to get to IP address 195.166.16.133 as a host route, the next hop is the VIP address of the cluster (see Figure 21.46).

Figure 21.46: Using Static Routes on the ISP Router for NATed IP Addresses

With Automatic NAT Rules

If you are using Automatic NAT, you have some options. You can still use static routes on the ISP router to get the packets onto the active member of the cluster, as described in the Manual NAT section, but you also have another useful alternative.

If you are using Automatic NAT and you have the Automatic ARP Configuration set in the SmartDashboard menu Policy | Global Properties | NAT – Network Address Translation | Automatic Rules section (see Figure 21.47), a firewall member switching to Active mode will issue a gratuitous ARP for all the Automatic NAT objects as well as the cluster VIP.

Figure 21.47: Automatic NAT Settings for Cluster Member to Issue a Gratuitous ARP on Failover

Configuring ClusterXL in HA Legacy Mode

HA Legacy mode is the technology that existed in earlier versions of Check Point NG (and, in fact, late versions of FireWall-1 4.1). From FP3, we have the option to use HA New mode, which provides the same functionality but improved underlying technology. For this reason, Check Point suggests that New mode is used in FP3 installations. We do not discuss Legacy mode in detail; instead, we look at a summary of how Legacy mode differs, in terms of configuration procedure and operation:

• Cluster members should be prepared with identical IP addresses, with the exception of the secured network.

• When adding a cluster member, connect it to the secured network only until a policy has been installed to it, to avoid IP address conflicts.

• To select Legacy mode operation, select that mode in the gateway cluster object ClusterXL tab.

• Cluster object topology is configured implicitly by the duplicated IP addresses over the members.

• Standby members are reachable via the secured network only, so the management station must be connected to that network.

• The ClusterXL module configures all cluster members to use the same MAC address on their connected interfaces, so a single MAC address is presented to adjacent network devices.

• The CPHA protocol uses a broadcast destination MAC address.

Configuring ClusterXL in Load-Sharing Mode

In this section, we configure and test ClusterXL in Load-Sharing mode. As you will see, ClusterXL in Load-Sharing mode has a lot in common with ClusterXL HA New mode—especially its configuration. For this reason, it is a good idea to digest the contents of the HA New mode section of this chapter first! This mode also has a great deal in common with Nokia clustering in terms of how the cluster operates and appears to adjacent network equipment. These similarities will become apparent as we proceed.

Prerequisites for Configuring ClusterXL in Load-Sharing Mode

The configuration of ClusterXL in Load-Sharing mode is so similar to ClusterXL in HA New mode that all the HA prerequisites apply. Our example network topology is also identical (refer back to Figure 21.12).

You must make sure that your ISP router (and any adjacent routing equipment that is physically connected to the load-sharing interfaces) will accept an ARP reply with a multicast MAC—even if the IP address is not a multicast IP address. There are various ways of doing this, depending on the specific networking equipment. The reason for doing so is that ClusterXL in Load-Sharing mode allocates a multicast MAC address to the VIP address. This means that for a specific VIP address, the MAC address will stay the same. This means that all members in the cluster receive the network traffic, but only one will route the traffic based on a load-sharing algorithm that takes into account which members are available and properties of the traffic.

Configuration of ClusterXL in Load-Sharing Mode

In order to configure load sharing, follow the steps as you would for HA New mode, but when you come to configuring the Gateway Cluster object ClusterXL mode, select the Load Sharing radio button (see Figure 21.22).

Installing the policy will then make the cluster behave as a load-sharing cluster as opposed to an HA cluster. If the cluster was previously operating in HA mode, it is wise to reboot each member after the new policy install, to ensure that the ClusterXL modules are configured correctly.

Testing ClusterXL in Load-Sharing Mode

Once you have configured your ClusterXL in Load-Sharing mode, you will want to perform some tests to determine that your load sharing is working properly and to make sure that it functions as you expect under failure conditions. We can use the same tests we used for HA New mode, but we should see some differences in results.

Test 1: Pinging the Virtual IP Address for Each Interface

You should be able to ping the VIP address for each network. The main difference between this test and the HA test is that the MAC address of the VIP address is a multicast MAC address. When you ping from a host that is on the same local subnet as a VIP of the cluster, you should receive an ARP reply from one of the members of the cluster (not necessarily the member that will take the traffic; this is based on the load-sharing algorithm). The MAC address that you receive in the ARP cache will be a multicast MAC address.

If you were to run a packet trace while pinging the VIP address of the cluster, in the ping echo response packet from the cluster you will see the real MAC address of the member that responds as the source MAC address.

Test 2: Using SmartView Status to Examine the Status of the Cluster Members

As with HA modes, the SmartView Status GUI allows detailed monitoring and manual stop and start of the cluster members.

Looking at Figure 21.48, you can see that ClusterXL on member fw1 has a problem. If you examine the ClusterXL Details on the right side of the screen, you can see that interface qfe3 (the internal interface) is down. In this particular case, because it is a test, this was the interface we unplugged, so this was the expected result.

Figure 21.48: SmartView Status Demonstrating a Problem with an Interface

If you click ClusterXL for member fw2, you will see all the details of this member as well. You can see the details regarding the status of fwd and policy loaded if you scroll down a little further in the ClusterXL Details. The details show that the Working mode is Load Sharing and that the Running mode is down for member fw1. As with ClusterXL in HA New mode, you can right-click the ClusterXL icon and take that particular member down or start it up again. Be wary that if you do this, the SmartView Status will no longer receive updated information from the ClusterXL member, so it might still state that the member is up and running.

Test 3: FTPing through ClusterXL Load Sharing During Failover

This test applies to load sharing as it did for HA mode; we still want connection resilience, so if a member fails, the load-sharing algorithm reallocates those connections to other members, and they are preserved. One snag with performing this type of test on a load-sharing cluster is this: How do we know which member the FTP traffic is going through? If you have the Real Time Monitor package installed on the modules, you could use that, as demonstrated later in the "How Nokia Clustering Works" section of this chapter. Another alternative is to watch the SmartView Tracker firewall logs and note which member logs the Accept of the FTP connection. However, in NG FP3, logging from cluster members is identified by the cluster name only, not the member name, so this is no help. Your other—rather unpleasant—option is to run a packet trace while the FTP download is taking place, identify a packet on the FTP connection that has come from the cluster, and check the source MAC address. This process will tell you which member the traffic is going through. You can then pull an interface cable out of the correct member in the cluster to observe failover. Take care not to stop the FTP session after taking the packet trace, and then start the FTP session again, because the new connection could go through a different member in the cluster!

Note

Happily, by the time you read this, there should be an FP3 hotfix release that will result in logging with the origin of the member, not the cluster name.

Command-Line Diagnostics for ClusterXL

The command-line diagnostic tools for ClusterXL in Load-Sharing mode are the same as ClusterXL in HA New mode, but the responses are different. Here, we take a quick look at how they differ.

fw hastat

When you run the fw hastat command on the cluster members, they should all respond with a status of active. In our little example, you would see something like:

fw2 #fw hastat     HOST      NUMBER     HIGH AVAILABILITY STATE          MACHINE STATUS localhost 2          active                           OK fw2 #     fw1 # fw hastat     HOST      NUMBER     HIGH AVAILABILITY STATE          MACHINE STATUS localhost 1          active                           OK fw1 #

If there was a problem on a member, for example, and interface was down on member fw2, fw hastat would produce an output that looks something like:

HOST      NUMBER     HIGH AVAILABILITY STATE          MACHINE STATUS localhost 2          not active                       problem fw2 # 

cphaprob

We explored two variations of this command when we looked at ClusterXL in HA New mode. The first was the cphaprob state command. On a load-sharing cluster, you would see an output such as:

fw1 # cphaprob state     Working mode:   Load Sharing     Number     Unique Address  State     1 (local)  192.168.11.131  active 2          192.168.11.132  active     fw1 #

Note that both members have a state of Active as opposed to Active/Standby in a ClusterXL HA New mode cluster. Should there be a failure on one of the members, you would see something like:

fw1 # cphaprob stat     Working mode:   Load Sharing     Number     Unique Address  State     1 (local)  192.168.11.131  active 2          192.168.11.132  down     fw1 #

In this example, member fw2 was taken down (an interface connection was removed), but the command was run on member fw1. All members in the cluster should report the same state for a member in a correctly working cluster.

cpstat ha

The information returned using the cpstat ha command is similar to the ClusterXL in HA New mode, but it reports on the load-sharing aspect of the cluster. The command cpstat ha will give you an output such as:

fw1 # cpstat ha     Product name: High Availability Version:      NG Feature Pack 3 Status:       OK HA installed: 1 Working mode: Load Sharing HA started:   yes     fw1 # 

The only differences here worthy of note are the working mode and the status. Predictably, if there is a problem, you will see the status change to:

Product name: High Availability Version:      NG Feature Pack 3 Status:       problem HA installed: 1 Working mode: Load Sharing HA started:   yes

The other syntax of this command is cpstat –f all ha. An example of the output is as follows:

fw1 # cpstat -f all ha     Product name:        High Availability Major version:       5 Minor version:       0 Service pack:        3 Version string:      NG Feature Pack 3 Status code:         2 Status short:        problem Status long:         problem HA installed:        1 Working mode:        Load Sharing HA protocol version: 2 HA started:          yes HA state:            down HA identifier:       1         Interface table ---------------------------------------------------- |Name|IP            |Status|Verified|Trusted|Shared| ---------------------------------------------------- |hme0|192.168.11.131|Up    |       0|      1|     0| |qfe0|195.166.16.131|Up    |       0|      0|     0| |qfe2|192.168.12.131|Up    |       0|      0|     0| |qfe3| 192.168.1.131|Down  |   32000|      0|     0| ----------------------------------------------------             Problem Notification table ------------------------------------------------ |Name           |Status|Priority|Verified|Descr| ------------------------------------------------ |Synchronization|OK    |       0|    1618|     | |Filter         |OK    |       0|    1618|     | |cphad          |OK    |       0|       0|     | |fwd            |OK    |       0|       0|     | ------------------------------------------------         fw1 # 

From this output, we can see that there is a problem with the local member (fw1 in this example) and that the status of interface qfe3 is down.

How ClusterXL Works in Load-Sharing Mode

ClusterXL in Load-Sharing mode works in a very similar way to ClusterXL in HA New mode but with the following unique distinctions:

• The MAC address used for the VIP address is shared among cluster members for that subnet. This means that there is no MAC address change on failure of a member as far as the network equipment on the local subnet of the cluster is concerned.

• The MAC address of the VIP address is a multicast MAC address. (in other words, its first octet is an odd number).

• In a healthy load-sharing cluster, all members of the cluster should be active and routing a portion of the active traffic.

Connections through the cluster are managed on a per-connection basis. For example, if a host on 192.168.1.200 initiates a connection through the cluster to 195.166.16.129 and member fw1 takes the connection, the connection will just go through member fw1 unless a failure of member fw1 occurs. The connection will continue through member fw1 until the session has completed. No asymmetric routing should occur on this particular connection.

The member in the cluster a new connection will go through is based on a hash of specific parameters defined in the Advanced section for ClusterXL Load Sharing (see Figure 21.49).

Figure 21.49: A Load-Sharing Algorithm Hash Can Be Based on These Parameters

Assuming a "normal" connection passing through the cluster, all the packets involved will have the same hash value. For an Internet firewall, this means that, for a particular connection, a packet arriving from the internal network and a packet arriving from the Internet will have the same hash value. However, if the cluster is performing NAT or if VPNs are involved, we have a potential problem. The IP addresses and ports will be different on the "inside" and "outside" of the firewall. FireWall-1's stateful inspection helps us out here; because it understands what changes have been applied to connections, it can adjust the hashing accordingly.

As with ClusterXL in HA New mode, the members of the cluster still have their real IP addresses bound to their interfaces. This is particularly useful when the SmartCenter server is communicating with the cluster members, because it need not be located on the secured network. This makes it easier for the SmartCenter server to manage other firewall modules as well as the cluster.

Although all members are live and handling traffic, who should respond to ARP requests for the VIP address? The members in the ClusterXL cluster will agree on which member in the cluster will respond to the ARP request; however, that choice is not based on the member priority in the cluster, and even if a member is designated as having a problem but the interfaces on the member are active, the problem member may still respond to the ARP request. Within the ARP reply packets is the multicast MAC address for the VIP.

Note

You need to make sure that adjacent hosts and routers will accept a multicast MAC reply for a nonmulticast IP address. For example, host 192.168.1.200 would ARP for 192.168.1.130—the VIP address of the cluster—in order to route packets through the cluster. The ARP response would contain a multicast MAC address. Different systems respond in different ways: Windows is generally fine, but Cisco routers on the same subnet will not accept the ARP reply and will not cache the multicast MAC address, so steps need to be taken to circumvent this problem for Cisco routers. These steps usually involve entering a static entry into the ARP table of the router for the multicast MAC address.

ClusterXL Load-Sharing Mode Failover

As with ClusterXL in HA New mode, the key to how failover works is in the CPHA protocol that the members send to all the other members in the cluster, using multicasts.

There are many similarities between ClusterXL HA New mode and ClusterXL Load-Sharing mode CPHA protocol packets. In fact, they are identical in the way they work, apart from some details in the UDP data payload. The similarities include:

• The source MAC address of the CPHA update packet is always 00:00:00:00:fe:<member number>, where member 1 would be 00, member 2 would be 01, and so on.

• The destination MAC is always a multicast MAC address, ending with the VIP address in the last two octets of the MAC address.

• The source IP of the CPHA update packet is always 0.0.0.0.

• The destination IP address of the CPHA update packet is always the network IP address.

• Layer 4 (the transport layer of the OSI model) is always UDP, source port 8116, destination port 8116.

• The first part of the CPHA payload within the UDP header packet is the same as ClusterXL in HA New mode, and the format of an FW_HA_MYSTATE payload is the same parameters but different data for these parameters.

If we focus on the last point, we can see from Figure 21.50 how the data for the same parameters differ.

Figure 21.50: Packet Structure of a CPHA Packet When a Cluster Is in Load-Sharing Mode

The main areas of note here are the HA mode, which states that the mode is mode 4 FWHA_Balance_mode—more than one member active. ClusterXL in HA New mode is referred to as mode 2 in this field.

The other field of note is "Machine states." This field communicates what the member originating the CPHA packet thinks the status of all the other members is. As we can see in Figure 21.50, the sending member is aware that member 0 is active. This packet was originated from member 1, or fw2 from our example.

Under normal operation, these CPHA packets are multicast to all the other members in the cluster. Each member multicasts its perception of the state of the rest of the members in the cluster. This process occurs on each interface of a cluster member and is sent at regular intervals, several a second.

Examining the CPHA protocol between cluster members, we see that if there is a problem on the member, the other members will show a "Machine states" value for that the member as down/dead. The member that is taking over a particular connection will then ARP for the MAC address of the local host it needs to push a packet to, and on response, it will continue the session. Note that the hosts on the local subnet do not notice any change in MAC address or IP address on failover. You could notice a small glitch in the data transfer while the failure occurs and failover to another member takes place, but the period of disruption should always be less than three seconds and is usually just over one second.

Note that when a member in a load-sharing cluster takes over from another member, there is no gratuitous ARP broadcast, unlike HA mode. This is because it is unnecessary since there has been no MAC address change.

Special Considerations for ClusterXL in Load-Sharing Mode

We have covered the principles of how ClusterXL in Load-Sharing mode works. We now contrast and compare how the special considerations for ClusterXL in Load-Sharing mode differ relative to other cluster modes.

Network Address Translation

ClusterXL in Load-Sharing mode is actually quite forgiving with regard to NAT and how proxy ARP is performed, unlike HA mode. It will handle manual proxy ARP entries fine for NATed IP addresses, as long as you proxy ARP for the cluster multicast MAC address. You enter these static published ARP entries on all members in the cluster. Automatic ARP configuration can be selected in the Policy | Global Properties | Network Address Translation area of the SmartDashboard GUI. This works fine because the multicast MAC address is used for all the automatic ARPs that are required. Manual routes on the ISP router can also be used instead of using proxy ARPs.

To summarize, as long as the multicast MAC address is used in any manual proxy ARPs, there should be no issues with Load-Sharing mode and NAT.

User Authentication and One-Time Passcodes

Like all HA and Load-Sharing clustering solutions, if you are using the Check Point security servers (for SMTP, HTTP, or FTP services) and a failover occurs, you will lose the connection and have to start again through the new member that the traffic is now going through. The security server and remote authentication issues discussed earlier in this chapter (comparing single gateway and clustering functionality) apply particularly to Load-Sharing mode, because sessions—with multiple connections—are always likely to be shared between all cluster members, unlike HA, when problems only occur on failover.