6.1.2.1. Creating a Firewall Object Manually

To start the firewall object creation wizard, right-click the Firewalls folder in the User tree and select New Firewall.

The first page of this wizard is displayed.

Give the firewall object a name. Usually, this name will be the same name as the device, but it doesn't have to be if you're assigning interfaces manually. (If you will use SNMP or DNS to populate the interfaces, then the name must be the same as the device name.) Then specify the firewall software and device OS.

Leave the Use pre-configured template firewall objects checkbox unchecked.

Click Next.

Select Configure interfaces manually and click Next.

Use this screen to add firewall interfaces. Populate the following fields for an interface, then click Add to add the interface. Then, populate the fields again for the next interface. If you make a mistake, click on the interface in the list, make your changes, then click Update.

• Interface type: Indicate the type of interface. Section 6.1.3 explains the interface types in more detail. Briefly, though, a Regular interface has a static IP addresses, a Dynamic address interface has a dynamic address provided by something like DHCP, an Unnumbered interface never has an IP address (a PPPoE connection, for example), and a Bridge port is an interface that is bridged in the firewall.

• Name: The name of the interface object in Firewall Builder must match exactly the name of the interface of the firewall machine it represents. This will be something like "eth0", "eth1", "en0", "br0", and so on.

• Label: On most OS's this field is not used and serves the purpose of a descriptive label. The label is mandatory for Cisco PIX though, where it must reflect the network topology. Firewall Builder GUI uses the label, if it is not blank, to label interfaces in the tree. One of the suggested uses for this field is to mark interfaces to reflect the network topology ('outside', 'inside') or interface purpose ('web frontend' or 'backup subnet').

• Address: If the interface has a static IP address, specify it here. (In Firewall Builder version 3.X, this must be an IPv4 address. If you need it to be an IPv6 address, create the interface without an IP address, then add the IPv6 address after you have created the firewall object.)

• Netmask: Use either a traditional netmask (255.255.255.0) or slash notation (24, without the actual slash) to specify the interface netmask.

• MAC: If you like, you can also specify the interface physical address. The MAC address is not necessary, but it can be used to combat spoofing. If the feature is turned on and available, the firewall will only accept packets from the given IP address if the MAC address also matches the one specified. Section 6.1.6.1 has more information.

Once all the interfaces are configured, click Finish to create the new firewall object.

6.1.2.2. Creating a Firewall Object using SNMP Discovery

If your firewall runs an SNMP daemon, you can save yourself some time by using SNMP discovery to automatically create interfaces of the new firewall object.

Start by checking the Use SNMP to discover interfaces of the firewall checkbox on the second page of the wizard and enter your SNMP 'read' community. Then click Discover interfaces using SNMP.

Firewall Builder runs a series of SNMP queries to the firewall to read the list of interfaces and their addresses. Both IPv4 and IPv6 address can be imported. For IPv6 the firewall must support IP-MIB RFC4293. Once the discovery process finishes, click Next.

The next page of the wizard offers an opportunity to review the discovered interfaces and make adjustments if necessary. To change something, highlight an interface, edit its parameters in the dialog, then click Update. Finally, when the process is done click Finish. The program creates the new firewall object in the tree and adds all configured interfaces and their addresses.

6.1.2.3. Editing a Firewall Object

The Firewall Object represents the firewall machine and is the most complex object in Firewall Builder. It has three sets of controls that you can modify, not including the policy rule sets. All these controls become available when you double-click the firewall object in the tree.

6.1.3.1. More about Security Levels and Network Zones

Consider the network layout as in Figure 6-13.

Here the firewall has three interfaces: 'outside', 'dmz', and 'inside'. Behind the firewall there is a router which in turn is connected to three subnets: 'subnet A', 'subnet B', and 'subnet C'. Subnet A is shared between the router and the firewall (each device has an interface on this subnet). Let's suppose we have created Network objects for each subnet and called them 'subnet DMZ', 'subnet A', 'subnet B' and 'subnet C' (remember, spaces are allowed in object names). For this setup, network zones should be configured as follows:

Since the network zone for the 'inside' interface consists of multiple objects, you must create a group so that you can use this group as a Network Zone object.

Table 6-1 explains the differences in the way firewall platforms interpret values in the Security Level and Network Zone parameters of the firewall interfaces.

