New Features In Firewall Builder 4.0 - Page 4

Handling of the cluster rule set and member firewalls rule sets

Normally, only the cluster object should have non-empty policy, NAT and routing rule sets, while member firewall objects should have empty rule sets. In this case, Firewall Builder policy compilers will use rules they find in the cluster. However, if a member firewall has rule set object of any type (Policy, NAT, Routing) with the name the same as the name of the cluster object and the same type, then compilers will use rules from the member firewall and ignore those found in the cluster. They also issue a warning that looks like shown in Figure 13:

Figure 13. A warning shown when a rule set that belongs to the member firewall overrides rule set that belongs to the cluster

Suggested use case for this feature is to create a small non-top rule set in the cluster which can be used as a branch using a rule with action "Branch" to pass control to it. The cluster can define some rules in this rule set, these rules are going to be common for all member firewalls. However if for some reason you want to implement these rules differently for one member, you just create rule set with the same name in it and add some different rules there. Of course two members can have the rule set with this name and both will override the one that belongs to the cluster. The warning is only given if member firewall rule set is not empty. If it exists and has the same name as the one that belongs to the cluster, but has no rules, then the warning does not appear.

Examples of cluster configurations

Chapter “Firewall Builder Cookbook” in Firewall Builder 4.0 User's Guide offers several detailed examples of complete firewall cluster configurations. We have:

Support for OpenWRT and DD-WRT

Firewall Builder 4.0 can generate a drop-in replacement script for the standard OpenWRT and DD-WRT firewall script. On OpenWRT this was tested with stable Kamikaze (v7.06) and the latest OpenWRT (v8.09 at the time of Firewall Builder v4.0 release). On DD-WRT we tested with v24 and v24.sp1. Chapter “Integration with OS running on the firewall machine” in Firewall Builder 4.0 User's Guide has more details on intergration with OpenWRT, DD-WRT and other OS.

Branching rules in NAT

The NAT rule set now has additional column "Action" with just two actions: "Translate" and "Branch". Action "Branch" passes control to another NAT rule set. This has been implemented for iptables and PF. For iptables, compiler generates command using "-j target" clause in the "nat" table. For PF, it generates "anchor" or "nat-anchor" (depending on the version of PF).

Figure 14. Example of branching NAT rule, compiled for PF

Incremental management of IP addresses, VLAN, bridge and bonding interface configuration

Generated activation script compares IP addresses of interfaces on the firewall machine with those configured in Firewall Builder objects and adds or removes them as appropriate to bring two in sync. If lists of interfaces match, the script does nothing. Activation script generated by previous versions of Firewall Builder removed all addresses, then added them back to make sure address configuration of the machine matches fwbuilder objects. New version does not do that, which makes policy activation a lot safer.

The program supports new types of interfaces: VLAN, bridge, bonding. This is fully implemented for Linux and partially for other platforms. VLANs are added as child objects of an interface, like so:

Figure 15.

The program can generate commands to configure vlans, bridges and bonding interfaces on Linux. This is off by default and controlled by checkboxes in the "script" tab of the firewall object dialog. Generated script adds and removes vlans, bridges, bridge ports, bond and bond slaves incrementally. That is, the script analyzes existing vlan interfaces and compares them with vlan interfaces defined in the Firewall Builder GUI and then adds new ones and removes those that do not exist in fwbuilder. The same algorithm is used to create bridges, add or remove bridge ports and create bonds and then add or remove slave interfaces.

Chapter “Configuration of interfaces” in Firewall Builder 4.0 User's Guide explains interface configuration in great details.

Built-in installer is much faster when working with Cisco routers and ASA (PIX) firewalls

Built-in installer can use scp to copy generated IOS or PIX configuration to the device. This means it works much much faster then before. I would like to show some comparison figures to demonstrate just how much faster it is, but the comparison is really meaningles. Entering router or firewall configuration line by line, as in the old fwbuilder, is very slow, especially over high latency network connection. Copying the whole script using scp happens in a few seconds.

While updating configuration of a router or a firewall, fwbuilder copies generated configuration using "scp" command to the router and then executes it using "copy file running-config" command. It does not use "config replace" command because configuration created by fwbuilder is incomplete and should be merged with running config rather than replace it.

For this to work, of course, scp support must be enabled on the router or firewall for this to work. There should also be enough room on the flash storage on the device. Not all versions of IOS and PIX support scp, you are going to have to check the version you are running.

Chapters “Installing generated configuration onto Cisco routers” and “Installing generated configuration onto Cisco ASA (PIX) firewalls” in Firewall Builder 4.0 User's Guide have more details on this feature and provide a brief guide on configuring scp in Cisco routers and PIX firewalls.

Using EEM for automatic rollback of the configuration changes with Cisco routers

Built-in policy installer uses EEM (Embedded Event Manager) on IOS 12.4 or later to schedule automatic configuration rollback instead of reloading the router. EEM appears in IOS 12.4 and supports background operations that can be triggered by some events on the router or by the timer. In this new feature, fwbuilder creates EEM applet with a countdown timer that executes command "config replace nvram:startup-config force" when timer expires. User has the following options, controlled by checkboxes in the fwbuilder installer parameters dialog:

Schedule automatic rollback in a few minutes and install updated ACL configuration. This can be used to test new policy and revert to the original one after some short period of time. This also helps to avoid a situation when updated policy blocks access to the router because of an error; rolling back to the ACL configuration that was running before the update will restore access automatically.
Schedule rollback in a few minutes, install updated ACL but cancel rollback if installation of the new configuration was successful. This is mostly intended to prevent blocking access to the router in case of an error in the new ACL configuration. If fwbuilder was able to enter all lines of the new configuration all the way to the end, this means new configuration does not block access and installer executes command "no event manager applet fwbuilder-rollback" to cancel scheduled rollback.

Since IOS before 12.4 does not have EEM, automatic rollback on these older versions is implemented by scheduling router reload with command "reload in ". This hasn't changed since Firewall Builder v3.0

Automatic generation of "mirrored" rules for Cisco routers

Policy rule option "Add mirrored rule" (controlled by a checkbox in the rule options dialog) makes policy compiler for IOS ACL automatically create a rule with mirrored source and destination addresses and service fields. This can be used to match "reply" packets using address and service parameters matched by this rule. The action of the mirrored rule is the same as that of this one. Firewall Builder recognizes the following services and creates "mirrored" versions as follows:

UDP service: mirrored service has source and destination port ranges reversed
TCP service: mirrored service has source and destination port ranges reversed and "established" flag inverted. If TCP service used in this rule does not have "established" flag, the mirrored service gets it, and the other way around. This is designed to simplify creating ACL rules to permit "reply" TCP packets
ICMP service: ICMP echo request is recognized, mirrored service becomes ICMP echo reply. Other ICMP types are simply copied to the mirrored service
ICMPv6 service: like with ICMP, ICMP echo request is recognized and other ICMPv6 types are just copied
IP service: mirrored service is a copy

This feature helps generate router access lists to permit specific services in both directions, saving you time in that you do not have to remember to add rules for the reply packets.