Recently active topics

DescriptionCheck the installed license and administrator profile when saving a Security Action returns HTTP 403. The required entitlement depends on whether the action is used for Security Incidents or Endpoint Compliance.ScopeFortiNAC with a PLUS license.SolutionSymptomsWhen you add a Security Action, such as Set Host Role, clicking OK can display the following error even when the administrator profile has all available permissions selected:Add Event Action Error - HTTP Status 403 - Forbidden The requested URL was not found on this server.In the browser developer tools, the failed save request appears as:POST /actions/policy/event-action/ HTTP 403 ForbiddenAdmin permission request and attribute error:License and permission requirementsThe installed license controls the available feature set. The administrator profile controls which licensed operations you can perform. Selecting all available administrator permissions does not enable features outside the installed license. See the Fort

Product: FortiGate-80F-POE, S/N FG80FPTK24000713 Firmware: FortiOS v7.6.8 build3744 (GA.M); IPS Engine 7.01200; AV Engine 7.00062 Severity: 3 (business impact, workaround available)SummarySince Windows clients started sending hybrid post-quantum key shares (OpenSSL 3.5+, Chrome/Edge), TLS 1.3 handshakes from Windows hosts through our FortiGate time out. The ClientHello (~1.5–2 KB) is split into two TCP segments. For sessions without the TCP timestamp option (Windows default timestamps=allowed), the FortiGate ACKs the second segment to the client on behalf of the server. It then retransmits that segment on wan1 about 6 times, and the server never acknowledges it. The handshake hangs until the client times out (FIN from server after ~15 s, or RST after ~35 s).macOS clients (TCP timestamps on) are unaffected through the same policy, with the same NAT IP and destination, and even with a byte-identical ClientHello split at the same offsets.This looks related to KB “ERR_SSL_PROTOCOL_ERROR wh

Description   This article describes the basics of TACACS+ authentication, how this can be used for authorization, and general troubleshooting logs.  Scope   FortiAuthenticator.   Solution   Provides Authentication, Accounting, and Authorization for devices as routers, switches, firewalls, and servers. Uses TCP port 49, and the payload is encrypted, providing security.    Working: User attempts to log in.  Username is checked locally; if present, it is forwarded to the TACACS+ server.  Password is verified successfully, forwarded, and processed to verify the Trusted host list. The required profiles and resources are allowed for the user. Successful authentication returns the Vendor-specific attributes (VSA) as per the specified user group.   Successful snippets of logs for reference. TACACS+ Authentication logs:   2025-12-09T09:42:08.789839+00:00 FAC01 authen_tac_plus[2916]: 10.10.10.2 test1 ssh 10.10.10.1 pap login succeede

Our 700G, running version 7.4.12, is not showing a notification that version 7.4.13 is available (I expect I’ll just update it manually soon). The licenses are valid, and the Fortinet servers are reachable. Do you know why this is happening? Is anyone else experiencing this? 

DescriptionThis article explains how to use variables to mask specific field values when configuring FortiAnalyzer Fluentd Output Profiles to send logs via the Azure Monitor Log Ingestion API.ScopeFortiAnalyzer 8.0.SolutionGo to System Settings -> Advanced -> Log Forwarding -> Output Profile -> Create New Type the name, and then select Azure Logs Ingestion as the type.Create the variables under Configuration and Fields, and then click Validate and Save.<match> tenant_id ${TENANT_ID} client_id ${CLIENT_ID} client_secret ${CLIENT_SECRET} dce_url ${DCE_URL} dcr_id ${DCR_ID} table_name ${TABLE_NAME} </match>Once the configuration is complete, go to Log Forwarding -> Settings -> Create New, enter a name, select Remote Server as the server type, choose Forward via Output Plugin, select the profile you created under Output Profile, and select OK.Related document:FortiAnalyzer Fluentd supports the Azure Monitor Log Ingestion API

