Fortinet Community

I was doing some troubleshooting today and I kept getting errors when trying to save my DoS policies. Turns out that 7.4 uses the individual interfaces, despite the interfaces being in an SD-WAN zone. In 7.6, all of the DoS policies use SD-WAN zones and NOT the interface. I somehow missed this in any of the release notes, but wanted to mention it hear in case it's giving anyone else problems. 

Hello,I’m creating this Topic because I’m facing an issue that neither me, Dell or our Forticlient provider faced before and we both have no idea what exactly is going on. We ordered a batch of Dell Computer Pro 3 14260. Those computers are facing kernel boot trap double fault with fortishield.sys. It occurs most of the time when the computer is booting with Forticlient 7.2.15.1309, but also very often when connecting or disconnecting of Forticlient. We also tried with 7.2.14 and 7.2.13 with same issueOur EMS is in 7.2 so we can’t try 7.4 for now it’s ongoing we have to build a linux machine for the upgrade.We don’t have this problem with any other dell computer model Of course if I don’t have Forticlient installed I don’t have any issueI’m trying to compare the components for those computers and see what could be conflicting but extremely difficult  I just know it’s something with fortishield.sys as it is mentioned in the minidumps If anyone faces this (no result on forum search) or h

Failed to perform SNMP connect. Please verify that the device can be contacted via ICMP (ping), and that the SNMP credentials are correct.Ping worked, SNMP was enabled on the FortiGate interface, and the SNMPv3 settings matched on both sides. A packet capture on the FortiGate showed UDP 161 requests arriving from FortiNAC, but the FortiGate did not respond.The cause in my case was FortiGate administrator Trusted Hosts. The FortiNAC source IP was not included in the permitted hosts for an administrator account with Trusted Hosts configured. This prevented the SNMP request from being processed, even though it reached the FortiGate.To resolve it:Identify the source IP FortiNAC uses to reach the FortiGate.In System > Administrators, review the accounts with Restrict login to trusted hosts enabled.Add the FortiNAC source IP as an allowed trusted host in all the administartors.Save the change and run Validate Credentials again in FortiNAC.The FortiGate was added successfully after the Tru

Hi guys,I have FortiGate VM 7.6.6 on windows 10 with Hyper V &  FortiSwitch 124F 7.6.6I configured Software switch with Fortilink and following this KBi have enabled MAC spoofing on the Hyper V VM networkso when I connect the Fortiswitch to my computer its receiving DHCP, then I authorize  it on the FortiGateat first it seems that Fortilink is up and after a few seconds its down and I also no longer have ping to the Fortiswitch this is my interface settings config system switch-interface    edit "FortiLink2"        set vdom "root"        set member "port2"    nextendconfig system interface    edit "FortiLink2"        set vdom "root"        set fortilink enable        set ip 10.200.0.1 255.255.255.0        set allowaccess ping fabric        set type switch        set lldp-reception enable        set lldp-transmission enable        set snmp-index 15        set switch-controller-nac "FortiLink2"        set switch-controller-dynamic "FortiLink2"    nextendI would appreciate it if someo

I have multiple IPsec site to site VPNs and remote access VPNs but all the tunnel shows in same table and there is not any option to see this is site to site and this is Remote access VPN tunnel.To verify that I need to open every VPN every time and check this is site to site and this is remote VPN.Like there are option in sophos firewall that we can differentiate this is remote and this is site to site.I faces issue multiple time during troubleshooting and every time need to open tunnel and verify that is remote access or site to site

HelloI've been tasked with migrating from a 60E to a 70G.7.4.12 to 7.4.12A backup and a read-only user in the 60E was given to me.I've participated in this procces before but now i'm alone.Any usefull advice?

Hi everyone,Since a few days FW can’t access the servers and we’ve lost our access for a few users (with quota, app and YT supervision). Licenses are up to early 2027.I noted the firmware was coming to EOS on 10/01. I followed the troubleshooting tip on the community and got this result in the cmd prompt:FGD_DNS_SERVICE_LICENSE:server=139.138.105.53:853, expiry=0000-00-00, expired=1, type=0server=173.243.140.53:853, expiry=0000-00-00, expired=1, type=0Thanks for any help.Sylvain

Hi everyone,We are currently facing a weird issue on our network and I'm hoping someone here might be able to point me in the right direction.A few of our employees in the finance and HR department need to access an online UK tax and salary calculation portal for payroll verification.However, whenever they try to open it from their office machines connected behind our FortiGate firewall, the page either fails to load or shows a block/timeout error. Interestingly, it works completely fine on their mobile data or home networks, which confirms the issue is strictly related to our corporate network setup.Here is a quick overview of our current setup:FortiGate Model: FortiGate 100FFirmware Version: FortiOS 7.2Features Active: Web Filtering, SSL Inspection (Deep Inspection), and FortiGuard Categories.I checked the FortiGate Log & Report section under Forward Traffic and Web Filter, but nothing obvious stands out immediately blocking it—though it might be falling under a strict category o

