Skip to main content
MarcoAlbano
Explorer
June 17, 2026
Question

Best Strategy for Upgrading a Mixed FortiGate Environment (40F, 60E, and 70F) – Looking for Community Experience

  • June 17, 2026
  • 3 replies
  • 139 views

Hello everyone,

I'm planning a maintenance window to upgrade the FortiGate firewalls in our environment, and I'd like to hear from those who have gone through a similar scenario.

I've already completed an inventory of all devices, reviewed the Fortinet recommended firmware versions, and validated every upgrade path using the Fortinet Upgrade Path Tool. At this point, my questions are more about strategy than technical execution.

Our current environment is as follows:

Hostname Model Current Firmware Target Firmware
FGT-HQ 70F 7.4.3 7.4.12
FGT-BR01 60E 7.4.3 7.4.12
FGT-BR02 60E 7.4.7 7.4.12
FGT-BR03 40F 7.4.11 7.4.12
FGT-BR04 40F 7.6.1 7.6.7
FGT-BR05 40F 7.6.6 7.6.7
FGT-BR06 40F 7.2.11 7.2.13 (or migrate to a newer branch)

Additional information:

  • Production environment.
  • We use IPsec Site-to-Site VPNs, SD-WAN, security policies, NAT, VIPs, and SSL VPN.
  • A full configuration backup will be taken before every upgrade.
  • All firmware upgrades will strictly follow the paths recommended by the Fortinet Upgrade Path Tool, including every intermediate version.
  • Each upgrade step will be fully validated before proceeding to the next one.

One important point is that our FortiGate 60E units will be replaced by FortiGate 40G appliances in the coming months. Because of that, I'm trying to determine the best long-term strategy.

In your opinion, which approach would make the most sense?

  1. Upgrade each device only to the latest Mature release within its current branch (7.4.12 and 7.6.7) and keep it there until the hardware replacement.
  2. Take this opportunity to migrate the entire environment to the 7.6 branch for better standardization.
  3. Keep the 60E units on the 7.4 branch until they are replaced by the 40G models, while maintaining the newer 40F units on the 7.6 branch.

I'd also appreciate your thoughts on the following:

  • Have you experienced any significant issues running FortiOS 7.6.7 in production?
  • Do you still consider FortiOS 7.4.12 a solid choice for enterprise environments?
  • If you were in my situation, would you migrate the 60E units to a newer branch, or simply keep them on a stable release until they are replaced?
  • Are there any lessons learned or best practices you would recommend before starting this upgrade project?

Any real-world experience or recommendations would be greatly appreciated.

