Before You Configure a Cloud-Managed FireCluster in WatchGuard Cloud

Before you configure a cloud-managed FireCluster in WatchGuard Cloud, make sure that you:

Verify feature support
Verify requirements:
Verify the external interface configuration
Verify network router and switch configurations
Plan the cluster interface configuration

Verify Feature Support

FireCluster does not support all Firebox features. For more information, go to Unsupported Features for a Cloud-Managed FireCluster.

Verify Requirements

To add a cloud-managed FireCluster in WatchGuard Cloud, you can use one of these options:

Add two Fireboxes with factory-default settings as a cloud-managed FireCluster.
Change a locally-managed active/passive FireCluster to cloud management.

Cloud-managed FireClusters operate in active/passive mode. You cannot add an active/active cloud-managed FireCluster.

WatchGuard Cloud Account Requirements

You must make sure to:

Activate both Fireboxes in your WatchGuard account. For more information, go to Activate a WatchGuard Firebox.
Allocate one of the Fireboxes to a Subscriber account (Service Providers only). To add the second Firebox, you can specify the serial number. For more information, go to Allocate Fireboxes.

Firmware Requirements

Cloud-managed FireClusters have these firmware requirements:

Both Fireboxes in the FireCluster must run the same Fireware firmware version. For information about the firmware version, go to Configure Device Settings in WatchGuard Cloud.
Both Fireboxes must run Fireware v12.8.2 or higher

License and Subscription Requirements

Cloud-managed FireClusters have these license requirements:

Enable the subscription services in the feature key for only one cluster member. The active cluster member uses the subscription services that are active in the feature key of either cluster member.
One cluster member must have a license for Total Security Suite or Basic Security Suite. The other cluster member must have a minimum Standard Support license.
For service providers and partners, you can use a Not for Resale (NFR) Firebox in a FireCluster with another NFR or non-NFR Firebox. Note that the activation of a High Availability SKU on an NFR device requires another non-NFR device of the same model in your account not already paired with a High Availability SKU.

Cloud-managed FireClusters have these requirements for license subscriptions:

A support subscription applies to a single device, even when that device is configured as a member of a cluster. Each device in the cluster must have an active support subscription. If the support subscription expires for a cluster member, you cannot upgrade the firmware on that device.
To see the support level and subscription expiration dates for each member, go to the Manage Products page in your account on the WatchGuard website.

Cloud-managed FireClusters have these requirements for RMA subscriptions:

To upgrade both FireCluster members to a Premium 4-Hour RMA subscription, you must purchase this subscription for each cluster member. For more information about Premium 4-Hour RMA subscriptions, go to the RMA Service FAQ on the WatchGuard website.

For more information about license activation, renewal, and expiration, go to About Firebox WatchGuard Cloud Licenses.

Hardware and Cable Requirements

Make sure that you have:

Two activated Fireboxes with the same model number.
Local administrative access to the FireCluster.
The same number and type of interface modules installed in the same slots on each Firebox.
At least one unused Firebox interface to use as the dedicated cluster interface. To configure a backup cluster interface, you must have an additional unused Firebox interface.
An Ethernet cable for each cluster interface. You can use a straight or crossover cable to connect the cluster interface on one cluster member to the cluster interface on the other cluster member.
One network switch for each enabled internal, guest, or external interface.
Ethernet cables to connect the interfaces of both devices to the network switches.
Some Firebox models support user-installable interface modules. Because the number of interface modules installed on these models can vary, these models have additional FireCluster configuration requirements:
Both members of a FireCluster must be the same Firebox model and have the same number and type of interface modules installed in the same slots. The cluster cannot form if the hardware configuration for both Fireboxes does not match exactly.
You must select a built-in interface as the primary cluster interface. With this configuration, you directly connect the built-in interfaces of the two members. Member discovery happens through that interface when the cluster first forms.
On an M5600, the only built-in interface is interface 32
On an M470, M570, M590, M670, M690, M4600, T80, and T85, the eight built-in interfaces are interfaces 0 through 7

FireCluster is fully supported on all Firebox devices, with these exceptions:

Firebox T15 and NV5 devices do not support FireCluster.
FireboxV devices in a VMware ESXi environment only support an active/passive FireCluster.
FireCluster is not supported for a Hyper-V environment.
Firebox Cloud does not support FireCluster.

