Fortinet HA Cluster Firmware Upgrade (Active & Passive)

This KB describes a safe, controlled method to upgrade firmware on a Fortinet HA cluster with minimal disruption. It covers pre‑checks, change planning, GUI/CLI procedures, expected HA behavior (including Override and Device Priority), validation, and rollback. Examples reference FortiADC/FortiGate style navigation—adjust names to your product/GUI version.

Home > Enterprise security devices or applications > Fortigate firewall > Fortinet HA Cluster Firmware Upgrade (Active–Passive)

Change Overview

1. Goal: Upgrade firmware from Current → Target version following the upgrade path.
2. Expected Impact: Single failover event during upgrade; optional second failover depending on Override.
3. Change Window:
   1. 30–60 min
   2. Low‑traffic hours
4. Backout Plan: Restore previous firmware/config on both nodes; re‑elect preferred primary.

Pre‑Upgrade Preparation (Do Not Skip)

1. Readiness & Compatibility

1. Read release notes for the target version (breaking changes, default changes, special steps).
2. Follow the upgrade path (intermediate hops if required).
3. Confirm model compatibility and any HA cluster prerequisites for your platform/version.

2. Backups & Access

1. Full configuration backups of each node (download and store off‑box).
2. Boot/firmware image files: download all intermediate & target images in advance.
3. Out‑of‑band access ready (console or iDRAC/ILO/serial) in case of control‑plane loss.

3. HA Health Baseline

1. Both nodes online and synchronized; no HA alarms.
2. Monitored interfaces/ports are UP to avoid unintended failover during upgrade.
3. Session pickup (if used) enabled and tested.
4. Override/priority setting noted (this affects post‑upgrade role).
5. Traffic baseline captured (CPU/Memory/Throughput/Log rates) for comparison.

1. Steps involved in Firmware Upgrade (GUI)

Menus differ slightly by product/firmware. Use your platform’s equivalent.

FortiADC‑style navigation

1. Log in to the Active node as admin.
2. Go to System → Settings → Maintenance.
3. Click Upgrade Firmware (or Upgrade section → Choose File).
4. Select the intermediate/target firmware image file.
5. Enable “HA cluster upgrade/HA sync” (distributes the image to passive nodes).
6. Click Upload/Upgrade and confirm.

FortiGate‑style navigation (typical)

1. Log in to active firewall → System → Firmware.
2. Choose Upload Firmware (from local) or Upgrade (from FortiGuard/Manager).
3. If presented, select Upgrade HA cluster.
4. Confirm and monitor progress.

Detailed Upgrade Workflow (What Actually Happens)

1. Active node distributes the firmware image to Passive node(s).
2. Active instructs Passive to upgrade first; Active continues forwarding user traffic.
3. Passive upgrades & reboots → returns UP and reports success to Active.
4. After all passives are upgraded, the Active begins its own upgrade and reboots.
5. During the Active reboot, failover occurs → one upgraded Passive becomes Active.
6. Traffic is redirected to the new Active. After the original node returns, the final roles depend on Override (see below).

1. Post‑Upgrade HA Role Logic: Override vs Uptime
2. Override = Enabled
   1. The cluster prefers the unit with the higher Device Priority to be Active.
   2. Expect a second failover (failback) after the original preferred primary finishes rebooting.
3. Override = Disabled
   1. The cluster prefers the unit with longer uptime to be Active (to avoid churn).
   2. Usually no second failover; the newly active node stays primary until next event.

Planning tip: If you want to avoid a second failover, temporarily disable Override before the change (note the original state), then re‑enable later if desired.

Command‑Line Aids (FortiGate examples)

1.Check HA & Sync

get sys ha status
get sys ha stat.................#summary
get sys ha checksum.............#configs in sync?

2. Validate health

get system performance status..............# CPU/Memory/Session counts
exec ping <gateway/IP>

3. Manage Override/Priority

config system ha
    set override enable|disable
    set priority <1-255>..................# higher wins when override enabled
end

4. Optional: Reset uptime bias (to influence election)

diag sys ha reset-uptime

5. Confirm firmware & member roles

get system status.............#Firmware version/build
get sys ha status.............#Which unit is Master/Slave (Primary/Secondary)

End‑to‑End Procedure (Runbook Checklist)

Phase A — Pre‑Checks (15–20 min)

1. Capture screenshots/outputs of HA status & versions on both nodes.
2. Verify both nodes reachable over management and HA links.
3. Confirm monitored interfaces UP; disable port‑monitoring temporarily only if justified.
4. Backups: configs of both nodes + export current boot image details.
5. Confirm OOB/console access tested.
6. Agree on failover expectations (Override on/off) and communicate potential double‑flip.

Phase B — Upgrade (per hop if intermediate versions required)

1. On current Active, open Firmware/Upgrade page.
2. Select image (intermediate, then final) → Enable HA cluster upgrade/HA sync.
3. Start upgrade → Observe sequence: Passive first, then Active.
4. During Active reboot, confirm traffic continuity through the new Active.

Phase C — Validation (post‑hop)

1. Check firmware version/build on both nodes.
2. Verify HA state (roles as planned) and config sync.
3. Run functional tests:
   1. Internet/NAT, key VPNs, VIPs/Load‑balancer services, critical apps.
   2. Security services (IPS/AV/SSL inspection) and log forwarding.
4. Monitor for CPU/memory/packet loss anomalies for ≥10 minutes.
5. If more hops required, repeat Phase B/C.

Phase D — Post‑Change

1. Restore Override to original setting (if you changed it).
2. Re‑enable any temporarily disabled monitoring.
3. Update change record with outcomes and attach backups/screens.

Rollback Plan (If Things Go Sideways)

1. Use out‑of‑band/console to boot prior firmware (if dual image supported) or restore previous image.
2. Revert configuration from backups (node‑specific where applicable).
3. If cluster is split‑brain or down:
   1. Isolate a single node, recover it to last good state, then rejoin the peer.
   2. Verify HA links and restore synchronization.
4. Keep Override disabled during recovery to minimize flapping; re‑enable after stability is confirmed.

Validation Checklist

1. Both nodes upgraded to Target build.
2. HA state healthy; roles as planned.
3. Configs in sync.
4. Traffic flows OK (NAT/VPN/VIPs/Services).
5. Security services running (IPS/AV/SSL/Certificates).
6. Logs visible in SIEM/Wazuh; no duplication.
7. CPU/Memory within baseline.
8. Stakeholders sign‑off received.

Conclusion Upgrading firmware on a Fortinet HA cluster is a controlled process when proper preparation, backups, and HA health checks are completed beforehand. By upgrading passive members first, the cluster minimizes disruption, ensuring user traffic remains available throughout most of the change. The final HA roles after the upgrade depend on whether Override is enabled or disabled, which determines if a second failover occurs. With thorough validation and rollback readiness, the upgrade can be executed with minimal risk and predictable outcomes.

Home > Enterprise security devices or applications > Fortigate firewall > Fortinet HA Cluster Firmware Upgrade (Active–Passive)