The Best Damn Firewall Book Period

Most of the hard work and decision making you'll encounter will be at the design stage. Are you using existing modules to upgrade to NG FP3, what platforms are the modules on, and what hubs and switches do you have available are all questions you will have to consider. Many of these issues are based on the type of clustering solution you choose. In short, the pertinent points of each clustering solution are as follows:

• ClusterXL in HA New mode High availability with monitoring of system, cluster, and network state, integrated with FireWall-1. Unicast MAC addresses are used for the VIP address on each subnet. Can be fully managed from SmartView status GUI. SmartCenter Server (management station) can be located on the secured network or elsewhere. Interfaces of the members in the cluster also have real IP addresses as well as the VIP address.

• ClusterXL in HA Legacy mode High availability with monitoring of system, cluster, and network state, integrated with FireWall-1. Included for compatibility with older FireWall-1 versions, limited by technology that leaves standby nodes unreachable except from management network. Can be fully managed from SmartView Status GUI, depending on failover conditions and location of GUI client on network. Unicast MAC for the VIP address, which is shared across the cluster, as is the MAC address for a particular subnet. SmartCenter Server must be located on the secured network and should have a second interface onto an Internet-routable IP address if managing other FireWall-1 enforcement points outside of the local network. Interfaces of the members in the legacy cluster do not have unique IP addresses or MAC addresses, apart from the secured network.

• ClusterXL in Load-Sharing mode Load sharing with monitoring of system, cluster, and network state, integrated with FireWall-1. Can be fully managed from SmartView Status GUI. Multicast MAC address responses for an ARP of the VIP (which is not a multicast IP address). This means that each member in the cluster has the same MAC and VIP across the cluster for a particular subnet. The SmartCenter Server can be located on the secured network or elsewhere. Interfaces of the members in the cluster also have real IP addresses as well as the VIP address.

• Nokia Load Sharing cluster Load sharing with monitoring of system, cluster, and network state, limited integration with FireWall-1. Can be partially managed by SmartView Status GUI but also must use Voyager to find the status of the cluster. Multicast MAC address responses for an ARP of the VIP (which is not a multicast IP address). This means that each member in the cluster has the same MAC and VIP across the cluster for a particular subnet. The SmartCenter Server can be located on the secured network or elsewhere. Interfaces of the members in the cluster also have real IP addresses as well as the VIP address. The solution requires no license since it is part of the IPSO operating system.

• Nokia VRRP cluster Simple configuration but limited management. No monitoring of system or cluster state other than network interfaces. Unicast shared MAC for the VIP address, which is shared across the cluster. The SmartCenter Server can be located on the secured network or elsewhere. Interfaces of the members in the cluster also have real IP addresses as well as the VIP address. The solution requires no license since it is part of the IPSO operating system.

After you initially configure the cluster, make sure that you have the clustering solution working as you would expect before configuring a complex firewall rule base. The key here is to keep testing the functions of the cluster failover after each significant change to ensure that you have not done something to compromise the functionality of your cluster.

Once your cluster is configured and working and you have your security policy in place, take careful note of the configuration of your cluster and its members—and the settings of all the networking equipment on the same subnet as the VIP addresses of the cluster. This includes settings on routers, switches, and hosts. Taking note of these settings will be very useful if you ever need to troubleshoot the cluster. Sometimes configuration of adjacent devices has a habit of changing without advance warning to the firewall administrator.

The final step is to tune your cluster. Go through the procedure of examining your connections table to determine which services are most common in your connections table, and determine if you need to synchronize that service across the cluster. Is the service very transient? If so, it's a good candidate for switching off state table synchronization. Can you reduce the TCP or UDP timeout for a particular service? Additionally, make sure you increase the number of connections that your cluster will be able to handle and the kernel and hash allocation.