During the engine installation, you map the network interfaces on the engine to the Physical Interface definitions created in the Management Client. See the Appliance Installation Guide delivered with the appliance for more information.
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 6: Install a Firewall Policy
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. 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.
Using a Firewall Cluster
The main points of Firewall Cluster configuration are explained in the preceding sections of this chapter. This section illustrates some additional concepts for working with Firewall Clusters:
•Internal DHCP Server (page 57)
•Node State Synchronization (page 57)
•Security Level for State Synchronization (page 58)
•Manual Load Balancing (page 58)
Internal DHCP Server
Firewall clusters contain an internal DHCP server that can be used to assign IPv4 addresses to hosts in the protected network. This is meant for small installations where it may be more practical to assign the IP addresses using the firewall rather than relay the DHCP requests from a separately maintained local DHCP server or from some other site’s DHCP server through a VPN.
Node State Synchronization
State synchronization is essential for the following features:
•Dynamic load balancing.
•Transparent switchover of nodes in case of failure or maintenance.
Caution – Do not modify the firewall’s Advanced Settings without due consideration. An invalid configuration of the parameters may lead to system instability or malfunction.
Regular, timer-launched synchronization events are needed to synchronize state data and to avoid cutting connections in case of node failure. Timed synchronization events are divided into full and incremental sync messages (see Table 6.3 for details).
By default, a combination of full and incremental sync messages is exchanged between nodes.
This way, frequent updates on incremental changes and recurrent reports on existing connections are combined.
In cases where synchronization of connection information between nodes is causing a
disturbance to specific traffic, you can optionally disable synchronization for the traffic using rule options in the Policy. Disabling synchronization reduces the traffic volume on the active
heartbeat interface, but it also prevents transparent failover of connections to other nodes.
Security Level for State Synchronization
Because synchronization controls the inter-node traffic within a heartbeat network, you must ensure the security of the heartbeat and synchronization data. The inter-node traffic can be authenticated, or both authenticated and encrypted. Inter-node traffic can also optionally be sent without authentication or encryption. However, this makes it possible to both sniff synchronization data and send fraudulent messages to open connections.
Manual Load Balancing
The Firewall Cluster’s load balancing filter can be manually modified if there is a specific need for modifications. Any modified load balancing parameters are combined with the automatically created filtering entries. However, modifying the load balancing parameters of the Firewall Cluster without careful consideration can cause conflicts in filtering decisions.
Table 6.3 Sync Messages
Type Explanation
Full Sync Messages
Contain all connection data about the traffic handled by a node at the time when the message was sent. When new data is received, it replaces the existing data. Full sync requires more bandwidth and processing time.
Incremental Sync Messages
Contain only data on connections that were created or changed since the last full or incremental sync message. Incremental sync needs less bandwidth and processing time. Since the incremental changes are sent only once, the system may lose connections if the data is lost. While able to produce accurate data with frequent updates, incremental sync requires full sync to provide reliable synchronization data.
Note – Independent of the security level, all critical information such as passwords and encryption keys are protected. They are never sent in plaintext.
Examples of Firewall Cluster Deployment
The examples in this section illustrate the configuration of a Firewall Cluster with general steps on how each scenario is configured.
Setting up a Firewall Cluster
The administrators at the headquarters of Company A want to set up a Firewall Cluster. The cluster consists of two cluster nodes: Node 1 and Node 2. The HQ Cluster Firewall has a dedicated heartbeat network (10.42.1.0/24), and it is connected to two internal networks:
Headquarters Intranet (172.16.1.0/24) and Management Network (192.168.10.0/24). It uses Multi-Link to ISP A and ISP B for its connection to the Internet.
Illustration 6.3 Headquarters Network
The administrators:
1. Create a Firewall Cluster element (HQ Cluster) and define HQ Log as its Log Server.
2. Define the physical interfaces 0-4.
3. Define the CVIs and NDIs for the physical interfaces. Except for the IP addresses, the node-specific properties for Node 1 and Node 2 are the same. See Table 6.4.
Headquarters
4. Save the initial configuration of the engines in the Management Client.
5. Map the interface identifiers in the configuration to the physical interfaces on each engine’s command line and establish contact between each engine and the Management Server.
6. Install a Firewall Policy on the Firewall Cluster in the Management Client to transfer the working configuration to the firewall engines. The nodes exchange authentication information and begin to work as a cluster.
Adding a Node to a Firewall Cluster
Company A’s Firewall currently consists of two nodes. However, the load on the Firewall is exceptionally high, so the administrator has decided to add another node to ensure continuity of network services even when one of the nodes is offline. The administrator does the following:
1. Adds a third node in the Firewall Cluster element’s properties.
2. Defines the node-specific IP addresses for the NDI interfaces of the new node.
•The cluster-level interface configuration does not need adjustments, since it is shared by all nodes.
3. Installs the new engine and performs the initial configuration.
4. Refreshes the security policy of the Firewall Cluster.
Table 6.4 Cluster Interfaces
Interface ID Type IP Address Comment
0 NDI for Node1 10.42.1.1 Heartbeat
0 NDI for Node2 10.42.1.2 Heartbeat
1 CVI 129.40.1.254 ISP B
1 NDI for Node1 129.40.1.21 ISP B
1 NDI for Node2 129.40.1.22 ISP B
2 CVI 212.20.1.254 ISP A
2 NDI for Node1 212.20.1.21 ISP A
2 NDI for Node2 212.20.1.22 ISP A
3 CVI 192.168.10.1 Management Network
3 NDI for Node1 192.168.10.21 Management Network
3 NDI for Node2 192.168.10.22 Management Network
4 CVI 172.16.1.1 Headquarters Intranet
4 NDI for Node1 172.16.1.21 Headquarters Intranet
4 NDI for Node2 172.16.1.22 Headquarters Intranet
C HA PT E R 7
R OUTING AND A NTISPOOFING
Routing is the process of defining through which network interface StoneGate forwards traffic from a source address to a destination address. Antispoofing is the process of defining which addresses are considered valid source addresses for the network(s) connected to each interface.
The following sections are included:
Overview to Routing and Antispoofing (page 62)
Configuration of Routing and Antispoofing (page 62)
Using Routing and Antispoofing (page 65)
Examples of Routing (page 66)
Overview to Routing and Antispoofing
In addition to examining packets, a firewall has to determine how to route packets. For the most part, StoneGate automates the routing and antispoofing configuration. Much of the
configuration is generated automatically based on the IP addresses of the network interfaces.
Configuration of Routing and Antispoofing
The routing and antispoofing information is displayed and configured graphically in interface-based trees in the Routing view and Antispoofing view. The routing information is stored on the Management Server. The information is transferred to the firewalls when the firewall policies are installed or refreshed.
In addition to the routing information that is automatically generated based on the interface definitions, you must manually add any networks that are not directly connected to the firewall to the routing tree. Similarly, you must also add a default route for packets whose destination IP address is not included anywhere else in the routing tree.
IP address spoofing is an attack where the source IP address in a packet is modified to gain unauthorized access or to cause a denial-of-service (DoS). Such attacks can be prevented with antispoofing rules. The antispoofing configuration is generated automatically based on the routing tree. Antispoofing is always enforced on all interfaces. You can change the antispoofing configuration, but in most environments, there is no need to do so.
Reading the Routing and Antispoofing Trees
The Routing view automatically displays the interfaces and a Network element for each network that is directly connected to the firewall. The Network is created based on the IP address(es) that you define for each interface. Interfaces that belong to an aggregated link always share the same routing information. Only the first interface that belongs to the aggregated link is
displayed in the Routing and Antispoofing views.
When the firewall reads routing definitions, it selects the most specific route and antispoofing definition it finds for each packet. The firewall first checks if there is a route defined for the specific destination IP address of the packet (a Host element), then checks routes to the defined networks (a Network element), and finally uses the default route (the Any Network element) if none of the other routes match the packet’s destination address. If there are overlapping definitions, the more specific one is considered first.
Example Interface 1 has a Host element for 192.168.0.202 and Interface 2 has a Network element for 192.168.0.0/24, a packet to 192.168.0.202 is routed through Interface 1, and the Interface 2 definition is not considered for those packets at all.
Illustration 7.1 Example: The More Specific Destination is Considered First in Routing
Interface 1 is always used for a destination of 192.168.0.202 because it has a Host element with the most specific address under it.
The Antispoofing view defines the source addresses of traffic that are considered valid (not spoofed) for each interface of a Single Firewall and Firewall Cluster element. If an interface receives a packet with a source address that is not a valid address for the network(s) connected to that interface, the packet is discarded. This is the case, for example, when an external interface receives a packet with an internal source. The firewall selects the most specific antispoofing definition it finds for each packet.
Example In the Antispoofing tree automatically generated based on the routing example above, antispoofing discards any traffic with the address 192.168.0.202 if it originates from Interface 2, because it has the less specific definition for that address (the Network 192.168.0.0/24).
Illustration 7.2 Only The Most Specific Destination is Considered Valid in Antispoofing
Packets from Example Host (192.168.0.202) are only considered valid if they originate from Interface 1, because it has the most specific route to the host’s address.
Example To allow the traffic to originate from both interfaces, you would also have to add the Host element for 192.168.0.202 under Interface 2, so that the definitions are equally specific (both interfaces contain the Host element) and therefore both definitions are valid at the same time.
Illustration 7.3 Both Interfaces are Considered Valid
Both Interface 1 and Interface 2 are considered valid routes to Example Host (192.168.0.202) because the Host element is included under both interfaces.
Multi-Link Routing for Single and Clustered Firewalls
Multi-Link uses multiple network links (NetLinks) to balance the load of outbound traffic and ensure high availability of Internet connectivity. With each new outbound connection, the system selects the fastest route for the connection from the available NetLinks. Multi-Link routing can be used for both IPv4 and IPv6 traffic. See Outbound Traffic Management (page 205) for more information on Multi-Link for outbound connections.
Illustration 7.4 NetLinks in Routing View
In the illustration above, a Multi-Link configuration is used to define a default route to the Internet (to “Any network”) through the ISP A and ISP B NetLinks.
Default Elements
Networks that correspond to the IP addresses of each interface are automatically added to the routing and antispoofing configurations of Firewall elements.
The system includes a default network element called Any network, which is needed to define the default route. The system also includes a Host element for Bootp/DHCP clients in the Antispoofing view for Firewall elements.
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.