FirewallBuilder

Create your firewall objects. Assign platform and host OS and name interfaces as usual. Do not add any policy or NAT rules. These are your real (member) firewalls. Interfaces should have their real IP addresses (not CARP or VRRP addresses).

Create a cluster object. Configure the cluster object with the proper platform and host OS. Use the usual New Object menu or toolbar button to create this object. Note that in order for the firewall object to become a member of a cluster, their platform and host OS settings must match.

There are two ways to create new cluster object: you can use main menu "Object / New Object" option (or a toolbar button that calls the same function) as shown on Figure 5.13:

Figure 5.13. Create a New Cluster Using the "Object / New Object" Option

Using this menu option or toolbar button opens a wizard that guides you through the steps of creating new cluster object. The first page of the wizard shows all the available firewall objects. In this page, you choose which ones become cluster members:

Figure 5.14. Using the Wizard to Choose Firewall Cluster Members

Another method is to select two or more firewall objects that are to become cluster members, then right-click and select the "New cluster from selected firewalls" menu item, as shown on Figure 5.15. You can select two or more objects in the tree by clicking the object while holding the "Ctrl" key ("Cmd" on the Macintosh).

Figure 5.15. Using the Right-Click Menu to Choose Firewall Cluster Menus

Using the right-click options launches the same wizard, but the list on its first page is already populated with the selected firewall objects, as shown below.

Figure 5.16. Wizard Populated with Selected Firewall Objects

Reducing the number of firewall objects displayed in the wizard can be helpful when you have many of firewall objects defined in the object tree.

The program guides you through the process of creating new cluster objects using a wizard-like dialog. You start with the list of firewall objects where you choose which firewalls should become members of the cluster. Next, the program finds interfaces of the member firewalls that have the same name and can be part of the cluster and creates cluster interfaces with the same name. Not all interfaces are eligible: for example, bridge ports, bonding interface slaves, and parents of VLAN interfaces cannot be used for the cluster. Cluster interfaces define failover groups. You can add, remove, or rename cluster interfaces, as well as change which interfaces of the member firewalls are used with each one. On the next page of the wizard you can change failover protocols and add, remove, or change IP addresses of cluster interfaces. Not all failover protocols require IP addresses: for example, VRRP or CARP do but heartbeat or OpenAIS do not. Finally, you can choose to use policy and NAT rules of one of the member firewalls to populate policy and NAT rule sets of the new cluster. If you do this, all references to the original member firewall and its interfaces in rules are replaced with references to the cluster and its interfaces. The program also creates backup copies of the member firewall objects with the name with suffix "-bak" and clears policy and NAT rule sets of the member firewall objects used with the cluster before the new cluster is created.

OpenBSD or FreeBSD clusters are assigned with CARP interfaces. Name them "carp0", "carp1", and so on (or whatever indexes the addresses are assigned on your machines). You can add the CARP password and ID at the same time or you can add them later.

If you use heartbeat or OpenAIS (on Linux) for failover, cluster interfaces should have the same names as the corresponding member firewall interfaces. In this case, cluster interfaces are virtual entities that represent interfaces of the corresponding member firewalls. The program makes the necessary substitutions when it compiles the rules. This is also how PIX failover configuration works.

Each cluster interface has a child "Failover group" object with the name "firewall:carp0:members", or similar. This is the object where you configure associated member firewall interfaces. Double-click this object in the tree and then click "Manage Members" button in the dialog. Select interfaces of the member firewalls in the panel on the left-and side and click the Arrow button to add them to the list on the right. Use the checkbox to select the master. Click OK when done. The platform and host OS of the cluster object and members must match, otherwise firewall objects do not appear in the "members" dialog panel.

Besides interfaces, the Cluster object has a new child object "State Sync Group". This group represents state synchronization protocol. Currently pfsync is supported for OpenBSD and conntrackd for Linux. To configure, double-click this object in the tree to open it in the dialog and click "Manage Members". Select the interfaces of the member firewalls in the panel on the left hand side and click the Arrow button to add them to the list on the right. Use the checkbox to select the master. Click OK when done. The new objects should appear in the "members" table in the State Sync Group dialog. The platform and host OS of the cluster object and members must match, otherwise firewall objects do not appear in the "members" dialog panel.

The "Edit protocol parameters" button allows you to edit some parameters for the chosen failover protocol. This is how you configure an address and port for heartbeat and OpenAIS.

There are few additional checkboxes in the "Script" tab of the firewall object dialog. These allow you to control whether the program add shells commands for creating and configuring bonding, bridge, and VLAN interfaces.

Compile by right-clicking the cluster object and selecting "Compile". This compiles each member firewall separately, resulting in .fw and .conf files for both of them.

Again, you configure all the rules in the policy and NAT rule sets that belong to the cluster object. If you put cluster's interfaces in rules, the program replaces them with interfaces of the member firewall when it compiles rules. If you put cluster object in a rule, it is like if you put member firewall object there instead, except the program automatically picks the member firewall it compiles the policy for.

First, the program looks at Policy and NAT rule set objects of the cluster and member firewalls and compares their names. If there is rule set object with the same name in both the cluster and member firewall and both have non-zero number of rules, the rule set object from the member is used and the one from the cluster is ignored. The program prints a warning message when this is done. If rule set objects with the same name exist but the one in the member firewall has zero rules, it is ignored and the one from the cluster is used (no warning is issued). Likewise, if there are rule sets with the same name but the one in the cluster has zero rules, it is ignored.

Here is what you need to do if you want to have most rules defined in the cluster so they will translate into rules for all member firewalls, but have some rules defined in the members so you can make configurations of the members slightly different:

This method works for both policy and NAT rules for all platforms.