FirewallBuilder

As in the previous examples, we start with member firewall objcts. The difference between this and previous examples is that now we need to configure VLAN interfaces. Let's start with firewall objects with interfaces eth0 and eth1. In fact, these objects are copies of the linux-test-1 and linux-test-2 objects used in Section 14.4.3. New objects have names linux-test-3 and linux-test-4. I am going to add VLAN interfaces and rearrange IP address objects to match the network diagram Figure 14.159

Figure 14.160. Member Firewall Objects without VLAN Interfaces

First, we need to add VLAN subinterface to eth1. To do this, select eth1 in the tree, right-click, and select "New interface" from the context menu to add the interface object:

Table 14.3. 

Figure 14.161. Using the Context Menu to Add a Subinterface

Figure 14.162. Subinterface Created with a Default Name

The new interface object is created with the default name "Interface". Double-click it to open it in the editor and rename it to eth1.101:

Figure 14.163. VLAN Subinterface in the Editor

Click the "Advanced interface settings" button to verify its VLAN configuration:

Figure 14.164. VLAN Configuration of the Subinterface

Note that interface type has been set to VLAN automatically. This is because Firewall Builder analyses the name of the subinterface and automatically chooses the correct type in the "Advanced" settings dialog. If the interface name matches a standard VLAN interface name for the chosen host OS, then it automatically is recognized as a VLAN subinterface and the program extracts VLAN ID from its name. For example, supported VLAN interface names on Linux are "eth1.101", "eth1.0101", "vlan101", "vlan0101". On other OSs, naming conventions are often different.

Create Subinterface eth1.102 Using the Same Method.

Now you can move IP address objects from the interface eth1 to subinterface eth1.101. Use the context menu items Cut and Paste to do this. While doing this, I also removed the IPv6 addresses that are not used in this example. You should arrive at the following configuration:

Figure 14.165. IP Addresses Reassigned to the Subinterface

We also need to configure IP address for the second VLAN interface eth1.102 using context menu item "New address".

Finally, we have the firewall object linux-test-3 configured according to the network diagram Figure 14.159:

Figure 14.166. Adding IP Addresses to VLAN Subinterface

This is not quite all yet though. Interface eth1 is now a parent of two VLAN subinterfaces eth1.101 and eth1.102. In this configuration, eth1 does not have an IP address of its own. To reflect this, open it in the editor and check "Unnumbered" interface button as shown below:

Figure 14.167. Interface eth1 Is Unnumbered

We need to configure the second firewall object linux-test-4 as well. You can repeat the process you just used to add subinterfaces and addresses like it was done for linux-test-3, or instead of doing this from scratch, you can copy and paste interface objects eth1.101 and eth1.102 from linux-test-3 to interface eth1 of linux-test-4 and then just edit addresses. Here is the final configuration of both member firewalls:

Figure 14.168. VLAN Subinterface and Addresses of Both Member Firewalls

Now that both member firewall objects are ready, we can create an object for the cluster. Use the "New Object" menu, and select the "Cluster" option to launch the wizard. On the first page of the wizard, choose linux-test-3 and linux-test-4 firewalls and enter the name for the cluster object:

Figure 14.169. Creating the Cluster Object

On the next page of the wizard, you can build cluster interfaces. The program finds interfaces of the member firewalls with the same name and preconfigures cluster interface objects. On this page of the wizard, you can add or delete cluster interfaces and establuish correspondence between them and interfaces of the member firewalls. The screenshot Figure 14.170 shows this page:

Figure 14.170. Interfaces of the Cluster

Moving on, on the next page of the wizard we configure IP addresses of the cluster interfaces accroding to our network diagram Figure 14.159:

Figure 14.171. IP Addresses of the Cluster Interfacess

The next page of the wizard offers an opportunity to use policy and nat rules of one of the member firewalls for the cluster. However since our member firewalls have no rules, we do not need to use this feature and can just finish creating new cluster object. New cluster object is shown on Figure 14.172:

Figure 14.172. Cluster Object Configuration

Firewall Builder can generate a shell script to configure VLAN interfaces for both member firewalls. The script is in fact a shell function inside the common firewall configuration script Firewall Builder creates for each firewall. To activate this feature, open each member firewall object in the editor by double clicking it in the tree and click "Firewall Settings" button, then navigate to the "Script" tab of the dialog. Screenshot Figure 14.173 shows this tab. Turn checkbox "Configure VLAN interfaces" on:

Figure 14.173. Turn VLAN Configuration On

If you compile the policy for the cluster (or a standalone firewall) with the "Configure VLAN interfaces" checkbox turned on, the generated script includes the following fragment that is executed before iptables rules are loaded:

configure_interfaces() {
    :
    # Configure interfaces
    update_vlans_of_interface "eth1 eth1.101 eth1.102"
    clear_vlans_except_known eth1.101@eth1 eth1.102@eth1
    update_addresses_of_interface "lo 127.0.0.1/8" ""
    update_addresses_of_interface "eth0 10.3.14.108/24" "10.3.14.150/24"
    update_addresses_of_interface "eth1" ""
    update_addresses_of_interface "eth1.101 10.1.1.1/24" "10.1.1.254/24"
    update_addresses_of_interface "eth1.102 10.1.2.1/24" "10.1.2.254/24"
}
        

Lines highlighted in red configure VLAN interfaces. The first command, a call to the update_vlans_of_interface shell function, checks if vlan interfaces eth1.101 and eth1.102 already exist and adds them if they are not there. It uses vconfig utility to do this. If VLAN interfaces with these names already exist, the function does nothing. This allows for incremental management of the VLAN interfaces, that is, when the script runs again, it does not try to add interfaces that already exist. It does not remove and add them back, either.

