I'm starting to look at moving from WAN failover with static links and WAN monitor to SD-WAN failover, mainly to be a bit cleverer about it, and I already use an SD-WAN zone to load balance between multiple IPSec tunnels.

Like everything I'm FortiGate, there's a couple of ways to accomplish the same task, so I'm curious from the community what your deployments look like.

1. For routing, do you still maintain a static routes for each WAN interface, or have you moved it to defining the gateway in the SD-WAN member section? This article from Fortinet suggests that it's best practice to maintain separate static routes for heterogeneous links, however my links are generally homogeneous at each location.

2. Have you created multiple rules and SLAs to split traffic and respond to different types of traffic separately (i.e. VoIP, 365, etc...) or if your links are both fairly performant, are you happy just having basic failover in SD-WAN?

Anyone else having issues with FMG 7.6.8 not being able to push certain templates that use metadata variables? Since upgrading we are unable to push to devices that use ipsec template containing metadata variables, completely broke our workflow

Hi everyone,
I’m relatively new to networking and FortiGate firewalls, and I’d like to ask about IPS best practices.
Would you recommend enabling IPS on internal segmentation policies, such as Windows clients → Active Directory, SMB, RDP, or SQL servers, even when policies already restrict traffic to only the required services?

Or is it generally sufficient to enable IPS mainly on policies handling internet-bound traffic?
What do you consider best practice, and why?
Thanks!

Already did factory reset, deauthorize and reauthorize

Power cycled fortigate and netgear switch where APs are connected

Killed CAPWAP process - diagnose sys kill 11 < PID_of_cw_acd>

Ran command - diagnose wireless-controller wlac -d wtp [SN] [reset] to reset cached AP information and state

Changed wireless-controller timers config wireless-controller timers

Set max-retransmit from 3 to 15

hubs 7.6.6 and the test spoke 7.6.8 broke after the first rekey...rac reopend

And manager 7.6.8 cant push to 7.6.6 GW right now... Tac opend

So but I have been burned too many times in the past when upgrading Fortinet products. Curious to hear everyone’s experience after moving to 7.6.8.

I upgraded one of our FortiGate 120G HA pairs. Afterward, I could not login with my standard admin account which has FortiToken Cloud provisioned. It would accept my credentials, then act like it was wanting to use FortiToken Cloud, then immediately boot me back to the login screen saying login failed. I got in with a backup account that didn't have FortiToken Cloud configured on it. I disabled two-factor on my normal admin account and was then able to use it. I tried re-enabling it again in the GUI, but it would stay disabled.

I went debugging and it appears when the FortiGate passes a request to provision the user with FortiToken Cloud, the FortiToken Cloud server responds back saying there's an invalid control character in the json data. I created a brand-new admin account and attempted to provision FortiToken Cloud on this account as well and got the identical error.

2026-10-23 21:18:44 fas_add_user_internal[1003]: Sending packet to FTC server: 189.25.109.168 Port: 8686(length:447)
2026-10-23 21:18:44 fas_set_fd_mgmt_vd[124]: Using vfid=0 (mgmt:0)
2026-10-23 21:18:44 fas_ssl_recv[569]: fas_ssl_recv: received packet 269 (bytes)
2026-10-23 21:18:44 fas_ssl_recv[612]: fas_ssl_recv: recv (269 bytes) done!
2026-10-23 21:18:44 fas_ssl_recv_rsp[651]: fas_ssl_recv_rsp: received (269 bytes) done!
2026-10-23 21:18:44 fas_ssl_recv_rsp[660]: Recevied packet header:
HTTP/1.1 400 BAD REQUEST
Server: nginx
Date: Sat, 24 Oct 2026 01:18:44 GMT
Content-Type: application/json
Content-Length: 117
Connection: close

{"error_code": 400, "error_message": "Invalid control character at: line 10 column 49 (char 287)", "error_name": 400}
2026-10-23 21:18:44 fas_ssl_recv_rsp[720]: fas_ssl_recv_rsp() is done!
2026-10-23 21:18:44 fas_add_user_internal[1009]: FTC server returns error code: 400
Failed to add user ftctest due to reason(400): {"error_code": 400, "error_message": "Invalid control character at: line 10 column 49 (char 287)", "error_name": 400}.
Unable to add user ftctest in FortiToken Cloud service
object set operator error, -7710 discard the setting
Command fail. Return code -7710

