5.2.10. Host Object

The host object in Firewall Builder is designed to represent real hosts in the network: workstations, servers, and any other network node with an address. Just like real hosts, host objects have interfaces that represent different physical connections to the network.

Most hosts have just a single (visible) interface with a single IP address. In that case the actual interface and its name do not matter. For most foreign hosts, Firewall Builder assigns an arbitrary name, like interface1, to the host's interface. However, by using the tree-like hierarchy of hosts -> interfaces -> addresses, it is possible to specify the exact address and/or interface of a host in cases where it does matter.

As in the Firewall object, interfaces and addresses are represented by objects that are organized in a tree. An interface can have multiple addresses. An example of a host with one interface and multiple addresses is shown in Figure 5.47. Host test server is located on the LAN and has three virtual IP addresses that all belong to the same interface, eth0.

Note that in Firewall Builder, the host object is an abstraction. It does not have to conform to an individual host. This host object may in fact represent a web farm that accepts connections on three IP addresses, each on a different computer.

Figure 5.47. A Host Object with One Interface and Multiple Virtual Addresses

A Host Object with One Interface and Multiple Virtual Addresses


The host object cannot have any access, NAT, or routing policy associated with it; only firewall objects can have policies. 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 Hosts and select it from there.

Section 5.2.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.


You can always add, modify, and remove interfaces of the new host object later using controls provided in the main window and object tree view. Editing a Host Object

Figure 5.48. Editing the Host Object

Editing the 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

  • Comment:

    This is a free-form text field which can be used to add comments. 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.

Figure 5.49. Host with multiple interfaces, Some with Multiple Addresses

Host with multiple interfaces, Some with Multiple Addresses

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

Figure 5.50. Host in a Rule

Host in a Rule

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  -j ACCEPT 
$IPTABLES -A Cid6066X5981.1  -d  -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":

Figure 5.51. Host in a Rule with both IPv4 and IPv6

Host in a Rule with both IPv4 and 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  -j ACCEPT 
$IPTABLES -A Cid6066X5981.1  -d  -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 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:

Figure 5.52. Host Object with an Interface with Multiple Addresses

Host Object with an Interface with Multiple Addresses

Figure 5.53. Using Objects with Multiple Addresses in Policy Rules

Using Objects with Multiple Addresses in Policy Rules

Consider example Figure 5.52, Figure 5.53. 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 5.54 (original rule #9 also shown there, but it is disabled.)

Figure 5.54. Equivalent Rules

Equivalent Rules

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

In fact, the algorithm used is even more general. In the example Figure 5.53, 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.


There is an exception to this algorithm, see Section


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