Hello,Our client used to be able to connect to our website but is now blocked since the end of July.The error:Fortinet" wasn't installed properly on your computer or the network. Ask your IT administrator to resolve this issue.NET::ERR_CERT_AUTHORITY_INVALIDPlease install a root certificate for "Fortinet". We recommend your IT administrator read the configuration instructions for "Fortinet" to resolve this issue. Antivirus, firewall, and web filtering or proxy software are among the applications that can cause this issue. What could be the reason? How can we debug it with our client? Thanks

What would cause apple devices running ARD to disappear in network list when there are more devices connected and reappears when there are less devices? This is a FortiAPs/FortiSwitches environment. 

I have been running FortiClient 7.4.8 on my endpoints, all of which are Windows 11 devices fully compatible with the FortiClient agent.Recently, I have been experiencing an issue with Google Chrome. Whenever FortiClient requires an update and prompts for a system reboot, after the endpoint restarts, the Chrome configuration appears to be partially reset. It seems as though the browser's local data or cache has been cleared, causing some settings to be lost.The behavior is almost as if Chrome had been reinstalled or its user profile had been recreated after the reboot. The most noticeable impact is that browser extensions lose their configuration and must be set up again.Has anyone else experienced a similar issue with Chrome following a FortiClient update? Does anyone know what could be causing this behavior?I suspect it may be related to the Anti-Exploit feature or possibly the Web Filter browser extension, but I have not been able to confirm the root cause yet.Any insights or recomme

Our company is transitioning from SSL-VPN to ZTNA.  We have been testing ZTNA on 2 devices.  It seems Windows built-in applications are extremely slow to open.  For an example, when ZTNA is enabled, task manager took 17 seconds to open, command prompt took 39 seconds, recyle bin took 1 minute to open.When ZTNA was disabled, task manager took 1.81 seconds, command prompt took 1.18 seconds. and recycle bin took 1.81 seconds.  This is a big difference.  For a basic configuration, we are using ZTNA destinations and tags in EMS and ZTNA servers and firewall policies on the Fortigate.  To resolve internal FQDN’s, I have configured DNS servers on Fortigate forwarding DNS request to internal DNS servers.  We have also setup a KDC proxy which may have helped slightly.  Has anyone experience this before and is there a configuration fix for this?  In my testing everything works pretty well except for group policy.  The only big issue is slowness opening these types of applications.  

HiI have reviewed the FortiClient website and available documentation, but I was unable to find any clear resources explaining how to deploy FortiClient together with the required configuration VPN profile via Intune for Windows users.deployment with a preconfigured setup is supported? If so, please provide the relevant deployment guide, configuration documentation, or recommended deployment method.

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

When IKE-over-TCP and HTTPS administrative access share the same TCP port (commonly TCP/443) on an interface bound to an IPsec tunnel, HTTPS management access becomes unavailable. Web browsers attempting to connect to the FortiGate GUI typically return an ERR_EMPTY_RESPONSE error.This document explains why this local service listener conflict occurs, how to verify it, and how to safely recover GUI access.Root CauseThis issue is caused by a local FortiGate service binding conflict, not an upstream firewall policy issue. When both IKE-over-TCP and HTTPS administrative access are assigned to the same port on an IPsec-bound interface, FortiOS grants listener precedence to the IKE daemon. Consequently, incoming TCP/443 connections are handled by IKE, causing the HTTPS daemon to become unreachable on that interface.Note: Allowing UDP/500 and UDP/4500 on an upstream firewall does not resolve this conflict. Upstream policies control path transit, whereas FortiGate service bindings control whic

Hi Fortifiers,I just wanted to do a quick post for the community that I thought might be interesting to some. Many organisations share the same network segment between wired and wireless clients. While this can simplify network design and conserve address space, it may introduce an overlooked security consideration. In some scenarios, normal Layer 2 communication can expose the MAC addresses of wired devices over the air, potentially providing useful reconnaissance information to an attacker.You may have unintentionally increased your attack surface by exposing additional Layer 2 information to wireless observers. This includes possible:MAC discovery  Device/vendor reconnaissance  Visibility of wired endpoints  Potential pretext for spoofing attacksThe likelihood of an outsider discovering the MAC addresses of your wired clients may seem hard unless they connect to the wired network themselves. But when it comes to sharing the same segment with wired and wireless, you are more than lik

Hi Everybody,We are running a Kubernetes cluster on Rocky Linux 10.2 VMs, with the FortiEDR Linux Collector installed on the host OS.When FortiEDR Communication Control was changed from Simulation to Prevention, the entire Kubernetes cluster became unavailable. After changing the policy back to Simulation, the cluster recovered and became operational again.I have allowed everything regarding the connections to the outside after checking with my Dev Ops Engineer and we see no new logs regarding the communication control. The affected nodes reported this kernel message:Failed to initialize the IGMP autojoin socket (err -1)FortiEDR Collector version: 6.2.0.1350I double-checked the FortiEDR Events and Communication Control logs, but there were zero events showing that anything was blocked or denied by FortiEDR.Has anyone experienced a similar issue with FortiEDR Communication Control and Kubernetes? If you have any ideas or troubleshooting recommendations, I would really appreciate your he