DescriptionThis article describes how to manage the condition where the BGP neighborship remains in the Active state, and the BGP debug shows the message '107-Transport endpoint is not connected'.ScopeFortiGate.SolutionAssuming a scenario where a FortiGate is receiving no traffic, the first check to perform is to verify the presence of the necessary routes in the VDOM routing table using the command :get router info routing-table allIf the required route is missing and should be announced by a BGP neighbor, you need to check the neighbor state with the command :get router info bgp neighbors <neighbor-ip>When a BGP neighbor remains in the Active state, and it is not possible to perform checks directly on the neighbor's configuration and status, it is important to first understand what this state indicates. StateMeaningIdleThe local FortiGate has not started the BGP process with the neighbor. For eBGP, this can be because the peer is multiple hops away and multihop is not enabled.C

Hello everyone,I'm not sure if I'll get any help on this topic here, but I'll give it a try anyway.We primarily use FortiClient VPN to establish a VPN connection to our Fortigate via IPsec using SAML.Some employees who do not work in the company, but are mainly in the home office or work on the road, have the Microsoft Global Secure Access Client installed on their Windows devices.With the background of tunneling the Microsoft365 connections and web connections via the EntraID GSA without FortiClient VPN.https://learn.microsoft.com/en-us/entra/global-secure-access/overview-what-is-global-secure-accessIn exceptional cases, however, these employees may still require an IPsec VPN connection in order to access various VLANs behind the Fortigate.The problem is as follows. The employee can connect to the FortiClient VPN, but the connection is terminated after approx. 10 seconds. Nothing can be seen in the FortiClient VPN for incoming traffic.The FortiClient VPN log files there is nothing use

We have a few switches (124G) which are standalone, but daisy changed together in a loop, one switch per building. This all works. We have 3 ISPs, one in each building. We have two Fortigates, so two of the switches have links to a Fortigate port, one port per ISP. We do this for redundancy. My question is: Should I do any special commands on these standalone switches for hardening purposes? Since at least some of the ports are directly connected to the ISP.Thanks.

I recently encountered and resolved the following issue, and I am sharing the troubleshooting process because the FortiClient error did not immediately indicate the actual cause.EnvironmentFortiClient EMS: 7.4.8 FortiClient for Windows: 7.4.8 FortiAuthenticator: 6.6.9 FortiGate VM: FortiOS 7.4.13 VPN type: IKEv2 IPsec Authentication method: EAP-TTLS User source: LDAP/Active Directory Two-factor authentication: FortiToken managed through FortiAuthenticatorIssueWhen I tried to establish the VPN connection using a domain account, FortiClient returned the following error:EAPPasswordErrorThe authentication process failed, and the VPN connection could not be established.Since I was taking over an existing installation, I was not yet fully familiar with every step of the authentication flow between FortiClient, FortiGate, FortiAuthenticator, and the LDAP server.Troubleshooting performedI initially verified the following points: The FortiGate was reachable from the client’s public IP address.

DescriptionHow to troubleshoot whether the third-party phishing simulation campaign is suspected of being clicked by FortiMail.ScopeFortiMail.SolutionAdd the "third party phishing simulation" sending IPs to the FortiMail Safelist.Create a dedicated Recipient Policy matching the "third party phishing simulation" sender address, and ensure no AntiVirus or Content profiles are attached to it.Reasoning for Step 2:Merely adding the IP to the Safelist is not enough.FortiMail will still forward URLs/files to FortiSandbox and perform a Content Disarm and Reconstruction scan if a matching AntiVirus/Content profile exists in the policy.For additional details and a configuration example on safelisting FortiSAT in FortiMail, refer to Safelisting FortiSAT in FortiMail.