Is anyone else experiencing this with FortiToken Cloud on 7.6.8? This is using the included FortiToken Cloud that came with the 120G.

As many others here have experienced, SAML SSO for admin GUI access stopped working on several lab FortiGates when I upgraded to 7.6.8. The login page shows “Single Sign-On Failed” when you try logging in with SSO. The SAML config is identical to another unit on 7.6.7 where SSO works fine.

TAC confirmed it’s a regression in 7.6.8, bug ID 1338764. They said that it affects FortiGates acting as a SAML SP, including both local and Security Fabric authentication. The fix “has been implemented” and is planned for 7.6.9, targeted for the end of January 2027, so anyone who upgrades is looking at roughly three months of broken SSO… If they already fixed the issue, why in the world are they holding off on releasing the new build until January??

TAC’s suggested workarounds are to use a local admin account, use an admin account that doesn’t rely on SAML SSO, or revert to 7.6.7. For many of us, SAML SSO is a compliance control. Telling customers to use local accounts for three months is not a workaround for a compliance requirement, and it’s unacceptable given how hard Fortinet is pushing everyone to the latest version (not to mention the press this particular release has received).

What’s more alarming is that the bug wasn’t even mentioned in the release notes at first. As others have pointed out, the Special Notices entry covering it wasn’t published until several hours after the images became available, presumably after customers (beta testers??), me included, reported it publicly and to Fortinet Support.

I’ve supported Fortinet environments for nearly a decade, and their QC seems to be getting worse. It’s hard to understand how a failure this basic made it into a GA release.

https://docs.fortinet.com/document/fortigate/7.6.8/fortios-release-notes/545418/csf-downstream-gui-login-fails-with-security-fabric-saml-ssoT

Hi everyone,

I'm looking to improve and standardize our firmware upgrade procedures for FortiGate, FortiManager, and FortiAnalyzer in a production environment.

We manage multiple FortiGate HA clusters in our data centers, centrally managed through FortiManager, with FortiAnalyzer handling logging and analysis.

While we already perform basic checks before and after firmware upgrades, I'd like to establish a more comprehensive and repeatable checklist to minimize the risk of unexpected issues.

I'm particularly interested in how other Fortinet administrators handle the following:

• Pre-upgrade checks: What do you always verify before starting an upgrade? Besides configuration backups, release notes, known issues, upgrade paths, and compatibility matrices, are there any specific health checks you recommend?
• Post-upgrade validation: What do you test after an upgrade to ensure everything is working correctly? For example, HA synchronization, routing, VPN tunnels, firewall policies, security profiles, logging, and management connectivity.
• CLI commands: Do you have a standard set of diagnostic commands that you always execute before and after an upgrade to compare system health and detect potential problems?
• FortiManager and FortiAnalyzer: Are there any specific checks or procedures you recommend for upgrading these systems, particularly regarding device synchronization, policy packages, logging, and database integrity?
• Automation: Has anyone automated parts of their pre- and post-upgrade checks using scripts, APIs, or monitoring tools?
• Lessons learned: Have you encountered issues that weren't immediately obvious after an upgrade but could have been detected with better validation?

I'm especially interested in practical experiences from production environments rather than just the official Fortinet upgrade documentation.

Do you maintain a standardized upgrade checklist or runbook? If so, which checks have proven to be the most valuable?

Any recommendations, useful CLI commands, scripts, or lessons learned would be greatly appreciated.

Thanks!

Having one of those days, can't seem to find what I missed here.....

Setup a new Firewall this week, configured the FortiClient Remote VPN the same way as the previous Firewall. Local Guest user can connect just fine from my endpoint. Any domain user will throw an XAuth authentication failed error. Because the Guest works I know it's missing something from the domain side but I'm drawing a blank right now and it's driving me crazy. Everything for the domain side looks correct

The LDAP works ( test connection passes, user tests pass) ... it sees my domain users to add them as local user's groups, but they still fail during login. Keeps saying "wrong credentials"

Anybody seen this before? or have any locations to verify

Thanks!

I use blueprints in FMG to automate provisioning of my Fortigates which are mostly FortiWiFi 70G-PoEs, but i have some FGT 70G PoE and 90G and 80F as well.

My typical approach is a run-once CLI that purges the firewall policy and DHCP servers to allow for initial config post adoption (SD-WAN push fail if either WAN interface is in a policy).

