Recently active topics

Hi, Initially, several FortiGate 70G HA pairs became out of sync due to an unknown FortiAP entry, AP-11N-SERIAL-0001, appearing under Managed FortiAPs. Deleting the unknown AP entry from the primary FortiGate resolves the HA synchronization issue. Eventually, I found another entry in System Event log on FortiGate showing that the unknown AP was added after a discovery request was received. Source IP: 66.132.224.63 Event: AP AP-11N-SERIAL-0001 added Reason: Discovery request was received Any insights or relevant known issues would be appreciated. Thank you!

If i want to make traffic shaper to prioritize traffic from LAN to host 10.10.10.10 located on datacenter for example,then are i need to create the traffic shapper only for this specific host? Or I need to make another traffic shaper for other traffic with medium priority?

Hello,I have an FMG running version 7.4.7 on Azure, and this FMG has 2 ADOMS, each of which manages a “pair” of FortiGate devices operating in HA (via an Azure ELB).We need to perform scheduled backups once a week from the FMG.Is this possible?Is it possible to export the backups to a TFTP server from the FortiGates, but with everything managed through the FMG?Thank you for your feedback.

Hi allNothing important or urgent.According to Fortiguard RSS feed about updates, a new version of FAC (8.0.4) has been released over 24h ago.However, I am not seeing any release notes on the fortiauthenticator page or see a download folder for 8.0.4 (so no firmware or release notes there either).Usually it doesn't take that long after a release info to see downloads and release notes. So, I am not sure if I am just impatient.Anyone know if the info and firmware files have been withdrawn?Thanks

Hello everyone,I need assistance with configuring FortiNAC guest self-registration to assign different VLANs based on the location of the Cisco access point.Environment:FortiNAC: Version 7.6.7, deployed at HQ. Cisco WLC: Catalyst C9800 running version 17.9.4a, deployed at HQ. Access Points: Deployed at both HQ and Site A. Guest SSID: Configured for FlexConnect, with local switching at Site A. FortiNAC: Guest self-registration and the relevant policies are already configured.Issue:I want guest clients connecting through APs at HQ to be assigned to the HQ guest registration and guest VLANs, while clients connecting through APs at Site A should be assigned to the corresponding Site A VLANs.Currently, when a guest connects through an AP at Site A and completes the self-registration process, FortiNAC assigns the client to the HQ guest VLAN. I have already created the necessary policies in FortiNAC, but I am unable to get the VLAN assignment to work correctly according to the AP's location.M

Hi,I just downloaded FortiOS 7.6.7 for VMware, but when I use the CLI, I am able to log in with my username and password:Username: adminPassword: [Assigned password]However, when I try to authenticate via the web interface, I get a credential error.Does anyone have any ideas?

DescriptionThis article describes how to troubleshoot when the Server Connection status shows Invalid credentials.ScopeFortiGate.SolutionWhile implementing the LDAP server in FortiGate with Bind Type as regular, provide the LDAP server admin credentials to authenticate the LDAP server to perform a user search. While implementing, consider the following points regarding the Username configured in the FortiGate. If the Common Name Identifier is set as 'cn', use the user name (Display name) in the LDAP server. In case the Common Name Identifier is set as sAMAccountName, use the logon name.Use the syntax below to mention the username. If the Common Name Identifier is set as 'cn', mention the user's Distinguished Name. It is possible to use the query username '<full_user_name>' to find the complete DN of the user. Example: C:\Users\Administrator>dsquery user -name "ldap test" "CN=ldap test,CN=Users,DC=t3sophialab,DC=net" In FortiGate, Username will be CN=ldap test,CN=Users,DC=t3sop

We have experienced what appears to be a chronic problem with the 40F routers crashing and dumping their firmware entierly when they lose power unexpectedly. In the last year I would say 8-10 of our deployed 40F routers have dumped firmware, forcing an on-site trip to connect physically and attempt a TFTP load of firmware just to get the box to boot again. I just did one this morning, and another before that just last week. I haven’t gotten anyone from Fortinet to acknowledge an issue, they just ask me to buy more support contracts. Has anyone else had this experience? Is there a paritcular firmware minumum that resolves this issue? We’re setting them all at 7.4.12M which seems to be quite stable on the 60E, 60F, and 80E units we have in the field. I’d like to proactively address this issue if possible. 

