High availability

Multiple FortiAuthenticator units can operate as an high availability (HA) cluster to provide even higher reliability.

There are three HA roles:

1. Cluster member
2. Standalone primary
3. Load-balancer

The FortiAuthenticator can operate in two separate HA modes:

1. Cluster: Active-passive clustered fail-over mode where all of the configuration is synchronized between the devices.
2. Load-balancing: Active-active HA method in which one device acts as a standalone primary with up to ten additional, geographically separated load-balancers. The load can be distributed across the devices using round-robin DNS, Auth/NAS client load distribution, or external load balancing devices. Load-balancing mode is intended for two-factor authentication deployments, as only a subset of the configuration is synchronized between the devices.

Both HA modes can be combined with an HA cluster acting as a standalone primary for geographically distributed load-balancers.

If an HA cluster is configured on an interface (such as port 2) and then disabled, it will not be possible to re-enable HA. This is because, when disabled, the interface's IP address is reconfigured to the interface to allow the administrator to access the newly standalone device. To ensure the port is available for use again in a HA cluster, the IP address must be manually removed.

Cluster member role

In the cluster member role, one unit is active and the other is on standby. If the active unit fails, the standby unit becomes active. The cluster is configured as a single authentication server on your FortiGate units.

Authentication requests made during a failover from one unit to another are lost, but subsequent requests complete normally. The failover process takes about 30 seconds.

Cluster mode uses Ethernet broadcasts through UDP/720 as part of its active/standby election mechanism and for ongoing communication. Layer 2 connectivity is required between the two devices in an HA cluster, preferably via a crossover cable, as some network devices might block such Ethernet broadcasts.

To configure FortiAuthenticator HA:

1. On each unit, go to System > Administration > High Availability.
2. Enter the following information:

   Enable HA	Enable HA.
   Role	Select Cluster member. For more information about the other options, see Standalone primary and load-balancers below.
   Maintenance Mode	Enable to put the FortiAuthenticator unit of an HA cluster into maintenance mode to remove it from the cluster. Upon entering maintenance mode, if the FortiAuthenticator unit is the active member, it relinquishes the active member role and assumes a standby role. While in maintenance mode, the FortiAuthenticator will continue to monitor the status of its HA pair and announce its presence. When set to Enabled with synchronization, the FortiAuthenticator continues to keep its configuration synchronized with the active member. When set to Enabled without synchronization, the FortiAuthenticator stops synchronizing its configuration with the active member.
   Interface	Select a network interface to use for communication between the cluster members. This interface must not already have a IP address assigned and it cannot be used for authentication services. Both units must use the same interface for HA communication.
   Cluster member IP address	Enter the IP address this unit uses for HA-related communication with the other FortiAuthenticator unit. The units must have different addresses. Usually, you should assign addresses on the same private subnet.
   Admin access	Select the types of administrative access to allow from: Telnet, SSH, HTTPS, Admin access, REST API, HTTP, and SNMP.
   Priority	Set to Low on one unit and High on the other. Normally, the unit with High priority is the active member.
   Password	Enter a string to use as a shared key for IPsec encryption. This must be the same on both units.
   Load-balancing slaves	Add the other load-balancing cluster members by entering their IP addresses.
   Monitored interfaces	Enable the interfaces you want to monitor.
   Monitored interfaces stability period	Define the stability period for the monitored interfaces in seconds, between 0-3600 (or one hour). The default is set to 30.
   Node-Specific Default Gateway	Define a default gateway for the FortiAuthenticator device if it differs from the default gateway of the other HA cluster member.

   The Priority setting is a static value. It allows the administrator to specify which unit to elect as the active member when both units are working equally well (i.e. in a failover situation, the "high priority" setting will not be transferred to the new active member). If both units are healthy, the one with high priority will be elected as the active member. If the high priority unit goes down, the low priority unit becomes the active member. When the low priority is the active member and the high priority comes back online, the high priority assigns the standby member role and syncs from the low priority active member. If the high priority unit is synced and remains stable for around five minutes, it takes over and becomes the active member again.

3. Select OK to apply the settings.

   When one unit has become the active member, reconnect to the GUI and complete your configuration. The configuration will automatically be copied to the standby member.

Standalone primary and load-balancers

The load-balancing HA method enables active-active HA across geographically separated locations and Layer 3 networks. Only the following authentication related features can be synchronized:

• Token and seeds.
• Local user database.
• Remote user database.
• Group mappings.
• Token and user mappings.
• Certificates included in:
  • Certificate Management > End Entities > Local Services, excluding firmware (Fortinet) certificates.
  • Certificate Management > Certificate Authorities > Local CAs, including firmware (Fortinet) certificates.
