Print Download PDF Send Feedback



Maximizing Network Performance and Redundancy

In This Section:

Solutions for Enhancing Network Performance and Redundancy





VRRP Cluster

To Learn More About Maximizing Network Performance

Solutions for Enhancing Network Performance and Redundancy

These are features that you can enable to increase the performance of the Firewall:

These Gateway clustering solutions enable you to enhance network redundancy:

These are software based features that are included in the Check Point operating systems. It is not necessary to purchase additional hardware to use them.


In a Security Gateway with CoreXL enabled, the Firewall kernel is replicated multiple times. Each replicated instance runs on one processing core. These instances handle traffic concurrently and each instance is a complete Firewall kernel that inspects traffic. When CoreXL is enabled, all Firewall instances in the Security Gateway process traffic through the same interfaces and apply the same gateway security policy.

When you enable CoreXL, the number of kernel instances is based on the total number of CPU cores.

Number of Cores

Number of Kernel Instances








Number of cores, minus 2

More than 20

Number of cores, minus 4. Up to a total of 40 instances. Cores can be IPv4 or IPv6.

Configuring CoreXL

Use the cpconfig command to open the wizard to enable CoreXL and configure the number of firewall instances.

To enable/disable CoreXL:

  1. Log in to the Security Gateway.
  2. Run cpconfig
  3. Select Configure Check Point CoreXL.
  4. Enable or disable CoreXL.
  5. Reboot the Security Gateway.

To configure the number of instances:

  1. Run cpconfig
  2. Select Configure Check Point CoreXL.
  3. If CoreXL is enabled, enter the number of CoreXL firewall instances.

    If CoreXL is disabled, enable CoreXL and then set the number of CoreXL firewall instances.

  4. Reboot the gateway.

To Learn More About CoreXL

To learn more about CoreXL, see the R80.10 Performance Tuning Administration Guide


SecureXL is an acceleration solution that maximizes performance of the Firewall and does not compromise security. When SecureXL is enabled on a Security Gateway, some CPU intensive operations are processed by virtualized software instead of the Firewall kernel. The Firewall can inspect and process connections more efficiently and accelerate throughput and connection rates. These are the SecureXL traffic flows:

The goal of a SecureXL configuration is to minimize the connections that are processed on the slow path.

Throughput Acceleration

Connections are identified by the 5 tuple attributes: source address, destination address, source port, destination port, protocol. When the packets in a connection match all the 5 tuple attributes, the traffic flow can be processed on the accelerated path.

The first packets of a new TCP connection require more processing and they are processed on the slow path. The other packets of the connection can be processed on the accelerated path and the Firewall throughput is dramatically increased.

Connection-rate Acceleration

SecureXL also improves the rate of new connections (connections per second) and the connection setup/teardown rate (sessions per second). To accelerate the rate of new connections, connections that do not match a specified 5 tuple are still processed by SecureXL.

For example, if the source port is masked and only the other 4 tuple attributes require a match. When a connection is processed on the accelerated path, SecureXL creates a template of that connection that does not include the source port tuple. A new connection that matches the other 4 tuples is processed on the accelerated path because it matches the template. The Firewall does not inspect the new connection and the Firewall connection rates are increased.

Configuring SecureXL

SecureXL is enabled by default. Configure it using the CLI.

To configure SecureXL:

  1. Log in to the CLI on the Security Gateway.
  2. Run cpconfig
  3. Enter the option that enables or disables SecureXL.

    For example, (9) Disable Check Point SecureXL

  4. Enter y and then enter 11.

    Note -

    • Run fwaccel or fwaccel6 to dynamically enable or disable SecureXL acceleration for IPv4 or IPv6 traffic
    • This setting does not survive reboot or the Security Gateway


To Learn More About SecureXL

To learn more about SecureXL, see the R80.10 Performance Tuning Administration Guide.


By default, the traffic for each interface is processed on one CPU core. If there are more CPU cores than interfaces, not all of the CPU cores are used to process traffic.

You can enable the Multi-Queue feature to assign more than one CPU core to one interface. Run the cpmq command to configure the Multi-Queue settings.

