Firewall Builder Release Notes
Version 2.1.7
Released 10/31/2006
GUI and compilers v2.1.7 require API library libfwbuilder version 2.1.7
Summary
For those who wish to build from source, instructions are outlined
in the document "Install and Build instructions" on our web site here
Installation
Packages of Firewall Builder 2.1 are built in a such way that you
should be able to install them on the same machine with Firewall
Builder 2.0.X. All binaries have names that end with "21",
e.g. "fwbuilder21" or "fwb_ipt21". On Windows the
binary name is the same but the package installs in
directory c:\FWBuilder21 which is different from the default
directory for Firewall Builder 2.0; all registry entries are also
located in different subtrees. All this is done to ensure the user
can run Firewall Builder 2.1 while still using stable version 2.0.12
on the same machine.
Improvements and changes in the GUI
- The GUI works much faster with very large object trees. Tested
using a data file with over 3000 objects)
- "Where used" menu item has been added to quickly find and show
all groups and firewall rules that reference given
object. Confirmation dialog that is shown when user tries to
delete an object also shows all groups and rules that use it.
- By popular request, built-in installer can now save a copy of
.fwb file to the firewall.
- Compile/install dialog is now an independent window instead of a
modal dialog, this means the user can look at the policy and
objects while compilation and/or installation is going on. This is
especially convenient as it allows one to inspect the rules after
failed compilation while still having compiler error on screen.
- Network discovery driud is back, ported from fwbuilder
1.0. As before, it supports reading object definitions from a
file in /etc/hosts format, can read DNS zone and also can
crawl the network using SNMP queries.
- Startup wizard ("Welcome to Firewall Builder") has been
removed. The GUI now starts either into an empty database or
opens data file specified on the command line.
- Keeping track of dependencies between objects. This is
useful when many firewalls in the tree use the same set of
objects. Each firewall object keeps track of objects it
depends on, so if any object is modified, all firewalls that
use it in their rules are marked with bold font to indicate
that they need to be recompiled. Object dependencies are
tracked not only when objects are directly used in rules,
but also when they apepar there indirectly, as members of
groups
- Added bulk compile and install operations. This is useful
when there are many firewalls in the tree that need to be
compiled and installed in one go. Bulk install operation is
only possible if all firewalls use the same user name and
password for authentication. If this is not the case,
built-in installer can be instructed to ask for the
authentication information before it touches each firewall.
- All object dialogs have been converted into built-in
panels that appear in the right hand part of the main
window. This simplifies navigation ( pop-up dialogs used to
obscure parts of the main window). Objects open in the
editor on a single mouse click in the tree and rules.
- Improvements in "Find" function: administrator can now
drag an object into a well in the find dialog panel to make
it search for this particular object. This is useful if the
name of the obejct is not unique. Search by object's name or
a value of its attribute is also possible.
- In addition to the "Find" function, the "Find and replace"
operation has been implemented. Objects can be found and
replaced in groups and firewall rules
New object types, new rule types and rule elements, new
actions and other new features
- AddressTable This object resolves to a set of
IP addresses defined in an external file. The object can be
configured to read the file at compile time or at run time. For
each compile-time AddressTable object defined in the object tree
compiler tries to find and read the file specified in the object
configuration. Compiler aborts processing if the file can not be
found or can not be read. If the file is in place and can be
read, such AddressTable object behaves as if it was a group of
IP address objects, that is, all addresses are explicitly copied
into generated configuration, although compiler may use target
firewall syntax that helps to group such sets of addresses into
tables. Compilers for iptables, ipfw, ipf and PIX generate bunch
of rules matching each address read from the file. Compiler for
PF creates a table and also lists all IP addresses it reads from
the file; it uses the name of the AddressTable object for the
name of the table it creates.
Run-time AddressTable objects are only supported by
compilers for iptables and PF. Compiler for iptables
generates shell code to read the contents of the file when
firewall configuration is activated. Compiler for PF uses
native "table <name> persist file <file_name>"
syntax. Here also the name of the table is the same as the
name of the AddressTable object it was created for.
- DNSName: This object resolves a host name to
the IP address using DNS. Object can be confgiured to do so at
compile time or run time. Resolution is done using system call
gethostbyaddr() to read DNS A records for the name. System
resolver should take care of recursion and CNAME records, if
any. If the name resolves to several IP addresses, all addresses
are used in the generated firewall configuration. Run-time
DNSName objects rely on the target firewall software to be able
to convert symbolic names used in rules into actual IP addresses
at a time when policy is activated. Not all platforms provide
means to support run-time DNSName objects.
- TagService: This object matches tags set by
action Tag. It is translated into --mark
<mark_code> for iptables and tag option for
PF. This service object is only supported by compilers for
iptables and PF.
- Interface objects can now have an attribute to mark
them as bridge ports, used for bridging firewalls.
- Support for routing rules has been implemented using patch
provided by Tidei Maurizio <fwbuilder-routing at
compal.de> Support for routing rules is only implemented in
compiler for iptables. See file README.routing included in
fwbuilder2 package.
NOTE: I can only provide very limited support for this feature, please direct your questions and bugreports to the author
- Global policy and interface policies have been merged. Each
policy rule now has rule element "Interface". Administrator
can drag and drop interface object of the firewall into this
rule element field. Policy compilers support multiple
interfaces and negation in "Interface" rule element. Rule
element "direction" that previously was only part of the
interface policy rules is now part of all policy rules.
- Policy rules can have the following new actions:
- Queue: This action passes the packet to
user space process for inspection, it is translated
into QUEUE for iptables and divert for
ipfw. This action is only supported by compilers for
iptables and ipfw..
- Custom: This action allows administrator
to define arbitrary piece of code to be used in place of
an action. Supported by compilers for iptables, ipf and
ipfw
- Branch: This action is used to create a
branch in the rule set. It works on target platforms that
provide suitable syntax and allow control to return to the
higher level rule set if the branch can not make final
decision about the packet. For iptables this action is
translated into user-defined chain. The name of the chain
is the name of the branch choosen by administrator. For PF
this action is translated into an anchor with the name the
same as the name of the branch defined by the
administrator. This action is only supported by compilers
for iptables and PF.