DescriptionThe ipsengine daemon crashes frequently on FortiGate devices running FortiOS 7.4.x / 7.6.x when FortiSandBox scanning is enabled in AntiVirus profiles.ScopeFortiGate 7.4.x, 7.6.xipsengine 07.004.604 FortiSandBox FortiSandBox-Cloud.SolutionSymptomAfter upgrading to FortiOS 7.4.x or 7.6.x, the ipsengine daemon has been observed to crash repeatedly.The crash logs indicate a segmentation fault (Signal 11). This behavior results in Intrusion Prevention System scanning failures, which may cause certain traffic sessions or websites to be blocked.The following command below allows you to check the latest ipsengine crashes that occurred:Note:When an AntiVirus profile is configured to use FortiSandBox scanning (either Cloud or On-Premises), this will trigger a crash in the ipsengine.diagnose debug crashlog read | grep ipsengine -A 1 15512: 2026-09-08 07:26:43 <26080> application ipsengine 07.004.604 15513: 2026-09-08 07:26:43 <26080> *** signal 11 (Segmentation fault) rec

DescriptionThis article describes how to recover the Resize and Remove button options of a widget from the FortiSASE status dashboard.ScopeFortiSASE.SolutionThe FortiSASE dashboard has widgets that allow admins to add or remove widgets.There are instances where the button options are missing.To recover the resize and remove button options, zooming in or out of the browser view would resolve the issue.If the issue persists, capture and simulate the issue using the Fortinet Support Tool:Troubleshooting Tip: Collect GUI slowness and errors debugs via Fortinet Support Tool

DescriptionInformation on which corresponding value from the downloaded credentials from the FortiAnalyzer Cloud to be used in the FortiCASB-SSPM FortiAnalyzer Connector field.ScopeFortiCASB-SSPMSolutionAfter downloaded the credentials from the FortiAnalyzer Cloud (refer to documentation at the end of this article) and upon opening the downloaded file, below information are available.The respective information and the corresponding field.After entering the information, the Check Connection page should show the status as Connected, which confirms the information is correct.Related document:FortiAnalyzer Connector

