FirewallBuilder

In the previous example, we put object "mail server" into the Destination field of the policy rule #0, because our goal was to permit the protocol SMTP to that host and not to any other one. This actually reflects the general principle Firewall Builder is based on: put the object for which you want to control access in the Source or Destination field of the policy rule. Two different objects with the same address may or may not be interchangeable, depending on their type and other parameters. One of the frequent mistakes is to create a host object with the IP address of the firewall, then use it in the policy and expect Firewall Builder to build a policy controlling access to the firewall. Unfortunately, it does not always work that way. If you wish to control access to or from the firewall machine, then put the firewall object into the policy rule.

Another example of two objects which may on the first glance represent the same thing, but in fact are not interchangeable, is an IP service object with the protocol number set to 1 and an ICMP service object with type and code set to "any". Both objects seem to represent the same type of service, namely "Any ICMP message". IP protocol 1 is in fact ICMP, so one would expect the behaviour of the firewall to be the same regardless of what type of service object is used. However, the target firewall software typically uses special syntax for indication of different protocols, so using specific syntax for ICMP protocol turns certain features on; for example, session state tracking and association of the ICMP packets to known sessions these packets might carry error messages for. Using just IP with protocol number 1 will most likely not turn these features on and therefore will lead to unexpected results.

An interface object and its IP address are interchangeable in rules, provided the interface has only one address. If the interface object has several address child objects, then using the interface object in a rule is equivalent to using all of its addresses in the same place. If interface has only one address, then the result will be the same whether you put interface object or its address in the rule. Also, using the firewall object in the rule should yield the same policy script as if you put all its interfaces in the same place instead. This one comes with a caveat though: many firewall platforms offer special syntax for rules that control access to or from the firewall itself and Firewall Builder takes advantage of this syntax, so the result may not look exactly the same, but should be equivalent in function. Some platforms, such as iptables, require using different chain to control access to and from firewall. Firewall Builder compares IP addresses used in the source and destination of rules to addresses of all interfaces of the firewall and uses proper chains, even if the address object in the rule is not the firewall object itself.

Two objects of the same type with different names but the same values of all other parameters are always interchangeable. Using different objects to describe the same object may be confusing, but the final firewall policy will be correct. Firewall Builder leaves design of the objects up to the firewall administrator.