Note that the "external" interface option may be deprecated in the future versions of the program.

In PIX, access lists must always be attached to interfaces. The policy compiler for PIX uses information about the network zones of interfaces to decide which interface a rule should be associated with if its "Interface" column does not specify one (is left set to "All"). Instead of placing this rule in access lists attached to all interfaces, it compares addresses in the Source and Destination of the rule with network zones of interfaces and only uses interfaces that match. This helps generate a PIX configuration that is more compact.

6.1.3.2. Using Interface Object in Rules

Policy rules in Firewall Builder have a rule element called Interface. You can drag-and-drop, or copy/paste interface object into this column of a rule to make the firewall match not only the source and destination address and service, but also the interface of the firewall through which packets enter or exit. The direction of the packet is defined in column Direction. Consider the following example:

Rule #0 is "anti-spoofing" rule which relies on the ability to define interface and direction. It matches packets with source addresses equal to the addresses of the firewall's interfaces or internal network, but that are coming in from outside, which is determined by comparing the interface through which packets enter the firewall. Packets with "internal" addresses cannot normally come from outside, and if they do, they must be spoofed and should be dropped. This is what this rule does: it drops and logs these packets. Rule #1 permits connections originating from the internal network going out, but it makes sure these packets enter the firewall through its internal interface.

These two rules generate the following iptables script:

# 
# Rule 0 (eth0)
# 
$IPTABLES -N In_RULE_0
$IPTABLES -A FORWARD  -i eth0  -s 192.0.2.1  -j In_RULE_0 
$IPTABLES -A FORWARD  -i eth0  -s 172.16.22.1  -j In_RULE_0 
$IPTABLES -A FORWARD  -i eth0  -s 192.168.2.1  -j In_RULE_0 
$IPTABLES -A FORWARD  -i eth0  -s 172.16.22.0/24  -j In_RULE_0 
$IPTABLES -A In_RULE_0  -j LOG  --log-level info --log-prefix "RULE 0 -- DENY "
$IPTABLES -A In_RULE_0  -j DROP 
# 
# Rule 1 (eth1)
# 
$IPTABLES -A FORWARD  -i eth1  -s 172.16.22.0/24  -m state --state NEW  -j ACCEPT 
      

Here all iptables commands have an "-i eth0" or "-i eth1" clause, which makes iptables compare the interface and direction.

Here is what we get if we compile the same rules for PF:

# Tables: (1)
table <tbl.r9999.d> { 192.0.2.1 , 172.16.22.1 , 192.168.2.1 } 

# 
# Rule  0 (eth0)
# 
block in   log  quick on en0 inet  from <tbl.r9999.d>  to any
block in   log  quick on en0 inet  from 172.16.22.0/24  to any
# 
# Rule  1 (eth1)
# 
pass in   quick on en1 inet  from 172.16.22.0/24  to any keep state
# 
      

For PF, the compiler generated a "block in log quick on eth0" clause to make the rule match interface and direction.

In the case of Cisco IOS access lists, defining an interface in the rule makes the compiler place code generated for this rule into the ACL attached to the given interface. The compiler for IOS ACL always generates both inbound and outbound access lists for each interface, but if the rule specifies both interface and direction ("Inbound" or "Outbound"), the generated configuration goes only into the corresponding access list. Here is the output produced for the rules shown above for Cisco IOS ACL:

ip access-list extended inside_in
! Rule  1 (eth1)
! 
  permit ip 172.16.22.0 0.0.0.255 any  
exit

ip access-list extended outside_in
! Rule  0 (eth0)
! 
  deny   ip host 192.0.2.1 any  log 
  deny   ip host 192.168.2.1 any  log 
  deny   ip 172.16.22.0 0.0.0.255 any  log 
exit

interface FastEthernet1
  ip access-group inside_in in
exit
interface FastEthernet0
  ip access-group outside_in in
exit
      

So far, the examples in this section have demonstrated how to use Interface objects to associate policy rules with interfaces so as to match packets crossing certain interface. An interface object can be used in the "source" and "destination" of rules just like any other addressable object. In this case, Firewall Builder replaces the interface object with the set of its addresses, picking only those addresses that match the address family (IPv4 or IPv6 or both) assigned to the rule set.

For example, we start with a firewall configuration where interface eth1 has two IP addresses, one IPv4 and another is IPv6. Note that this could be a host object as well because interfaces can belong either to a Firewall or a Host object.

