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
Support for OpenWRT and DD-WRT
Firewall Builder 4.0 can generate a drop-in replacement script
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 “
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:
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.
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.
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:
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:
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.