ClusterXL and SMB devices

[G_W_Albrecht]

Using ClusterXL with SMB units is easy - the secondary cluster member syncs with the configuration details from the active node after setup. Only HA Clustering is supported, and also some other details are different when compared to GAiA devices:

• On locally managed SMB clusters, you have to use the Advanced Settings for special cluster parameters:

  Attribute Name	Type	Value	Description
  Cluster - Use virtual MAC	bool	false	Indicates if a virtual MAC address will be used by all cluster members to allow a quicker failover by the network's switch
  NAT - Perform cluster hide fold	bool	false	Indicates if local IP addresses will be hidden behind the cluster IP address when applicable
  VPN Site to Site global settings - Cluster SA sync packets threshold	long	200000	Sync SA with other cluster members when packets number reaches this threshold
  VPN Site to Site global settings - Use cluster IP address for IKE	bool	true	Indicates if IKE is performed using cluster IP address (when applicable)

• sk111854 1400/1100/1200R/700/600 ClusterXL does not fail-back to Primary member

For the Primary cluster member to resume handling the traffic of a SMB cluster, a manual fail-over must take place. Connect to the WebUI of the Secondary (Currently Active) cluster member, browse to: Device > High Availability > Force Member Down.

• sk20576 How to set ClusterXL Control Protocol (CCP) in Broadcast / Multicast mode in ClusterXL

On cluster members, a cphaconf set_ccp multicast will change ClusterXL to Multicast mode. This does also work on SMB clusters, but will not survive a reboot - see also a cat $FWDIR/boot/ha_boot.conf ! We can not write to ha_boot.conf but have to use userScript.

On the 1400/1100/1200R/700/600 appliance, go to /pfrm2.0/etc/ directory:

[Expert@Appliance]# cd /pfrm2.0/etc/

Create the special file:

[Expert@Appliance]# touch userScript

(Note: the name contains Captial 'S'.)

Edit the file in Vi editor:

[Expert@Appliance]# vi userScript

userScript must be in shell script format:

#!/bin/sh

Add the full path to the command 'cphaconf':

/opt/fw1/bin/cphaconf set_ccp broadcast

Or:

/opt/fw1/bin/cphaconf set_ccp multicast

Set the file permissions:

[Expert@Appliance]# chmod 777 userScript

Reboot the appliance and check CCP mode:

[Expert@Appliance]# cphaprob -a if

• sk113039 SMB ClusterXL and VPN HA do not work upon Cluster-failover

This is important for configuration of a VPN between a locally managed cluster and a single SMB GW.

[HristoGrigorov]

An undocumented limitation I hit this week. You cannot configure HA on an appliance that has 2 WAN connections configured as VLAN. An error "IP address is in the subnet of an existing network" appears at the step where HA interface is to be configured for any of these WAN connections. 

I've opened support ticket and it was confirmed by TAC in their lab. Currently waiting for their statement whether this is a bug or built-in undocumented limitation. 

[G_W_Albrecht]

Strange - only HA Clustering limitation i know of is that Bridge and switch configurations are not supported in cluster configuration. You do not use any, though ?

[HristoGrigorov]

There are few known ClusterXL limitations listed in sk105380. This one is not one of them. If you have switch or bridge defined it will not even let you configure HA. In this case, error appears at a later stage when you define HA mode for interfaces. Strange for me it does let you configure HA for LAN ifaces with assigned VLANs but fails to do that for WAN interface that is physically nothing more but LAN iface itself. 

[G_W_Albrecht]

I can tell you the following out of experience (and after asking my collegues for theirs ;-):

- we have never encountered customers using VLANs on SMB devices (Edge, 600, 700...)

- larger companies not using SMB appliances do configure VLAN on LAN ports to support large networks

- most ISP redundancy configurations are using only two ISPs

- configuring VLAN on WAN ports is at least a very exceptional case and not at all a widely used configuration, so it is the question why it should be supported on SMB devices at all

[HristoGrigorov]

We have a lot of small networks here and not enough ports on the upstream switch for all of them. And I want to use DMZ interface for what it is intended, that's why the VLANs on the WAN interface. May be we are not a typical customer. But let's see what has CheckPoint to say about that. Still waiting for their comments....

[Pedro_Espindola]

We do have costumers with a small number of users (10 to 15) which have segmented networks and redundant links that do benefit a lot from VLANs on SMB appliances We see A LOT of potential in this market. There are thousands of small companies running sensitive services such as financial consulting that are very interested in Check Point SMB. So I think these limitations are not something to be overlooked.

[G_W_Albrecht · Accepted solution]

Going out into new markets is a thing never to be undervalued - you that do sales have to look out for customers all the time! My shared experience comes more from the past 😉 and the distribution side of the channel...

[HristoGrigorov]

An update:

CheckPoint Development have confirmed that this is a bug in their code and issued a hotfix for it. I will test it tomorrow. It likely be included in the next firmware update.

[G_W_Albrecht]

Have your tests proofed successfull ?

[HristoGrigorov]

Yes, with the hotfix it works fine.

[HristoGrigorov]

One thing to be aware of...

If you are trying to configure ClusterXL on a locally managed appliances it won't work if you have SYSLOG defined server. You will get an error 00361 (or similar) at the end of the configuration while it is applying new policy. You should delete the syslog server definition, configure cluster and then add it again. Don't know if that is by design but it took me a while until I figure out what that error actually means.