Skip to main content
M
MohammedAlrawiii
Explorer
June 8, 2026
Solved

fortiweb update active active firmware update

  • June 8, 2026
  • 3 replies
  • 122 views

Hello everybody,

I hope you all doing well,

I have some question for Forti web a-a setup as this is my first time updating I did my research and found that both nodes will be updated at the same time and there will be down time so is there any way like splitting the HA connection and try to update one of them then swap the traffic or am taking to much risk ? 
the upgrade path will be from 7.4.8->7.6.2->7.6.7
what is the best way to prepare for such kind of operations I have previously worked with FortiGate's but only in Active-Passive clusters.

Please advise as this is my first time trying to prepare for this Forti Web updates.
Also have anyone tried 7.6.7 in production env ? it seems for me the most stable one and has no CVEs or known issues.

Thank you in advance.

Best answer by sjoshi

Hi ​@MohammedAlrawiii 

Even if it is active active one of them is primary and rest of the devices on the cluster is secondary and upgrade will not happen at the same time. First secondary devices will get upgraded then only the primary.
After the standby appliance reboots and indicates via the HA heartbeat that it is up again, the primary appliance will begin to update its own firmware. During that time, the standby appliance will temporarily become active and process your network’s traffic. After the original appliance reboots, it indicates via the HA heartbeat that it is up again. Which appliance will assume the active role of traffic processing depends on your configuration (see How HA chooses the active appliance):

If FortiWeb high availability (HA) is enabled, the cluster will consider your FortiWeb high availability (HA) setting. Therefore both appliances usually make a second failover in order to resume their original roles.
If FortiWeb high availability (HA) is disabled, the cluster will consider uptime first. The original primary appliance will have a smaller uptime due to the order of reboots during the firmware upgrade. Therefore it will not resume its active role; instead, the standby will remain the new primary appliance. A second failover will not occur.

Refer:How HA chooses the active appliance
https://docs.fortinet.com/document/fortiweb/8.0.5/administration-guide/551871/ha-heartbeat-active-node-election#concepts_1292349118_1717796

3 replies

christian_89_
christian_89_
Explorer II
June 8, 2026

FortiWeb does not upgrade both nodes at the same time. The HA cluster upgrade is orchestrated. On any FortiWeb HA cluster running 4.0 MR4 or later, the upgrade is streamlined: you upgrade the active appliance and it automatically upgrades the standby as well, with no manual intervention required. The sequence is rolling, not simultaneous: the standby reboots and updates first, signals via the HA heartbeat that it is back up, and only then does the primary update its own firmware while the standby temporarily becomes active and carries the traffic; after the original primary reboots, roles resume per the HA configuration. So the both-nodes-down outage they're afraid of is not what happens if they use the built-in HA upgrade.

Therefore do not hand-roll the split-and-swap. That's the more dangerous path, not the safer one. Manually breaking a FortiWeb HA pair that shares VIPs and then running one node on 7.4 and one on 7.6 invites IP conflicts while they're split and config-sync corruption when they rejoin, because the config schema differs across majors. The "first HA upgrade and I took both nodes down" horror stories are exactly what happens when people manually manage a sequence the box would have done correctly on its own. Let the cluster orchestrate it.

One honest caveat for Active-Active specifically: "streamlined" is not "zero impact." In A-A both nodes actively proxy, and WAF connection state is not stateful-synced the way FortiGate sessions are, so the node being rebooted drops its in-flight connections. Clients reconnect, but expect resets, not a seamless FortiGate-style failover. Still do this in a maintenance window. Coming from FortiGate A-P, that's the main mental adjustment: FortiWeb HA is its own mechanism, not FGCP.

On the upgrade path, verify it, don't trust the forum. 7.4.8 to 7.6.2 to 7.6.7 may be roughly right, but confirm it against the official Fortinet Upgrade Path Tool for your exact model before you touch anything. The validated hops change per version and per model, and that tool is the only authoritative source. Note also that 7.6.8 and the 8.0.x line already exist, so 7.6.7 is not the latest 7.6 patch.

The "7.6.7 has no CVEs or known issues" reasoning is not safe. Every FortiWeb release ships with a Known Issues section, 7.6.7 included, and "no CVEs" conflates PSIRT security advisories with release-notes bugs. Pick the target from Fortinet's recommended/mature release guidance and the current PSIRT advisories, not from a feeling about stability. If the goal is the most-patched 7.6, 7.6.8 is already out.

