Recently active topics

DescriptionThis article describes the case when a FortiGate VM hosted on Google Cloud Platform (GCP) experiences significant packet loss and latency during high bursts of traffic. While interface-level counters do not show RX drops, the internal RX queue statistics indicate drops.ScopeFortiGate VM, GCP.SolutionThe issue is caused by RX queue buffer exhaustion. When the GCP instance presents only one RX queue, the ring buffer descriptors are exhausted during traffic bursts, leading to packet drops. This occurs even if the CPU utilization is not high, as the bottleneck is at the NIC descriptor level rather than the CPU processing level.The following command will list the interface counters. Notice that all the RX drops are zero.diagnose hardware deviceinfo nic port1 Name: port1 Driver: gve Version: 1.3.0 Bus: 0000:00:04.0 HWaddr: 42:01:0a:5c:1a:02 State: up Link: up Mtu: 1460 Supported: Advertised: Speed: 32000half Auto: disabled Rx packets: 14891007 Rx bytes: 1101897774 Rx compressed: 0

DescriptionSteps to disable the HTTP TRACE method on FortiClient EMS for Linux when vulnerability scanners report that the Apache web server accepts HTTP TRACE requests.ScopeFortiClient EMS.SolutionThe Apache web server used by FortiClient EMS may allow HTTP TRACE requests depending on the underlying Linux distribution and its default Apache configuration.On some RHEL deployments, HTTP TRACE requests may return HTTP 200 OK and echo the original request. On Debian/Ubuntu deployments, Apache may reject these requests by default.To disable the HTTP TRACE method, follow these steps.Verify the HTTP TRACE behavior.From a Windows machine with connectivity to EMS, open PowerShell and execute the following:curl.exe -ki -X TRACE https://<EMS-IP-or-FQDN>/When TRACE is enabled, the server may return the following:HTTP/1.1 200 OK Server: Apache Content-Type: message/http TRACE / HTTP/1.1 Host: <EMS-IP-or-FQDN>Modify the Apache configuration.Access the underlying Linux operating system

FortiRecon Digital Risk Protection (DRP), a SaaS-based service, includes External Attack Surface Management, Brand Protection, and Adversary Centric Intelligence.Adversary Centric Intelligence (ACI): leverages FortiGuard Threat Analysis to provide comprehensive coverage of dark web, open-source, and technical threat intelligence, including threat actor insights to enable organizations to respond proactively assess risks, respond faster to incidents, better understand their attackers, and guard assets.The Vulnerability Intelligence Module under Adversary Centric Intelligence (ACI) provides a realistic view of the impact of the vulnerability based upon chatter and discussion of the same across various external sources such as Darkweb, social media, News / Blogs etc.CVE IDCVE-2026-111497CVE TitleGoogle Brotli Unchecked Return Value VulnerabilityNVD SeverityCRITICALFortiRecon SeverityCRITICALFortiRecon Score95/100Epss Score0.55483ExploitedYesExploited by Ransomware Group(s)NoExploited by A

DescriptionAn issue where the log field under Job details shows "Skip VM Scan in Lite mode".ScopeFortiSandbox version 5.2.0 and above.SolutionThe Scan Job details show that the VM scan is skipped as the device is in Lite mode.FortiSandbox supports two scan modes: Full mode and Lite mode. For more details about these scan modes and their differences, refer to the FortiSandbox scan mode documentation.This points to a case where FortiSandbox performs a particular scan in Lite Mode.Check the following points:Check whether the device shows the Lite Mode label in the top banner. This appears only if Lite Mode is enabled.Alternatively, check the output of the CLI command status, which will indicate lite-mode status if it is enabled.> status System: Version: v5.2.2-build0319 (GA) Serial Number: FSA5HGTXXXXXXX86 Model: FortiSandbox-500G System Time: Tue Oct 27 12:59:08 2026 UTC SSD Data Disk:

