Checkpoint/Nokia Firewall Clustering. Uh Oh. I’ve been reviewing a network that has some Check. Point firewalls that have been unstable, and while this isn’t surprising (in my experience, it’s common for Checkpoint firewalls to be unstable for some reason or the other), this time I’ve been faced with Checkpoint Clustering. A few years back I tried to make this work but gave up when Check. Point couldn’t make it work either.
Policy compilation error when installing Security Policy on. When using PIM Sparse-mode with ClusterXL. HKEY_CURRENT_USER\Software\Checkpoint\SSL Network. Important Information Latest Software We recommend that you install the most recent software release to stay up-to-date with the latest functional improvements.
A few years later, I find someone brave enough to attempt it. This time it’s different, I’m the one who has to justify why it’s a bad idea. Here we go. What is Check. Point Clustering ? The premise behind Check. Point clustering is that having two firewalls in active/standby is a bad idea.
This is true for Check. Point because they are so expensive that you can’t afford to keep buying new units so why waste half of your money with the second firewall doing nothing.
Therefore, owning two units, and using them in Active/Active mode is perceived as a way of saving money. To make it worse, this very idea is so ‘kleva’ that Check. Point engineers are commonly known to suggest the practice as a ‘competitive advantage. There is one useful feature, the fact that you can cluster up to four units into a ‘single cluster’. However, the operational impact of this is very poor.
It is not possible to to determine which firewall is handling a given flow, thus making troubleshooting very hard or impossible. Anyone who thinks that the Tracker tool can be used for troubleshooting needs a good spanking – it’s a good logging tool but not a perfect troubleshooting tool. How does Check. Point clustering work ? In fact, Checkpoint doesn’t do the clustering, the Nokia IPSO software does although it seems that the manual makes no reference to this. You might want to refer to Cluster XL Admin Guide for this much improved( since 2. I last couldn’t get the manuals because of a paywall) but mostly unhelpful piece of documentation.
It’s worth noting that Check. Point is actually a piece of software that runs on many platforms. In the past Check. Point was used on Solaris, Windows and Bay.
- Configuring ClusterXL. This procedure describes how to configure the Load Sharing Multicast, Load Sharing Unicast, and High Availability New Modes from scratch.
- Home Tutorials Check Point Check Point R75 Cluster Setup. Select Check Point ClusterXL and select High Availability. CheckPoint is Exterior Firewall.
- After changing the High Availability configuration from ClusterXL and VRRP (or from VRRP to ClusterXL) and installing the policy, the cluster members do not apply the.
- Checkpoint/Nokia Firewall Clustering. Uh Oh. On the interconnect, a multicast CheckPoint ClusterXL, with an active/active firewall configuration.
- Http:// Supported Hotfix Accumulators. log in to the machine using admin as the username and adminadmin as. Installing ClusterXL on VMware.
- We now take a look at the Check Point ClusterXL clustering solution. (High Availability and Clustering) Part 1. (High Availability and Clustering) Part 2.
- Upgrading ClusterXL Deployments. Related Topics. If you must do this, see Installing a Policy during Cluster Upgrade. To upgrade all but one of the cluster members.
RS routers. Today it runs on Nokia IPSO, SPLAT (custom Linux distro) and Crossbeam. As a result, the Check.
ClusterXL in High Availability mode fails over during policy installations. SmartView Tracker logs show the following messages during policy installation.
Point software isn’t tightly coupled to the networking features of the underlying platform. Perhaps this explains why the manuals miss out on the networking aspects of firewall functions. Normal Firewall Operation. So lets set a baseline around normal firewall operation. In normal operation a firewall works this way: client sends packetfirewall will receive an ARP from from the router, respond with MAC address that is shared between the firewalls (and transfers between the active and standby unit on failover). The firewall will receive the packet and forward it to the internal network.
The reverse flow is identical. All this is standards compliant, expected and operationally easy to maintain and troubleshoot.
Installing Clusterxl Checkpoint Inhibitors
Checkpoint Clustering Operation. Obviously, to provide clustering something unusual has to happen because either, or both, firewalls need to receive each and every packet that needs to be forwarded. The purpose of clustering is to enable two or more (up to four ??) firewalls to pass flows in a fully load balanced/shared way. Why would you do this ? My view is that Check. Point / Nokia firewalls are relatively very expensive compared to Cisco/Juniper equivalents, so customers want to make the most of the “investment”.
A shortcut like this looks attractive to double the throughput of the system. From the Manual. From the manual: Cluster. XL uses unique physical IP and MAC addresses for the cluster members and virtual IP addresses to represent the cluster itself. Virtual IP addresses do not belong to an actual machine interface (except in High Availability Legacy mode, explained later). Cluster. XL provides an infrastructure that ensures that data is not lost due to a failure, by ensuring that each cluster member is aware of connections passing through the other members.
Passing information about connections and other Security Gateway states between the cluster members is known as State Synchronisation. IP and MAC addresses. No, really, if you don’t understand these you should not be reading this. Return to school, do not collect $2. State Synchronisation. This is easy enough.
Each flow that traverses the firewall creates a entry in a state database on the firewall, and this state database must/should/depends/your choice to be replicated to other firewalls so that if a failure event occurs, the other unit knows what traffic flows you were forwarding and can keep on going. State Synchronisation means that for every flow on one firewall, it’s data is replicated to other firewalls. It’s most useful for long held data flows such as SQL and not so much for HTTP (YMMV). Cluster Control Protocol. There is no standard protocol for synchronising such devices so Check.
Point created something with an imaginative name: The Cluster Control Protocol (CCP) is the glue that links together the machines in the Check Point Gateway Cluster. CCP traffic is distinct from ordinary network traffic and can be viewed using any network sniffer. CCP runs on UDP port 8. It allows cluster members to report their own states and learn about the states of other members by sending keep- alive packets (this only applies to Cluster. XL clusters). – State Synchronisation. Great. Basics are done. Cluster. XL modes.
Cluster. XL has four working modes: Load Sharing Multicast Mode. Load Sharing Unicast Mode. New High Availability Mode. High Availability Legacy Mode. Ok, so there are four possible high availability modes. Two of which are actually “clustering” and two of which are NOT – they are ‘High Availability” active/standby.
So we will ignore those. Checkpoint/Nokia Multicast Clustering. Anything with the word ‘Multicast’ in it automatically means trouble.
And, you would be right. Except that Checkpoint does naughty multicast. Well, it’s not IP Multicast it’s Ethernet Multicast. Lets walk it through: For Check. Point/Nokia the packet flow works something like this: client sends packetrouter will ARP for the next hop MAC address, all firewalls will respond with a Multicast MAC address. Router sends Ethernet frame with a Multicast MAC address which the switch must treat as a broadcast to all devices in the VLANThe Cluster protocol will notify one of the firewalls to forward the flow, and it will reach the server.
Let’s consider the reverse direction: Server sends an ARP request. Firewalls respond with Multicast MAC address and transmit Ethernet frame. Server sends Ethernet frame with a Multicast MAC address which the switch must treat as a broadcast to all devices in the VLANThe Cluster protocol will notify one of the firewalls to forward the flow, and it will reach the server. Multicast Ethernet, Undirected Broadcasts and Denial of Service. Check. Point has now switched to using Ethernet multicast without using IP Multicast.
By default, Ethernet switches are configured with IGMP enabled. Therefore after IGMP Query times have expired (about three minutes), the port will start to block the frames and thus disable the Clustering functionality. Checkpoint recommends three options to ‘fix’ this: disable IGMP on the switchesconfigure static MAC address mappings for the multicast mac address on all portsinstall an IGMP agent on the firewall.
Disable IGMP on the switches. This is the primary recommendation from Check. Point engineers and from the manual. To be fair, it’s possibly the best of three bad options although it’s most likely to cause significant problems. When you disable IGMP on your ethernet switches, you are effectively allowing all multicast packets to be broadcast. That is, a multicast frame becomes a broadcast frame and every packet must be handled by every device in the VLAN. That is, broadcast frames are received by all devices, and the software protocol driver of the device must process the broadcast frame before discarding it thus creating performance problems (bus interrupts, buffer memory, CPU, software cycles, etc etc)This is more commonly known as a Denial of Service Attack.
Consider this scenario: Lets assume that you have 1. Mbps of inbound traffic on a fairly typical, dual router, dual firewall cluster type of setup like the following diagram. In this case, with IGMP disabled, 1. Mbps of traffic will sent to the firewall and the standby router and all other devices on the public facing LAN. In this scenario, each VPN concentrator is connected to a VLAN with Public IPv. Since this is the only VLAN with the public address, you can’t put them anywhere else.
The VPN concentrators will needs to handle 1. Mbps of broadcast traffic, in addition to the VPN traffic. Most likely, this will cause intermittent outages and service problems on those devices as the CPU struggles to read and discard that volume of traffic. In the worst case, the VPN concentrator may attempt to report broadcast flood and even shut down. Server hosting. Lets consider the return path for traffic (because all flows have a return path). In this case, lets have a VLAN directly connected to the Check.
Point / Nokia firewall and some servers connected to that VLAN. Typically, this would be an email server, a web server, maybe a proxy or some other gateway. Most likely it would be several servers on that VLAN. The server will get a Multicast MAC address for the IP address of any frames destined for firewall (most likely the default gateway) and will dispatch those according to the normal process. However, EVERY OTHER server will receive every packet as a Broadcast. This will cause serious CPU impacts, and possible stability problems. You can fix this by having a L3 device on the inside of the firewalls, and limiting the impact of the broadcasts to the L2 VLAN that is directly connected to the firewalls, of course.
But this limits your design choices, and isn’t helpful in an existing environment. Configure static MAC address mappings for the multicast mac address on all ports.