• SAML configurations:
  • IdP settings configured in Authentication > SAML IdP > General.
    Realm tables are not synchronized, but the default realm selection (radio button) is.
  • SP settings configured in Authentication > SAML IdP > Service Providers.
• Administrators with Sync in HA Load Balancing mode enabled.

Other features, such as FSSO cannot be synchronized between devices.

The current synchronization status of the standalone primary to load-balancers can be viewed at Dashboard > HA Status.

The standalone primary is the primary system where users, groups, and tokens are configured. Load-balancers are synchronized to the standalone primary device.

To improve the resilience of the primary system, an active-passive cluster with up to ten load-balancing devices can be configured.

To configure load-balancing HA:

1. On each unit, go to System > Administration > High Availability.
2. Enter the following information:

   Enable HA	Enable HA.
   Role	Select Standalone master on the primary device, and Load-balancing slave on the load-balancing device(s).
   Load Balancing master IP address	On the load-balancing device(s) enter IP address of the primary unit.
   Password	Enter a string to use as a shared key for IPsec encryption. This must be the same on both units.
   Load-balancing slaves	On the standalone primary, enter IP address or IP addresses of the load-balancing devices. Up to ten can be added.

3. Select OK to apply the settings.

Administrative access to the HA cluster

Administrative access is available through any of the network interfaces using their assigned IP addresses or through the HA interface using the Cluster member IP address, assigned on the System > Administration > High Availability page. In all cases, administrative access is available only if it is enabled on the interface.

Administrative access through any of the network interface IP addresses connects only to the active cluster member. The only administrative access to the standby member is through the HA interface using the standby member's Cluster member IP address.

Configuration changes made on the active member are automatically pushed to the standby member. The standby member does not permit configuration changes, but you might want to access the unit to change HA settings, or for firmware upgrades, shutdown, reboot, or troubleshooting.

FortiAuthenticator VMs used in a HA cluster each require a license. Each license is tied to a specific IP address. In an HA cluster, all interface IP addresses are the same on the units, expect for the HA interface.

Request each license backed on either the unique IP address of the unit's HA interface or the IP address of a non-HA interface which is the same on both units.

If you disable and then re-enable HA operation, the interface that was assigned to HA communication will not be available for HA use. You must first go to System > Network > Interfaces and delete the IP address from that interface.

Restoring the configuration

When restoring a configuration to an HA active cluster member, the active member reboots and in the interim the standby member is promoted to active member. When the previous active member returns to service, it becomes a standby member and the existing active member overwrites its configuration, defeating the configuration restore. To avoid this, use the following process when restoring a configuration:

1. Shutdown the standby member.
2. Restore the configuration on the active member.
3. Wait until the active member is back online.
4. Turn on the standby member — it will synchronize to the restored configuration after booting up.

Firmware upgrade

For a stable HA configuration, all units in an HA cluster must be running the same firmware version, and have the same sized license for HA devices.

When upgrading the firmware on FortiAuthenticator devices in an HA cluster, you can perform a coordinated upgrade of both cluster members. During the coordinated upgrade, the cluster upgrades the standby device and then the active device to run the new firmware image. The firmware upgrade takes place without interrupting communication through the cluster. This firmware upgrade method can only be initiated from the active member of the cluster.

The following sequence describes the steps the cluster goes through during a coordinated firmware upgrade.

1. The administrator initiates the firmware upgrade from the active member.
2. The firmware image transfers to the standby member.
3. The firmware upgrades on the standby member.
4. The standby member reboots and synchronizes with the active member.
5. The firmware upgrade begins on the active member. The standby member becomes the new active member.
6. The former active member reboots and synchronizes with the new active member.
7. The former active member becomes the active device, and the former standby member becomes the standby device.

If you want to perform the firmware upgrade on each FortiAuthenticator cluster member individually, specific steps must be taken to ensure that the upgrade is successful:

1. Start the firmware upgrade on the active member. See Upgrading the firmware.

The device reboots. While the active member is rebooting, the standby member becomes the active member.

2. Start the firmware upgrade on the new active member.

The device reboots. After both devices have rebooted, the original active member becomes the active device, while the standby member returns to being the standby device.

If a situation arises where both devices are claiming to be the active cluster member due to a firmware mismatch, and the HA port of the device that is intended to be the standby member cannot be accessed (such as when a crossover cable is used), use the following steps:

1. Shutdown the active member to which you have access, or, if physical access to the unit is not available to turn it back on, reboot the device. See System information widget.

Note that, if rebooting the device, Step 2 below must be completed before the device finishes rebooting, which can be as short as 30 seconds.

2. With the previously inaccessible device now accessible, upgrade its firmware to the required version so that both devices have the same version.

The device reboots.

3. If you shutdown the device in Step 1, power it back on.

After both devices are back online, they assume the HA roles dictated by their respective HA priorities.