We have become aware of the following security advisories regarding a vulnerability in FortiClient:https://fortiguard.fortinet.com/psirt/FG-IR-26-156https://advisories.ncsc.nl/2026/ncsc-2026-0296.htmlWithin our organization, we exclusively use FortiClient VPN-only for Windows. We do not use the full FortiClient client or FortiClient EMS.Therefore, we would like to know whether the vulnerability described in FG-IR-26-156 also affects the FortiClient VPN-only client.Additionally, we would appreciate clarification on the following:* Is FortiClient VPN-only affected by this vulnerability?* If so, which versions are affected?* Which version does Fortinet recommend installing to address the vulnerability?* Is an updated version of FortiClient VPN-only currently available?* Does the VPN-only client update automatically, or do we need to manually deploy the updated version to all our laptops?We would appreciate your clarification so that we can take the appropriate measures if necessary.Kind r

Hello,We are using the free FortiClient Windows VPN-only agent, version 7.4.3.Regarding Fortinet PSIRT advisory FG-IR-26-156 / CVE-2026-70465, the advisory lists FortiClient Windows 7.4.0 through 7.4.3 as affected and recommends upgrading to 7.4.4 or later. However, the FortiClient Windows release notes state that versions 7.4.4 through 7.4.7 do not include a new release of the free VPN-only agent, and that users can continue using the 7.4.3 free VPN-only agent. Could a Fortinet representative please clarify the following?Is the latest available free FortiClient Windows VPN-only 7.4.3 build affected by CVE-2026-70465? References:FG-IR-26-156: https://fortiguard.fortinet.com/psirt/FG-IR-26-156FortiClient 7.4.7 release notes: https://docs.fortinet.com/document/forticlient/7.4.7/windows-release-notes/683433/special-notices This is a request for clarification of the public PSIRT advisory’s impact and remediation path for the free VPN-only edition

DescriptionThis article explains why Perfect Forward Secrecy (PFS) is reported as disabled in debug logs during the initial IKEv2 tunnel establishment and how to verify it is active during rekeying. ScopeFortiGate. SolutionWhen analyzing IPsec IKEv2 VPN debug logs on a FortiGate, the output may indicate that PFS is disabled during the initial tunnel negotiation.ike 0:tunnel-wuw:148:tunnel-wuw:1206: matched proposal id 1 ike 0:tunnel-wuw:148:tunnel-wuw:1206: proposal id = 1: ike 0:tunnel-wuw:148:tunnel-wuw:1206: protocol = ESP: ike 0:tunnel-wuw:148:tunnel-wuw:1206: encapsulation = TUNNEL ike 0:tunnel-wuw:148:tunnel-wuw:1206: type=ENCR, val=AES_GCM_16 (key_len = 256) ike 0:tunnel-wuw:148:tunnel-wuw:1206: type=INTEGR, val=AUTH_NONE ike 0:tunnel-wuw:148:tunnel-wuw:1206: type=ESN, val=NO ike 0:tunnel-wuw:148:tunnel-wuw:1206: PFS is disabled <------ ike 0:tunnel-wuw:148:tunnel-wuw:1206: lifetime=14400 ike 0:tunnel-wuw:148:tunnel-wuw:1206: replay protection enabled ike 0:tunnel-wuw:148:tun

