A Practical Guide to FortiGate High Availability

A single firewall can become the most expensive single point of failure in a business network. If it fails, internet access, cloud applications, payment processing, site-to-site VPNs, remote users, and internal security controls may all stop at once. This guide to FortiGate high availability explains how to reduce that risk with a properly designed FortiGate HA pair - and why the design work around the firewalls matters as much as the HA configuration itself.

For many small and midsize organizations, FortiGate high availability is not about chasing zero downtime at any cost. It is about protecting the services that cannot be unavailable during a business day, while keeping the environment supportable and within budget.

What FortiGate High Availability Actually Does

FortiGate HA uses the Fortinet Clustering Protocol, commonly called FGCP, to join two compatible FortiGate appliances into a cluster. In the most common active-passive design, one firewall actively processes traffic while the second firewall remains synchronized and ready to take over if the primary unit or a monitored network path fails.

The primary benefit is fault tolerance. The secondary unit receives configuration updates and, depending on the selected settings, can maintain session information for active connections. When a failure occurs, the standby firewall assumes the active role without requiring staff to rebuild policies, restore a backup, or manually reconnect every cable.

HA does not eliminate every type of outage. It will not keep the internet working if the ISP circuit is down, correct a bad firewall policy pushed to both cluster members, or protect an improperly configured switch uplink. It is one layer of availability engineering. The WAN design, switching topology, power protection, firmware process, and monitoring plan must support it.

Choosing the Right FortiGate HA Design

Active-passive is usually the right starting point

For most offices, medical practices, retail locations, restaurants, and professional services firms, active-passive HA is the preferred approach. It is easier to validate, easier to troubleshoot, and provides a clear operational state: one appliance is forwarding production traffic and the other is standing by.

This design is well suited to organizations that depend on cloud applications, VoIP, VPN access, card transactions, guest Wi-Fi, or secure connectivity to another location. It also avoids many of the traffic-flow and capacity considerations associated with active-active clusters.

Active-active has a narrower use case

Active-active HA can distribute sessions between FortiGate appliances, but it should not be selected simply because two devices are available. Traffic symmetry, inspection requirements, routing behavior, and feature compatibility require more careful engineering. In environments using extensive SSL inspection, advanced threat protection, complex SD-WAN rules, or application-sensitive traffic, active-passive often provides more predictable results.

The question is not whether active-active is more advanced. The question is whether its additional design and support complexity produces a meaningful business benefit.

Size the pair for normal operations and failure conditions

An HA pair does not double the throughput capacity of an active-passive deployment. Each FortiGate must be capable of carrying the full production workload on its own after failover. Capacity planning should account for internet bandwidth, VPN users, SSL inspection, IPS, web filtering, application control, logging, and expected growth.

A firewall that performs acceptably with basic filtering can become constrained when security inspection is enabled properly. This is especially relevant for organizations improving PCI DSS, NIST, CIS, or other security-control alignment. Firewall sizing should reflect the intended security posture, not only today’s bandwidth test.

Prerequisites for a Reliable HA Deployment

FortiGate cluster members should be matching supported models with compatible hardware characteristics and the same FortiOS firmware version. Both appliances need appropriate FortiGuard subscriptions and support coverage. A mismatch in firmware, licensing, or hardware capability creates avoidable risk during a failover event.

The network connections also need deliberate planning. Each FortiGate normally uses dedicated heartbeat interfaces to exchange cluster status and synchronize configuration. These links should be physically redundant where the model and design allow it. They should not share the same path as ordinary user traffic or depend on a single small switch that could fail independently.

Upstream and downstream connectivity must be able to tolerate the firewall role change. This may involve redundant switch connections, stacked switches, multi-chassis link aggregation, or carefully designed VLAN trunks. A pair of firewalls connected to a single unmanaged switch is not an HA design. It simply moves the single point of failure to the switch.

Power also deserves attention. Place the FortiGates on protected power, preferably with separate UPS-backed power paths when practical. If the building has a generator, confirm that network closets, ISP equipment, core switches, and wireless infrastructure are covered as well. Firewall redundancy is of limited value if the active unit and standby unit lose power together.

How to Deploy FortiGate High Availability Safely

