If you do not include a policy in the initial configuration, only the primary control interface with the Management Server is configured after the engine establishes contact with the
Management Server. You must install a Firewall Policy using the Management Client to transfer the complete configuration to the firewall. After this is done, the firewall is ready to start processing traffic.
Example of a Single Firewall Deployment
The examples in this section illustrate common deployment scenarios for a Single Firewall and general overviews to the steps on how each scenario is configured.
Setting up a Single Firewall
Company A has just opened a new branch office. The administrator at the branch office is setting up a Single Firewall in the branch office network.
Illustration 5.1 shows the network at the branch office.
Illustration 5.1 Branch Office Network
The Branch Office Firewall has two interfaces with internal and external routers:
•The internal router is connected to Interface ID 0.
•The external router is connected to Interface ID 1.
StoneGate Management Center has already been installed at the remote site, and the branch office administrator is now ready to install and configure the Single Firewall. The administrator:
1. Creates a Single Firewall element (Branch Office Firewall) and defines the Log Server at the remote site as its Log Server.
2. Creates an interface for connecting to the internal router and gives it the following properties:
•Interface ID: 0.
•IP Address: 172.16.2.1.
3. Creates an interface for connecting to the external router and gives it the following properties:
•Interface ID: 1.
•IP Address: 212.20.2.254.
4. Saves the initial configuration of the Branch Office Firewall on a USB stick.
5. Installs the firewall engine in the server room.
6. Inserts the USB stick in the firewall, turns it on, and waits until the Management Client shows that contact is established between the engine and the Management Server.
7. Checks the routing configuration and adds the first few rules for allowing traffic through the firewall.
8. Installs a Firewall Policy using the Management Client to transfer the first working
Internet Intranet
Adding a New Interface to an Existing Configuration
In the previous example, the administrator initially configured the firewall at the company’s new branch office with just two interfaces. Now the administrator decides to add a physically separated DMZ network for access to/from that office’s mail server to properly control both internal and external traffic with this publicly exposed server. The administrator:
1. Creates an interface for the DMZ and gives it the following properties:
•Interface ID: 2.
•IP Address: 192.168.2.1.
2. Creates new rules in the firewall’s policy to allow traffic to/from the DMZ and NAT rules to translate between the private and public IP address of the mail server.
3. Connects the new DMZ router to the firewall.
4. Installs a Firewall Policy using the Management Client to transfer the new working configuration to the Firewall.
C HA PT E R 6
F IREWALL C LUSTER C ONFIGURATION
A Firewall Cluster is a group of firewall nodes that work as a single logical entity to share the load of traffic processing and provide redundancy, ensuring the availability of network services to the users.
The following sections are included:
Overview to Firewall Cluster Configuration (page 50)
Configuration of Firewall Clusters (page 51)
Using a Firewall Cluster (page 57)
Examples of Firewall Cluster Deployment (page 59)
Overview to Firewall Cluster Configuration
A StoneGate Firewall Cluster consists of 2 to 16 nodes that function as a single entity.
Clustering is a standard feature that you can activate on any StoneGate Firewall/VPN installation if you have two or more licensed engines.
You can also configure Multi-Link on the Firewall Cluster to provide high-availability for inbound and outbound connections. See Outbound Traffic Management (page 205) and Inbound Traffic Management (page 213) for more information. StoneGate UTM adds anti-virus scanning and anti-spam filtering to the standard Firewall/VPN cluster feature set. See Virus Scanning (page 151) and Spam Filtering for more information.
This chapter concentrates on the configuration of network interfaces, IP addresses, and clustering, which are the only parts of the basic configuration where there are major differences between a Single Firewall and a Firewall Cluster. The section Using a Firewall Cluster (page 57) describes other configuration tasks that you may do in the Firewall Cluster element properties.
Other features, including routing and antispoofing, are explained together for both types of installations in separate feature-specific chapters.
Benefits of Clustering
A Single Firewall can be a single point of failure. This can affect the availability of business critical applications and complicate the maintenance of the firewall equipment. Clustering firewall nodes can significantly reduce the risk of these problems.
The StoneGate Firewall/VPN solution uses built-in clustering technology. No additional software or hardware is needed to cluster several nodes. If a node itself or the surrounding network equipment malfunctions, the other nodes in the cluster take over the traffic processing, minimizing any disruptions to the traffic flow. Similarly, maintenance is easier with a cluster, because individual nodes can be taken offline and even exchanged for new hardware without causing service outages.
Firewall Clusters also balance the load of traffic processing between the firewall nodes. You can flexibly add nodes to scale up the Firewall Cluster, improving the throughput and performance.
Communication Between the Nodes
The Firewall Cluster nodes exchange information constantly. The state tables that list open connections (state sync) and the operating state of the other nodes (heartbeat) are exchanged.
This exchange of information ensures that all nodes have the same information about the connections and that if a firewall node becomes unavailable, the other nodes of the cluster immediately notice this. The exchange of information between clustered StoneGate nodes is synchronized through selected interfaces via a heartbeat network using multicast
transmissions. The heartbeat messages are authenticated, and can also be encrypted if necessary (authentication is enabled by default).
Hardware
The hardware the cluster nodes run on does not need to be identical. Different types of equipment can be used as long as all nodes have enough network interfaces for your configuration.
If equipment with different performance characteristics is clustered together, the load-balancing technology automatically distributes the load so that lower performance nodes handle less traffic than the higher performance nodes. However, when a node goes offline, the remaining node(s) must be able to handle all traffic on their own to ensure high availability. For this reason, it is usually best to cluster nodes with similar performance characteristics.
Configuration of Firewall Clusters
StoneGate firewalls are configured and managed centrally through the Management Server. The Firewall Cluster element represents the Firewall Cluster’s configuration on the Management Server. The main configuration options in the Firewall Cluster element include the settings related to network interfaces and clustering. This chapter concentrates on those settings.
Load Balancing
In a Firewall Cluster configuration, the recommended way to cluster the nodes is load-balanced clustering, where traffic is balanced between the nodes dynamically. Load-balanced clustering provides both fault tolerance and performance benefits.
The traffic arriving at the Firewall Cluster is balanced across the nodes according to the settings of the cluster’s load balancing filter. This filtering process distributes packets between the firewall nodes and keeps track of packet distribution. The Firewall determines the packet ownership of the nodes by comparing the incoming packet with node-specific values based on the packet headers. The load-balancing filter is pre-configured for optimal performance and is not meant to be adjusted independently by the system administrators.
The Firewall Cluster keeps track of which node is handling each ongoing connection. As a result, all packets that are part of a given connection can be handled by the same node. Some protocols use multiple connections, which are sometimes handled by different nodes, but this does not usually affect the processing of the traffic.
Standby Operation
In standby clustering, only one node at a time processes traffic, and other nodes wait on standby, ready to take over when the currently active node goes offline. Nodes that should not take over automatically can be set offline as usual. The drawback with standby mode is that there is no performance gain in clustering the firewalls.
Network Interfaces and IP Addresses
To work as replacements for each other, cluster members must have near-identical network interface configurations. A Physical Interface definition in the Management Client always represents a network interface definition on each node of the cluster. The table below explains the two types of IP addresses that you can add to a Physical Interface definition. You can add several IP addresses of each type to a single Physical Interface.
Illustration 6.1 Cluster Interfaces
The illustration above shows how CVIs and NDIs are used on a Firewall Cluster. In this example, the Interface ID 0 on each node has an NDI that is used for heartbeat traffic between the nodes in a dedicated network. There is no CVI on Interface ID 0, since it handles only node-to-node traffic. Interface ID 1 has a CVI that is used for Internet traffic (for example, Web browsing), and it also has an NDI for traffic that the nodes send toward the Internet (for example, automatic tests the firewall uses to check connectivity). Interface ID 2 has a CVI for protected network traffic and an NDI for management connections to and from the nodes.
Table 6.1 Firewall Cluster IP Address Types
IP Address Type Description
Cluster Virtual IP Address (CVI)
A CVI handles the traffic directed to the Firewall Cluster for inspection. The CVI is shared by all the nodes in the cluster. It depends on the selected clustering mode how this shared IP address is used. The CVI gives the cluster a single identity on the network, reducing the complexity of routing and network design.
Node Dedicated IP Address (NDI)
An NDI handles all communication for which the end-point is the node itself, including node-to-node, Management Server to node, and node-initiated connections. Each node in the cluster has its own dedicated IP address that is used as the NDI. In most cases, you must define an NDI for each physical interface. If necessary, you can define more than one NDIs for the same physical interface.
Node 1
Clustering Modes
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.
All CVIs on the same physical interface must use the same mode. It is possible to set different cluster modes for CVIs that are defined for different physical interfaces.
As Packet Dispatch mode is the recommended clustering mode, this section explains only the Packet Dispatch mode in more detail. For more information on the other clustering modes, see Multicasting (page 329).
How Packet Dispatch Works
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. The illustration below shows an example of how packet dispatch handles a connection.
Table 6.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. All the nodes in the cluster see all the packets.
Multicast MAC
The nodes share the same multicast MAC address for the CVI. 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 network interface cards 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.
Illustration 6.2 Packet Dispatch CVI Mode
1. The dispatcher node for CVI 1 receives a new packet.
2. The dispatcher node either handles the packet itself or dispatches the packet to one of the other firewall nodes for processing according to the load-balancing filter. The packet is sent to the other node through the interface the packet arrived from.
3. The dispatcher node for CVI 2 forwards the replies within the open connection to the same node.
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.
The network switch must 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.
1
2 3
Configuration Workflow
The following sections provide an overview of the configuration tasks. Detailed step-by-step instructions can be found in the Online Help of the Management Client and the Administrator’s Guide PDF.