An incident occurred involving the FortiMail RAID configuration (RAID60-S) where multiple disks simultaneously switched to "UNKNOWN" status, subsequently transitioned to "REBUILDING," and finally recovered to "OK."Have there been any similar incidents in the past?Does anyone know the cause?Model: FortiMail 3000FFirmware: v7.4.2 (GA-Maturity), build583, 2024.02.07RAID SystemModel: AVAGO MegaRAID SAS 9460-16iDriver: 07.714.04.00-rc1Firmware: 5.170.00-3483u0 (RAID60)├ u0-0 (RAID6)│  ├ p0│  ├ p1│  ├ p2│  ├ p3│  └ p4│└ u0-1 (RAID6)├ p5├ p6├ p7├ p8└ p9p10: SPAREp11: SPARE  3,"2026-09-26","21:07:33.594","system","Disk p3 has changed status from 'REBUILDING' to 'OK'.","warning","0702003084"4,"2026-09-26","21:07:33.594","system","RAID device has changed status from 'REBUILDING' to 'OK'.","warning","0702003084"13,"2026-09-26","17:08:48.462","system","Disk p7 has changed status from 'REBUILDING' to 'OK'.","warning","0702003084"19,"2026-09-26","16:32:54.634","system","Disk p2 has changed status fr

DescriptionThis article describes the information and logs required when creating a new case to Investigate a Possible False Positive event.ScopeFortiEndpoint.SolutionWhen opening a FortiEndpoint ticket to investigate a possible false positive, providing complete event and endpoint information helps accelerate the investigation and enables the TAC AV team to perform a more effective analysis.Section 1 - How to open the case:Section 2 - provide the following details:Affected Endpoint Information:HostnameOperating systemCollector statusHASH of the eventOn the FortiClient EMS side:EMS Server versionFortiClient versionAV buildOn the FortiEDR side:The FortiEDR Collector version installed on the affected endpointThe exported json file of the eventThe number of affected endpointsDetection / Incident Details. Include the complete information for the detection:Event/Incident IDDate and time of the eventDetection nameSecurity rule that triggered the eventEvent classificationAction taken: Block,

DescriptionThis article describes how to troubleshoot a FortiNAC Manager synchronization failure where a managed FortiNAC-F server contains a stale GUID for a globally synchronized Group.The manager may report an error under application logs (output.master) similar to the following:GlobalObjectGRPCClient sync Failed GUID conflict for table: Group-ALL_MANAGEMENT,the guid will be cleared automatically,please re-sync the table,please contact support.ScopeFortiNAC Manager, FortiNAC-F.SolutionFortiNAC Manager uses the GUID value to identify globally synchronized objects.The local database ID on the managed FortiNAC-F server does not have to be the same as the corresponding object ID on the Manager.For example, a working configuration may have:Manager:ID = 1481818496667662guid = 1481818496667662Managed CA:ID = 295942325798912guid = 1481818496667662The local IDs are different, but the GUID is the same.When synchronization fails, check the affected Group on both the Manager and managed server.

DescriptionThis article explains how to resolve a timeout error during a FortiGate High Availability (HA) firmware upgrade performed through FortiManager, where the upgrade task fails and the remaining cluster members are not upgraded.The issue may occur when a FortiGate requires multiple reboots during the upgrade process and the configured reboot-after-upgrade timeout is insufficient to allow the process to complete.ScopeFortiGate, FortiManager.SolutionWhen performing a firmware upgrade on a FortiGate HA cluster through FortiManager, the upgrade task may fail with an error similar to:FGT_check_status failed: timeoutBy default, the secondary unit is upgraded first during an HA upgrade. Depending on the firmware version and the changes being applied, the unit may require multiple reboots before it completes initialization and rejoins the HA cluster.For example, changes involving hardware acceleration or NPU-related configuration may require an additional reboot to make the changes effe

I replaced the secondary unit of a FortiMail (3000F) configured in a primary-secondary setup and rebuilt it using the old secondary unit's configuration.Before connecting it to the primary unit, the following entries appeared in the "Mail Event" logs:/var/spool/etc/mail/submit.cf: WARNING: dangerous write permissions/var/spool/etc/mail/sendmail_ec.cf: WARNING: dangerous write permissions/var/spool/etc/mail/sendmail.cf: WARNING: dangerous write permissionsDoes FortiMail use sendmail for email transmission and reception?For the time being, I have connected it to the primary unit, and data synchronization is complete.If the primary unit were to fail in this state, causing the secondary unit (which generated these error logs) to take over as the primary,would email transmission and reception function correctly?I am concerned about this point. Do you have any information regarding these logs?When I tested sending an email via Webmail from this secondary unit,the following entry appeared in