The SND (Secure Network Distributer) is part of SecureXL and CoreXL. It processes and helps to accelerate network traffic:

Sample Multi-Queue Configuration

This sample configuration shows how CoreXL, SecureXL and Multi-Queue can help to use more CPU cores for SNDs to accelerate network traffic. There is a Security Gateway with two six core CPUs (total 12 CPU cores) and three interfaces:

To learn more about Multi-Queue, see the R80.10 Performance Tuning Administration Guide.


The Need for Clusters

Security Gateways and VPN connections are business critical devices. The failure of a Security Gateway or VPN connection can result in the loss of active connections and access to critical data. The Security Gateway between the organization and the world must remain open under all circumstances.

ClusterXL Solution

ClusterXL is a Check Point software-based cluster solution for Security Gateway redundancy and Load Sharing. A ClusterXL Security Cluster contains identical Check Point Security Gateways.




Internal network


Switch for internal network


Security Gateways with ClusterXL Software Blade


Switch for external networks



IPv6 Support for ClusterXL

R80.10 ClusterXL supports High Availability clusters for IPv6. IPv6 status information is synchronized and the IPv6 clustering mechanism is activated during failover. However, IPv6 is not supported for Load Sharing clusters. Also, you cannot define IPv6 addresses for synchronization interfaces.

How ClusterXL Works

ClusterXL uses State Synchronization to keep active connections alive and prevent data loss when a member fails. With State Synchronization, each member "knows" about connections that go through other members.

ClusterXL uses virtual IP addresses for the cluster itself and unique physical IP and MAC addresses for the members. Virtual IP addresses do not belong to physical interfaces.

ClusterXL can work with OPSEC certified High Availability and Load Sharing products, which use the same State Synchronization infrastructure as Check Point ClusterXL.

Note - The ClusterXL Administration Guide contains information only for Security Gateway clusters. For information about the use of ClusterXL with VSX, see the R80.10 VSX Administration Guide.

The Cluster Control Protocol

The Cluster Control Protocol (CCP) is the glue that links together the members in the Security Cluster. CCP traffic is distinct from ordinary network traffic and can be viewed using any network sniffer.

CCP runs on UDP port 8116, and has the following roles:

The Check Point CCP is used by all ClusterXL modes as well as by OPSEC clusters. However, the tasks performed by this protocol and the manner in which they are implemented may differ between cluster types.

Note - There is no need to add a rule to the Security Policy Rule Base that accepts CCP.



Installation and Platform Support

ClusterXL must be installed in a distributed configuration in which the Security Management Server and the Security Cluster members are on different computers. ClusterXL is part of the standard Security Gateway installation.

For installation instructions, see the R80.10 Installation and Upgrade Guide.

To see the ClusterXL supported platforms, see the R80.10 Release Notes .

High Availability and Load Sharing in ClusterXL

ClusterXL is a software-based Load Sharing and High Availability solution that distributes network traffic between clusters of redundant Security Gateways.

ClusterXL has these High Availability features:

All members in the cluster are aware of the connections passing through each of the other members. The cluster members synchronize their connection and status information across a secure synchronization network.

The glue that binds the members in a ClusterXL cluster is the Cluster Control Protocol (CCP), which is used to pass synchronization and other information between the cluster members.

High Availability

In a High Availability cluster, only one member is active (Active/Standby operation). In the event that the active cluster member becomes unavailable, all connections are re-directed to a designated standby without interruption. In a synchronized cluster, the standby cluster members are updated with the state of the connections of the active cluster member.

In a High Availability cluster, each member is assigned a priority. The highest priority member serves as the Security Gateway in normal circumstances. If this member fails, control is passed to the next highest priority member. If that member fails, control is passed to the next member, and so on.

Upon Security Gateway recovery, you can maintain the current active Security Gateway (Active Up), or to change to the highest priority Security Gateway (Primary Up).

ClusterXL High Availability supports IPv4 and IPv6.

Load Sharing