DescriptionThis article describes how to troubleshoot when an upgrade to FortiManager fails with an 'Invalid Image' error.ScopeFortiManager.SolutionFortiManager firmware upgrade may fail with the error message 'Invalid Image'. The following is the checklist and steps to troubleshoot and identify the issue.Check the upgrade path and ensure that the image has no intermediate images. Upgrade path tool can be used to check: Upgrade Path Tool.Check the image downloaded. The image is specific to the model and VM instance. To check the VM instance, the following command can be run:diagnose debug klogSnippet of the output:<6>[0.000000] Hypervisor detected: KVMBased on the output, the Hypervisor is KVM, and the image used should match the hypervisor (example):FMG_VM64_KVM-v7.6.8.M-build3788-FORTINET.outThe same command provided in the previous steps can also be used to identify if there are issues in the disks. The following is an example of the error:<0>[702415.444478] EXT4-fs (dm-

DescriptionThis article describes the FortiADC Server Load Balance Real Server Pool member backup state behavior when failover and failback are triggered.ScopeFortiADC.SolutionPrerequisite: FortiADC Server Load Balance Virtual Server with a Layer-4 application profile. Configurations:FortiADC Server Load Balance Virtual Server with Layer-4 application profile configured with 2 real server members and one of the real servers configured in backup state.Test and behaviors:In the test, an HTTP session is established, and a continuous ping is performed. The session is initially connected to Server01, and a failover is triggered by bringing down Server01.HTTP session is re-established to Server02.After resuming the service on Server01, the real server status changed to UP for Server01. The HTTP session does not stay in Server02 but immediately flows back to Server01.HTTP Session failback to Server01.Explanation:In a normal Real Server Pool with multiple server members configured with load ba

DescriptionThis article describes how to exclude a specific sender from specific Data Loss Prevention (DLP) Rule scanning.ScopeFortiMail.SolutionIn IP Policy and Recipient Policy, it is possible to apply a DLP Profile for FortiMail scanning to stop sensitive data from leaking to the outside network.DLP Profile can consist multiple DLP Rule enable and allow to take different action between the DLP Rule.To exclude a specific sender from DLP checks on a specific DLP Rule, edit the DLP Rule and add the condition as per below in the Exception tab.The log message will show as below if the sender matches the exception rule.In this example, the sender only bypassed the check for DLP Rule ‘test_dlp_1’ but is still checked by DLP Rule ‘No_password’.

DescriptionFortiSIEM upgrade may fail because the upgrade script incorrectly identifies a non-HA environment as an HA deployment. The script attempts to validate Patroni replica health, but no active replicas exist in the standalone environment.ScopeFortiSIEM.SolutionThe upgrade process fails with one of the following error messages.ERROR: Patroni cluster is missing IPs: <Supervisor_IP>. Fix the Patroni cluster configuration and rerun the upgrade.ERROR: Patroni cluster is not in healthy state. Please check the Patroni cluster status and ensure it is healthy before proceeding with the upgrade.This issue may occur in environments where Supervisor HA was previously configured but has since been removed. The Patroni service remains present, but no active replicas are available.The upgrade script checks for the presence of the Patroni service to determine whether the environment uses HA. When the service is detected, the script executes a health check in patroni_sync.py.The health che

Hi all,I've been building FortiSOAR playbooks for SOC work and turned the lessons I learned into a free, open-source skill for Claude AI.You describe the playbook in plain English, and Claude writes a complete FortiSOAR playbook JSON export that you can import directly. A bundled Python validator checks the export first for problems FortiSOAR would reject on import (broken step routes, Jinja syntax and similar).Example prompt:"Build a FortiSOAR playbook that runs on alert create, enriches every IP with FortiGuard and VirusTotal, and closes the alert as false positive if all are clean."What it covers:- Alert triage and incident response- IOC enrichment and phishing analysis- FortiSIEM / FortiAnalyzer queries (uses a reference of 7,000+ FortiSIEM event attributes)- Response actions with client approval (manual input) links- PDF / HTML reports generated inside FortiSOAR- Reviewing, debugging or adapting an existing playbook exportIt doesn't connect to your FortiSOAR instance. You import t

DescriptionIncident notifications may fail to send and display a SendFail status due to an incorrectly formatted email address configured in the CC field. This article explains how to identify and resolve the issue by correcting the CC email address.ScopeFortiSIEM.SolutionThe notification status for incidents displaysSendFail, even though standard email testing functions work correctly.The issue occurs when the CC field contains an invalid email address format.FortiSIEM expects a complete email address in the CC field. If a username or alias is entered instead of a valid email address, the notification process may fail and generate the following error in the Appsvr.log.Error MessageERROR com.ph.phoenix.service.notify.email.SmtpClientHelper - [PH_APPSERVER_NOTIFIER_ERROR]:[eventSeverity]=PHL_ERROR,[phEventCategory]=3,[procName]=AppServer,[phCustId]=0,[phLogDetail]=AddressException: Local address contains illegal characterResolutionVerify and correct the email address configured in the n

DescriptionSteps to troubleshoot a situation where an email address cannot receive normal emails and no corresponding email logs appear in FortiMail because the address is configured for the FortiGuard Spam Sample Submission Service.ScopeFortiMail all versions & FortiMail Cloud.SolutionWhen troubleshooting an issue where a recipient cannot receive emails, administrators may find that FortiMail has no corresponding mail logs for the affected address.One possible cause is that the email address has been configured under the Spam Sample Submission Service in FortiMail. This setting is intended for receiving spam samples for submission to FortiGuard, rather than for normal email delivery.Verify the Spam Sample Submission Service configuration:Log in to the FortiMail administrative GUI.Navigate to System -> FortiGuard -> Antispam.Locate the Spam Sample Submission Service setting.Check whether the affected email address is configured in Email account to receive spam:More details: C

DescriptionFortiClient version 7.4 fails to establish a VPN connection before user logon using Windows credentials.ScopeFortiClient version 7.4.SolutionSymptoms.Users cannot connect to the SSL VPN or IPsec VPN using the VPN Before Logon feature after upgrading to FortiClient version 7.4. The connection fails at the Windows logon screen, and no logs are generated on the FortiGate.Root cause.In FortiClient version7.4, a change in behavior causes the client to check for credentials before initiating the connection. If the Prompt for Username setting is disabled, FortiClient may fail to retrieve the necessary credentials from Windows, causing the pre-logon connection to halt. This differs from FortiClient version 7.2, which attempted to start the connection even if credentials were not immediately found.Resolution.Workaround:To resolve this issue in FortiClient version 7.4, enable the prompt for usernames in the endpoint profile:Log in to the FortiClient EMS console.Select Endpoint Profile

Hello Fortinet Community,We are facing a persistent issue with a FortiAP 231K that fails to come online on our FortiGate 60E. Interestingly, the same behavior has also been observed on the replacement FortiAP received through RMA.We would appreciate guidance from the community or Fortinet engineers who may have encountered similar symptoms.EnvironmentFortiGate: FortiGate 60E FortiOS: 7.4.12 Access Point: FortiAP 231K AP management: FortiGate wireless controller Original testing topology: FortiGate -> PoE switch -> FortiAP 231K Replacement AP testing setup: PoE injector -> FortiAP 231K, with a laptop connected for testing and a serial console connection through PuTTYWe have checked the official FortiAP and FortiOS Compatibility Matrix and are investigating the issue using the supported firmware combination listed for the FortiAP 231K and FortiOS 7.4.12.Issue ObservedThe FortiAP boots successfully but does not come online or establish a stable CAPWAP connection with the FortiGat

DescriptionThis article describes how to deal with the issue of a report chart not being generated in some sections of the report.ScopeFortiWeb version 8.0.x  SolutionAdmin creates a report in Log&Report -> Log Access -> Report -> Report Config and downloads it in Report Browse.   After reported is created, Admin review within the report and in some sections randomly the chart associated to the table is not generated.  This is a known issue that is resolved in version 8.0.8.

DescriptionThis article describes how to configure Agentless FSSO Polling via an IPsec VPN tunnel between two FortiGates.ScopeFortiGate.SolutionIn the network diagram above, the AD server is only reachable by FGT-A by IPsec VPN tunnel to FGT-B. By using FSSO Agent, specify the source IP to reach FGT-B. However, there is no such option in Agentless FSSO polling.LDAP is configured to specify the source IP, but performing a sniffer on FGT-A on port 445 reveals it was being sent out using another source IP:config user ldap     edit "AD"         set server "10.125.1.11"         set source-ip 10.149.1.21         set cnid "sAMAccountName"         set dn "dc=ces,dc=com"         set type regular         set username "cn=Administrator,cn=Users,dc=ces,dc=com"     next end FGT-A # diagnose sniffer packet any 'port 445' 4 interfaces=[any] filters=[port 445] 0.624513 VPN-AtoB out 2.2.2.2.11209 -> 10.125.1.11.445: syn 2524384594 4.636167 VPN-AtoB out 2.2.2.2.11209 -> 10.125.1.11.445: syn 25243

Hello, We are having this issue on FGT-80F and FGT-80E, both version 7.2.14. When renewing certificates, we edit the existing certificate object and replace the certificate chain with the new one, so we can keep the same certificate name. The updated certificate is reflected everywhere except on virtual servers. When checking the certificate presented by a virtual server, it appears that the old certificate is still being used.If we switch the virtual server to a different certificate, the change takes effect immediately and the new certificate is presented correctly, but when we switch back to the new certificate, the virtual server continues to present the old one.  Has anyone encouter this issue? Is there a way to force virtual servers to reload the updated certificate without rebooting the FortiGate or manually changing certificate references?  Thanks!