Linux Building Rules For The Cluster With Firewall Builder

Now that all objects are ready and heartbeat is configured on the machines, we can move on and build some firewall rules. Since this is a cluster configuration, all rules go into the rule set objects that belong to the cluster rather than its member firewalls. Because all policy and NAT rules are entered in the rule set objects of the cluster, all member firewalls end up running firewall configuration that implement the same rules. The difference is that whenever you use cluster object or one of its interfaces in a rule, the program replaces it with actual IP addresses of the member firewall it compiles for and virtual addresses that belong to the cluster. Each member firewall gets slightly different script, the difference is in the part that matches addresses of the member: script on each one matches its own addresses. If you wish to build a rule to match addresses of both members, just put corresponding firewall objects in the rule.

Note

You can override this algorithm and make the program generate different rules for each member if you wish. See section “Cluster object” of the Firewall Builder Users Guide.

Rules that we’ve got from the template object are shown in FigureÂ 19:

FigureÂ 19.Â Overview of the policy rules and compiled output for rule #0

Figure 19. Overview of the policy rules and compiled output for rule #0

Rule #0: anti-spoofing rule. This is the only rule in this simple setup that generates different iptables commands for two member firewalls. Fwbuilder optimizes other rules using INPUT and OUTPUT chains as appropriate so they look identical on both firewalls. The bottom panel visible in FigureÂ 19 shows generated iptables script for the rule #0. To get that, select the rule in the rule set, click right mouse button and use menu item “Compile”, or use keyboard shortcut “X”.

Rule #1: permits everything on loopback. This rule is configured as “stateless” to simplify generated iptables code. The output looks like this (commands for linux-test-2 firewall look the same):

Once you are happy with the rules, you can try to compile the whole script and deploy it to both member firewalls. To do this, I am going to use “Compile this” toolbar button located right above the rules as shown in FigureÂ 20:

FigureÂ 20.Â “Compile this” toolbar button

Figure 20. "Compile this" toolbar button

This opens standard “compile” dialog but it only shows the cluster and its two member firewalls. I actually have many other firewall and cluster objects in my test data file, but since I started compile process using “compile this” button, only those that are relevant to the cluster configuration I am working with at the moment are shown.

FigureÂ 21.Â Compiling cluster configuration

Figure 21. Compiling cluster configuration

Clicking “Next” on the first page of the dialog starts the compiler. It processes both member firewalls, one after another, and prints its progress output in the window on the next page of the dialog. Errors and warnings, if any, appear there as well.

FigureÂ 22.Â Compiling process progress window

Figure 22. Compiling process progress window

Tip

If compiler generates any errors or warnings, they are highlighted in the output using different colors. Errors appear red and warnings appear blue. The text lines of errors are warnings are clickable. Clicking on one automatically makes the main window switch to the firewall, rule set and rule that caused the message.

If you inspect the output of the compiler, you’ll notice that it processed 11 rules, while the main window shows only 7. To find out what are these additional 4 rules, we are going to look inside the generated script. There are two scripts, actually, one for each member firewall. Their names are the same as names of the member firewall objects, “linux-test-1” and “linux-test-2”, with extension .fw. Other chapters of the Users Guide discuss various parts of the generated script, here we are going to look at the automatically added rules. Here is a fragment of the script linux-test-1.fw, specifically the beginning of the part that defines iptables rules:

Rules with negative numbers were added by the program automatically to permit packets of the heartbeat protocol. Rules added to interface “eth0” look right, they are in the right chains INPUT and OUTPUT and match multicast group 224.0.10.100 and port 694 which were configured in the protocol settings dialog FigureÂ 18. The program also added the same rules to the loopback interface which we probably do not need. This is because the wizard that creates new cluster object treats all interfaces equally and since it has found two interfaces in each member firewall, “eth0” and “lo”, it set up failover groups on both. In other words, the program assumed that I want to run heartbeat on all interfaces. I could have fixed this right in the wizard when I was creating new cluster object. To do that, I would have to switch to the tab “lo” in FigureÂ 14 page of the wizard and set “Protocol” to “None” for the interface “lo”. However, I did not do it then, so I need to fix it now, when cluster object and its interfaces have already been created.

To fix this, I find interface “lo” of the cluster and failover group object “web_server_cluster:lo:members” located right under it in the tree:

FigureÂ 23.Â Failover group that was added to loopback interface

Figure 23. Failover group that was added to loopback interface

Then I double click on the failover group “web_server_cluster:lo:members” in the tree to open it in the editor and switch the type from “heartbeat” to “None”. Once this is done, I recompile the firewall again and inspect generated script:

Last change I am going to do before I upload generated script to my firewalls is switch to iptables-restore format in the generated script. This offers many advantages over entering iptables commands one by one, the most important is that iptables-restore policy update is atomic. If it encounters an error, it aborts without changing running firewall policy. Also the update happens much faster and the firewall does not run in the undefined state with only part of its policy loaded. To switch, find firewall object in the tree, double click it to open it in the editor and click “Firewall Settings” button. Navigate to the tab “Script” and turn on checkbox “Use iptables-restore to activate policy”. Do it in both member firewall objects, then recompile again. Generated script now looks like this (this is only relevant part of the script):

Note

In addition to rules for the failover protocol, Firewall Builder can automatically add rules to permit packets used by the state synchronization protocol. In case of iptables this is conntrackd. Protocol parameters are configured in the “State Sync Group” object that is located in the tree immediately under the cluster.

Installing cluster configuration using built-in policy installer

To upload generated script to both firewalls and activate it, use toolbar button “Install” that is located next to the button “Compile”. It also opens wizard-like dialog that lists the cluster and member firewalls and provides checkboxes that allow you to choose which firewall you want to install on (both by default).

FigureÂ 24.Â Policy installer parameters

Figure 24. Policy installer parameters

Once you choose which firewalls you want to install the policy on and click Next, you are presented with policy installer dialog FigureÂ 24 where you need to enter authentication credential and some other parameters that control installation process.

Policy installer shows its progress in the dialog that looks like this:

FigureÂ 25.Â Policy installer progress

Figure 25. Policy installer progress

Installer copies the script to the firewall using scp (pscp.exe on Windows), then runs it there. If this is the first time you connect to the firewall using ssh, installer recognizes ssh warning about unknown host key and opens another pop-up dialog where it shows the key and asks administrator to verify it. If there were no errors during policy install, corresponding status is declared “success” in the left hand side column and installer tries to do the same for the next member firewall.

About the author: This article seires is contributed by Vadim Kurland {vadim at fwbuilder DOT org}, the main author of Firewall Builder.