Interface eth1 has IPv4 address 172.16.22.1 and IPv6 address fe80::21d:9ff:fe8b:8e94. It is used in a simple policy rule as follows:

This policy rule set is configured as a mixed IPv4+IPv6 rule set. For iptables, the compiler generates the following code:

# ================ IPv4
# Rule 0 (global)
# 
$IPTABLES -A INPUT -p tcp -m tcp  -d 172.16.22.1  --dport 22  -m state \
 --state NEW  -j ACCEPT 

# ================ IPv6

# Rule 1 (global)
# 
$IP6TABLES -A INPUT -p tcp -m tcp  -d fe80::21d:9ff:fe8b:8e94  --dport 22 \
 -m state --state NEW  -j ACCEPT
      

For PF we get the following:

# Rule  0 (global)
# 
# 
pass in   quick inet proto tcp  from any  to 172.16.22.1 port 22 keep state
pass out  quick inet proto tcp  from any  to 172.16.22.1 port 22 keep state

# Rule  0 (global)
# 
# 
pass in   quick inet6 proto tcp  from any  to fe80::21d:9ff:fe8b:8e94 port 22 \
keep state
pass out  quick inet6 proto tcp  from any  to fe80::21d:9ff:fe8b:8e94 port 22 \
keep state
      

Since the interface has two addresses, one IPv4 and another IPv6, the compiler generates commands in both the IPv4 and IPv6 sections of the script, but it uses only the appropriate address in each. Other than that, the interface object behaves just like a set of addresses when used in the source or destination element of a rule. It can also be used in NAT rules. Here is an example:

This generates the following code for iptables:

# Rule 0 (NAT)
# 
$IPTABLES -t nat -A POSTROUTING -o eth0  -s 172.16.22.0/24 -j SNAT \
--to-source 192.0.2.1 
# 
# Rule 1 (NAT)
# 
$IPTABLES -t nat -A PREROUTING  -p tcp -m tcp   -d 192.0.2.1 --dport 80 \
-j DNAT --to-destination 172.16.22.100 
       

And for PF:

# Rule  0 (NAT)
# 
nat on eth0 proto {tcp udp icmp} from 172.16.22.0/24 to any -> 192.0.2.1 
# 
# Rule  1 (NAT)
# 
rdr on eth0 proto tcp from any to 192.0.2.1 port 80 -> 172.16.22.100 port 80 
        

6.1.3.3. Using Interface Object with Dynamic Address in Rules

The examples above demonstrated what happens when an interface with one or several IP addresses is used in policy and NAT rules. Let's look at the case when an interface has an address assigned dynamically. This means the address is unknown to the Firewall Builder policy compiler when it generates the configuration script. The compiler uses features of the target firewall to work around this. Here is the configuration of the interface object eth0. The radio-button Address is assigned dynamically is selected.

The following policy rule uses interface eth0 in destination:

Here is what we get for iptables:

getaddr eth0  i_eth0
getaddr6 eth0  i_eth0_v6

# ================ IPv4

# Rule 0 (global)
# 
test -n "$i_eth0" && $IPTABLES -A INPUT -p tcp -m tcp  -d $i_eth0  --dport 22 \
  -m state --state NEW  -j ACCEPT 

# ================ IPv6

# Rule 0 (global)
# 
test -n "$i_eth0_v6" && $IP6TABLES -A INPUT -p tcp -m tcp -d $i_eth0_v6  \
 --dport 22  -m state --state NEW  -j ACCEPT 
        

Shell functions "getaddr" and "getaddr6" are defined earlier in the script. The generated script determines IPv4 and IPv6 addresses of interface eth0 at the time of execution and then uses the values in iptables commands. If the interface does not have an address, the corresponding variable gets an empty string for its value and the iptables command using it is skipped.

PF allows for using interface name in rules and gets its current IP address automatically. Here is what is generated for PF:

# Rule  0 (global)
# 
pass in   quick inet proto tcp  from any  to (en0) port 22 keep state
pass out  quick inet proto tcp  from any  to (en0) port 22 keep state

# Rule  0 (global)
# 
pass in   quick inet6 proto tcp  from any  to (en0) port 22 keep state 
pass out  quick inet6 proto tcp  from any  to (en0) port 22 keep state
         

