A firewall failure at 10:30 a.m. can stop cloud applications, branch connectivity, internet access, and remote work at the same time. This FortiGate HA deployment guide focuses on preventing that single-device failure from becoming an operational outage, while keeping the design realistic for the way your business actually uses its network.
High availability, or HA, is not simply two firewalls connected together. It is a planned system of matched hardware, synchronized configuration, monitored links, controlled failover, and regular testing. Done properly, it gives your organization a standby FortiGate that can take over when the primary unit, a critical interface, or a monitored network path fails.
Start With the Right HA Design
For most businesses, an active-passive FortiGate cluster is the practical starting point. One appliance actively processes traffic while the secondary unit stays synchronized and ready to assume the role if the primary device fails. This approach is easier to manage than active-active HA and avoids introducing load-sharing decisions that may not suit every application or internet setup.
Active-active HA can be appropriate for organizations with higher throughput demands and teams experienced in diagnosing asymmetric traffic and session distribution. It should not be selected just because two appliances are available. The correct choice depends on traffic volume, application behavior, WAN architecture, and the internal team’s ability to support the environment after deployment.
Before purchasing hardware, size each FortiGate as though it will carry the full production load on its own. HA protects availability, but it does not turn two undersized firewalls into a properly sized security platform. Account for enabled security services such as IPS, antivirus, web filtering, SSL inspection, VPN users, site-to-site tunnels, and expected growth over the appliance lifecycle.
Use Matched and Supported Components
Both FortiGate appliances should be the same model and run the same supported FortiOS version and build. They should have compatible licenses and subscriptions, matching interface layouts, and sufficient ports for production, management, heartbeat, and redundant uplinks where required. Mixing models or firmware builds creates unnecessary deployment risk and can prevent stable cluster formation.
Use genuine Fortinet appliances and valid licenses from the beginning. Unsupported or questionable hardware can complicate firmware updates, security subscription renewals, and vendor support at the exact time your business needs help. This is especially relevant when HA is being deployed to reduce outage exposure.
The cluster also needs two dedicated heartbeat connections between the firewalls. Directly connected ports are usually preferred. These links carry HA status and configuration synchronization, so they should not be treated as spare production interfaces. If one heartbeat link fails, the second connection helps maintain cluster communication and reduces the chance of an unintended split-brain condition, where both units believe they should be active.
FortiGate HA Deployment Guide: Prepare Before Configuration
A successful HA deployment starts with a written network plan. Identify every connection that must remain available: internet circuits, LAN trunks, DMZ segments, VPN paths, management access, routing adjacencies, and connections to switches or wireless infrastructure. Document interface names, VLANs, IP addresses, gateways, and whether each link is physically redundant beyond the firewall itself.
For example, two FortiGates connected to a single access switch still leave the switch as a possible point of failure. A cluster protects the firewall layer, not every device around it. If continuity is the goal, consider redundant switch paths, dual WAN connections, redundant power supplies, and separate power sources where the business impact justifies the cost.
Back up the existing FortiGate configuration before making changes. Record the current firmware version, routing table, VPN settings, security policies, certificates, administrator access methods, and license status. A backup is valuable, but it is not a substitute for a rollback plan. Your team should know who will approve a change reversal, how remote users will be informed, and how long the maintenance window can safely run.
Decide how management will work after HA is enabled. The cluster uses a shared operational identity for normal administration, but each physical appliance should also have its own reserved management address. Individual management access is useful for troubleshooting a member, reviewing hardware status, and recovering from unusual cluster issues. Restrict these addresses to authorized administrators and a dedicated management network whenever possible.
Configure the Cluster Carefully
Configure the initial HA settings during an approved change window. The exact menu labels and commands vary by FortiOS release, but the core values must match on both devices: HA mode, group name, group ID, authentication password, heartbeat interfaces, and monitored interfaces. A small mismatch can stop the appliances from joining the same cluster.
Begin with the intended primary unit. Apply the HA settings, connect the heartbeat links, and then apply the same cluster values to the secondary unit. Once the members discover each other, the primary appliance normally synchronizes the configuration to the secondary member. Avoid manually changing production policies on both devices while synchronization is underway.
Use interface monitoring with care. Monitoring tells FortiGate to trigger failover if a vital interface fails, even when the firewall itself remains powered on. WAN and key LAN connections are common choices, but monitor only links whose failure should genuinely cause the active member to step aside. Monitoring every interface can create unnecessary failovers from a minor or nonessential link event.
Enable session pickup when minimizing disruption to established sessions is a priority. Session synchronization can help preserve traffic during a failover, which matters for voice calls, remote desktop sessions, long-running application connections, and VPN users. It also adds processing and synchronization overhead. In smaller environments, the trade-off may be reasonable; in high-throughput deployments, validate the effect against actual traffic patterns.
Decide whether the original primary firewall should automatically reclaim the active role after it returns. Automatic preemption can restore the preferred design quickly, but it creates another failover event. Many businesses leave preemption disabled so the recovered unit stays passive until a planned maintenance window. There is no universal setting here. The best choice is the one that matches your outage tolerance and operating procedures.
Test Failover Before Calling the Work Complete
A green cluster status is not proof that HA will protect business traffic. Testing is the step that reveals missing routes, unmonitored uplinks, switch configuration problems, VPN behavior, and applications that do not recover as expected.
Start with a controlled test from several locations. Confirm that users can browse approved websites, access internal applications, establish VPN sessions, resolve DNS, and reach cloud services. Then simulate a failure by disconnecting the active FortiGate from power or by disabling a planned monitored interface. Observe which member becomes active, how long traffic interruption lasts, and whether critical services reconnect without manual intervention.
Test both device failure and link failure. These are different events. A firewall may remain healthy while its WAN circuit, LAN trunk, or upstream switch path has failed. Verify that interface monitoring causes the intended response and does not trigger a cluster takeover for a link that should be handled elsewhere in the network.
After each test, review cluster logs, event timestamps, interface status, routing behavior, VPN tunnel status, and user reports. Document the actual results rather than assuming the design behaved as planned. If a business-critical application takes several minutes to reconnect, that may be acceptable, or it may require an application-side adjustment, a different timeout, or a revised HA strategy.
Operate HA as an Ongoing Security Service
HA needs maintenance after deployment. Keep both appliances on the same approved FortiOS release, schedule firmware updates with a tested procedure, and confirm synchronization before and after each change. A cluster reduces downtime during maintenance, but careless upgrades can still interrupt service.
Review health alerts and cluster events regularly. Repeated heartbeat warnings, configuration synchronization failures, high resource use, failing power supplies, or unstable interfaces should be investigated early. Waiting until the primary appliance fails turns a manageable issue into a high-pressure incident.
Your support plan should also cover licensing renewals, replacement hardware, configuration backups, and escalation contacts. When subscriptions expire, the firewall may continue passing traffic, but security inspection and threat intelligence can be reduced. Availability without current protection is not the outcome most organizations want.
For UAE businesses that need assistance with model selection, deployment planning, testing, and post-installation support, Digital World Technology can help align FortiGate HA with the real network and budget rather than applying a one-size-fits-all design.
The most useful final test is simple: ask whether your team can explain what will fail over, what will not, and who will respond at any hour. When those answers are documented and tested, HA becomes a practical safeguard for business continuity instead of a feature left waiting for an emergency.