5.2.15. Special-Case addresses

Policy compilers treat some addresses in policy rules in special ways, depending on the requirements of the target firewall platform. For example, the compiler for iptables checks if the address found in "Destination" or "Source" of a rule matches the address of any interface of the firewall to determine if the rule should be placed in INPUT or OUTPUT chain. The compiler for PIX uses the command ssh <address> <netmask>> inside when it detects such an address in the destination of a rule where the service is TCP Service object "SSH". There are other special cases as well. Broadcast and Multicast Addresses, iptables Firewall

Two important special cases are broadcast and multicast addresses. It is important to place rules in the correct chain in generated iptables script, because even though these addresses are not equal to those of the firewall's interfaces, iptables processes packets with broadcast or multicast destination in the INPUT chain. Firewall Builder is aware of this and generates the correct iptables commands.

In order to match broadcast or multicast addresses in the rules, we need to create objects to describe them. The choice of object type to describe broadcast or multicast address depends on whether this is just a single address, a range or a block. An address object is good for defining a single address, address range is good for sets of consecutive addresses and network object is good for describing a block. For example, you can use an address object with address "" to describe a broadcast. address range with addresses " -" would work well to describe two multicast groups used by OSPF. A network object with address "" and netmask "" can be used to describe a whole multicast address block.

Here are few examples:

Figure 5.78. Multicast Object

Multicast Object

Object "all multicasts" is part of the Standard Objects library that comes with the program. It describes an entire address block allocated for multicasts. Consider a simple policy rule that permits all multicasts:

Figure 5.79. Multicast Rule

Multicast Rule

For iptables, this rule translates into the following script:

$IPTABLES -A INPUT  -d  -m state --state NEW  -j ACCEPT 

The rule went into the INPUT chain because iptables processes multicast there.

Here is another example, this time it involves broadcast addresses. The interface "inside" of the test firewall has address with netmask This defines subnet with broadcast address We create an address object with the name "net-172.16.22 broadcast" and address "" and use it in the destination field of a policy rule. Another rule in the same example will match broadcast address ""; an address range object that defines this address is present in the standard objects library under the name "broadcast". Here are the rules:

Figure 5.80. Broadcast Rules

Broadcast Rules

These two rules translate into the following script for iptables:

# Rule 0 (global)
$IPTABLES -A INPUT  -d  -m state --state NEW  -j ACCEPT 
# Rule 1 (global)
$IPTABLES -A INPUT  -d  -m state --state NEW  -j ACCEPT 

Both rules went into INPUT chain as expected. Broadcast and Multicast Addresses and Bridging iptables Firewall

Compilers treat broadcast and multicast addresses differently if the firewall object is set to be a bridging firewall. In this case the checkbox "Bridging firewall" should be turned on in the firewall settings dialog and one or more interface objects should be marked as "Bridge port":

Figure 5.81. Broadcast and Multicast Address in a Bridging Firewall

Broadcast and Multicast Address in a Bridging Firewall

Now the rule that matches the broadcast destination address will be treated differently:

Figure 5.82. Broadcast and Multicast Address in a Rule

Broadcast and Multicast Address in a Rule

This produces the following iptables commands:

$IPTABLES -A FORWARD  -d  -m state --state NEW  -j ACCEPT 
$IPTABLES -A INPUT  -d  -m state --state NEW  -j ACCEPT 

Rules went into both INPUT and FORWARD chains because the bridging firewall passes broadcasts through, but at the same time accepts them as packets headed for itself. Since the rule did not specify which interface it should look at, Firewall Builder assumed that the generated rule should inspect packets crossing all interfaces, both bridge ports and "normal" ones, and therefore placed the rule in both INPUT and FORWARD chains.


Copyright © 2000-2012 NetCitadel, Inc. All rights reserved.
 Using free CSS Templates.