We still get two separate parts for IPv4 and IPv6 because the rule set is configured as IPv4+IPv6 mix, but in both cases compiler just used the interface name because its actual IP address is dynamic and was unknown at the time the configuration was generated.

6.1.3.4. Using Interface Object in Rules of Bridging iptables Firewall

In case of the "normal" iptables firewall, Firewall Builder adds an "-i eth0" or "-o eth0" parameter to the generated iptables command to make it match interface and direction. If radio button "Bridge port" is turned on in the interface object, the compiler uses a different option to make iptables match packets crossing bridge ports. Here is the interface "eth1" which is configured as a bridge port:

Consider the following rule in the policy of the firewall this interface belongs to:

This rule matches interface "eth1" and generates the following iptables command:

$IPTABLES -A FORWARD  -m physdev --physdev-in eth1  -s 172.16.22.0/24 \
 -d 172.16.22.255  -m state --state NEW  -j ACCEPT 
      

Since the interface is now a bridge port, the compiler uses "-m physdev --physdev-in eth1" to match it.

6.1.4.1. IPv4 Address Object When Used as an Address of an Interface

In this case the object is a "child" or "leaf" under the an interface object, either on a Host or a Firewall object. To create this kind of an Address, right-click on the interface object to bring up the context menu.

Its dialog provides the following entry fields:

• Name

  This is the name of the object. Use a descriptive name because when the address object is used in the firewall policy, it is labeled with this name. It may be hard to tell one address from another if their names are similar.

• Address

  This is an IP address. The GUI widget provides syntax control for the values entered in the field. (This syntax control activates when you save the object.)

  Note: A typical error is to interpret this object as an address of the subnet to which the interface of the host or firewall belongs. This object represents an address of the interface, not a network address. (So, 192.168.1.1, not 192.168.1.0)

• Netmask

  This is a netmask assigned to the interface. You can enter the netmask using the traditional method (255.255.255.0) or using network bit length notation ("24"). Bit length notation is converted to a traditional netmask by Firewall Builder.

• DNS Lookup

  If the host object has the same name as the actual machine, then clicking this button generates a DNS query that populates the interface IP address and subnet. Only the parent host or firewall object's name is used for the DNS query; the name of the interface is ignored and can be anything.

• Comment

  This is free-form text field for a comment.

Here we use our IPv4 address in a rule (remember, it belongs to the interface):

Firewall Builder's iptables compiler, for example, generates the following command from this rule:

$IPTABLES -A INPUT -p tcp -m tcp  -d 172.16.22.1  --dport 22  -m state \
	--state NEW  -j ACCEPT

Note how even though the Address object has a netmask, the generated command matches the address as a host address, not as a subnet. This is because the netmask is used only to describe the subnet for the interface, not to describe the subnet. When this address object is used in a rule, it is understood that the intention is to match the address of the interface it belongs to rather than any address on the subnet. Use the Network object if you need to match a whole subnet.

This iptables rule was placed in the INPUT chain because the object in the "Destination" was an address of an interface of the firewall. While processing the policy for the iptables target firewall platform, Firewall Builder compares addresses in the source and destination of a rule to the addresses of all interfaces of the firewall to find rules that control access to and from the firewall. Firewall Builder places these rules into INPUT or OUTPUT chains. This is only necessary for iptables.

6.1.4.2. IPv4 Address Object When Used as a Stand-alone Object

In this case the object is located in the Objects / Addresses part of the objects tree and does not have a netmask entry field. To create this kind of an Address, use the New Object menu to select New Address or use the right-click menu associated with the Addresses folder in the tree.

Dialog fields Name, Address and Comment have the same purpose and properties as an Address object assigned to an Interface object.

The DNS Lookup button can be used to automatically populate the address field using a DNS query. The program runs DNS query for the "A" record with the name of the Address object. The object name does not have to match any DNS record if you never plan to use this feature. DNS query function is just a convenience, but to use it, the name of the object must match a DNS record.

6.1.5.1. IPv6 Address Object When Used as an Address of an Interface

If it is used to describe an IPv6 address of an interface, it has a netmask represented as bit length. Unlike with IPv4 address object, an IPv6 netmask is never represented as a colon-separated string of octets.

6.1.5.2. IPv6 Address Object When Used as Stand-alone Object