DescriptionThis article describes the JSON API flow between FortiPortal and FortiManager when a firewall policy is modified from FortiPortal and the policy package is installed.The FortiManager JSON API debug can be used to identify the configuration sent by FortiPortal, the installation preview process, and the final policy package installation task.ScopeFortiPortal, FortiManager.SolutionThe following debug commands can be used on FortiManager to capture the JSON API requests sent from FortiPortal:diagnose debug reset diagnose debug service sys 255 diagnose debug service main 255 diagnose debug enableWhen a firewall policy is modified from FortiPortal, FortiPortal sends an API update request to the corresponding policy object in the FortiManager policy package.In the following example, firewall policy ID 2 in policy package FGT-1 was modified from FortiPortal.The FortiPortal IP address has been replaced with <FortiPortal_IP> in the debug output.Policy configuration change from F

DescriptionSteps to investigate the FortiClient telemetry being disconnected after connecting to SIA.ScopeFortiSASE.SolutionVerify that the FortiSASE endpoint can access the following domains on TCP port 443:forticlient-emsproxy.forticloud.comforticlient.forticloud.comforticlient-dispatch.forticloud.comWhen applying tags in all policies, there may be an issue if tags are not synced.The DNS resolution with forticlient-emsproxy.forticloud.com should not be denied.If the inquiry above or connection to the forticlient-emsproxy.forticloud.com is down, it means that the FortiClient telemetry is down, which causes the following tags policies cannot match.To avoid this issue, ensure there is a "Fortinet" policy on top of all policies without any tags and groups:The policy above will ensure the FortiClient can communicate with the EMS cloud properly.

DescriptionWhen administrators access the FortiManager GUI via Cloudflare ZTNA (Zero Trust Network Access), the login session may automatically terminate or disconnect roughly 30 seconds after logging in. This typically occurs because proxy routing, load-balancing, or edge POP switches cause minor fluctuations in the client's apparent source IP address, triggering session security validation failures on the FortiManager side.ScopeFortiManager, FortiAnalyzerSolution To resolve this issue, you need to configure FortiManager to bypass strict source IP validation checks for active sessions.Log in to the FortiManager CLI as an administrator and execute the following commands: config system global set skip-ip-check-in-session enable end Once this setting is enabled, FortiManager will ignore intermediate source IP modifications or fluctuations during an active session, allowing Cloudflare ZTNA users to maintain a stable, uninterrupted connection to the GUI.

I am experiencing an interference problem inside a room where we have set up one access point inside the room and another outside it.In total, I have 9 Fortinet access points spread across our offices on the 5th and 6th floors.However, for some time now, my desktop computers with integrated external PCI Wi-Fi cards operating at 2.4 GHz have been automatically disconnecting from the network and reconnecting immediately; often they lose the connection completely and then reconnect straight away. Thank you for your support. 

Anyone run into this scenario?fortiems client 7.4.7 can connect to dialup tunnel on Fortigate running 7.4.13, but fortiems client 7.4.8 cannot.7.4.8 can connect to other fortigates we have on 7.4.11 with no issues, but once upgraded to 7.4.13 it breaks. 

DescriptionFortiPAM retrieves an incorrect FortiClient EMS serial number for synchronized tags, preventing ZTNA access for tagged devices.ScopeFortiPAM, FortiClient EMS.SolutionDevices with assigned tags in FortiClient EMS cannot access FortiPAM via ZTNA. The tags synchronized from FortiClient EMS to FortiPAM are associated with an incorrect serial number that does not match the actual FortiClient EMS console serial number. Root CauseFortiPAM retrieves the default tenant serial number instead of the specific tenant serial number in multi-tenant FortiClient EMS environments. This is identified as BUG 1343587. Permanent FixUpdate FortiClient EMS to version 7.4.9 or later. WorkaroundPerform the following steps to clear the invalid tags and refresh the synchronization: Clear the invalid tags associated with the incorrect serial number by running the following command on FortiPAM: diagnose endpoint tags remove-by-sn <INCORRECT_SERIAL_NUMBER> Restart the fabric connector daemon to refr