To test this feature, you can run the generated script with the command-line parameter "test_interfaces". This makes the script analyse interfaces and print commands that it would normally execute to configure them, but it does not actually execute these commands but only prints them. To illustrate this, I start with machine linux-test-4 in the state where it has no VLAN interfaces and some IP addresses do not match configuration defined in fwbuilder. Running the script with "test_interfaces" command line parameter demonstrates what it is going to do to bring configuration of the machine in sync with setup configured in fwbuilder:

root@linux-test-4:~# ip addr ls
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether 00:0c:29:fc:67:8c brd ff:ff:ff:ff:ff:ff
    inet 10.3.14.109/24 brd 10.3.14.255 scope global eth0
    inet6 fe80::20c:29ff:fefc:678c/64 scope link 
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether 00:0c:29:fc:67:96 brd ff:ff:ff:ff:ff:ff
    inet 10.1.1.2/24 brd 10.1.1.255 scope global eth1
    inet6 fe80::20c:29ff:fefc:6796/64 scope link 
       valid_lft forever preferred_lft forever

root@linux-test-4:~# /etc/fw/linux-test-4.fw test_interfaces
# Adding VLAN interface eth1.101 (parent: eth1)
vconfig set_name_type DEV_PLUS_VID_NO_PAD
vconfig add eth1 101
ifconfig eth1.101 up
# Adding VLAN interface eth1.102 (parent: eth1)
vconfig set_name_type DEV_PLUS_VID_NO_PAD
vconfig add eth1 102
ifconfig eth1.102 up
# Removing ip address: eth1 10.1.1.2/24
ip addr del 10.1.1.2/24 dev eth1
ifconfig eth1 up
# Interface eth1.101 does not exist
# Adding ip address: eth1.101 10.1.1.2/24
ip addr add 10.1.1.2/24 dev eth1.101
ifconfig eth1.101 up
# Interface eth1.102 does not exist
# Adding ip address: eth1.102 10.1.2.2/24
ip addr add 10.1.2.2/24 dev eth1.102
ifconfig eth1.102 up
      

Commands that manage VLAN interfaces are highlighted in red. The script adds VLAN interfaces eth1.101 and eth1.102 to eth1 and brings them up, then removes IP address 10.1.1.2 from eth1 and adds addresses 10.1.1.2 to eth1.101 and 10.1.2.2 to eth1.102.

To set interfaces up and load iptables rules, just run the script with command line parameter "start". If you only want to try to configure interfaces but not load iptables rules just yet, run the script with command-line parameter "inetrfaces". Here is what happens:

root@linux-test-2:~# /etc/fw/linux-test-4.fw interfaces
# Adding VLAN interface eth1.101 (parent: eth1)
Set name-type for VLAN subsystem. Should be visible in /proc/net/vlan/config
Added VLAN with VID == 101 to IF -:eth1:-
# Adding VLAN interface eth1.102 (parent: eth1)
Set name-type for VLAN subsystem. Should be visible in /proc/net/vlan/config
Added VLAN with VID == 102 to IF -:eth1:-
# Removing ip address: eth1 10.1.1.2/24
# Adding ip address: eth1.101 10.1.1.2/24
# Adding ip address: eth1.102 10.1.2.2/24
      

We can now verify that the script added VLAN inetrfaces and configured IP addresses:

root@linux-test-2:~# ip addr ls
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether 00:0c:29:fc:67:8c brd ff:ff:ff:ff:ff:ff
    inet 10.3.14.109/24 brd 10.3.14.255 scope global eth0
    inet6 fe80::20c:29ff:fefc:678c/64 scope link 
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether 00:0c:29:fc:67:96 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::20c:29ff:fefc:6796/64 scope link 
       valid_lft forever preferred_lft forever
4: eth1.101@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 00:0c:29:fc:67:96 brd ff:ff:ff:ff:ff:ff
    inet 10.1.1.2/24 scope global eth1.101
    inet6 fe80::20c:29ff:fefc:6796/64 scope link 
       valid_lft forever preferred_lft forever
5: eth1.102@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 00:0c:29:fc:67:96 brd ff:ff:ff:ff:ff:ff
    inet 10.1.2.2/24 scope global eth1.102
    inet6 fe80::20c:29ff:fefc:6796/64 scope link 
       valid_lft forever preferred_lft forever
      

Now that vlan interfaces are there and IP addresses are correct, lets see what happens if we run the script again:

root@linux-test-2:~# /etc/fw/linux-test-4.fw test_interfaces
root@linux-test-2:~# 
      

The script verified configuration and has found that it does not need to change anything.

Heartbeat configuration in this setup is rather straightforward and is not very different from the one we used in the previous recipe Section 14.4.3.

# cat ha.cf:

mcast eth0 225.0.0.1 694 1 0
mcast eth1.101 225.0.0.1 694 1 0
mcast eth1.102 225.0.0.1 694 1 0
auto_failback on
node linux-test-1
node linux-test-2


# cat haresources 

linux-test-1 IPaddr::10.3.14.150/24/eth0/10.3.14.255
linux-test-1 IPaddr::10.1.1.254/24/eth1.101/10.1.1.255 
linux-test-1 IPaddr::10.1.2.254/24/eth1.102/10.1.2.255 


# cat authkeys 

auth 3
3 md5 hb-auth-key
        

The difference between heartbeat configuration in Section 14.4.3 and this is that we now run it over three interfaces, using VLAN interfaces eth1.101 and eth1.102 instead of eth1. Otherwise it works exacly the same and manages virtual addresses 10.3.14.150, 10.1.1.254 and 10.1.2.254 on corresponding subnets.

Policy and NAT rule configuration in this setup is also the same as in Section 14.4.3 and we won't repeat it here.