Concrete prep, pulled from the release notes:

  • Read the release notes for every hop, not just the final target.
  • Full config backup before you start. And because of a known issue where backups taken with private-encryption-key enabled on pre-7.6.3 versions may not restore after upgrade, take a fresh backup after you land on the new version.
  • After each major upgrade, check the database status. If it shows Not Available, run execute db rebuild; in HA, running that on the primary takes effect on all secondaries at once.
  • Expect a 30 to 60 minute delay before new logs appear in the GUI after upgrading, due to the log version migration.
  • Re-enable bot and API protection features that the upgrade disables, including ML-based detection, malicious bots, known good bots, mobile API protection, and API management.
  • Confirm FortiCare/licensing is valid, and keep console access to both nodes during the window in case the orchestration stalls mid-sequence.

Bottom line for a first-timer: use the built-in HA cluster upgrade from the primary, don't split anything by hand, confirm the path in the upgrade tool, and treat 7.6.7 as a candidate to verify against PSIRT and the known-issues list rather than a known-safe target.

CFR_
    M
    MohammedAlrawiiiAuthor
    Explorer
    June 9, 2026

    Hi Christian,

    I really want to thank you for your response I appreciate it.

    I understand the idea of not splitting and will not be going to that plan as for the other stuff I did read on Fortinet Documentation regarding Active-Active cluster (as we are currently operating) in my search I only find the following and quote “ The standby appliance will upgrade its firmware first… After the standby appliance reboots and indicates via the HA heartbeat that it is up again, the primary appliance will begin to update its own firmware. During that time, the standby appliance will temporarily become active and process your network's traffic” also “ When you upgrade the active appliance, it automatically upgrades any standby appliance(s), too; no manual intervention is required”

    So there is no information about updating active active I understand the difference from streamlined and stateful-synced but nobody explained the behavior when updating active active will both nodes reboot at the same time so that i can plan my maintenance window.
    as for your other point regarding Fortinet upgrade path tool it doesn’t contain Forti Web only FortiGate , analyzer , manager. (https://docs.fortinet.com/upgrade-tool/fortigate) but I checked from fortiweb GUI.
    as for the firmware that I choose yes both 7.6.7 , 7.6.8 both have no CVEs but I found known issues in 7.6.7 (https://docs.fortinet.com/document/fortiweb/7.6.7/release-notes/54989/known-issues) as for 7.6.8 ( https://docs.fortinet.com/document/fortiweb/7.6.8/release-notes/54989/known-issues).
    my current firmware is 7.4.8 and my appliance is 600F.
    and many thanks for your response it really helps.

    Have a good day.
     

     

    sjoshi
    Staff
    sjoshi
    Staff
    June 9, 2026

    Hi ​@MohammedAlrawiii 

    Based on your upgrade path, both device will not be upgraded at the same time. Secondary device will get upgraded first and then it upgrade the primary device.

    You can refer below article:

    https://docs.fortinet.com/document/fortiweb/8.0.5/administration-guide/172532/updating-the-firmware

    Thanks, Salon
      M
      MohammedAlrawiiiAuthor
      Explorer
      June 9, 2026

      Hello Sjoshi,
      just to confirm this from the documents it says “The primary appliance will transmit the firmware file to the standby appliance over its HA link. The standby appliance will upgrade its firmware first... After the standby appliance reboots and indicates via the HA heartbeat that it is up again, the primary appliance will begin to update its own firmware” 
      my setup is Active-Active no stand by cluster the documents isn’t really clear about the description are they describing both clusters upgrade behavior here ? so from my understanding is 
      7.4.8 (active 2 will upgrade to 7.6.2 ) → (active 1 will upgrade then to 7.6.2) device will reboot and active 2 will take traffic 
      after upgrading both devices to 7.6.2 they will also update the active 2 to 7.6.7 then reboot → active 1 will reboot after active 1 take traffic 
      am getting things correct here ? 

      and thank you for your response I really appreciate it 

      M
      MohammedAlrawiiiAuthor
      Explorer
      June 11, 2026

      Dear Sjoshi & funkylicious,

      Thank you for the explanation appreciate your support.

        Terms & ConditionsAccessibility statement