Thank you in advance!

    3 replies

    christian_89_
    Explorer II
    June 17, 2026

    Solid prep work. Two things in your stated targets will bite you, and the branch decision is partly made for you by hardware lifecycle and feature removals rather than preference.

    Landmine 1, and it sits right in your 7.4 target: the FortiGuard DoT/853 bug. There is a known issue where the FortiGuard default DNS servers (96.45.45.45 / 96.45.46.46) become unreachable when the FortiGate uses DNS over TLS on TCP/853, which is the default. It is tracked as bug ID 1298350 and affects exactly v7.4.10, v7.4.11 and v7.4.12. The root cause is that the FortiGate trust store is missing the DigiCert High Assurance EV Root CA that the certificate chain for globalsdns.fortinet.net is signed with, so the DoT hostname verification fails and DNS resolution stops. When it hits, you lose name resolution, web filtering and FortiGuard Cloud reporting, not just DNS.

    Why this matters for you specifically: your 7.4 target is 7.4.12, so upgrading FGT-HQ, BR01 and BR02 from 7.4.3 / 7.4.7 to 7.4.12 walks them straight into the affected range, and BR03 on 7.4.11 is potentially already exposed. Upgrading to FortiOS 7.6.7 has been reported to resolve it, and the documented workarounds for anything staying on 7.4.x are to import the DigiCert CA certificate, switch to a custom DNS provider, or disable the DoT server-hostname check. So for every box you land on 7.4.12, apply the DigiCert CA fix in the same maintenance window or you risk a DNS outage right after the upgrade. Boll

    Landmine 2, bigger than it looks given you use SSL VPN: tunnel mode is gone on 7.6. Starting in FortiOS 7.6.3, SSL VPN tunnel mode is no longer available in GUI or CLI, the settings are not upgraded from previous versions, this applies to all models, and you must migrate SSL VPN tunnel mode to IPsec VPN before upgrading to 7.6.3 or later. Every 40F you push to 7.6.7 loses SSL VPN tunnel mode. BR05 is already on 7.6.6, so if that site used SSL VPN it is already gone, confirm it is on IPsec. Migrate those users to IPsec dial-up (IKEv2) first, then upgrade. 

    2 GB RAM caveat: the 40F is a 2 GB model. On 7.6.x the 2 GB RAM models no longer support most proxy-related features, nor Security Rating and Security Fabric topology. If any 40F site runs proxy-based inspection, plan the move to flow mode before the jump. 

    On the strategy itself: your option 3 is the correct skeleton, not option 2. Do not migrate the 60E to 7.6. It is being replaced by 40G shortly, and verify it against the 7.6.7 supported-models list before you even consider it, since older E-series models have been dropped from 7.6. Spending migration risk on a device that is leaving is wasted effort. Refined targets:

    • FGT-HQ 70F: 7.4.12, plus the DigiCert CA fix. Staying on 7.4 also keeps SSL VPN available at HQ.
    • BR01 / BR02 60E: 7.4.12, plus the DigiCert CA fix, until the 40G swap. No branch migration.
    • BR03 40F: keep on 7.4.12 (keeps SSL VPN, needs the CA fix) or align it to 7.6.7 with the rest of the 40F fleet, but only after the SSL-VPN-to-IPsec migration.
    • BR04 / BR05 40F: 7.6.7. The DoT bug is already resolved there. Confirm IPsec is in place.
    • BR06 40F: bring it up to 7.6.7 for fleet uniformity rather than parking it on 7.2.13, again after SSL-VPN-to-IPsec. 7.2.13 is just a dead-end holding pattern.

    End state is two standards, 7.4.12 where SSL VPN must stay or hardware is leaving, 7.6.7 on the 40F fleet once it is off SSL VPN. That is justified by hardware and feature removal, not a failure to standardize.

    Direct answers to your questions:

    • 7.6.7 in production: stable, late patch, and it fixes the DoT/853 issue. The real gotchas are feature removals, not stability, namely SSL VPN tunnel mode and 2 GB proxy features.
    • Is 7.4.12 still solid for enterprise: mature, yes, but it ships bug 1298350. It is only safe if you apply the DigiCert CA fix or move off FortiGuard DoT.
    • Migrate the 60E or wait: wait. Keep it on 7.4.12 with the CA fix until the 40G replaces it.
    • Lessons / best practices: sequence the work as (1) migrate SSL VPN to IPsec, (2) apply the DoT/853 CA fix, (3) firmware, never the reverse. Keep out-of-band or console access for the remote 40F sites so a bad step does not strand a branch. If you manage these with FortiManager, upgrade FMG first, and note that FortiManager 7.6.5 and 7.6.6 have a documented install-fail against 2 GB RAM models running 7.4.10 and 7.4.11, which is exactly your 40F and 60E population. Validate IPsec phase1/phase2, SD-WAN rules and VIPs after each step, and reboot the 2 GB units once after upgrade.
    CFR_
    MarcoAlbano
    Explorer
    June 17, 2026

    Regarding the DNS over TLS issue, is there a reliable way to verify whether our firewalls are actually using the affected FortiGuard DNS over TLS configuration before the upgrade?

    If they are, would you recommend:

    • importing the DigiCert High Assurance EV Root CA certificate,
    • disabling FortiGuard DNS over TLS,
    • switching to custom DNS servers,
    • or simply moving those firewalls to FortiOS 7.6.7?

    I'd like to follow the approach that is considered the best practice for production environments.

    Thank you again for taking the time to share your experience and recommendations. They have been extremely valuable in helping us plan this upgrade.

    MarcoAlbano
    Explorer
    June 17, 2026

    Thank you for the detailed explanation.

    I checked our environment and confirmed that we do not use SSL VPN.

    All of our firewalls use IPsec Site-to-Site VPNs, and only BR05 also provides IPsec Dial-up VPN (FortiClient) for remote users. In other words, we are not using SSL VPN Tunnel Mode anywhere in our environment.

    Based on that, I believe the removal of SSL VPN Tunnel Mode in FortiOS 7.6.3 and later does not affect our deployment.

    That makes Bug ID 1298350 my primary concern for the firewalls that will remain on FortiOS 7.4.12.

    In your opinion, would you recommend proactively applying the DigiCert High Assurance EV Root CA workaround on every firewall that will remain on FortiOS 7.4.12, or would you recommend migrating those firewalls to FortiOS 7.6.7 instead?

    Thank you again for taking the time to share your experience and recommendations. They have been extremely valuable in helping us plan this upgrade.

    christian_89_
    Explorer II
    June 17, 2026

    To your direct question: migrate to 7.6.7 rather than babysitting the CA workaround, on every box where the hardware can run it. Keep the DigiCert workaround only for the 60E, which cannot run 7.6 and are being retired anyway. And the point that settles your hesitation: 7.6.7 is Fortinet's current recommended release for these platforms, so you are not betting on a fresh build, you are moving to the version Fortinet itself points you at. You can confirm the recommended flag in the support portal and in the Upgrade Path Tool.

    Per device:

    • FGT-HQ 70F: go to 7.6.7. The 70F has about 3.7 GB of RAM, so it is not a 2 GB model and the 2 GB proxy-feature limitation does not touch it. With SSL VPN confirmed unused, nothing keeps it on 7.4. The DoT/853 bug is fixed natively, so your hub carries no workaround.
    • BR03 / BR04 / BR05 / BR06 40F: all to 7.6.7. These are 2 GB, so keep them flow-based, which they already are with pure IPsec. BR05's IPsec dial-up (FortiClient, IKEv2) is fully supported on 7.6.x, no action needed there.
    • BR01 / BR02 60E: the only candidates for the CA workaround, because they cannot run 7.6 and are leaving. But they sit on 7.4.3 and 7.4.7 today, which are below the affected 7.4.10 to 7.4.12 range, so 1298350 does not hit them as they stand. If the replacement is weeks away and no CVE forces your hand, the cleanest move is to leave them on their current build and not upgrade them at all. If you must take them to 7.4.12 for a security reason, apply the DigiCert CA fix or point them at a trusted non-DoT resolver in the same window.

    Why migrate instead of carrying the workaround:

    • The CA import is operational debt. It is a manual per-device band-aid in the trust store that survives only until a config restore, factory reset or RMA, after which someone has to remember to reapply it. It hides a known-defective build instead of removing the defect.
    • 7.6.7 fixes the root cause and is the recommended release, so you drop the workaround entirely and align with the version Fortinet supports best.
    • It gives you the standardization you wanted from the start. Once the 60E are replaced, the whole fleet sits on one version, one validation surface, one patch cadence.

    Side note on the replacement hardware: there is no FortiGate 40G. The G-series entry models are 30G, 50G, 70G, 90G and 120G. Worth confirming which one is actually on the order as the 60E successor, since the 50G and 70G differ in throughput and the 50G carries its own feature constraints. It changes nothing above, but you want the correct SKU on the PO.

    Validate IPsec phase1/phase2 and the BR05 dial-up after each step, as usual.

    CFR_
    MarcoAlbano
    Explorer
    June 17, 2026

    Thank you for pointing that out. You're absolutely right—I meant the FortiGate 50G, not the 40G. The 60E units are planned to be replaced with FortiGate 50G appliances in the coming months. Thanks for catching that.

    Toshi_Esumi
    SuperUser
    SuperUser
    June 17, 2026

    We haven’t upgraded any of our FGTs to 7.6.x yet. But one thing for sure is SSL VPN is no longer available with 7.6. And any G-series FGT won’t support SSL VPN.

    Toshi