In this case this object is located in the Objects / Addresses part of the objects tree (the same place where stand-alone IPv4 addresses are located) and does not have a netmask entry field. To create this kind of an Address, use the New Object menu item New Address IPv6 or the right-click menu associated with the Addresses folder in the tree.

Policy compilers treat IPv6 addresses in policy rules according to the same algorithms as those for IPv4 rules. For example, just like with IPv4, the compiler for iptables checks if an address matches an address of any interface of the firewall to determine if the rule should be placed in the INPUT or OUTPUT chain.

Consider the rule shown in the screenshot below where we use two IPv6 address objects. One object belongs to the interface inside of the firewall while another is the IPv6 address of the project's web site.

For iptables, Firewall Builder generates the following commands from this rule:

$IP6TABLES -A INPUT -p tcp -m tcp  -d fe80::21d:9ff:fe8b:8e94  --dport 80  \
-m state --state NEW  -j ACCEPT 
$IP6TABLES -A FORWARD -p tcp -m tcp  -d 2001:470:1f0e:162::2  --dport 80  \
-m state --state NEW  -j ACCEPT
      

The rule that matches the address described by object guardian-2:eth1:ipv6 went to the INPUT chain because compiler detected that this rule matches packets that are headed for the firewall itself, which iptables inspects in the INPUT chain. The rule that matches the address described by the object ipv6.fwbuilder.org went to the FORWARD chain because these packets go through the firewall.

6.1.6.1. Using The Physical Address Object in Policy Rules

Only a few firewall platforms really support physical address filtering. Currently, Netfilter/iptables is the only firewall platform supported by Firewall Builder that can do physical address filtering.

As described in Section 6.1.7.4, if an Interface object that has multiple child address objects is used in a rule element (either Source or Destination), then the policy compiler tries to generate a rule using all of them. Section 6.1.7.4 explains that the compiler actually does this by generating multiple rules using each address in turn. This roughly corresponds to using the logical operation "OR" on the IP addresses: if our interface has two addresses, Address1 and Address2, then the generated rule would match if the address in the packet is either Address1 OR Address2. The case of a Physical Address is different though. If the Interface has a physical address, then the compiler builds a rule that has to match an IP address and the MAC address. The reason is to combat IP spoofing.

Suppose we have a very important host on the network. We create a Host object, then add an interface to it. The interface should have both Address and Physical Address objects as shown in Figure 6-29. The two child objects are visible in the tree under the Interface "eth0".

Because this is a very important host, we would like to be sure that packets whose source IP is that of this host are really coming from it and are not spoofed. The best way to achieve this goal is to use strong authentication, for example with IPSEC protocol. Using IPSEC is outside the scope of this document though; our goal right now is to show that inspecting the MAC address of the packet can improve security.

Both a real packet originated from this host and a spoofed packet have a source IP address of the interface of this host, but the source MAC address is going to be different if spoofing is going on. We can use this to catch and drop spoofed packets. Here are three possible ways to build security policy in this situation:

• Using only Address object in the rule element. This means the firewall inspects only IP address and ignores the MAC address of the packets.

  Figure 6-30. Policy rule using only Address object

  

  Firewall Builder generates the following simple iptables command for this rule:

  $IPTABLES -A FORWARD  -s 10.3.14.44  -m state --state NEW  -j ACCEPT 
  

• Using only Physical Address object. A rule built this way permits all kinds of traffic coming from the trusted host even if its IP address changes.

  Figure 6-31. Policy rule using only Physical Address object

  

  For this rule, the following iptables command is generated:

  $IPTABLES -A FORWARD  -m mac --mac-source 00:1D:09:8B:8E:94 -m state --state NEW \
  -j ACCEPT 
                

• Using Host or Interface object. This way we end up with a rule that matches on a combination of the IP address and MAC address. This may be used as a sophisticated anti-spoofing rule.

  Figure 6-32. Policy rule using Host object

  

  Figure 6-33. Policy rule using Interface object

  

  For this rule, the following iptables command is generated:

  $IPTABLES -A FORWARD  -m mac --mac-source 00:1D:09:8B:8E:94 -s 10.3.14.44  -m state \
  --state NEW  -j ACCEPT 
                

Using Address and Physical Address objects in a rule is not the same as using the Host or Interface object to which these Address and Physical Address belong. Here is what happens if we put objects representing IP address and MAC address in the rule:

For this rule, the following iptables commands are generated:

$IPTABLES -A FORWARD  -s 10.3.14.44  -m state --state NEW  -j ACCEPT 
$IPTABLES -A FORWARD  -m mac --mac-source 00:1D:09:8B:8E:94 -m state --state NEW \
-j ACCEPT 
        

As described in Section 6.1.7.4, using an multiple objects in the rule element is like bundling them together using logical operation OR. If we were to put Address and Physical Address in the rule like in Figure 6-34, we would end up with a policy matching packets that have the source address 10.3.14.44 or MAC address 00:1D:09:8B:8E:94, but not necessarily both at the same time. Any host that manages to pretend to have the IP address 10.3.14.44 would be able to send packets through our firewall even if its MAC address is different. To achieve our goal and make sure packets with the source 10.3.14.44 really belong to our important host, we should be checking its IP address and MAC address at the same time and let a packet through only if its IP address AND MAC address are what we expect them to be. That is why Firewall Builder treats physical addresses differently and generates firewall code that inspects both IP address and physical address.

Firewall Builder generates firewall code to inspect MAC address only for Host objects with the option MAC address filtering turned on. If this option is off, the Physical Address object will be ignored even if it is present in the Host object's Interface. This is because Host objects created using the Network Discovery Druid ( Chapter 7 ) are often populated with both IP address and MAC address information (available through SNMP query), but inspection of MAC addresses is rarely needed. Use the MAC address filtering option in the Host object to specify that you want the MAC address to be verified for the host.

6.1.7.1. Creating a Host Object

To speed up the process and make it simpler, creating a new host object is aided by a wizard that is similar to the one for creating a new Firewall Objects.

To launch the wizard, select New Host from the New Object menu or right-click on Hosts and select it from there.

Section 6.1.2 shows how to use the Firewall object wizard. The Host object wizard is the same, with the following exceptions:

• All methods

  You do not specify the operating system or platform for host objects.

• From template

  The Host object templates are different than those for Firewall objects. Browse through the list in Firewall Builder to see what's available.

• Manually

  This method works the same as for the Firewall object, though the Add Interfaces page is slightly different. You cannot tag an interface as a "bridge port" interface. You can, however, indicate it is unnumbered or dynamic by selecting the appropriate checkbox. If neither checkbox is selected, then the interface is assumed to have a static IP address. As with the Firewall object wizard, you can only add IPv4 addresses in this way. If you need to use IPv6 addresses, create the host object without IP addresses and add them later.

• Via SNMP

  This method works the same as for a Firewall object. The Host object must have the same name as the actual device and the host must respond to SNMP.

6.1.7.2. Editing a Host Object

The Host object dialog allows you to edit the following parameters:

• Name:

  The Host object name.

• MAC matching:

  If this option is activated, the policy compiler uses the MAC addresses of all interfaces of this host in the firewall rules. Not all firewall platforms support MAC address filtering, so this option may have no effect on the generated firewall script. This is treated as a non-critical situation, and the policy compiler will only generate a warning while processing a firewall policy where such a host is used. You cannot enter the physical (MAC) address in this dialog, however. See Section 6.1.6.1.

• Comment:

  This is a free-form text field which can be used to add comments.

6.1.7.3. Using a Host Object in Rules

When a Host object is used in a rule, it acts as a group of all of the addresses that belong to all of its interfaces. The only exception is the loopback interface; the compiler skips that address when replacing the Host object with its addresses.

Consider the following Host object. It has interface eth0 with two IP addresses and a MAC address, interface he-ipv6 with an IPv6 address and a MAC address, interface lo (loopback) with its own IP address and interface sit0 (tunnel) with no address.

Let's put this host object in a rule as follows:

The rule set is configured as "IPv4 only", so even though interface he-ipv6 has IPv6 address, Firewall Builder will ignore it while generating iptables commands for this rule. Interface eth0 has two IPv4 addresses and both will be used. Here are iptables commands generated for this rule:

$IPTABLES -A FORWARD -p tcp -m tcp  --dport 22  -m state --state NEW \
-j Cid6066X5981.1 
$IPTABLES -A Cid6066X5981.1  -d 10.3.14.44  -j ACCEPT 
$IPTABLES -A Cid6066X5981.1  -d 10.3.14.55  -j ACCEPT 
$IPTABLES -A Cid6066X5981.1  -d  -j ACCEPT 
      

