Recently active topics

Need help troubleshooting. Already did factory reset of APs, deauthorize and re-authorize as well as the following.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 timersconfig wireless-controller timersset echo-interval 100set discovery-interval 15end Set set max-retransmit from 3 to 15config wireless-controller globalset max-retransmit 15nextend 

Hello Fortinet Support,We are looking for guidance on deploying and configuring the FortiClient VPN application on Android devices managed through SOTI MobiControl.Our goal is to deploy FortiClient with a predefined VPN configuration, including authentication settings, so that users do not need to configure the VPN manually.Specifically, we would appreciate your guidance on the following:Can FortiClient VPN be deployed and configured automatically on Android devices through SOTI MobiControl? Can VPN profiles and authentication settings be preconfigured using Managed App Configuration or another officially supported method? Does FortiClient support receiving VPN configurations from FortiClient EMS on Android devices, and can this be used in conjunction with SOTI MobiControl? Is there any official Fortinet documentation or recommended best practice for deploying and configuring FortiClient VPN on Android using SOTI MobiControl?Our environment:MDM: SOTI MobiControl Devices: Zebra MC9400 r

Hello,we currently use several FortiExtenders as WAN extensions in combination with 5G, SIM cards an IP passthrough. While this seems like the optimal solution we randomly encounter issues because the ISP assigns random CGNAT subnets through DHCP within 10.0.0.0/8. This seems completely random and may or may not conflict with our internal networks.I have thought about using the FEX in standalone NAT mode so I am able to use deterministic transit networks on the FortiGate. However in that case we lose the nice FortiGate integration & management.Has anyone an idea how this can be solved more elegant? Can NAT mode used while the extender is managed by FortiGate?

I have a FortiGate firewall with FortiGate switches all connected via Fortilink in the firewall.  I have a requirement to now connect 20 PLC devices that share the same ip addresses to our network.  I am not able to re-ip the PLC devices so need to figure out the correct NAT setup for this.  I have setup each PLC in its own vlan (Vlan 3001-3020). Each vlan its own unique subnet as the primary subnet (10.0.2.0/29…..10.0.2.210/29).  I then added the overlapping subnet (192.168.1.0/24) as a secondary subnet to each vlan.  Dnat and Snat ip pools have been setup for each device and firewall rules have been setup to allow the communication. The snat is working I am able to ping from each PLC device to the corp network.  The problem I have is the Dnat ping from the Corp network to each PLC device.  Because of the overlapping subnets the VIP is converting the traffic back to the 192.168.1.1 address and the firewall is routing all traffice back to one vlan not the correct vlan. I have searched

DescriptionTroubleshooting steps to take when there are no allowed web-filter logs in the FortiAnalyzer.ScopeFortiAnalyzer, FortiGate.SolutionWhen checking the FortiAnalyzer Analytics logs, it is possible to see there are no Allow web-filter logs:First thing needs to do is to verify if there are any Allowed traffic log in the Archived logs. Navigate to FortiView -> Log Browse -> Traffic logs of the selected device.If there are no allowed logs, it means the FortiGate itself does not generate the logs. Note that FortiAnalyzer can only process what is being received from the logging devices and does not generate the logs.To address this, FortiGate needs to generate the logs. The following article can be referred to on how to configure for all logs for traffic:Technical Tip: How to see all visited website URLs under web filter security logIf there are necessary archive logs, but no analytics logs, capture the following debug output:diagnose debug reset diagnose debug app fazsvcd 255

DescriptionThe signatures that can help block block Brotli Vulnerability (CVE-2026-111497) on FortiWeb.ScopeFortiWeb.SolutionCVE-2026-111497 is a Brotli Request Body http traffic.FortiWeb can help to block the header since it is encoded in protocol level.To do this, create a customer signature. Navigate to the CLI of FortiWeb and run the following commands sequentially:config waf custom-protection-rule edit "CVE-2026-111497" set action alert_deny config meet-condition edit 1 set request-target REQUEST_HEADERS_NAMES set expression Transfer-Encoding next edit 2 set request-target REQUEST_RAW_BODY set expression "\\x50\\x67\\x81\\x00\\x00\\x00\\x00\\x00\\xF8\\x97\\xFB" next end next end config waf custom-protection-group edit "node" config type-list edit 5 set