As discussed, while using FortiClient, we have observed an intermittent behavior when incorrect credentials are entered. In some instances, the expected incorrect credentials/error prompt is not displayed, whereas in other instances, the prompt appears as expected.To further investigate this behavior and identify a possible resolution, we have also posted the issue on the Fortinet Community for additional inputs and recommendations.We request you to kindly share any suggestions or recommendations from your end that may help us troubleshoot and resolve this intermittent behavior.We will continue to monitor the behavior and share any further observations or updates.

I haven’t been able to connect to my company network with Forticlient for the past two weeks. The latest versionof Forticlient vpn installed is 7.4.3 hotfix 1.8758. I keep getting a “connection timeout” error. I tried running it as an administrator, but that didn’t fix it. I uninstalled and reinstalled it, but that didn’t work either. I tried installing older versions, but that didn’t solve the problem either. The strange thing is that I can connect from some computers but not others. My Windows updates are also up to date. For example exact same windows uptade version and same forticlient vpn config but one computer can connect but other cannot.

Hi,a few days we updated from FortiOS 7.2.13 to 7.6.6.Now we can’t download “*.xlsx” files, because our DLP profile is blocking that.But we have only “*.xls” configured for blocking and not “*.xlsx”.When i remove the “*.xls” pattern, we are able to download “.xlsx” Files again.It looks to me that he is using “*.xls*” when entering “*.xls”. Is this a bug or a expected behavior? What do i need to enter, when i only want to block “*.xls” and not “*.xlsx”?A second problem, when i edit the DLP profile i can’t see the file types and can’t edit them. A other admin who is in the same admin group see 2 more colums in the profile table and is able to edit the file types. I switched on already all features in the feature visibility and cleard the browser cache, but no change. Has someone a hint for me?Kind regardsStefan

Hi community,I am very familiar with configuring FortiGate Web Filter policies using traditional Active Directory via LDAP and FSSO for user and group-based rules. However, we are moving to a pure cloud environment with Microsoft Entra ID (Azure AD), and I want to achieve the same group-based web filtering capability.Environment Details: FortiGate Model: FG-120G FortiOS Version: 7.6.7 Identity Provider: Microsoft Entra ID (No local Domain Controller / No FortiClient EMS) Since Entra ID does not support native LDAP out of the box like traditional AD DS, I understand that integrating Entra ID with FortiGate for user-based policies relies on SAML 2.0.My Questions: What is the recommended workflow to map Entra ID User Groups (Object IDs/Claims) into FortiGate user groups for policy enforcement? How does FortiGate handle transparent user identification and policy matching for web traffic when using SAML instead of classic LDAP/FSSO queries? Are there any best practices or step-by-st

Hello Fortinet community,We are trying to connect our Fortigate 100F (7.6.7) to our RADIUS server (Windows NPS) but the NAS-IP of the Fortigate is designed to only accept IPv4 addresses. In our case, the NAS-IP needs to be the gateway of one of the interfaces on the Fortigate (configured as aaaa:bbbb:cccc:dddd::1) which is autorised in the NPS server According to the CLI reference, the field is hardcoded to use legacy IPv4 which I do not want to enable on my network :set nas-ip {ipv4-address}Are there any plans to add IPv6 support to this field ? Thanks

FortiGate-A ↔ FortiGate-B IPsec Tunnel – BGP TCP/179 Return Traffic Not DecryptingHi Fortinet Community,I am troubleshooting a BGP connectivity issue over an IPsec tunnel.Environment:FortiGate-A: FortiGate 60F FortiOS: 7.4.11 GA FortiGate-B: Remote FortiGate IPsec: IKE/IPsec with NAT-T BGP: TCP/179IssueThe BGP session is not establishing over the IPsec tunnel.Troubleshooting performedThe IPsec tunnel is UP and DPD status is OK. NAT-T is enabled and UDP/4500 traffic is observed in both directions. FortiGate-A generates the BGP TCP/179 SYN and sends it through the IPsec tunnel. Flow debug confirms that the packet enters the IPsec interface and is encrypted successfully. On FortiGate-B, the SYN-ACK is generated and confirmed to be taking the correct return path toward FortiGate-A. On FortiGate-A, the return UDP/4500 packets from FortiGate-B are visible on the WAN interface. However, the IPsec dec:pkts counter does not increase when the return traffic is generated. The decrypted inner TCP/

Hi everyone!On my FortiAuthenticator running version 6.6.10, I've connected a remote LDAP server and already imported the first batch of users. As a second step, I've set up a sync rule for it.I'd like to clear up a few doubts regarding the sync rule, and confirm whether the following understanding of the automatic enablement (for new users imported via the sync rule) is correct:Under Synchronization attributes → OTP method assignment priority: do I just need to move SMS to the top of the list and flag/enable it? Is that the only step required ? (see screenshot below)*   What sync interval would you recommend? Is every 30 minutes a reasonable value ?   Finally, if I understood correctly: for users that already exist on FAC (previously imported), the sync only updates already-mapped attributes (e.g. phone number, email) — is that correct ?* Thank you all in advance!"This is the way"