Support Forum

Hi Fortinet Team, FortiClient EMS certificate not authorized..I am experiencing an issue connecting my FortiGate-90G to an On-Premise FortiClient EMS server via the Fabric Connector. The connection fails with certificate verification errors.Environment Details:FortiGate Model: FG-90G FortiGate and EMS Location: Both devices are in the same local subnet (192.168.2.x). DNS Setup: Configured via a Local DNS Database entry on the FortiGate, pointing the FQDN to the local EMS IP. Pings to the domain name resolve correctly. EMS Certificate: A valid Public Domain Certificate issued by RapidSSL / DigiCert (Domain: winxsfp.com). Symptoms & Errors Observed:The Fabric Connector GUI shows an "Untrusted Certificate" status. I have disabled strict common name checking using the set trust-ca-cn disable command under config endpoint-control fctems, but the issue persists. Running the verification command in the CLI results in the following error output: text FortiGate-90G # execute fctems verify 1

I had automatic updates turned on on my fortigate 60F. After Installation of OS 7.4.12 none of my VPN-Clients were able to login anymore. No idea why. Reverting to 7.4.11 resolved the problem. Does anyone have an idea what exactly caused the problem? I am not an fortigate expert but that a minor update to the os breaks a basic functionality, at least on my device, doesnt make me happy. First thing i learned was turning off automatic updates. But thats not a longterm strategy.  

Hello,we have upgraded our FortiClient EMS Cloud instance to 7.4.7 recently, and we can’t seem to upgrade our FortiClients, because we are unable to choose a FortiEDR engine.The dropdown menu to select an engine version for the FortiEDR feature has nothing to select. Even when dropping down to other FortiClient versions we can’t pick any FortiEDR engine version. The fabric connection between the FortiEDR Cloud and FortiClient EMS Cloud instances are up. The installer is for regular Windows Clients.The same problem goes for our customers FortiClients EMS Cloud instance. So it seems to be a problem with the 7.4.7 version of FortiClient EMS Cloud?Also, the docs page for FortiClient EMS is currently down with the code 500 internal server error. So we can’t even look up known issues for the new FortiClient EMS version.

we have recently deployed a new FAZ300G analyzer to replace our old 200D.For internet traffic for the analyzer, what are the recommended URL or internet service that is required/permitted for the analyzer to work properly.

I've got a user whose IPsec Remote Access VPN won't ping out when connected. It can access a file server via IP address (despite failing to ping it), but it's not able to get DNS, nor can I ping the DNS server or anything external.The FortiGate is a 90G on 7.4.12, using the latest FortiClient VPN Only version (7.4.3.8758). There are a dozen or so other users currently using the same VPN connection, and I've confirmed that the policies haven't changed.As soon as we disconnect VPN, normal web traffic resumes, including the ability to ping.Any ideas? 

 FortiToken Mobile (FTM) push notifications provide a convenient MFA experience, but many organizations want additional controls to ensure push authentication is only available from trusted network locations.A simple way to reduce the attack surface is to route FortiToken Mobile push traffic through a dedicated loopback interface and then control access using firewall policies. This allows administrators to limit where FTM push requests can originate, such as corporate Wi-Fi, internal LAN segments, or approved VPN networks. Step 1: Create a Loopback InterfaceCreate a loopback interface that will be used exclusively for FortiToken Mobile communication.config system interface edit "FTM-Loopback" set type loopback set ip 10.255.255.1/32 nextend Step 2: Configure the FTM Push ServerConfigure the FortiToken Mobile push service to use the loopback address.config system ftm-push set server-ip 10.255.255.1endThis forces FTM push traffic through a dedicated interface that