DescriptionThis article describes how to set up a Microsoft Entra ID application as a backend Identity Provider (IdP) for FortiClient EMS user verification via FortiAuthenticator as an IdP proxy.ScopeFortiClient EMS, FortiAuthenticator, Microsoft Entra ID.SolutionTable of Contents:Configure Microsoft Entra ID applicationApplication registrationGrant the application API permissionAuthorise a set of users or groupsConfigure FortiAuthenticator as an IdP proxyConfigure OAuth settingsConfigure Microsoft Entra ID SAML settingsConfigure the remote SAML server (Entra side)Configure the remote SAML server (FortiAuthenticator side)Configure a realmConfigure SAML IdP general settings and user sourceConfigure FortiClient EMS SAML and Entra ID as the authentication serverConfigure SAML IdP and FortiAuthenticator as the SP Configure Entra ID as the authentication serverConfigure Domain ImportCreate invitationFortiClient EMS Windows client testingNote:Values such as tenant IDs, application IDs, clien

DescriptionThis article describes how to restrict 'quarantine release' privilege only to the group owner of the distribution list (email list). If no restriction is in place, all members of the distribution list may receive the quarantine summary and release the message for other members too. This may not be desirable in some circumstances.ScopeFortiMail 7.6FortiMail 8.0SolutionWhat will be achieved after implementing this configuration is summarized below:A user will send an email to the distribution list address.If the email is quarantined, list members will not receive the original email.The generated quarantine report will only be sent to the distribution list owner configured in Microsoft Exchange.Only the group owner will be able to see the report and release the email.The primary achievement is the prevention of any standard user from releasing a quarantined email.Test setup:Distribution list platform: Microsoft ExchangeDistribution list address: sales@internal100.labGroup owner

DescriptionThis article describes a known issue in FortiAuthenticator where an LDAP search for users fails due to a 'Timed out' error within 5 seconds, regardless of configured timeout settings. For this reason, FortiAuthenticator fails to perform group lookup, and users are missing in FSSO sessions.ScopeFortiAuthenticator, LDAP, FSSO.SolutionThis issue has occurred in cases where FSSO sessions are missing, and users were unable to access both internal and external resources because the firewall policies were configured based on user groups.Based on the debug logs below, FortiAuthenticator failed to search for users on the LDAP server, and the following error was reported:"ldapsearchext_s search failed: Timed out"Although the LDAP server's Response Timeout is configured to 30 seconds, the packet capture shows that the LDAP client sends an abandonRequest after approximately 5 seconds.17439 2026-05-05 15:16:03.605028 172.16.223.199 162.70.14.178 LDAP 241 searchRequest(12) "DC=gtoprod,DC=

Hi Guys,We are facing a wireless authentication issue specifically with hybrid Entra ID users.Fully cloud-based Entra ID users are able to authenticate and connect to the wireless network without any issues. However, hybrid users are unable to connect.We tested the affected user's credentials directly from FortiGate, and the credential test is successful. But when the same user attempts to connect through the SSID, Windows immediately shows “Can’t connect to this network.”From the RADIUS logs, we can see: RADIUS Access-Request → RADIUS Access-Reject It looks like the credentials/authentication source is working during the FortiGate test, but something is causing the actual wireless RADIUS request to be rejected.Has anyone faced a similar issue with FortiNAC 7.6.7 and hybrid Entra ID users?Also, what would be the best FortiNAC debug/logs to check to determine the exact reason for the RADIUS Access-Reject?Thanks in advance.