DescriptionHow to use Automation Stitch to collect debug logs when a FortiGate high availability failover occurs.ScopeFortiGate.SolutionCreate the auto-script:When an HA member loss occurs, one of the common root causes is high CPU utilization. If the CPU is overloaded, the FortiGate may fail to process HA heartbeat packets in a timely manner, triggering a false-positive or actual cluster split/failure. To investigate whether high CPU usage contributed to the HA member drop, use the troubleshooting command below to capture the CPU usage at the time of the issue.config system auto-script edit "Collect logs" set script "get system status get system performance status get system ha status diagnose sys top 1 200 1 diagnose sys top-mem 200" next endCreate an automation action:In this example, the FTP server IP address is 10.207.2.82, the username is 'admin', and the password is 'password'. The FTP server can be changed to a TFT

Hi all,after upgrading FortiManager to 7.6.8, all installs to our FortiGate-50G devices (FortiOS 7.6.7) fail. FortiManager pushes an attribute to the default profile “custom-deep-inspection” that the 50G does not support:config firewall ssl-ssh-profile edit "custom-deep-inspection" config https set udp-not-quic allow end config dot set udp-not-quic allow end nextend---> generating verification report(vdom root: firewall ssl-ssh-profile "custom-deep-inspection" https:udp-not-quic) remote original: to be installed: allow(vdom root: firewall ssl-ssh-profile "custom-deep-inspection" dot:udp-not-quic) remote original: to be installed: allow<--- done generating verification report------- Start to retry --------[same result]install failedTask status: “verify state: install OK/verify FAIL” → “install and save finished status=FAILED”. No changes are applied.Running the command manually on the 50G:set udp-not-quic allowcom

DescriptionThis article describes how to restore GUI access when nginx fails to start after upgrading FortiSOAR to version 8.0.0.ScopeFortiSOAR.SolutionAfter the upgrade, the FortiSOAR web portal is inaccessible, and the nginx service fails to start. The nginx error logs display the following message:[emerg] unknown directive "ssl" in /etc/nginx/conf.d/cyops-api.conf:217This occurs when /etc/nginx/conf.d/cyops-api.conf contains the standalone ssl on; directive. Previous nginx versions accepted this directive with a warning. nginx version 1.26.3, used in FortiSOAR 8.0.0, rejects it, preventing the service from starting.To correct the configuration and restore web portal access:Create a backup of the configuration file:sudo cp -p /etc/nginx/conf.d/cyops-api.conf /etc/nginx/conf.d/cyops-api.conf.before-fixOpen the configuration file:sudo vi /etc/nginx/conf.d/cyops-api.confLocate and remove the obsolete standalone directive:ssl on;If the ssl_protocols directive contains a duplicate TLSv1.3

Hello Fortinet Community,I am managing FortiGate firewalls in a healthcare environment, and I am facing a recurring challenge during network security inspections.The inspectors identify online file-sharing websites that are accessible through our network, and this has resulted in failed inspections.Some examples of these websites are:onetimedrop.app online-clipboard.online heave.ggThese websites provide online file-sharing or file-transfer functionality. However, they are categorized by FortiGuard under Information Technology rather than File Sharing and Storage.Current FortiGate Security ConfigurationI have already implemented the following controls:Web Filter: File Sharing and Storage is blocked. DNS Filter: File Sharing and Storage is blocked. Application Control: Cloud IT and Storage Backup applications are blocked.Despite these controls, the websites mentioned above remain accessible because their FortiGuard classification does not match the category I am blocking.My QuestionsIs t

Initially, I attempted to upgrade the firmware from 7.0.15 to 7.2, but the process failed. Following this failure, I tried to roll back to version 7.0.15; however, the console is now stuck on "duplicate action=find-dup," and I am unable to perform a hard reset on the FortiGate unit. What should I do? Please help. 