Fig.1 Rule #0 of the global policy creates a branch with the name rule0_branch
- Tag: This action associates internal tag
with the packet. Tag can later be inspected using
service object TagService. This action is
translated into MARK target with
corresponding --set-mark parameter and optionally
additional rule with CONNMARK --save-mark target
for iptables. If option that activates CONNMARK
target is used, compiler also adds a rule at the very
top of the policy to restore the mark. Rules are placed
in INPUT,OUTPUT and FORWARD chain
of the "mangle" table, this ensures
that DNAT happens before rules placed in the
mangle table see the packet. PREROUTING chain in
mangle table is executed before PREROUTING chain
in the nat table, so placing tagging rules in the
PREROUTING chain would make them fire before
DNAT. POSTROUTING chain of the mangle
table, as well as its FORWARD and OUTPUT
chains, work before corresponding chains of the nat
table. In all cases the goal is to make sure DNAT
rules process the packet before, and SNAT rules process
it after filtering and tagging rules.
For PF this action is translated into tag.
Supported only by compilers for iptables and PF.

Fig.2 Example of a rule utilizing action Tag. To illustrate policy branches, this rule belongs to the branch with the name rule0_branch
- Classify: This action allows the firewall
to define QoS class for the packet that matches the
rule. It is translated into CLASSIFY for
iptables, with parameter --set-class. For PF it
is translated into queue; compiler for ipfw can
use pipe, queue or divert depending
on how the action is configured by the administrator in
the GUI. This action is only supported by compilers for
iptables, PF and ipfw.
- Route: This action makes the firewall to
route the packet that matches the rule through an
interface or a gateway specified in the parameters of the
action. This action is translated into ROUTE target
for iptables and route option for PF and
ipfilter. Compilers for PF and ipfilter
support fastroute, route-to,
reply-to and dup-to options.