Let's see what we get for the same rule if we configure rule set object as "IPv4+IPv6":

Since the rule is now configured to compile for both address families, Firewall Builder processes it twice, once for each address family. Here is what we get (these are relevant fragments of the generated script):

# ================ IPv4

$IPTABLES -A FORWARD -p tcp -m tcp  --dport 22  -m state --state NEW  \
-j Cid6066X5981.1 
$IPTABLES -A Cid6066X5981.1  -d 10.3.14.44  -j ACCEPT 
$IPTABLES -A Cid6066X5981.1  -d 10.3.14.55  -j ACCEPT 
$IPTABLES -A Cid6066X5981.1  -d  -j ACCEPT 

# ================ IPv6

$IP6TABLES -A FORWARD -p tcp -m tcp  --dport 22  -m state --state NEW  \
-j Cid6066X5981.1 
$IP6TABLES -A Cid6066X5981.1  -d fe80::a3:e2c  -j ACCEPT 
     

6.1.7.4. Using Objects With Multiple Addresses in the Policy and NAT rules

Host and Firewall objects have child Interface objects, which in turn have child Address and Physical Address objects. In fact, an interface object can have more than one associated address object. Let's see how this works:

Consider example Figure 6-40, Figure 6-41. Here interface eth0 of "test server" has three IP addresses (named "test server:eth0:0" through "test server:eth0:2") and interface eth0 of "dmz host" has only one IP address: "dmz host:eth0". Policy rule #9 says that "dmz host" can talk to "test server" using any protocol. Since "test server" has three different addresses, we need to generate policy a rule that will match any of them. (Obviously we cannot match all three at once, so the compiler uses a logical "OR", not a logical "AND" here.) Basically, rule #9 is equivalent to three separate rules, each of them using one address of "test server" in turn. These three rules are represented in Figure 6-42 (original rule #9 also shown there, but it is disabled.)

Firewall Builder takes care of this situation automatically and generates the firewall policy described in Figure 6-41 as if a user had built a policy in the GUI using the three rules as shown in Figure 6-42.

In fact, the algorithm used is even more general. In the example Figure 6-41, host "test server" has a single interface with multiple addresses that the compiler used to generate the target firewall code. The policy compiler works in a similar way even if the host or firewall object used in the rule has multiple interfaces and each interface, in turn, has multiple addresses. If a host (or firewall) object is used in the rule, then the compiler scans all its interfaces, finds all corresponding addresses, and uses them to generate the firewall configuration. If an interface object is used in the rule, then the compiler uses all its addresses. And finally, if an Address or Physical Address object is used in the rule, then the compiler uses only this parameter to generate the firewall configuration. In other words, the compiler always traverses the tree, starting from the object found in the policy rule, and uses the parameters of all Address and Physical Address objects it finds. Since Address and Physical Address objects are the leaf nodes in the tree and have no other objects beneath them, the compiler uses the parameters of these objects to generate the target code.

6.1.12.1. Broadcast and Multicast Addresses, iptables Firewall

One important special case is 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 "255.255.255.255" to describe a broadcast. Address Range with addresses "224.0.0.5 - 224.0.0.6" would work well to describe two multicast groups used by OSPF. A Network object with address "224.0.0.0" and netmask "240.0.0.0" can be used to describe a whole multicast address block.

Here are few examples:

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:

For iptables, this rule translates into the following script:

$IPTABLES -A INPUT  -d 224.0.0.0/4  -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. Interface "inside" of the test firewall has address 172.16.22.1 with netmask 255.255.255.0. This defines subnet 172.16.22.0/255.255.255.0 with broadcast address 172.16.22.255. We create an Address object with the name "net-172.16.22 broadcast" and address "172.16.22.255" and use it in the destination field of a policy rule. Another rule in the same example will match broadcast address "255.255.255.255"; an Address Range Object that defines this address is present in the Standard Objects library under the name "broadcast". Here are the rules:

these two rules translate into the following script for iptables:

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

Both rules went into INPUT chain as expected.

6.1.12.2. 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":

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

This produces the following iptables commands:

$IPTABLES -A FORWARD  -d 172.16.22.255  -m state --state NEW  -j ACCEPT 
$IPTABLES -A INPUT  -d 172.16.22.255  -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.