There are several modes for how traffic can be directed to the cluster. The modes are explained in the table below. If necessary, refer to the documentation for the router, hub, or switch you are using for information on which mode is best in your
environment.
As Packet Dispatch mode is the recommended clustering mode in most cases, this section explains only the Packet Dispatch mode in more detail. For more information on the other clustering modes, see Multicasting, on page 361. It is also possible to set different cluster modes for different CVIs if they are defined for different physical interfaces.
TABLE 8.2 Clustering Modes
Mode Description
Packet Dispatch
This is the recommended clustering mode.One node per physical interface is the dispatcher that handles the distribution of traffic between the different nodes for all CVIs on that physical interface. The assigned node handles the traffic processing. No additional switch configuration is needed.
This mode can also be used with hubs but it is not the optimal clustering mode with hubs.
Unicast MAC
This is the recommended mode when hubs are used. This mode cannot be used with most switches.
All the nodes in the cluster share the same unicast MAC address for the CVI interface. All the nodes in the cluster see all the packets.
Multicast MAC
The nodes share the same multicast MAC address for the CVI interface.
All the nodes in the cluster see all the packets.
Do not use this mode instead of the packet dispatch mode except in special cases (for example, if the nodes have uncertified NICs whose MAC address cannot be changed).
Multicast MAC with IGMP
The clustering works otherwise the same as in the Multicast MAC mode except that the engine answers to IGMP membership queries.
This mode allows limiting multicast flooding when the switch does not support static MAC address forwarding tables.
Configuration of Firewall Clusters 75 In Packet Dispatch mode, the node selected as the dispatcher on the physical interface assigns the packets to one of the nodes (to itself or to some other node).
The assigned node then handles the actual resource-intensive traffic processing. The dispatcher attempts to balance the nodes’ loads evenly, but assigns all packets that belong to the same connection to the same node. The node that acts as the packet dispatcher can be (and often is) different for CVIs on different physical interfaces.
Illustration 8.2 shows an example of how packet dispatch handles a connection.
Illustration 8.2 Packet Dispatch CVI Mode
The dispatcher node for CVI 1 receives a new packet (1). It either handles the packet itself or dispatches the packet to one of the other firewall nodes for processing according to the load-balancing filter (2). The dispatcher node for CVI 2 forwards the replies within the open connection to the same node (3).
One node is responsible for handling each connection. The node responsible for the connection handles all resource-consuming tasks: it determines if the connection is allowed to continue, translates addresses as necessary, and logs the connection.
The dispatcher node controls the CVI’s IP address and MAC address. The other nodes use their own physical interface’s MAC address for the same CVI. When the dispatcher node goes offline, one of the other nodes becomes the dispatcher node. The new dispatcher node changes its interface’s MAC address to the address defined for the Packet Dispatch CVI.
1.
3. 2.
76 Chapter 8: Firewall Cluster Configuration
Note – Because of the limitation of only one unicast MAC address per physical interface, all the NDIs defined on the same physical interface as a Packet Dispatch CVI use the same unicast MAC address as the CVI is using on each node.
The network switch has to update its address table without significant delay when the packet dispatcher MAC address is moved to another firewall node. This is a standard network addressing operation where the switch learns that the MAC address is located behind a different switch port. Then, the switch forwards traffic destined to the CVI address to this new packet dispatcher.
Configuration Workflow
The following sections provide an overview of the configuration tasks related to configuring and customizing Firewall Clusters. Detailed step-by-step instructions can be found in the Online Help of the Management Client and the Administrator’s Guide PDF, in the section called Elements.
Task 1: Create a Firewall Cluster Element
To introduce a new firewall cluster to the Management Center, you must define a Firewall Cluster element that stores the configuration information related to the firewall engines. As an alternative to creating a new Firewall Cluster element, you can also promote an existing Single Firewall element to a Firewall Cluster element.
Task 2: Create Physical Interfaces
Physical interfaces represent the actual network interface cards on the engines. In a cluster, each physical interface definition represents a network interface on all nodes of the cluster.
When you define a CVI for a physical interface, the CVI inherits the MAC address defined for the physical interface definition. Because of the limitation of only one unicast MAC address per physical interface, all the Packet Dispatch CVIs defined on the same physical interface use the same MAC address. The CVIs on different physical interfaces cannot have duplicate MAC addresses.
The numbering of the physical interface definitions is independent of the operating system level numbering of the actual physical interfaces on the engine. By default, the physical interface definitions are mapped to the actual physical interfaces on the engines one to one, but you can change the mapping freely using command line tools on the engine. This mapping can be done differently from node to node as long as you take care that the interface that represents the same network interface on each node is correctly cabled to the same network.
Configuration of Firewall Clusters 77
Task 2: Define VLAN Interfaces
A Virtual Local Area Network (VLAN) is a logical grouping of hosts and network devices that allows creating several separated networks on a single physical link. To allow this separation, StoneGate supports VLAN tagging as defined in the IEEE 802.1q
standard. One network interface can support up to 4094 VLANs.
VLANs can also make it easier to deploy geographically distributed Firewall Clusters (for example, a cluster whose nodes are located in different buildings), as fewer physical interfaces and less cabling is needed.
When you create a VLAN interface, the CVI mode and MAC address are defined commonly for all virtual interfaces configured for the same Physical interface definition. The defined VLAN interfaces are displayed, for example, as “5.202” for network interface 5 with VLAN 202. You must also configure the router at the other end of the link with matching VLAN settings.
Task 3: Configure Interfaces
You can define two types of interfaces: CVIs and NDIs. Both CVIs and NDIs are basically IP address definitions, but the two different types are required due to the special requirements of clustering. You can define as many CVIs and NDIs per physical interface as you need.
• CVIs are used for traffic directed to the Firewall Cluster for inspection and have one IP address shared by all nodes. They allow the surrounding network to see the cluster as a single entity.
• NDIs handle all traffic for which the end-point of the communication is a node itself and have a dedicated IP address for each node. They allow the communications to reach a particular node.
You must specify an IP address and MAC address for each CVI. The MAC/IP address pair of the CVI remains the same all the time as only the location of the MAC address changes to the current dispatcher node (packet dispatch). This makes the external network equipment forward traffic to the correct node for dispatching.
The NDIs are used for node-to-node communications, for traffic between each individual node and the Management Server and Log Server, as well as
communications with external components (such as authentication servers, or hosts that are probed in network connectivity tests).
When you define NDIs, you must define both node-specific properties (such as the node’s IP address) and properties that are shared by all the nodes in the cluster. All nodes must have the same netmask value for the IP address of their respective NDIs.
To ensure correct operation in all cases, we recommend you define an NDI IP address for all nodes on each physical interface. If there is a shortage of IP addresses, it is possible to leave some physical interface without an NDI. If a physical interface does not have an NDI IP address for a node, the node uses an IP address from one of the other NDIs (the default IP address for outgoing traffic) when initiating communications through that interface. Gratuitous ARP requests used for updating the MAC address/IP address relationship in the Packet Dispatch mode may be affected by this
78 Chapter 8: Firewall Cluster Configuration
configuration. The ‘borrowed’ IP address can be used without issues with routers that strictly follow the ARP standard as long as the IP address used is valid from the routing point of view. However, some routers may not reply the firewall’s gratuitous ARP requests in this case, and static ARP entries may be required in the firewall’s
configuration to allow communications.
Task 4: Install the Firewall Engines
Engines in a clustered configuration are installed in the same way as engines of a single firewall. The engines do not receive any clustering settings until the first time you install a policy on them and the working configuration is received from the Management Server.
During the engine installation, you map the physical interfaces to the physical interface definitions created in the Management Client. You can also install the engine automatically using a configuration saved on a USB memory stick. If you use the automatic engine configuration, Management Client physical interface definitions are automatically mapped to the actual physical interfaces in sequential order. For example, interface 0 is mapped to eth0, interface 1 is mapped to eth1, and so on. In this case, the first physical interface (eth0) is always used as the Management interface. For this reason, interface 0 must be defined as the Management interface in the Management Client when the automatic configuration is used.
During the installation, a basic initial configuration is activated and an initial contact between the Management Server and each engine is initiated. During the initial contact, each engine authenticates itself to the Management Server with its own single-use password. When this initial contact succeeds, the engine receives a certificate from the Management Center for authenticating all subsequent communications - a trust relationship between that engine and the Management Server is established.
Task 5: Install a Firewall Policy
After the firewall engines have made initial contact with the Management Server, only the primary control interface with the Management Server is configured. You must install a Firewall Policy using the Management Client to transfer the complete interface configuration to the firewall.
All nodes must have the same version of the operating configuration. For this reason, a policy installation requires that all cluster nodes defined in the Management Client are installed and reachable. Nodes that are temporarily unreachable (under
maintenance) must be disabled from the configuration to install a policy on the rest of the firewall engines.