Fig.3 Rules #0 and #1 tag packets entering the firewall through interfaces eth0 and eth2; rules #3 and #4 help route reply packets back through the same interfaces
The GUI uses different names for the new actions depending
on the target firewall platform to simplify adoption. For
example, new action that created branch in rule set is
called Chain for iptables firewalls and Anchor
for PF fierwalls.
- Firewall object now has an attribute "inactive". Firewall
marked as inactive will not be picked by the GUI for the bulk
compile and install operations even if the timestamps indicate
that this firewall object needs to be recompiled
Compiler for iptables
- Support for address tables loaded from external files at
compile or run time
- Support user defined chains with predefined names (using
special action )
- Support
for CLASSIFY, MARK, CONNMARK, QUEUE, ROUTE
targets
- Support for physdev module for bridging firewalls
- additional optimization of rules i INPUT and OUTPUT chain:
now removing firewall object from src or dst to simplify rule
if it uses OUTPUT or INPUT chain. Doing this only if original
rule did not have negation and we do not add any virtual
addresses for NAT. After removal the rule collapses to a
simple command like this:
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT
this works fine except if we have added virtual addresses for
NAT. It is assumed that firewall object in rules represents
combination of addresses configured in its interfaces in the
GUI. Virtual addresses added for NAT are considered to be a
side effect and connections should not be implicitly permitted
to them by a rule with fw object in destination. The same
applies to fw object in source. See bug #685947 for
discussion. To avoid inadvertently opening holes in the
firewall by a rule like that, we remove fw object only when it
is safe to do so.
- support for modules connlimit
and hashlimit. There is an option to generate commands
for the latter module using name dstlimit because older
versions of iptables included this module under this (now
obsolete) name.
Compiler for PF
- Support for load balancing rules
- Support for tag and route options
- Support for address ranges and networ objects in TSrc in NAT
rules
- Support for pool types in NAT rules ('bitmask', 'random',
'source-hash', 'round-robin'), as well as 'static-port'
option.
- Supprot for anchors (by way of a special action)
- Support for tables with predefined names (using AddressTable object)
- Support for packet 'tagging' (by way of a special action and service object TagService)
Compiler for ipfilter
- Support for PPTP and IRC proxies
- Support for route option
API
- internal object ID is augumented with process ID of the
program that creates an object. This allows fwbedit to quickly
create objects and still ensure their IDs are unique
-
fwbedit
Fwbedit can now create objects and repair broken object
database. This tool can now be used to populate object database
using shell scripts or other automation. For example, to create an
address object in object library 'Test' one could run it like
this:
fwbedit -f filename.fwb -t IPv4 -n newAddress -L Test -o 192.0.2.1
Firewall Builder: general purpose object tree editing tool
Version 2.1.5-b
Usage: fwbedit21 -f filename.fwb -u [-a obj,grp] [-r obj,grp] [-d obj] [-s] [-l path] [(-p parent|-L library) -t objtype -n objname [-o object attributes]]
-t objtype : create an object of this type
-L library : specify library when creating a new object
-p obj : specify parent object when creating a new object
-n name : specify a name of the new object
-o attribute1[,attribute2...] : specify attributes when creating a new object
-a obj,grp : create reference to object 'obj' in the group 'grp'
-r obj,grp : remove reference to object 'obj' from the group 'grp'
-d obj : delete object 'obj' and remove references to it from
all rules and groups
-l path : print list of objects for 'path'
-s : test and repair object tree structure
-u : autoupgrade of file
An object and a group can be defined by their ID or
by the full path and name in the XML tree
Object creation syntax:
-t Firewall -n obj_name -L User -o platform, host OS
-t IPv4 -n obj_name -L User -o IP address
-t DNSName -n obj_name -L User -o DNS record,run time
-t AddressRange -n obj_name -L User -o start address, end address
-t ObjectGroup
-t Network -n obj_name -L User -o address,netmask
-t Interval -n obj_name -L User -o start time,start date,start day,end time, end date, end day
-t Interface -n obj_name -L User -o security level,address type (dynamic or unnumbered),management
-t Host
-t TCPService -n obj_name -L User -o source port range start,end,Destination port range start,end,UAPRSF,UAPRSF
-t UDPService -n obj_name -L User -o source port range start,end,Destination port range start,end
-t ICMPService -n obj_name -L User -o ICMP type,ICMP code
-t IPService -n obj_name -L User -o protocol number,lsrr/ssrr/rr/ts/fragm/short_fragm