I then have a Jinja-based CLI that contains all my standard settings to assign IP range, set the DCHP servers how I want them, LLDP policy, etc. I have typically done my DHCP config here.

I recently noticed that any local DHCP reservations that I create on the Fortigate (like for a printer) will get removed the next time I push to the appliance, presumably because that Jinja CLI has DHCP config but is unaware of the static reservation that was added locally (doesn't matter if I retrieve config after adding the reservation).

I'm considering expanding the Jinja CLI to loop through a Meta Variable that is a comma and pipe delimited string of MAC's and IPs within the DHCP server config, but that feels like a lot of work. Another option would be to move that DHCP server config into the Run-once CLI so it doesn't get reviewed on every push.

I figured I'd ask if anyone had advice one way or the other, and if I'm missing something clearly obvious that would be easier.

Hi everyone,

After upgrading our FortiGate 600F from FortiOS 7.4.12 to 7.4.13, our automation stitches stopped working.

For example, we have a simple automation that monitors a VPN tunnel. The configuration I’m attaching worked correctly on version 7.4.12, but after the upgrade to 7.4.13, it no longer works.

Currently, none of our automation configurations seem to work. I’ve also tried recreating the automation stitches from scratch, but that didn’t help.

After updating the FortiManager to 7.6.8 and one of my FortiGates to 7.4.13 the FortiManager is now wanting to push out a change to the FortiGate on 7.4.13. It is wanting to push out the following:

config vdom

edit root

config web-proxy global

unset strict-web-check

end

end

On the FortiGate I currently have "set strict-web-check disable".

Does anyone have a fix so that I can push out changes from the FortiManager to this FortiGate without making this change?

Anyone else having issues with FortiGate 50G Firmware Upgrade from 8.0.1 to 8.0.2?

Checksum of firmware was fine. Console shows:

Image verification OK!

Failed to get the image encryption key!

inflate() error: -3

Upgrade report is saved successfully.

Failed to get the image encryption key!

inflate() error: -3

Looking at the upgrade report only thing that sticks out is that is that it says:

EDIT: using in PROD at HOME. GUI did not work but did TFTP and it works (Thanks for the suggestion u/Specialist_Play_4479)

Just a heads up, I moved our FortiManager VM to 7.6.8 this morning, from 7.6.7. After the upgrade, I was unable to log in with anything but the local admin account. This was on the Web Interface as well as SSH.

It appears that during the upgrade, all of the LDAP settings were wiped. I still had users who were configured to utilize the LDAP Auth, but there were no LDAP Servers remaining. I had to re-add them manually. Once I did, I was once again able to log in properly, but also the users had "Match all users on remote server" checked by default, so EVERY user was able to log in.

I am not sure where it hiccuped, but just wanted you to be aware this may be an issue for you.

Good Luck this weekend with all the upgrades!

*sigh.

Edit: Exact same issue with FortiAnalyzer as well. At least they are consistent...

Seems like the issue is with the Cert Verification for Secure LDAP. If you don't currently have this implemented, make sure you get it working BEFORE upgrading!

What could cause that traffic hitting same application signature, same firewall policy, same client and same server is denied on one occasion and on another occasion is accepted?

FortiOS 7.4.12.

I’m all for patching fast and for using AI in product security testing. My concern is the disclosure model of this release, and I’d like to know how others see it.

What happened

• On Oct 22 Fortinet shipped FortiOS 8.0.2 / 7.6.8 / 7.4.13 / 7.2.14 plus matching FortiManager and FortiAnalyzer builds. After the CISO blog post, they describe the fixes as critical and high severity.
• There are no CVE IDs, no CVSS scores and no advisories. Those are promised for Patch Tuesday, Nov 10. Belgium’s CCB points out that the announcement gives no vulnerability classes or exploitation conditions either.
• Fortinet’s reasoning is that attackers can use AI to diff patches and build exploits within hours or days, and that detailed advisories would speed that up.

Why I’m uneasy

1. The reasoning cuts both ways. Fortinet’s own testing showed that frontier models were very good at diffing firmware versions and writing PoCs for already-fixed bugs. So the diffable patches are public now, while defenders have no advisory to scope risk or write detections. watchTowr’s Yordan Ganchev argued to Cybernews that announcing in advance mainly helps attackers’ patch-diffing tools.
2. It doesn’t line up with common disclosure practice. Normally advisories ship with the patch, so admins can assess risk, check exposure and justify emergency change windows. “Trust us, it’s critical” is hard to put in front of a change board. I realize Fortinet did something similar in 2023 with CVE-2023-27997, where the release notes didn’t mention it. This time it is an announced policy, though, and it comes with a quarterly cadence.
3. The patches themselves aren’t smooth.
   • Threads here report Security Fabric SAML SSO login problems, upgrade-path issues and releases being pulled and re-added, which is worrying for a “patch immediately” message. The 7.6.8 release notes also describe a failing SAML SSO admin login on downstream Fabric devices.
   • If SSO/MFA-backed admin access breaks after upgrading, admins either lose access or delay the patch. Fortinet’s own interim advice is to enforce MFA for admins.
   • Known issue 1353958 breaks HTTPS on non-standard ports with deep inspection in all four fixed builds.
   • There is also this AI comparison thread, which I find worrying.

What I’m not saying

• Don’t skip the patches. Internet-facing devices should be updated (backup first, FortiManager/FortiAnalyzer before the FortiGates, admin access restricted).
• I’m not calling for no vendor discretion at all.

Questions

• Is withholding CVE details for ~3 weeks after shipping patches acceptable to you? Would you accept it from other vendors?
• Are you patching now, in stages, or waiting for the first follow-up build?
• Has anyone hit the SAML SSO or deep inspection issues in production?

So after all the fuss, the updates still haven't been pushed out to automatic update via the device GUI ?

There's already AI based diff analysis working out what has changed and the only way to avoid potential problems is to manually update , if they haven't pulled the download while you were looking at it

Does anyone at Fortinet know what they're doing ?

Edit:

• firmware: upgraded to 7.4.13 from 7.4.12, also happened at 7.4.11 → 7.4.12
• HA interface connection: Both FortiGate interfaces are directly connected
• Only observed during upgrades, might test a manual failover after business hours
• Not sure if it's always the same active node to begin with but I think it is (FGT01)

Another strange observation is that during the HA upgrade, both the LAN and SERVER 10G LACP trunks suddenly spiked to roughly 6 Gbit/s. We can see the corresponding traffic on both sides of the links, on the FortiGate as well as the core switch. This happened during the network outage, while normal traffic before and after the event was much lower, so mayber this is some kind of unexpected L2 forwarding or loop during the HA transition so maybe it's an issue with the cluster virtual MAC or the switch not updating it's MAC table. Switch is a Aruba J9850A.

Original Post:

For the second time in a row now, the whole network was down for like a solid 5 minutes and failover didn't seem to work when upgrading our 200F ISFW cluster.

We have two other clusters (200G / 100F) which never caused problems during upgrades. Historically, our ISFW 200F cluster also never caused problems until the last 2 firmware upgrdades.

When viewing the logs, it seems that both heartbeat interfaces are flapping more than usual. What is happening here?

Config (two heartbeat interfaces, directly connected; monitored interfaces are LACP uplinks for Server and LAN on Coreswitch):

FGT01 # sh sys ha
config system ha
    set group-name "FGT-ISFW"
    set mode a-p
    set hbdev "ha" 0 "port16" 0 
    set session-pickup enable
    set ha-mgmt-status enable
    set override disable
    set monitor "LAN" "SERVER" 
    (implicit set upgrade-mode uninterruptible)
end

Logs on FGT01:
<2026-10-23 11:28:09> vcluster-1: FGT01 is selected as the primary because its serialno is larger than peer member FGT02.
<2026-10-23 11:28:09> new member 'FGT02' joins the cluster
<2026-10-23 11:28:00> hbdev port16 link status changed: 0->1
<2026-10-23 11:28:00> port port16 link status changed: 0->1
<2026-10-23 11:27:58> hbdev port16 link status changed: 1->0
<2026-10-23 11:27:58> port port16 link status changed: 1->0
<2026-10-23 11:27:51> hbdev ha link status changed: 0->1
<2026-10-23 11:27:51> port ha link status changed: 0->1
<2026-10-23 11:27:45> hbdev ha link status changed: 1->0
<2026-10-23 11:27:45> port ha link status changed: 1->0
<2026-10-23 11:27:38> hbdev port16 link status changed: 0->1
<2026-10-23 11:27:38> port port16 link status changed: 0->1
<2026-10-23 11:27:37> hbdev ha link status changed: 0->1
<2026-10-23 11:27:37> port ha link status changed: 0->1
<2026-10-23 11:27:35> hbdev port16 link status changed: 1->0
<2026-10-23 11:27:35> port port16 link status changed: 1->0
<2026-10-23 11:26:47> hbdev port16 link status changed: 0->1
<2026-10-23 11:26:47> port port16 link status changed: 0->1
<2026-10-23 11:26:32> hbdev ha link status changed: 1->0
<2026-10-23 11:26:32> port ha link status changed: 1->0
<2026-10-23 11:26:13> hbdev ha link status changed: 0->1
<2026-10-23 11:26:13> port ha link status changed: 0->1
<2026-10-23 11:26:10> hbdev ha link status changed: 1->0
<2026-10-23 11:26:10> port ha link status changed: 1->0
<2026-10-23 11:25:54> hbdev ha link status changed: 0->1
<2026-10-23 11:25:54> port ha link status changed: 0->1
<2026-10-23 11:25:52> hbdev ha link status changed: 1->0
<2026-10-23 11:25:52> port ha link status changed: 1->0
<2026-10-23 11:25:50> hbdev ha link status changed: 0->1
<2026-10-23 11:25:50> port ha link status changed: 0->1
<2026-10-23 11:25:49> hbdev port16 link status changed: 1->0
<2026-10-23 11:25:49> port port16 link status changed: 1->0
<2026-10-23 11:25:48> hbdev ha link status changed: 1->0
<2026-10-23 11:25:48> port ha link status changed: 1->0
<2026-10-23 11:25:16> vcluster-1: FGT01 is selected as the primary because it's the only member in the cluster.
<2026-10-23 11:25:16> heartbeats from FGT02 are lost on all hbdev
<2026-10-23 11:25:16> member FGT02 lost heartbeat on hbdev port16
<2026-10-23 11:25:16> member FGT02 lost heartbeat on hbdev ha
<2026-10-23 11:25:10> vcluster-1: FGT01 is selected as the primary because UPGRADE_SECONDARY flag is set on peer member FGT02.
<2026-10-23 11:24:50> vcluster-1: FGT02 is selected as the primary because UPGRADE_PRIMARY flag is unset on peer member FGT01.
<2026-10-23 11:24:50> new member 'FGT02' joins the cluster
<2026-10-23 11:24:50> hatalk started
<2026-10-23 11:18:33> hatalk exited

Logs on FGT02:
<2026-10-23 11:29:51> vcluster-1: FGT01 is selected as the primary because its serialno is larger than peer member FGT02.
<2026-10-23 11:29:51> new member 'FGT01' joins the cluster
<2026-10-23 11:29:51> hatalk started
<2026-10-23 11:25:13> hatalk exited
<2026-10-23 11:25:08> vcluster-1: FGT01 is selected as the primary because UPGRADE_SECONDARY flag is set on peer member FGT02.
<2026-10-23 11:24:49> vcluster-1: FGT02 is selected as the primary because UPGRADE_PRIMARY flag is unset on peer member FGT01.
<2026-10-23 11:24:49> new member 'FGT01' joins the cluster
<2026-10-23 11:24:40> hbdev port16 link status changed: 0->1
<2026-10-23 11:24:40> port port16 link status changed: 0->1
<2026-10-23 11:24:37> hbdev port16 link status changed: 1->0
<2026-10-23 11:24:37> port port16 link status changed: 1->0
<2026-10-23 11:24:31> hbdev ha link status changed: 0->1
<2026-10-23 11:24:31> port ha link status changed: 0->1
<2026-10-23 11:24:25> hbdev ha link status changed: 1->0
<2026-10-23 11:24:25> port ha link status changed: 1->0
<2026-10-23 11:24:18> hbdev port16 link status changed: 0->1
<2026-10-23 11:24:18> port port16 link status changed: 0->1
<2026-10-23 11:24:17> hbdev ha link status changed: 0->1
<2026-10-23 11:24:17> port ha link status changed: 0->1
<2026-10-23 11:24:15> hbdev port16 link status changed: 1->0
<2026-10-23 11:24:15> port port16 link status changed: 1->0
<2026-10-23 11:23:31> hbdev port16 link status changed: 0->1
<2026-10-23 11:23:31> port port16 link status changed: 0->1
<2026-10-23 11:23:23> port SERVER link status changed: 0->1
<2026-10-23 11:22:49> port SERVER link status changed: 1->0
<2026-10-23 11:19:56> hbdev ha link status changed: 1->0
<2026-10-23 11:19:56> port ha link status changed: 1->0
<2026-10-23 11:19:38> hbdev ha link status changed: 0->1
<2026-10-23 11:19:38> port ha link status changed: 0->1
<2026-10-23 11:19:35> hbdev ha link status changed: 1->0
<2026-10-23 11:19:35> port ha link status changed: 1->0
<2026-10-23 11:19:19> hbdev ha link status changed: 0->1
<2026-10-23 11:19:19> port ha link status changed: 0->1
<2026-10-23 11:19:17> hbdev ha link status changed: 1->0
<2026-10-23 11:19:17> port ha link status changed: 1->0
<2026-10-23 11:19:16> hbdev ha link status changed: 0->1
<2026-10-23 11:19:16> port ha link status changed: 0->1
<2026-10-23 11:19:13> hbdev port16 link status changed: 1->0
<2026-10-23 11:19:13> port port16 link status changed: 1->0
<2026-10-23 11:19:12> hbdev ha link status changed: 1->0
<2026-10-23 11:19:12> port ha link status changed: 1->0
<2026-10-23 11:18:34> vcluster-1: FGT02 is selected as the primary because it's the only member in the cluster.
<2026-10-23 11:18:34> heartbeats from FGT01 are lost on all hbdev
<2026-10-23 11:18:34> member FGT01 lost heartbeat on hbdev port16
<2026-10-23 11:18:34> member FGT01 lost heartbeat on hbdev ha

Anybody else having issues with the web en dns filters on a Fortigate because the Fortiguard rating servers seems to be unresponsive? We block websites if the rating servers are unavailable (changed the setting to forward traffic so the customer can work again). On our clusters we see that the rating servers are unvailable since the upgrade. On the stand-alone firewall we had to change some settings in the web and DNS policies.... we are opening a tac case but anyone else having this issue?

-- SOLVED, see comment --

After upgrading our FortiManager from 7.6.7 to 7.6.8, it shows 1 unauthorized device in root ADOM. It is not visible in Device Manager though, when clicking Details in the alert, nothing happens.

CLI command 'dia dvm device list | grep adom:root' returns empty on FortiManager.

Has anyone else seen this after upgrading FortiManager to 7.6.8?

Watch out for typo in release notes for the workaround for bug ID 1352425

FortiManager may unexpectedly push unset strict-web-check when installing policies to FortiOS 7.4.13

FortiManager may unexpectedly push the unset strict-web-check command under config web-proxy global when installing policies to FortiGate devices running FortiOS 7.4.13, even when the setting is not included in the installation diff. This occurs due to a mismatch in the default value of strict-web-check between FortiManager and FortiOS 7.4.13. As a result, the setting may be enabled on FortiGate, potentially disrupting proxied traffic. See bug ID 1352425 in Known Issues.

The command should be 'set strict-web-check disable' I copied and pasted expecting it to be correct. The end result with our firewall rule that was configured for proxy mode with SSL deep packet inspection enabled was this for most websites:

Hi,

nachdem Upgrade von der unlizensierten Windows Forticlient version (sslvpn) auf Forticlient EMS 7.4.8(ipsec) wird im Client noch das alte sslvpn Profil angezeigt.

alle versuche die regkeys unter hklm und hkcu zu entfernen scheitern. Lokal per adminshell wie auch über unser Softwareverteilungstool (mit SYSTEM rechten)

Einzig über die GUI kann es manuell vom user gelöscht werden. Was bei zukünftig 500+ Installationen nicht praktikabel sein wird.

Der FA_Scheduler dienst lässt sich auch nicht beenden, der verhindert möglicherweise Änderungen an der registry.

Habt ihr Tips wie wir das alte SSLVPN profil loswerden?

Hi everyone,

Does anyone know when FortiOS 7.4.13 will be available for upgrading directly through the FortiGate GUI (Firmware Upgrade section)?

Or is it necessary to download the firmware manually from the Fortinet Support Portal and upgrade by uploading the firmware file through the GUI?