ClusterXL Load Sharing distributes traffic within a cluster so that the total throughput of multiple members is increased. In Load Sharing configurations, all functioning members in the cluster are active, and handle network traffic (Active/Active operation).

If any member in a cluster becomes unreachable, transparent failover occurs to the remaining operational members in the cluster, thus providing High Availability. All connections are shared between the remaining Security Gateways without interruption.

IPv6 is not supported for Load Sharing clusters.

Example of a ClusterXL Topology

ClusterXL uses unique physical IP and MAC addresses for each cluster member, and a virtual IP addresses for the cluster itself. Cluster interface addresses do not belong to any real member interface.

The following diagram illustrates a two-member ClusterXL cluster, showing the cluster virtual IP addresses and member physical IP addresses. This sample deployment is used in many of the examples presented in this chapter.




Internal network


Internal switch (internal cluster IP address


Security Gateway - Cluster member A


Virtual interface to the internal network (


Interface to the Cluster Sync network (


Virtual interface to the external network (


Security Gateway - Cluster member B


Virtual interface to the internal network (


Interface to the Cluster Sync network (


Virtual interface to the external network (


External switch (external routable cluster IP address



Each cluster member has three interfaces: one external interface, one internal interface, and one for synchronization. Cluster member interfaces facing in each direction are connected via a switch, router, or VLAN switch.

All cluster member interfaces facing the same direction must be in the same network. For example, there must not be a router between cluster members.

The Security Management Server can be located anywhere, and should be routable to either the internal or external cluster addresses.

Defining the Cluster Member IP Addresses

The guidelines for configuring each cluster member are as follows:

All members within the cluster must have at least three interfaces:

All interfaces pointing in a certain direction must be on the same network.

For example, in the previous illustration, there are two cluster members, Member_A and Member_B. Each has an interface with an IP address facing the Internet through a hub or a switch. This is the external interface with IP address on Member_A and on Member_B, and is the interface that the cluster external interface sees.

Note - This release presents an option to use only two interfaces per member, one external and one internal and to run synchronization over the internal interface. This configuration is not recommended and should be used for backup only.

Defining the Cluster Virtual IP Addresses

In the previous illustration, the IP address of the cluster is

The cluster has one external virtual IP address and one internal virtual IP address. The external IP address is, and the internal IP address is

The Synchronization Network

State Synchronization between cluster members ensures that if there is a failover, connections that were handled by the failed member will be maintained. The synchronization network is used to pass connection synchronization and other state information between cluster members. This network therefore carries all the most sensitive security policy information in the organization, and so it is important to make sure the network is secure. It is possible to define more than one synchronization network for backup purposes.

To secure the synchronization interfaces, they should be directly connected by a cross cable, or in a cluster with three or more members, use a dedicated hub or switch.

Members in a Load Sharing cluster must be synchronized because synchronization is used in normal traffic flow. Members in a High Availability cluster do not have to be synchronized, though if they are not, connections may be lost upon failover.

The previous illustration shows a synchronization interface with a unique IP address on each member. on Member_A and on Member_B.

ClusterXL Modes

Introduction to ClusterXL Modes

ClusterXL has these working modes. This section briefly describes each mode and its relative advantages and disadvantages.

High Availability Mode

The High Availability Mode provides basic High Availability capabilities in a cluster environment. This means that the cluster can provide firewall services even when it encounters a problem, which on a stand-alone Security Gateway would have resulted in a complete loss of connectivity. When combined with Check Point State Synchronization, ClusterXL High Availability can maintain connections through failover events, in a user-transparent manner, allowing a flawless connectivity experience. Thus, High Availability provides a backup mechanism, which organizations can use to reduce the risk of unexpected downtime, especially in a mission-critical environment (such as one involving money transactions over the Internet.)

To achieve this purpose, ClusterXL High Availability mode designates one of the cluster members as the active member, while the other members remain in stand-by mode. The cluster virtual IP addresses are associated with the physical network interfaces of the active member (by matching the virtual IP address with the unique MAC address of the appropriate interface). Thus, all traffic directed at the cluster is actually routed (and filtered) by the active member. The role of each cluster member is chosen according to its priority, with the active member being the one with the highest ranking. Member priorities correspond to the order in which they appear in the Cluster Members page of the Cluster Properties window. The top-most member has the highest priority. You can modify this ranking at any time.

In addition to its role as a firewall, the active member is also responsible for informing the stand-by members of any changes to its connection and state tables, keeping these members up-to-date with the current traffic passing through the cluster.

Whenever the cluster detects a problem in the active member that is severe enough to cause a failover event, it passes the role of the active member to one of the standby members (the member with the currently highest priority). If State Synchronization is applied, any open connections are recognized by the new active member, and are handled according to their last known state. Upon the recovery of a member with a higher priority, the role of the active member may or may not be switched back to that member, depending on the user configuration.

It is important to note that the cluster may encounter problems in standby members as well. In this case, these members are not considered for the role of active members, in the event of a failover.

Load Sharing Modes - Multicast and Unicast

Load Sharing Multicast Mode - This is an efficient way to handle a high load because the load is distributed optimally between all cluster members. Load Sharing Multicast mode associates a multicast MAC with each unicast cluster IP address. This ensures that traffic destined for the cluster is received by all members. The ARP replies sent by a cluster member will therefore indicate that the cluster IP address is reachable via a multicast MAC address.

Load Sharing Unicast Mode - Some routing devices will not accept ARP replies. For some routers, adding a static ARP entry for the cluster IP address on the routing device will solve the issue. Other routers will not accept this type of static ARP entry.

Another consideration is whether your deployment includes routing devices with interfaces operating in promiscuous mode. If on the same network segment there exists two such routers and a ClusterXL Security Gateway in Load Sharing Multicast mode, traffic destined for the cluster that is generated by one of the routers could also be processed by the other router.

For these cases, use Load Sharing Unicast Mode, which does not require the use of multicast for the cluster addresses.


Failover is a redundancy operation that automatically occurs of a member is not functional. When this happens, another member takes over for the failed member.

In a High Availability configuration, if one member in a synchronized cluster goes down, another member becomes active and "takes over" the connections of the failed member. If you do not use State Synchronization, existing connections are closed when failover occurs, although new connections can be opened.

In a Load Sharing configuration, if one member in a cluster is unavailable, its connections are distributed among the remaining members. All members in a Load Sharing configuration are synchronized, so no connections are interrupted.

To tell each member that the other members are alive and functioning, the ClusterXL Cluster Control Protocol maintains a heartbeat between cluster members. If after a predefined time, no message is received from a member, it is assumed that the cluster member is down and failover occurs. At this point, another member automatically assumes the functionality of the failed member.

It should be noted that a cluster member may still be operational, but if any of the above tests fail, then the faulty member starts the failover because it has determined that it can no longer function as a member.

Note that more than one cluster member may encounter a problem that will result in a failover event. In cases where all cluster members encounter such problems, ClusterXL will try to choose a single member to continue operating. The state of the chosen member will be reported as Active Attention. This situation lasts until another member fully recovers. For example, if a cross cable connecting the cluster members malfunctions, both members will detect an interface problem. One of them will change to the Down state, and the other to Active Attention.

When Does a Failover Occur?

A failover takes place when one of the following occurs on the active cluster member:

Configuring ClusterXL

This procedure describes how to configure the Load Sharing Multicast, Load Sharing Unicast, and High Availability New Modes from scratch. Their configuration is identical, apart from the mode selection in SmartDashboard Cluster object or Cluster creation wizard.

Creating Cluster Members

Important - The hardware for all cluster members must be exactly the same, including:

  • CPU
  • Motherboard
  • Memory
  • Number and type of interfaces

To create new cluster members for ClusterXL:

  1. Install and configure Check Point Security Gateway for all cluster members. Each member must use the identical version and build. For installation and initial configuration procedures, refer to the R80.10 Installation and Upgrade Guide.

    During the installation process, enable ClusterXL and State Synchronization:

    Run cpconfig from the command line and select Enable cluster membership for this gateway.

    If you did not perform this action during installation, you can always do so by using the cpconfig utility at a later time. Run the cpconfig from the command line, and select the appropriate options to enable cluster capabilities for that member. You may be asked to reboot the member.

  2. Define an IP address for each interface on all members. Do not define IPv6 addresses for synchronization interfaces.
  3. For VPN cluster members, synchronize member clocks accurately to within one second of each other. If these members are constantly up and running it is usually enough to set the time once. More reliable synchronization can be achieved using NTP or some other time synchronization services supplied by the operating system. Cluster member clock synchronization is not applicable for non VPN cluster functionality.
  4. Connect the cluster members to each other and to the networks through switches. For the synchronization interfaces, you can use a cross cable or a dedicated switch. Make sure that each network (internal, external, Synchronization, DMZ, and so on) is configured on a separate VLAN, switch or hub.

Note - You can also perform synchronization over a WAN

Configuring Routing for Client Computers

To configure routing for client computers:

  1. Configure routing so that communication with internal networks uses the external cluster virtual IP address. For example, configure a static route such that internal network is accessible through
  2. Configure routing so that communication with external networks uses the internal cluster IP address. For example, define the internal network IP address as the default Security Gateway for each computer on the internal side of the router.

Choosing the CCP Transport Mode on the Cluster Members

The ClusterXL Control Protocol (CCP) uses multicast by default, because it is more efficient than broadcast. If the connecting switch cannot forward multicast traffic, it is possible, though less efficient, for the switch to use broadcast to forward traffic.

To change the CCP mode between broadcast and multicast, run:

cphaconf set_ccp broadcast|multicast

Configuring the Cluster Object and Members

The Check Point Appliance or Open Server Wizard is recommended for enterprise grade appliances and open server platforms.

To create a new cluster with the Appliance or Open Server Wizard:

  1. In SmartDashboard, right-click Check Point in the Network Objects tree.
  2. Select Security Cluster > Check Point Appliance/Open Server.
  3. In the Check Point Security Gateway Cluster Creation window, click Wizard Mode.
  4. In the Cluster General Properties window, enter or select:
    • Cluster Name - Unique name for the cluster
    • Cluster IPv4 and IPv6 address - Virtual Management IP addresses for this cluster.

      Important: You must define a corresponding IPv4 address for every IPv6 address. This release does not support pure IPv6 addresses.

    • Choose the Cluster Solution - Select Check Point ClusterXL and then select High Availability or Load Sharing.
  5. In the Cluster Member Properties window, click Add > New Cluster Member to configure each member.
    1. Enter the physical IPv4 and IPv6 addresses.

      Note: Make sure that you do not define IPV6 address for sync interfaces. The wizard does not let you define an interface with an IPv6 address as a sync interface.

    2. Enter and confirm the SIC trust activation key.
  6. In the Cluster Topology window, define a network objective (Role) for each network interface and, if necessary, define the virtual cluster IP addresses.

    The wizard automatically calculates the subnet for each network and assigns it to the applicable interface on each member. The calculated subnet shows in the upper section of the window.

    The available network objectives are:

    • Cluster Interface - A cluster interface that connects to an internal or external network. Enter the cluster virtual IP addresses for each network (internal or external). These addresses must be located in the calculated subnet.
    • Cluster Sync Interface - A cluster synchronization interface. You must define one or more synchronization interfaces for redundancy. If you are using more than one synchronization interface, define which interface is the primary, secondary, or tertiary interface. Synchronization redundancy is not supported on Small Business appliances. On these appliances, you can only select 1st sync and only for the LAN2/SYNC interface. You cannot configure VLANs on the synchronization interface.
    • Monitored Private - An interface that is not part of the cluster, but ClusterXL monitors the member state and failover occurs if a fault is detected.
    • Non Monitored Private - ClusterXL does not monitor the member state and there is no failover.

      This option is recommended for the management interface.

  7. Click Next and then Finish to complete the wizard.

After you finish the wizard, we recommend that you open the cluster object and do these procedures:

VRRP Cluster

Virtual Router Redundancy Protocol (VRRP) provides dynamic failover of IP addresses from one router to another in the event of failure. This increases the availability and reliability of routing paths via gateway selections on an IP network. Each VRRP router has a unique identifier known as the Virtual Router Identifier (VRID) which is associated with at least one Virtual IP Address (VIP). Neighboring network nodes connect to the VIP as a next hop in a route or as a final destination. Gaia supports VRRP as defined in RFC 3768.

On Gaia, VRRP can be used with or without ClusterXL enabled. The most common use case is with ClusterXL enabled. This guide describes one way of configuring VRRP, known as Monitored Circuit/Simplified VRRP, with ClusterXL enabled. To learn about all the ways of configuring VRRP, and to use VRRP without ClusterXL enabled, see the Gaia Administration Guide.

With ClusterXL enabled, VRRP supports a maximum of one VRID with one Virtual IP Address (VIP) on every interface. Only active/backup environments are supported, and you must configure VRRP so that the same node is the VRRP master for all VRIDs. This means that you must configure each VRID to monitor every other VRRP-enabled interface. You must also configure priority deltas to allow failover to the backup node when the VRID on any interface does a failover.

Monitored Circuit/Simplified VRRP makes possible a complete node failover by automatically monitoring all VRRP-enabled interfaces. You configure one VRID, and this VRID is automatically added to all the VRRP interfaces. If the VRID on any interface fails, the configured priority delta is decremented on the other interfaces. This allows the backup node to take over as the VRRP master.

How VRRP Failover Works

Each Virtual Router (VRRP Group) is identified by a unique Virtual Router ID (VRID). A Virtual Router contains one Master Security Gateway, and at least one Backup Security Gateway. The master sends periodic VRRP advertisements (known as hello messages) to the backups.

VRRP advertisements broadcast the operational status of the master to the backups. Gaia uses dynamic routing protocols to advertise the VIP (virtual IP address or backup address) of the Virtual Router.

If the master or its interfaces fails, VRRP uses a priority algorithm to decide if failover to a backup is necessary. Initially, the master is the Security Gateway that has the highest defined priority value. You define a priority for each Security Gateway when you create a Virtual Router or change its configuration. If two Security Gateways have same priority value, the platform that comes online and broadcasts its VRRP advertisements first, becomes the master.

Gaia also uses priorities to select a backup Security Gateway upon failover (when there is more than one backup available). In the event of failover, the Virtual Router priority value is decreased by a predefined Priority Delta value to calculate an Effective Priority value. The Virtual Router with the highest effective priority becomes the new master. The Priority Delta value is a Check Point proprietary parameter that you define when configuring a Virtual Router. If you configure your system correctly, the effective priority will be lower than the backup gateway priority in the other Virtual Routers. This causes the problematic master to fail over for the other Virtual Routers as well.

Note- If the effective priority for the current master and backup are the same, the Gateway with the highest IP address becomes the master.

Internal Network High Availability

This is a simple VRRP high availability use case where Security Gateway 1 is the master and Security Gateway 2 is the backup. Virtual Router redundancy is available only for connections to and from the internal network. There is no redundancy for external traffic.




Master Security Gateway


Backup Security Gateway


Virtual Router VRID 5 - Virtual IP Address (Backup Address) is


Internal Network and hosts

Preparing a VRRP Cluster

Do these steps before you start to define a Virtual Router (VRRP Group).

  1. Synchronize the system time on all Security Gateways to be included in this Virtual Router.

    Best Practice - We recommend that you enable NTP (Network Time Protocol) on all Security Gateways.
    You can also manually change the time and time zone on each Security Gateway to match the other members. In this case, you must synchronize member times to within a few seconds.

  2. Optional: Add host names and IP address pairs to the host table on each Security Gateway. This lets you use host names as an alternative to IP addresses or DNS servers.

Configuring Network Switches

Best Practice - If you use the Spanning Tree protocol on Cisco switches connected to Check Point VRRP clusters, we recommend that you enable PortFast. PortFast sets interfaces to the Spanning Tree forwarding state, which prevents them from waiting for the standard forward-time interval.

If you use switches from a different vendor, we recommend that you use the equivalent feature for that vendor. If you use the Spanning Tree protocol without PortFast, or its equivalent, you may see delays during VRRP failover.

Enabling Virtual Routers

When you log into Gaia for the first time after installation, you must use the First Time Configuration Wizard to the initial configuration steps. To use VRRP Virtual Routers (clusters), you must first enable VRRP clustering in the First Time Configuration Wizard.

To enable VRRP clustering:

  1. Install Gaia using the instructions in the R80.10 Installation and Upgrade Guide.
  2. On the First Time Configuration Wizard Products page, select Security Gateway.
    Do not select Security Management. The standalone environment (Security Gateway and Security Management Server) is not supported for VRRP.
  3. Select Unit is part of a cluster.
  4. Select VRRP Cluster from the list.
  5. Continue with the next steps in the wizard.
  6. When prompted to reboot the Security Gateway, click Cancel.
    Do not reboot.
  7. Do one of these steps:
    • Run cpconfig on the Security Gateway. Select Enable cluster membership for this gateway to enable Firewall synchronization.

      Note - This is the most common use and does not support active/active mode. You must configure VRRP so that the same cluster member is the VRRP master on all interfaces. Dynamic routing configuration must match on each cluster member.


    • Do not enable ClusterXL.

      Note - This is useful when each cluster member is required to be the VRRP master at the same time. You can configure two VRRP Virtual Routers on the same interface. Each cluster member can be the VRRP master for a different VRID on the same interface while it backs up the other. This configuration can also help run VRRP in a High-Availability pair with a device from another vendor. Disable the VRRP monitoring of the Firewall when you use this configuration. It is enabled by default but not supported with this configuration. Also, only Static Routes are supported with this configuration.

  8. Enter y when prompted.
  9. Reboot the Security Gateway.

Do this procedure for each Virtual Router member.

When you complete this procedure for each VRRP member, do these steps in the Gaia WebUI:

  1. In the navigation tree, click High Availability > VRRP.
  2. Refer to the VRRP Global Settings section.
  3. If the Disable All Virtual Routers option is currently selected, clear it.
  4. Click Apply Global Settings.

When you complete these procedures, define your Virtual Routers using the Gaia WebUI or the Gaia Clish.

Configuring Global Settings for VRRP

This section includes shows you how to configure the global settings. Global settings apply to all Virtual Routers.

Configure these global settings:

Cold Start Delay - Delay period in seconds before a Security Gateway joins a Virtual Router. Default = 0.

Interface Delay - Configure this when the Preempt Mode of VRRP has been turned off. This is useful when the VRRP node with a higher priority is rebooted, but must not preempt the existing VRRP master that is handling the traffic, but is configured with a lower priority. Sometimes interfaces that come up take longer than the VRRP timeout to process incoming VRRP Hello packets. The Interface Delay extends the time that VRRP waits to receive Hello packets from the existing master.

Disable All Virtual Routers - Select this option to disable all Virtual Routers defined on this Gaia system. Clear this option to enable all Virtual Routers. By default, all Virtual Routers are enabled.

Monitor Firewall State - Select this option to let VRRP monitor the Security Gateway and automatically take appropriate action. This is enabled by default, which is the recommended setting when using VRRP with ClusterXL enabled. This must be disabled when using VRRP with ClusterXL disabled.

Important - If you disable Monitor Firewall State, VRRP can assign master status to a Security Gateway before it completes the boot process. This can cause more than one Security Gateway in a Virtual Router to have master status.

Configuration Notes:

Gaia starts to monitor the firewall after the cold start delay completes. This can cause some problems:

Configuring Monitored Circuit/Simplified VRRP - Gaia WebUI

This section includes the basic procedure for configuring a Virtual Router using the Gaia WebUI.

To add a new Virtual Router:

  1. In the navigation tree, click High Availability > VRRP.
  2. In the Virtual Routers section, click Add.
  3. In the Add Virtual Router window, configure these parameters:
    • Virtual Router ID - Enter a unique ID number for this virtual router. The range of valid values is 1 to 255.
    • Priority - Enter the priority value, which selects the Security Gateway that takes over in the event of a failure. The Security Gateway with the highest available priority becomes the new master. The range of valid values 1 to 254. The default setting is 100.
    • Hello Interval - (optional) Select the number of seconds, after which the master sends its VRRP advertisements. The valid range is between 1 (default) and 255 seconds.
      All VRRP routers on a Security Gateways must be configured with the same hello interval. Otherwise, more than one Security Gateway can be in the master state.
      The hello interval also defines the failover interval (the time a backup router waits to hear from the existing master before it takes on the master role). The value of the failover interval is three times the value of the hello interval (default - 3 seconds).
    • Authentication:
      • none - No authentication necessary
      • simple - A password is required for authentication

      You must use the same authentication method for all Security Gateways in a Virtual Router.

      If you select simple, enter a password in the applicable field.

    • Priority Delta - Enter the value to subtract from the Priority to create an effective priority when an interface fails. The range is 1-254.
      If an interface fails on the backup, the value of the priority delta is subtracted from its priority. This gives a higher effective priority to another Security Gateway member.
      If the effective priority of the current master is less than that of the backup, the backup becomes the master for this Virtual Router. If the effective priority for the current master and backup are the same, the gateway with the highest IP address becomes the master.
  4. In the Backup Addresses section, click Add. Configure these parameters in the Add Backup Address window:
    • IPv4 address - Enter the interface IPv4 address.
    • VMAC Mode - Select one of these Virtual MAC modes:
      • VRRP - Sets the VMAC to use the standard VRRP protocol. It is automatically set to the same value on all Security Gateways in the Virtual Router. This is the default setting.
      • Interface - Sets the VMAC to the local interface MAC address. If you define this mode for the master and the backup, the VMAC is different for each. VRRP IP addresses are related to different VMACs. This is because they are dependent on the physical interface MAC address of the currently defined master.

      Note - If you configure different VMACs on the master and backup, you must make sure that you select the correct proxy ARP setting for NAT.

      • Static - Manually set the VMAC address. Enter the VMAC address in the applicable field.
      • Extended - Gaia dynamically calculates and adds three bytes to the interface MAC address to generate more random address. If you select this mode, Gaia constructs the same MAC address for master and backups in the Virtual Router.

      Note - If you set the VMAC mode to Interface or Static, syslog error messages show when you restart the computer or during failover. This is caused by duplicate IP addresses for the master and backup. This is expected behavior because the master and backups temporarily use the same virtual IP address until they get master and backup status.

    Click Save. The new VMAC mode shows in the in the Backup Address table.

  5. To remove a backup address, select an address and click Delete. The address is removed from the Backup Address table.
  6. Click Save.

Configuring the VRRP Security Gateway Cluster in SmartConsole

  1. From the Networks Objects tree, select Check Point > Security Cluster > Check Point appliance/ Open Server.

    The Security Gateway Cluster Creation window opens

  2. Choose Wizard Mode.
  3. Define the:
    • Cluster Name
    • Cluster IPv4 Address
    • For an IPv6 cluster: Cluster IPv6 Address
  4. Choose the Cluster's Solution: Gaia VRRP.
  5. Click Finish.

Configuring VRRP Rules for the Security Gateway

  1. Define this rule above the Stealth Rule in the Rule Base:




    Services & Applications


    Firewalls (Group)






    • Firewalls -Simple Group object containing the firewall objects.
    • fwcluster-object - the VRRP cluster object.
    • mcast- - Node Host object with the IP address
  2. If your Security Gateways use dynamic routing protocols (such as OSPF or RIP), create new rules for each multicast destination IP address.

    Alternatively, you can create a Network object to show all multicast network IP destinations with these values:

    • Name: MCAST.NET
    • IP:
    • Net mask:

    You can use one rule for all multicast protocols you agree to accept, as shown in this example:




    Services & Applications


    Cluster all IP addresses






To Learn More About Maximizing Network Performance

To learn more about maximizing network performance and redundancy, see these R80.10 guides: