DESCRIPCIÓN DE ACTIVIDADES

During the engine installation, you map the network interfaces on the engine to the Physical Interface definitions created in the Management Client. The mapping of Tunnel Interfaces to physical network interfaces on the engine is done automatically by the engine operating system based on the routing configuration. 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 8: 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

•Node State Synchronization

•Security Level for State Synchronization (page 59)

•Manual Load Balancing (page 59)

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.

•Handling of related connections when a service (for example, FTP) opens multiple connections.

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).

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.

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.

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.

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

Intranet Management _Network

HQ Cluster Heartbeat Internet ID O ID O ID 1 ID 2 ID 4 ID 3 ID 1 ID 3 ID 4 ID 2

Internal Switch Internal Switch

ISP A Switch ISP B Switch Node 2 Node 1 HQ Log Server and Management Server ISP B ISP A

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.

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

CHA PT E R 7

MASTER ENGINE

AND VIRTUAL FIREWALL CONFIGURATION

A Virtual Security Engine is a logically-separate engine that runs as a virtual instance on a physical engine device. A Virtual Firewall is a Virtual Security Engine in the Firewall/VPN role. A

Master Engine is a physical engine device that provides resources for Virtual Security Engines. The following sections are included:

Overview to Master Engine and Virtual Firewall Configuration (page 64)

Configuration of Master Engines and Virtual Firewalls (page 64)

Using Master Engines and Virtual Firewalls (page 67)

Overview to Master Engine and Virtual Firewall

Configuration

This chapter focuses on Virtual Security Engines in the Firewall/VPN role. Virtual Security Engines in the Firewall/VPN role are configured using Virtual Firewall elements in the Management Client.

Using Virtual Firewalls allows the same physical engine device to support multiple policies or routing tables, or policies that involve overlapping IP addresses. This is especially useful in a Managed Security Service Provider (MSSP) environment, or in a network environment that requires strict isolation between networks.

Configuration of Master Engines and Virtual Firewalls

Any Security Engine that has a license that allows the creation of Virtual Resources can be used as a Master Engine.

Illustration 7.1 Master Engine and Virtual Firewall Architecture

One physical Master Engine can host multiple Virtual Firewalls. A Virtual Resource element defines the set of resources on the Master Engine that are allocated a Virtual Firewall. Virtual Resource elements associate Virtual Firewalls with Physical Interfaces or VLAN Interfaces on the Master Engine. The license for the Master Engine defines how many Virtual Resources can be created. The number of Virtual Resources limits the number of Virtual Firewalls: one Virtual Firewall at a time can be associated with each Virtual Resource.

Master Engines can have two types of interfaces: interfaces for the Master Engine’s own traffic, and interfaces that are used by the Virtual Firewalls hosted on the Master Engine. In the example above, the Master Engine has the following kinds of interfaces:

1. Physical Interface for hosted Virtual Firewall traffic. 2. VLAN Interfaces for hosted Virtual Firewall traffic. 3. Physical Interface for the Master Engine’s own traffic.

Master Engine

1 3

Virtual Firewall B Virtual Firewall A

Virtual Resource A Virtual Resource B

Configuration Workflow

The following sections provide an overview of the configuration tasks. Detailed step-by-step instructions can be found in the Management Client Online Help and the Stonesoft

Administrator’s Guide.