A disciplined deployment begins with an accurate record of the existing environment: WAN handoffs, LAN VLANs, switch uplinks, static routes, DHCP responsibilities, VPN tunnels, public IP addresses, DNS dependencies, and critical applications. This assessment identifies the changes that must occur around the firewall pair, not just inside it.

Before creating the cluster, establish a current, encrypted configuration backup and document a rollback procedure. Review firmware compatibility and plan the maintenance window around business-critical functions such as payment systems, phone service, remote access, and cloud-based practice or line-of-business applications.

Configure the HA settings consistently on both FortiGates. This includes the group name, group ID, password, heartbeat ports, device priority, and monitored interfaces. The higher-priority appliance is normally intended to become the primary member, but the failover behavior should be planned rather than assumed.

Once the cluster forms, configure or validate production interfaces, VLANs, policies, routes, SD-WAN members, VPNs, and security profiles. The cluster should be treated as one managed firewall from an operations perspective. Changes made on the primary member synchronize to the peer, subject to the configuration elements supported by HA synchronization.

Reserved management access is strongly recommended. It provides separate administrative access to each physical unit for diagnostics, firmware work, and post-failover investigation. Without it, a technician may have limited visibility into the standby firewall precisely when that visibility is needed.

Session Pickup and Failover Behavior

Session pickup can synchronize active session state between cluster members. When enabled, it improves the likelihood that established traffic sessions continue through a failover. This can be valuable for VPN sessions, voice calls, file transfers, and business applications that react poorly to connection resets.

There is a trade-off. Session synchronization consumes resources and may not be necessary for every environment. Some businesses can tolerate a brief reconnection to cloud applications, while others cannot tolerate dropped calls or interrupted transactions. The right setting depends on the application mix and the operational impact of a short interruption.

Monitoring interfaces is equally important. A FortiGate can remain powered on while losing access to a critical WAN or LAN path. By monitoring selected interfaces, the cluster can fail over when the active unit loses connectivity that indicates it can no longer serve the network correctly. Interface monitoring must be designed carefully, however. Monitoring an unstable or noncritical link can cause unnecessary failovers.

Test the Failure You Designed For

An HA deployment is not complete when the dashboard shows two healthy members. It is complete when tested failover behavior meets the organization’s requirements.

During an approved maintenance window, test a controlled failover and observe internet traffic, DNS resolution, VPN connectivity, VoIP calls, payment terminals, Wi-Fi authentication, critical cloud services, and remote access. Record how long the transition takes and identify which applications reconnect automatically.

Then test more than a simple power-off event. Validate a monitored WAN-path failure, verify that switch uplinks remain available, and confirm that the intended primary unit resumes service after restoration if automatic failback is enabled. Automatic failback is not always desirable. Some teams prefer the current active unit to remain active until a technician confirms the original fault is resolved.

Keep the test results with the network documentation. They create a practical baseline for future troubleshooting, audits, insurance reviews, and infrastructure changes.

Ongoing Operations Matter More Than the Initial Build

FortiGate HA needs lifecycle management. Firmware updates must be planned for the cluster, tested against the organization’s feature set, and performed using a documented upgrade sequence. A rushed update can create more downtime than the HA pair was intended to prevent.

Review cluster health, synchronization status, resource consumption, interface errors, and event logs on a regular schedule. FortiAnalyzer can provide useful visibility into security events and operational trends, while FortiManager can help standardize configuration management in organizations with multiple sites. Configuration backups should be verified, retained securely, and available without relying on the firewall itself.

Policy hygiene is also part of availability. Overly broad rules, forgotten temporary access, stale VPN objects, and undocumented routing changes can cause a service interruption that hardware redundancy cannot solve. Change control does not need to be bureaucratic, but every firewall change should have an owner, a reason, and a rollback path.

For South Florida businesses with limited internal IT resources, a managed support arrangement can provide the operational discipline that HA requires: health checks, firmware planning, backup verification, policy updates, and timely escalation when the cluster reports a problem. Kamanel Consulting approaches FortiGate HA as part of the broader network - including switching, wireless, VLAN segmentation, WAN resilience, and ongoing support.

The best time to evaluate FortiGate high availability is before a firewall failure forces the decision. Start with the business services that cannot stop, then design the firewall, switching, WAN, power, and support model around keeping those services available.