When you configure two wireless Fireboxes as a FireCluster, the configuration must meet these requirements:

Firebox T15-W wireless models do not support FireCluster.
You cannot use wireless interfaces as the primary or backup cluster interfaces.
If the cluster interface IP address is on an interface that is bridged to a wireless network, you cannot use a wireless connection to manage the device.

Network Requirements

Both Fireboxes must be connected to the network and have reliable Internet access.

Network latency between cluster members must be less than 100ms.
FireCluster does not support bridged networks.

Virtual Machine (VM) Requirements

FireCluster in a VMware environment operates as expected only if all requirements are met. For information, go to Configure a FireCluster on VMware ESXi.

FireCluster is not supported for Hyper-V.
All clients protected by the cluster must be able to communicate to both cluster members. VMware does not send traffic from clients on the same ESXi host as a cluster member to the other cluster member on a different ESXi host. For more information, go to Configure a FireCluster on VMware ESXi.

Verify the External Interface Configuration

Each external interface must have a static IP address or be configured for PPPoE or DHCP. For more information about how to configure the external interface, go to Configure a Firebox External Network.

Verify Network Router and Switch Configurations

You must have a network switch or VLAN for each active traffic interface.

The primary and backup cluster interfaces must be on different, unused subnets. Make sure that you use subnets that do not overlap with local or VPN subnets. To avoid IP address conflicts with routable IP addresses, we recommend that you use Automatic Private IP Addressing (APIPA) subnets, also known as link-local addresses (169.254.0.1/16 – 169.254.255.254/16).

We recommend that you do not use a switch between each member for the cluster interfaces. If you use a switch between each member for the cluster interfaces, the cluster interfaces must be logically separated from each other on different VLANs.

Plan the Cluster Interface Configuration

We recommend that you plan which IP addresses and Firebox interfaces to use for FireCluster before you configure the FireCluster. In the FireCluster configuration, you must specify IP addresses and interface numbers for these FireCluster interfaces:

Cluster interface

A dedicated interface for communication between the cluster members. Cluster members use this interface to exchange heartbeat packets, and to synchronize connection and session information. This interface is not used for regular network traffic. When you set up the cluster hardware, we recommend that you connect the cluster interfaces of each Firebox to each other. We recommend that you do not use a switch between cluster interfaces.

Backup cluster interface (optional)

A redundant dedicated interface for communication between the cluster members. We recommend a backup cluster interface only if you use a switch between cluster interfaces.

Communication interface

An interface used to send log messages from both cluster members to your Dimension or syslog server, and to manage the backup cluster master. For locally-managed FireClusters, this interface is named Interface for Management IP address in Fireware Web UI and WatchGuard System Manager.

This list shows sample IP addresses for a cloud-managed FireCluster.

IP Addresses for a Cloud-Managed FireCluster
	Firebox Interface	Member1 IP Address	Member2 IP Address
Cluster interface	0	169.254.0.1/30	169.254.0.2/30
Backup cluster interface	1	169.254.1.1/30	169.254.1.2/30
Communication interface	2	10.10.2.3/24	10.10.2.4/24

Cluster Interface Best Practices

Follow these best practices for cluster interface IP addresses:

Use an IP address that is not in use on your network. To avoid conflicts with routable IP addresses, we recommend APIPA addresses or IP addresses from a dedicated private subnet.
The interface IP addresses for both cluster members must be on the same subnet.
If you have an interface configured as a dedicated VLAN interface, do not choose that interface as a dedicated cluster interface.
Do not set the cluster IP to the default IP address of any interface on the Firebox. By default, the Firebox uses 10.0.x.0/24 subnets for interface IP addresses, which means we recommend that you avoid using 10.0.x.0/24 addresses for cluster IP addresses. If you configure the cluster interface to use one of the factory-default interface IP addresses, a conflict can occur during cluster formation which can cause the failover to fail.
Do not use the cluster IP addresses for anything else on your network, including for VPNs.

Follow these best practices for cluster interfaces:

For the best fault tolerance against network interface card (NIC) failures on the Firebox, we recommend that you use eth0 for the primary cluster interface. If a Firebox NIC fails, the Firebox automatically reassigns the logical interface numbers. The Firebox assigns eth labels in the order in which the interfaces are detected. As a result, logical interface numbers appear to shift to the left. Label reassignment can affect FireCluster operations and backup cluster interface configurations.

For example, if you use eth0 for the primary cluster interface, and a NIC other than eth0 fails, the FireCluster continues to operate as expected because the interface label remains eth0. The Firebox does not reassign the logical interface label for eth0 because there is no interface physically to the left of eth0. This configuration protects the FireCluster against NIC failures on interfaces other than eth0. Only an eth0 failure would affect FireCluster operations.

If you use eth4 as the primary cluster interface, and eth3 fails, the Firebox reassigns the logical label eth3. The interface eth4 becomes eth3. This disrupts FireCluster operations because the FireCluster configuration settings on the Firebox specify eth4 as the primary cluster interface.
We recommend that you do not use a switch between each member for the cluster interfaces. If you use a switch between each member for the cluster interfaces, the cluster interfaces must be logically separated from each other on different VLANs.
You must select a Firebox built-in interface as the primary cluster interface. For more information, go to About FireCluster with Modular Interfaces.
On an M5600, the only built-in interface is interface 32
On an M470, M570, M590, M670, M690, M4600, T80, and T85, the eight built-in interfaces are interfaces 0 through 7

Backup Cluster Interface Best Practices

The type of connection between cluster interfaces determines whether we recommend a backup cluster interface.

FireCluster with a direct cable connection between cluster members

We do not recommend a backup cluster interface for this type of configuration because it provides limited redundancy.

FireCluster uses the backup cluster interface only if the cable between the primary cluster interfaces fails. If any NIC on the Firebox fails, the backup cluster interface does not provide redundancy because the Firebox automatically reassigns the logical interface labels as described in the previous section on this page.

FireCluster with a switch between cluster members

In this configuration, FireCluster members are physically separated by a switch, which we do not recommend. If you place a switch between the cluster interfaces, we recommend that you configure a backup cluster interface. The FireCluster uses the backup cluster interface in these events:

The cable between the switch and cluster interface fails.
The switch interface fails.
A networking issue causes the switch to become unavailable.

If any NIC on the Firebox fails, the backup cluster interface does not provide redundancy because the Firebox automatically reassigns the logical interface labels. For example, you specify eth3 as the primary cluster interface and eth4 as the backup cluster interface. If eth3 fails, the Firebox reassigns the logical label eth3. The interface that was labeled eth4 is now labeled eth3. The interface label reassignment disrupts FireCluster operations because the FireCluster configuration settings specify eth3 as the primary cluster interface and eth4 as the backup cluster interface.

For the best results, use eth0 for the primary cluster interface.

Use an IP address that is not in use on your network. To avoid conflicts with routable IP addresses, we recommend APIPA addresses or IP addresses from a dedicated private subnet. IP addresses for backup cluster interfaces must be on the same subnet. IP addresses for backup cluster interfaces must be on a different subnet than IP addresses for primary cluster interfaces.

Follow these best practices for cluster interfaces and IP addresses:

The primary and backup cluster interfaces must be on different subnets.
Do not set the backup cluster IP address to the default IP address of any interface on the Firebox. By default, the Firebox uses 10.0.x.0/24 subnets for interface IP addresses, which means we recommend that you avoid using 10.0.x.0/24 addresses for backup cluster IP addresses. If you configure the backup cluster interface to use one of the factory-default interface IP addresses, a conflict can occur during cluster formation that can cause failover to fail. The backup cluster IP addresses must not be used for anything else on your network, including VPNs.

Communication Interface Best Practices

Use an IP address that is on the same subnet as your Dimension or syslog server. The communication interface IP address must also be on the same subnet as your internal network.

In WatchGuard Cloud, you can configure a cloud-managed FireCluster to send log messages to Dimension or syslog servers to retain log messages longer than the normal data retention period in WatchGuard Cloud.

IP Addresses and RADIUS Authentication

After you configure a FireCluster, RADIUS authentication requests from users on your network can come from either the FireCluster management IP address or the Firebox interface IP address. This occurs because the routing table uses different factors to determine which IP address is used.

Next Steps

After you verify all requirements, you can Add a Cloud-Managed FireCluster.