DescriptionThis article describes how to identify and resolve an issue where the FortiNAC Groups page fails to load and returns HTTP Status 500 - Internal Server Error.The issue can occur when two groups reference each other as members, creating a circular group relationship. This can cause recursive group processing to fail with java.lang.StackOverflowError.ScopeFortiNAC.SolutionIdentify the issue:When navigating to System -> Groups, the following symptoms may be observed:The Groups page displays a nonzero total number of groups but does not display any entries.A pop-up reports "Load Groups Error - HTTP Status 500 - Internal Server Error".Browser Developer Tools show a failed request to GroupActions.jsp.In the investigated case, the database contained 691 groups, but the Groups page could not display them.Identify the Java exception:Review the FortiNAC application logs (output.master) while reproducing the issue.The following exception was observed:org.apache.catalina.core.Containe

DescriptionThis article describes the steps to enable lightning mode and its benefits.ScopeFortiSandbox version 5.2.0 and above.SolutionLightning mode has been introduced in FortiSandbox 5.2. Benefits:Reduces storage space by not saving clean job details.Only basic job information is retained for 12 hours.This mode is particularly beneficial for scanning large network shares.Lightning mode can only be enabled by using a CLI command. See the documentation: lightning-mode.GUI changes:Once enabled, the following changes can be observed in the GUI:The device will show 'Lightning mode' in the top title bar.A new hint icon appears under System -> Settings -> Data Storage with the following information."Lightning mode is enabled. The retention time for clean jobs applies only to on-demand jobs. Other Clean-rated jobs will not have their detailed data saved. Only basic job information is kept for 12 hours."

Hi community, I have a question about FAZ logging. Which I can’t seem to find the right answer to and I’m hoping you guys may have experienced something similar.Basically I need to undertake some work on a FAZ VM itself where I don’t want new logs to be ingested to the database for a few hours while I do some work. It will be coming up and down so I don’t want it to start taking new logs when it boots up again.I have about 50 Gates logging to this FAZ and it is not feasible to go to each one and turn off the FAZ logging. I’m ideally looking for something like a pause button on the FAZ if it were to exist. I’m on a VM running 7.4.10. I have seen some recommendations about disabling the port on the FAZ used by the Gates so traffic can’t make it through and using a separate management port to continue to connect to the device which I believe is potentially my only option.Any other thoughts?

DescriptionThis article describes an issue where an external threat feed connector using mutual TLS (mTLS) authentication fails to connect and displays a 'Not Start' status on FortiGate.ScopeFortiGate.SolutionVerify the mTLS client certificate:Make sure the client certificate complies with standard mTLS requirements described in mTLS client certification for external feed connections.The certificate must meet the following requirements.The Extended Key Usage (EKU) extension must include 'clientAuth'.Basic Constraints must be set to 'End Entity'.Valid Key Usage fields must be configured.Verify whether FortiGate sends the client certificate:Run the following sniffer command:diagnose sniffer packet any 'host <server-IP>' 6 0 lReplace <server-IP> with the IP address of the server.Analyze the packet capture in Wireshark.Open the resulting packet capture in Wireshark and inspect the TLS handshake between FortiGate and the server.When the issue occurs, the certificate message sent

Hi Community,I am reaching out because I am hitting a wall with a specific client installation and I suspect a hardware/driver conflict, but I need confirmation or ideas on how to debug this further.The Scenario: I am deploying an IPsec VPN configuration with SAML Authentication (Entra ID / Azure AD).Success: The exact same configuration works perfectly on an HP PC.Failure: It fails consistently on a specific Dell Laptop.Environment (Failing Machine):Hardware: Dell LaptopNetwork Adapter: MediaTek Wi-Fi 6E MT7922 (Wireless LAN Card)OS: Windows 10/11 [Please confirm your OS version here, e.g., 22H2]FortiClient Version: VPN-only Client 7.4.3 (Build 1790) / Hotfix 1.8758The Symptoms:The user starts the VPN connection.SAML Authentication window pops up (Microsoft Entra ID).Authentication is successful.The Issue: Immediately after the auth window closes, the FortiClient status hangs (stalls). It does not establish the tunnel.After a short moment, nothing happens, or the connection attempt si