DescriptionThe reason FortiMail in Transparent mode does not generate Mail Event or History logs for SMTP sessions that match an IP-based policy configured with the Proxy Bypass action, whereas FortiMail will generate the Mail Event or History logs for SMTP sessions when the IP policy action is set to "scan," and how to troubleshoot. ScopeFortiMail (Transparent Mode). SolutionIn FortiMail Transparent Mode, when a session matches an IP Policy with the Proxy Bypass action, FortiMail forwards the traffic at the network layer without engaging the SMTP proxy engine. As a result, the session bypasses processing by smtpproxy and mailfilterd entirely, which means there will be no Mail Event or History logs generated. For the administrator to generate logs for troubleshooting purposes, the admin can either move that specific Source IP from the current policy to a new policy with the action set to "Scan" or change the action of the existing policy to "Scan" instead of "Proxy Bypass" Proxy Bypass

DescriptionIn FortiSIEM, a custom Performance Monitoring object may not start monitoring an already discovered device after the custom monitor is added. The monitoring job may not display the green OK status in the Monitor Performance page, and the expected performance metrics may not be collected.ScopeFortiSIEM.SolutionUse the following steps to troubleshoot the issue.Log in to the FortiSIEM GUI.Navigate to Admin -> Setup -> Monitor Performance.Locate and select the affected device.Disable monitoring for the selected device.Wait a few minutes, then enable monitoring again.Refresh the Monitor Performance page and verify whether the monitoring job displays the green OK status.Confirm that the expected performance metrics are being collected.If the FortiSIEM 7.x issue persists, the alternative workaround documented in the Release Notes is to delete the affected device from the CMDB and rediscover it. Before proceeding, assess the impact of removing the device and ensure that redisc

DescriptionThe one-arm sniffer addressing mode remains visible in the GUI when an interface role is set to WAN.ScopeFortiOS.SolutionThe one-arm sniffer addressing mode should not be visible in the GUI when the interface role is set to WAN as mentioned in the document: One-arm sniffer.This only means that the one-arm sniffer mode is hidden on the GUI level: not on the functionality level. When the one-arm sniffer mode is selected before the role of an interface is set to "WAN", or when the one-arm sniffer is enabled via CLI, the option will remain visible in the interface GUI. The firmware does not restrict the users to set the addressing mode to one-arm sniffer in the interfaces with a role WAN. It only attempts to hide the option from the GUI.Two methods to enable the one-arm sniffer on a WAN interface:Using the Command Line Interface (CLI) below on an interface with the "WAN" role:config system interface edit <interface_name> set ips-sniffer-mode enable next end

DescriptionWhen the Web Filter extension is not uninstalled when the endpoint moves from on-fabric to off-fabric while 'Keep Extension When Endpoint is Off-Fabric' is disabled and 'Web Browser Plugin for HTTPS Web Filtering' is enabled.ScopeFortiClient Endpoint version 8.0.0, FortiClient Windows.SolutionIssue scenario: FortiClient v8.0.0.0103 GA.Enable the Web Filter profile.Disable 'Keep Extension When Endpoint is Off-Fabric'.Enable 'Web Browser Plugin for HTTPS Web Filtering'.Verify the extension is installed while on-fabric.Move the endpoint to off-fabric and observe that the extension is not uninstalled. Issue resolved In: FortiClient version 8.0.1. Solution description:Fixed a bug where the policy watchdog unconditionally re-added the browser extension force-install policy. The fix ensures that when 'Keep Extension When Endpoint is Off-Fabric' is disabled, the policy is removed during the transition to an inactive filtering state (including on-fabric to off-fabric). Both the perio

DescriptionUsers are automatically logged off from FortiGate Single Sign-On after enabling the Enforce Kerberos setting in the Collector Agent.ScopeFortiGate, FSSO Collector AgentSolutionA known issue exists where the workstation check fails when "Enforce Kerberos" is enabled. Users are de-authenticated when the workstation check fails after the dead entry timeout.Upgrade the FortiGate Single Sign-On Collector Agent to version 5.0.0335 or later. This version addresses WMI workstation check failures when "Enforce Kerberos" is enabled by adding reverse DNS lookup to resolve workstation IP addresses to hostnames.Download the FortiGate Single Sign-On Collector Agent version 5.0.0335 from the Fortinet Support Portal.Install the updated Collector Agent on the server.Enable the "Enforce Kerberos" setting in the Collector Agent configuration.Monitor the user sessions to verify that they are no longer automatically logged off after one hour.Related article:Technical Tip: FortiGate FSSO Collecto