Description   This article describes a feature deployed in January 2019.The 'Email Interaction' feature allows the choice of whether ticket updates can be handled via email.  This avoids the need to log into the Support Portal to read the latest ticket comments which have been added by the Fortinet engineer, or to provide updates to the engineer.When this feature is enabled the effects are that:   (1) When a Fortinet engineer adds notes to a ticket, the entire content of the latest update will be sent via email to all of the contacts named on that ticket.  The 3 most recent ticket comments will also be included in this mail.  File attachments that are added to the ticket will also appear in this mail.(2) Upon receipt by email of a ticket update, it is possible choose to simply reply to the email and the reply will be added to the ticket notes.  This reply may include file attachments.  The ticket will then be placed into a "Received Customer Feedback

Subject: FortiLink Through Standalone FortiSwitches in an MCLAG DesignHello Fortinet Community,I would like to get your advice on a planned network design involving FortiGate, standalone FortiSwitches, managed FortiSwitches, and FortiAPs.Proposed Network Topology          FortiGate                 | Standalone FortiSwitches      (MCLAG Peer Pair)                 | Managed FortiSwitches                 |           FortiAPs In this design, the FortiSwitches directly connected to the FortiGate will operate in standalone mode as an MCLAG peer pair. The downstream FortiSwitches will be managed by the FortiGate through FortiLink, and the FortiAPs will connect to the managed FortiSwitches.I would appreciate your advice on the following questions:Design feasibility: Is this topology supported by Fortinet, particularly when using standalone FortiSwitches as an intermediate layer between the FortiGate and the managed FortiSwitches? FortiLink connectivity: Can the FortiGate discover, authorize, a

My internet speed drops significantly when using SSL or IPsec VPNs. There are no speed limits or other restrictions in place; the speed simply started to decline—dropping from 300 Mbps to 50 Mbps. I haven’t performed any updates; the slowdown just began toward the end of August. The device model is a FortiGate 201G.

DescriptionLarge downloads through the explicit web proxy may be slow when tcp-option is disabled.In this example, downloads stayed at about 650 KB/s with a server round-trip time of 100 ms. A faster internet connection made no difference.Enabling tcp-option allows TCP window scaling, which removes this limit.ScopeFortiOS 8.0.x, FortiOS 7.6.x, FortiOS 7.4.x.SolutionWhen tcp-option is disabled, FortiGate removes all TCP options except MSS from the handshake, including window scaling. This limits the TCP receive window to 65,535 bytes. The sender fills the window, then waits for an acknowledgement before sending more data. With a round-trip time of 100 ms, downloads stay at around 600–650 KB/s, even on a faster link. The connection starts normally, with no packet loss or resets. The longer the round-trip time, the lower the download speed.The capture below shows the connection between the client and the proxy. The client requests window scaling, SACK, and timestamps. The proxy replies wi

Backstory:We're a small MSP that has a client with existing Fortinet equipment, which means they use FortiClient VPN, we also use Pulseway to do 3rd party patching with a delay to make software update a few weeks after new patches.This Monday, April 14th, we got reports of pre-boot BSOD, specifically PAGE_FAULT_IN_NONPAGED_AREA and some driver related ones but in all cases the "what failed" was fortitransctrl_74.sys in c:\windows\system32\driversThe most annoying part is you couldn't boot in safe mode, no matter what you tried it would always BSOD before the advanced start menu would appear.To fix the issue we used Windows ToGo usb and renamed the misbehaving driver, computer would boot back up no problem.The other weirdest part is it only happened to computers with intel 10th gen (10500T/10210U/10505), the OS breakdown was 5 Windows 11 and 2 Windows 10 but all windows 11 were not fresh installs but upgraded from Windows 10. This is with a client that has ~100 computers operating on av

DescriptionA solution to the issue where FortiNAC fails to resolve the correct physical port for Dell N1148T-ON switches, resulting in the assignment of the default VLAN instead of the policy-defined VLAN.ScopeFortiNAC 7.2.9.SolutionSymptomsDuring 802.1X authentication with a Dell EMC N1148T-ON switch, the endpoint authenticates successfully, but FortiNAC returns an incorrect Tunnel-Private-Group-ID (VLAN) in the RADIUS Access-Accept packet. The endpoint is assigned to the default VLAN (e.g., VLAN 1) instead of the VLAN specified in the Network Access Policy.Root CauseFortiNAC uses a CUSTOM port interpretation for Dell switches. On certain models like the Dell N1148T-ON, FortiNAC fails to resolve the physical interface using this method when the RADIUS request contains only the NAS-Port attribute without an associated NAS-Port-ID. This causes FortiNAC to fall back to the Called-Station-Id, which may resolve to the wrong port, leading the system to apply the default access action and th

Installing 7.4.0.1658 on two different Windows 11 (Dell Vostro and Dell Inspiron) Laptops.  Both laptops were Wiped and Prepped with the same Windows 11 23H2 Pro OS and are set up using very basic Intune Profiles (Intune barely does anything). The VPN Client, when launched, only goes as far as "Connecting".  It never times out and appears as if its stuck.   Are there any Windows Settings I should be looking at which would impact the clients ability to establish a connection?  Logs dont appear to show anything indicating the VPN is even attempting to connect.

DescriptionTroubleshooting steps to undertake when some devices discovered during a Microsoft Intune poll are not registered in FortiNAC due to an outdated Vendor OUI database.ScopeFortiNAC.SolutionSymptomsAfter completing a Microsoft Intune poll, some devices that exist in Microsoft Intune do not appear as registered in FortiNAC. Debug logs for MSInTuneServer show that the devices are discovered, but they are not registered in FortiNAC, thus missing from the Host View.Root CauseFortiNAC does not register devices if their MAC addresses are marked as invalid. This occurs when the Vendor OUI database is outdated and does not recognize the manufacturer of the device.ResolutionVerify if the MAC addresses of the missing devices are recognized as valid by running the following command in the CLI:validmac -mac <MAC_ADDRESS>If the output shows "Invalid," update the Vendor OUI database by following these steps:Select Agent Update Settings and enter the correct credentials.Perform an Auto

DescriptionThis article describes a captive portal redirect loop with User SAML SSO, and how to fix it. The user authenticates successfully at the IdP and is returned to the FortiNAC-F portal, but the device is never registered. The cause is a hostname mismatch: the SP URL of the User SAML SSO service connector is different from the captive portal Fully-Qualified Host Name set in Portal -> Portal SSL.ScopeFortiNAC-F 7.6.3 and later (User SAML SSO service connector). Observed on 7.6.7 build 0976.FortiAuthenticator as SAML IdP, including IdP proxy to Microsoft Entra ID. The same applies to any SAML IdP.Standalone and High Availability (1+1) deployments, L2 or L3 isolation.SolutionSymptoms:The rogue host is placed in the Registration VLAN and opens the captive portal.USER login redirects to the IdP. Authentication succeeds, the browser returns to FortiNAC-F, then lands back on the portal start page. Every new attempt repeats the cycle.The host stays Rogue, no SSO user record is created

DescriptionThis article describes how to perform an RMA for FortiGates that have a single HA license (Single FortiGuard license).ScopeFortiGate.SolutionWhen dealing with failures involving a FortiGate with a single license shared among Cluster/HA members, the license transfer procedure during an RMA differs significantly from the procedure used for a FortiGate with a conventional license. As multiple FortiGate units are covered by the same license, the new FortiGate provided through the RMA cannot be added to the existing single license when the standard RMA process is followed.In this case, when opening a ticket with Fortinet Support, indicate that the firewall has a license shared across the Cluster to prevent automatic license transfer.For instructions on creating a support ticket, refer to Customer Service Tip: How to create a ticket for Fortinet TAC.After opening the ticket and confirming the firewall failure, when transferring the license, follow the steps below:Access Fortinet S