Trying to get FortiGate VM 7.6.7 registered and controlled by FortiMan VM 7.6.7Cert is used as part of the authentication, the serial number is expected to be in the cert as the CN, but its not  We can see this by using debugs   diagnose debug resetdiagnose debug enablediagnose debug application depmanager 0diagnose debug application depmanager 255diagnose debug enable  Clearly the serial number is required   { "id": 1, "result": [{ "status": { "code": 5, "message": "device serial number conflicted"}, "url": "start\/probe\/session"}]}We can get passed the serial number issue by creating a new cert  i found that i have to use this low key size of 512, anything higher wont be accepted   openssl req -x509 -newkey rsa:512 -nodes -keyout fmg_tunnel.key -out fmg_tunnel.crt -days 365 -subj "/CN=MYSERIAL/O=Fortinet/OU=Lab"openssl pkcs12 -export -legacy -out fmg_tunnel.pfx -inkey fmg_tunnel.key -in fmg_tunnel.crt and now the issue is different  { "client": "\/bin\/dvmcmd:5115", "id": 2, "method

Environment:FortiManager 7.6.1 FortiGate-VM64-KVM, FortiOS 7.2.0 build1157, Evaluation License (15-day) ADOM version 7.2Issue:When installing a Policy Package from FortiManager to a managed FortiGate, the install fails with:  post_vdom copy error::(errcode)3 - max entry. object: firewall policy. detail: global limit. solution: limit is 3This strongly implies a hard cap of 3 firewall policies enforced during the FMG→device install process.However, this is demonstrably NOT a device-side limitation. Running show firewall policy directly on the same FortiGate via console/SSH shows 7 policies already present and fully functional, created locally without any issue:  [paste your 7-policy output here]This proves the FortiGate itself accepts well more than 3 policies. The limit is only encountered when FortiManager performs the install — meaning the restriction lives somewhere in FortiManager's install/validation logic (or possibly an ADOM/device-DB setting), not in the FortiGate's own firewall

Hello community, Im once again dealing with FortiNAC, as my company is been back and forwards with it.For example using Cisco ISE, we configure 802.1x on the switches, Cisco ISE validates certificate or username (if im not mistaken) and thats usually the way to go with ISE.My question is: whats the equivalent of what I mentioned for ISE on FortiNAC? Does it support 802.1x at all in the same way ISE does? And if it does, is that the common way to go with FortiNAC. If not, well, whats the common way to go?I got that FortiNAC support a lot of protocols, but thats actually what confuses me, it supports so many stuff that I don't know what to do or whats normally done out there in most scenarios (even though no environments are the same :)I guess Im asking for a practical aspect, I would like to know how are the most FortiNACs deployed out there, real case scenario in this aspect based on real world experience deploying/managing this monster.

I have an issue with Fortiswitches 2048 and a Cisco CBS 350 switch. I had in the Fortinet SFP Finisar and in the Cisco i had a multimode SFP Cisco. The link of the two switches is down and i don’t know why. I replaced the Finisar module with Cisco and the result was the same. Also, i changed the speed from Fortiswitch to 1000 and i didn’t see any change.Inside of the interface of Cisco , there isn’t choice for auto negotiation. The config is trunk with specific vlan and native another vlan from 1. Also, i change the STP to RSTP without any result and i don’t believe the problem was with spanning tree because the the issue is in Layer 1 and not Layer 2. The output of the tranceiver of finisar in Fortiswitch is the below:StatusOKTemperature27.109375 CVoltage3.319000005722046 voltsOptions0x000F: TX_DISABLE, TX_FAULT, RX_LOSS, TX_POWER_LEVEL1Options Status0x0008: TX_POWER_LEVEL1Alarm Flags0x0000Warning Flags0x0000Laser Bias5.624000072479248 mAmpsTransmit Power-4.974363327026367 dBmReceive

We required otp through sms and authentication code through Google authenticator or Microsoft authenticator. Pls evaluate and confirmin scnerio of fortiauthenticator as saml idp and forticlient ems and saml sp please confirm 

Hello,I have complain from user that they have application but not running, after i do investigation by remove web filtering from the policy the application is running. Then i make a new web filter and set all categories to 'enable' and apply to the policy, and unfortunately the application didn't work anymore, then i remove again this web filter from the policy and the application running back.So here i want to know if there any difference between we set all categories on the web filter to enable then apply to the policy with no web filter on the policy?

Hi all,We're looking at FortiSASE to possibly replace Cato SASE (a different debate).What mechanisms does FortSASE have to ensure only corporate devices connect? Does it support Entra Conditional Access Policies and Compliance checks?Can we use our machine certificate and authenticate based on that? 

OS - 6.4 I am trying to understand the behavior with this setting and when it should be used. Assuming we have multiple Internet healthchecks with this setting enabled across multiple SD WAN rules we use for steering, what would the impact be?   Based on the this article it sounds like it would remove our default route which we probably don't want.https://kb.fortinet.com/kb/documentLink.do?externalID=FD44679 I am probably missing something here.  Any guidance would be much appreciated.     

Hi @community,We are using the external manual input feature via email links in FortiSOAR and When a user clicks the link, it opens the standard manual input pop-up window. We are facing a couple of UI limitations and wanted to check if there are any workarounds: Pop-up Size: Is there a way to increase the dimensions (width and height) of the input template? The current text area is quite small for analysts to provide detailed inputs. Draggable Window: Is it possible to make this pop-up window draggable? We want analysts to be able to drag the popup aside so they can read the underlying alert data while filling out the form.   Any suggestions or guidance on this would be greatly appreciated.Thank you.

We pay for premium support. One of the reasons is when we have an issue with a firewall or device, we can call in to get help and resolve the issue immediately. This especially important in an MSP setting, where we have to go on-site for troubleshooting and don't have the luxury of waiting until they call us back. We can’t leave the site (which sometimes are hours away) and then travel back to the site when they call back. This is very concerning and a very bad support move. 

Hello everyone,At the moment i experience an issue with the FortiMail API when trying to retrieve the artifacts of a specific incident using it's session ID.When I try to send request, the API returns all incidents from the selected directory instead of the specific incident associated with the session ID.Could someone please advise on the correct way to retrieve a single incident by its session ID? Am I missing a required parameter or using the wrong endpoint?Any help would be greatly appreciated. Thank you!

Hi everyone,I am looking for the FortiClient VPN v6.0 (or any stable 6.x version) 32-bit installer.I need this specific 32-bit version to manage deployments and clean up large-scale uninstallations via Microsoft Intune on our remaining 32-bit Windows PCs.I've searched through previous community posts, but unfortunately, all the shared download links for the older v6 32-bit installers have expired.

I updated the FortiGate from FortiOS 7.6.6 to 7.6.7 and am experiencing issues with SSL inspection certificates.After the update, the firewall started dropping all traffic. Even traffic matching firewall policies without SSL inspection enabled is being dropped.As a temporary workaround, you can disable SSL inspection globally to restore connectivity.Has anyone else encountered this issue after upgrading to version 7.6.7? Is there a known bug or a recommended fix?Update:Not logging dropped packetsFirewall memory usage reaching 90%Thousands of active sessions (compared to normal levels)

I'm having an issue with devices accessing internal netowrk equipment using IPSec VPN and connected to the Guest WiFi of the same Firewall we're trying to remote in.  Some details about the setup, we have a firewall in place and we're broadcasting LAN and Guest WiFi SSIDs.The Guest WiFi is isolated and can only reach the internet with some webfiltering and ssl inspection.Devices that are connected to the Guest WiFi cannot communicate with the LAN Network, setup by a Firewall policy. Dialup IPSec VPN has been setup so the remote users can access a spesific server to the internal network (LAN).This is working as a charm when we're using mobile hotspot or another ISP connection outside the office's building. The problem is when we're at the office we have some personal devices we have to connect to the Guest WiFi for security purposes and althought we're able to esablish a connection using our Dialup IPSec VPN our computers cannot reach the spesified server on the inte

Hi!  I’m seeking clarification of KB 96255. I read it as that there are two different types of triggers for a session drop due to idle-timeout - (a) for a session in TCP Established state - resulting in log message with “action=close”; and (b) TCP session in an embryonic state resulting in log message with “action=timeout”. However, this contradicts my experience - for Log message logid=0000000013 with “duration=4376”, “rcvdbyte=64713”, “sentbyte=29953” (ie. not an embryonic session) I see “action=timeout”, implying timeout due to trigger (a), not (b). That is, the opposite of what the KB documents, (albeit, I am assuming it’s referring to Log message logid=0000000013). Anyone can vouch for veracity of the KB, and if so, explain why I’m seeing a log message with “action=timeout” for non-embryonic session?Thanks! 

Hello Everyone, I'm currently experiencing an issue logging into the FortiGate VM GUI.The GUI remains stuck on the license validation process, attempting to verify the license with FortiGuard. The FortiGate VM license expired four days ago. Based on my understanding and Fortinet's licensing behavior, even if the license has expired, I should still be able to access the GUI. Only subscription-based services should be affected.I have already verified the following:All required ports are open. The FortiGate VM has successful connectivity to the FortiGuard servers. DNS resolution and internet connectivity are working correctly.Also, i’ve attached the ping and system dns status for FortiGuard. Despite this, the GUI remains stuck during the login process.Has anyone experienced this issue before, or does anyone have any suggestions on how to resolve it?Any advice would be greatly appreciated. Thank you in advance 

Good day  Please assist , I have installed fortigate vm64 version 7.6.7, when trying to access the gui and logging in it says license is being validated  I can ping google , dns working fine  What could be the issue 

Hello, We are currently deploying Cisco ISE as Radius server for user 802.1X auth and device (printers,cameras,iphones) with MAB. We have a site which is composed with Fortinet devices (Fortinet Firewall, FortiSwitch & FortiAP). While i am testing mab authentication everything works fine, my main issue is that on Cisco ISE i can't get endpoint ip address.DHCP snooping is enabled on Fortiswitch Interfaces, Fortinet Firewall is on 7.2.8, i've done packet captures and see that fortiswitch is not sending framed-ip-address towards ISE. Any idea why this happens and how can i resolve it ?

Hi Team,We are using FortiClient EMS-managed IPsec Remote Access VPN (IKEv2) with split tunneling.Our FortiGate Phase 1 is configured with:mode-cfg enableipv4-split-include containing only RFC1918 networksNo full-tunnel configurationAfter connecting, the Windows routing table shows two default routes:0.0.0.0/0 -> 192.168.1.1   Metric 40   (Local Gateway)0.0.0.0/0 -> 10.68.1.14    Metric 9001 (VPN Gateway)The local gateway has the lower metric, so Internet traffic should continue to use the local ISP, which appears to be working correctly.However, we occasionally observe some Internet-bound traffic in the FortiGate traffic logs from VPN users, even though only RFC1918 routes are configured in the split tunnel.My questions are:Yes, this is expected behavior. FortiClient installs a secondary default route with a very high metric as part of its standard IKEv2/IPsec split tunneling implementation. This route acts as a fallback or "trap" route and does not override the primary local ga