DescriptionFortiClient Endpoints that are members of a specific Entra ID group do not match the corresponding group policy in FortiClient EMS. These endpoints are assigned to the default policy.ScopeFortiClient EMS and FortiClient Endpoint.SolutionFortiClient EMS cannot correctly retrieve the Azure device object ID for certain users. This occurs when a mismatch or failure happens in the lookup process between the reported user identity and the Entra ID device object, resulting in a 404 Not Found error during the API call to Microsoft Graph.Error example:ERROR update/sysinfo.go:344 [TID:KiK5dhcVVQ][site:default][uid:A11E1B23714F48A4910032061E4E7122]: Could not get azure device object id: search for device object id: http.GET(https://graph.microsoft.com/v1.0/devices(deviceId='0e427e3a-5d65-40bb-bfa5-b1b72f940d1b')?%24select=id) return status: 404 Not FoundPermanent solution: Update FortiClient EMS to version 7.4.8 or above. This version includes the fix for the identity matching bug.If u

We are experiencing an issue where some client devices cannot connect to Wi-Fi after upgrading our FortiGate 101F and FortiAP 231F environment to FortiOS 7.4.13, what can I follow up

We created site to site ipsec vpn Between two fortigate firewall... One firewall OS 7.6.6 & another firewall OS 7.4.2..we entry the data exact the same to both firewall like Ike v number ,  DH,  Encryption protocol etc but tunnel not working. Please help is there any solution for it 

I'm looking to go from 7.4.x to 7.6,.xI already upgraded Fortimanager. We normally make a new ADOM and migrate.However I see people just update the existing one since 7.6 ADOMs can manage 7.4 devices.Any opinions on which is a better practice?

DescriptionAfter an upgrade from versions 7.0.14, 7.2.8, and 7.4.4 to versions 7.0.15, 7.2.9, and 7.4.5, the rxqid value was changed and may cause RX drops on the interface.ScopeFortiOS.SolutionSymptomsUnder system 'affinity-packet-redistribution ' is the rxqid setting. It is the ID of the receive queue on an interface used to perform packet redistribution across multiple CPU cores. The value is from <0> to <255>.In 7.0.14, 7.2.8, and 7.4.4, the default value is 0. After upgrading FortiOS to 7.0.15, 7.2.9, 7.4.5, and above, the default value is changed to 255. In some cases, it can cause an increase in interface RX drops.7.0.14 7.2.8 7.4.4:FGT # get system status | grep Version: Version: FortiGate-VM64-KVM v7.4.4,build2662,240514 (GA.F) FGT # show system affinity-packet-redistribution config system affinity-packet-redistribution edit 1 set interface "port2" set affinity-cpumask "0xff" next end FGT # show full system affinity-packet-redistribution c

DescriptionThe public IP address migrations for the FortiIdentity Cloud North America and India regions, which began on October 10, 2026, are now complete. In North America, both the primary and disaster recovery addresses were successfully changed, and in India, the migration was scoped to the primary datacenter IP address.. This article explains the impact of the change and the recommended actions.ScopeFortiIdentity Cloud (formerly FortiTokenCloud).SolutionNo action is required for normal access when service endpoints are reached by FQDN and resolved through DNS. With the change now complete, DNS automatically returns the new IP addresses, so applications, integrations, and end-user access continue working without modification.If you use a ZTNA tunnel to connect to an on-premises LDAP server, allow the following IP addresses for your region: 154.52.17.20 and 141.109.161.3 in North America, and 189.25.3.92 in India.Action may be required for environments using IP-based access controls

Hello, our organization recently obtained a few MacBook Neos and Airs to test, running on macOS 27 Golden Gate. However, after installing FortiClient and connected to the office network, at random times, the Wi-Fi and Bluetooth would switch off and cannot be turned back on manually. After 2-3 minutes of this, the MacBook will then freeze then immediately restart on it’s own. Following a restart, everything seems normal, but this issue can repeat multiple times in a day, but as the day goes on, it becomes stable. This happens the moment I disconnect and reconnect back to the office network. Especially after bringing home and returning to the office with the MacBook. This issue does not happen with a private home network or hotspot. Resetting the MacBook does not resolve the issue either. When FortiClient is not installed, the MacBook behaves normally. 2 older MacBooks obtained last year does not experience this issue. We have disabled / blocked Apple Account login, Mail, Calendar, iClou

DescriptionThis article explains how to restore a policy block rule that was edited, disabled or deleted directly on a FortiGate. It also explains the two warnings that the Import Configuration wizard shows for a policy package that uses a policy block, and what not to do.ScopeIt applies to firewall rules that FortiManager installs from a policy block and that were then changed directly on the FortiGate. It does not cover changes made to the block in FortiManager itself.SolutionWhich way to go: if the change made on the FortiGate is unwanted, install the policy package to that device (section 3). If the change is wanted, make it in the policy block in FortiManager (section 4). Do not use Import Configuration for either case (section 5).How a policy block rule appears on the FortiGate.A policy package stores only a reference to the policy block. At install, FortiManager expands the block into normal firewall policies. The FortiGate has no policy block concept and shows the rules as ordi

fortigate FG201f running 7.4.12 b2902forticlient 7.4.8, managed by forticloudintune pki (CloudPKI)the payload (via sniff) appears to be sent, but fortigate ignores as the tunnel has been ignored.wanting to set up a device cert based TCP IPSEC tunnel.  end goal is for the device to connect without user involvement.from the ike debug logs:session started on tcp 8443proposal acceptedcert requestedcert sent (in 6 piecescert received and reassembledclient details sent, mostly correct except the OSVER.  this is a Win 11 devicepeer is matched“AUTH payload not received”tunnel is closed How do I diagnose why the tunnel was closed?  Why is the OSVER wrong? debug log:ike V=root:accepts ike tcp-transport(vd=0, vrf=0, intf=0:27, 162.252.yyy.yy:8443->142.167.xx.xx:58204 sock=42 refcnt=2 ph1=(nil)) (1).ike V=root:0: comes 142.167.xx.xx:58204->162.252.yyy.yy:8443,ifindex=27,vrf=0,len=606....ike V=root:0: IKEv2 exchange=SA_INIT id=225ee7034892962d/0000000000000000 len=606ike 0: in 225EE7034892962

Trying to create IPSEC Dialup using device certificates.  The authentication is not succeeding.This is the ike debug log:ike V=root:0:EMS-TCP-VPN:179: received FCT-UID : 66FEE5B1BADB40A799FEAAD9D836EFF4ike V=root:0:EMS-TCP-VPN:179: received EMS SN : FCTEMS8825002268ike V=root:0:EMS-TCP-VPN:179: received EMS tenant ID : 00000000000000000000000000000000ike V=root:0:EMS-TCP-VPN:179: received peer identifier DER_ASN1_DN 'CN = xxxx-000000'ike V=root:0:EMS-TCP-VPN:179: match gw peer ID by FNBAMike V=root:0:EMS-TCP-VPN:179: AUTH payload not receivedike V=root:0:EMS-TCP-VPN:179: schedule delete of IKE SA 7bd8a3c30b6c6d6f/7234bdc65e60b4a4ike V=root:0:EMS-TCP-VPN:179: scheduled delete of IKE SA 7bd8a3c30b6c6d6f/7234bdc65e60b4a4ike V=root:destorys tcp-transport(vd=0, vrf=0, intf=27:27, 162.252.xxx.xx:8443->142.167.xx.xx:53461 sock=42 refcnt=0 ph1=(nil)) (0).ike V=root:0:EMS-TCP-VPN: connection expiring due to phase1 downike V=root:0:EMS-TCP-VPN: going to be deletedike V=root:0:EMS-TCP-VPN: res

I'm looking to go from 7.4.x to 7.6,.xI already upgraded Fortimanager. We normally make a new ADOM and migrate.However I see people just update the existing one since 7.6 ADOMs can manage 7.4 devices.Any opinions on which is a better practice? 

Restore Fortianalyzer logs from old to new via "execute restore logs-only all sftp ip of server user id and password / (or /home/logs" I get error diagnose log restore cancel

 Since the update to version 7.4.13 build2933, emails are no longer sent to users whose username exceeds 36 characters.I am referring to the emails containing the QR code for FortiToken Mobile. Version: FortiGate-901G v7.4.13,build2933,260929 (GA.M) 

 Hello community,I would like to know whether the newly available FortiOS v7.4.13 (Mature) release addresses and fixes the multiple CVEs (Common Vulnerabilities and Exposures) identified in previous versions.  Regards,Lengai