Recently active topics

We have a user with the following admin profile that is not able to push Fortiswitch config from Fortimanager We first thought that maybe the firmware was an issue since the move to Fortigate 7.4.13, but my admin account and other’s works just fine. The error message from the non working user doensn’t tell much neither. We haven’t changed any config before it stopped working for them. The user does changes manually to switch ports and isn’t using any template for them.  Fortimanager is on 7.6.8 if that’s relevant. Any tips would be very appreciated!

Have an FS108.Reset the FS108 to factory defaults using paperclip + reset button.Manually assigned my laptop Ethernet adapter IP address 192.168.1.1 mask 255.255.255.0 GW 192.168.1.99Connected Ethernet cable between my laptop and port 1 on FS108.Open browser, go to http://192.168.1.99 and nothing. Also tried https...still nothing.Console to FS108 and exec factoryreset and factoryresetfull ….still nothing. I could set this up using the console, but I’d really like to know why it is not working as advertised.I have many more FS108’s to deploy and need to figure out if the “Easy FortiSwitch Setup” is not going to be so easy.

Our municipality and affiliated public institutions have invested in Fortinet equipment and solutions for over a decade. It is extremely disappointing that a mature product branch has been left with a serious, reproducible regression affecting essential public services.Technical details: OS: Windows 11 Pro 25H2 and 26H2 Product: FortiClient VPN-only (IPsec) Affected builds: 7.4.3.4726 and 7.4.3.6002 (probably all versions from ~7.4.1?) Steps: Connect FortiClient IPsec → disconnect → attempt Windows native L2TP/IPsec VPN. Result: Windows VPN fails with RAS errors 789/791. Confirmed workaround: Restarting the Windows IKEEXT service immediately restores connectivity. Network routing and adapter states appear normal after disconnect. This issue has been publicly reported since at least February 17, 2025, with no confirmed permanent fix. Even the latest security-maintenance build, 7.4.3.6002, still reproduces it.Related reports: Feb 17, 2025: https://community.fortinet.com/suppo

How can i change the FSSO Connection Password between a FortiGate and the FSSO? I tried FSSO_Setup_5.0.0337_x64 and FSSO_Setup_5.0.0335_x64, no luck.In the FSSO Agent config i do thisrun as Administrator Change the Password in Authentication  Leave the Ceckmark for Require authentication Click on Apply Click on Save&Close i Restart the Fortinet Single Sign On Agent ServiceThe firewall will always connect to the FSSO agent, no matter what password i enter here.This works as long as i use the default password of the FSSO Agent (that came with the installation).this password is even writtenin cleartext inside the collectoragent.exe.you will find it even with notepad.any idea

Hi Everyone, I  am facing  issue to downaload an image of Forigate 200f. My license is expired.. Please guide or share me how can i download the image..?? 

When I login as the ems cli user to our Fortinet provided OVA Ubuntu instance, I see this message:5 updates could not be installed automatically. For more details,see /var/log/unattended-upgrades/unattended-upgrades.log These logs appear to be hardened and not accessible from the cli.  I can access “execute ls /var/log/forticlientems/*” but not the folder holding the logs mentioned above.  I’d like to confirm what isn’t being updated from a CVE standpoint.  Does anyone know how to access these logs?

Hi! I´m looking for advice configuring an IPSec hub with FortiOS 8.0.1 for terminating IPSec site-to-site tunnels from multiple remote sites.We have a relatively high number of remote sites >50 with very low traffic (just remote management), but overlapping IP ranges.The IPsec tunnel interfaces (the inside of the tunnels) would need to connect to different VRFs. The tunnels would be initiated by the remote sites, which have different source IPs in the Internet,  but on the hub site all IPsec tunnels are terminated on a single public IP. Can I create a VRF instance per remote site?Having >50 VDOMs would not be feasible, as we are talking about maybe 10Mbps aggregate traffic and a relatively small firewall at the hub site, which can only support 10 VDOMs (like a an FG-120G).Some remote site will not have Fortigates, but most of them have. Is this doable at all? BR Peter 

 Hello everyone,I am troubleshooting a dial-up IPsec VPN connection issue affecting one client in Egypt. Our VPN connections work normally for clients in Lebanon, Germany, and Spain.The affected client is our only client in Egypt, so I cannot confirm whether this affects other users there.IssueThe client’s initial IKE request reaches our FortiGate. The FortiGate selects a matching proposal and generates an SA_INIT_RESPONSE. However, the client continues retransmitting the initial request, and the FortiGate repeatedly resends its response.It appears that the response may be getting dropped on the return path, although the firewall logs alone do not confirm where the issue occurs.Troubleshooting completed Tested three different VPN tunnels using different public IP addresses. Suspected filtering of UDP ports 500/4500 and tested IPsec over TCP on one tunnel, but the connection still failed. The client tested another ISP and a different PC, with the same result. Egypt is allowed in o

Good Afternoon, Since upgrading Fortianalyzer VM to 7.4.12, within the Fortiview → Traffic → Top Source, I am no longer able to filter a SourceIP by CIDR notation in the GUI. In the past, I’ve been able to use e.g. 172.1.1.0/16, and will get results for traffic only for that specific subnet.  Since upgrading, I receive “no records found”, when the CIDR notation would align with individual IPs I can see in the traffic Fortiview. I am not seeing in the release notes that this was taken out or is a known issue.  Is anyone else experiencing this, or is there another method to filter by subnet within Fortiview on Fortianalyzer 7.4.12? Thank you!

Hello, team!Today we identified an FSA/RISK_HIGH detection involving Windows PowerShell files, specifically the Get-NetView.psm1 module.We are investigating this issue across three different customers, each with their own independent FortiClient EMS environment. So far, we have identified that the same files and SHA256 hashes are being detected across all three environments.Since the detections started occurring around the same time and across independent environments, we suspect this may be a false positive related to the FortiGuard detection database.We would like to check whether your team has already identified any similar incidents or if there have been any recent updates that could be causing this behavior.We have submitted the information for analysis and look forward to your feedback.Thank you!

DescriptionThe meaning of the System Event log ID 44562, "CMDB get request for sensitive information table", and an explanation of why it appears after making changes on the Dashboard.ScopeFortiOS 7.6.SolutionIn this scenario, an administrator logged into the GUI and changed the CPU timeframe from 30 minutes to 1 hour under Dashboard -> Status.As a result, FortiOS logged "CMDB get request for sensitive information table" followed by an "Object attribute configured" log as shown below:Example raw logs:date=2026-11-04 time=07:40:41 eventtime=1793806840205720745 tz="-0800" logid="0100044562" type="event" subtype="system" level="warning" vd="root" logdesc="CMDB get request for sensitive information table" msg="A request is being made by process /bin/httpsd (pid 9242) to table system.admin" date=2026-11-04 time=07:40:43 eventtime=1793806842463090027 tz="-0800" logid="0100044547" type="event" subtype="system" level="information" vd="root" logdesc="Object attribute configured" user="admin"

Hello traveler, I'm assuming you've stumbled upon this post after using very specific search terms and are perhaps now at the end of your rope. I hope I can maybe be your last stop. There's a lot that's going to depend on your own setup, such as which cipher suites you're using, your local and remote subnets, etc. I'm not posting this as a definitive guide to get your swanctl.conf perfect - I'm assuming you've already got it to a place where it "should be working". My goal is instead to draw attention to the changes that took my tunnel creation getting totally dropped and ignored by the FortiGate after first contact, to it actually trying to authenticate. It was of course, very simple, but took me hours upon hours to finally get right. The lynchpin was this: Set Remote auth to PSK. Set Local auth to EAP. Make sure Local is set to round 2, otherwise it sends your EAP credentials before it's asked and the Fortigate shrugs it off. Note that on my FortiGate side, I'm no

Description   This article describes how to download the FortiClient offline installer.   Note: Registration of the FortiClient owner is required to proceed with this process.   Scope   FortiClient.Solution   Download the FortiClient Offline installer using these steps: Go to Support and log in. Navigate to Support -> Firmware Download -> Firmware Images Under Select Product, select FortiClient. Select Download to obtain the offline installer.       Choose the desired OS and download the offline installer.       For example, if the desired Operating System is Windows, follow the steps below:   Select Windows: Select the desired version (i.e., v7.00):                           Select the desired version (i.e., '7.4'):                             

I'm facing a strange issue with a new FortiGate VM instance running on Proxmox.EnvironmentHypervisor: Proxmox VE FortiGate: FortiGate VM Disk image: fortios.qcow2 Access: Web GUI over HTTPS Version: FortiGate-VM64-KVM v8.0.0.build0167.260420 (GA.F)IssueI created a new FortiGate VM using the fortios.qcow2 image.The VM boots successfully, and I can access the FortiGate GUI login page. I can also enter the admin credentials and authentication is successful.However, immediately after successful login, I am logged out and redirected back to the login page.So the behavior is:FortiGate GUI Login ↓Enter credentials ↓Authentication successful ↓GUI starts loading ↓Immediately logged out ↓Redirected back to Login pageThere is no normal session timeout involved because the logout happens immediately after login.Troubleshooting already attemptedI also tried increasing the administrator timeout:config system global set admintimeout 30endHowever, this did not res

Hello Fortinet Community,We are facing an issue with Active Directory user visibility and User-Host mapping in FortiNAC.Environment FortiNAC version: 7.6.7 Active Directory configured as the LDAP identity source. The LDAP bind account configured in FortiNAC is a domain user account. Authentication method: 802.1X – PEAP-MSCHAPv2.   Observations: LDAP Validate Credentials: Success. Synchronize Users with Directory: Success. Hosts are discovered successfully, and their MAC addresses are visible. AD users are not visible in FortiNAC. Registered To and Logged On User fields are empty.   Why are AD users not appearing in FortiNAC even though LDAP validation and directory synchronization are successful? Is there any additional configuration required to retrieve and display AD users in FortiNAC? Thank you for your help.

DescriptionUpgrading a FortiGate device to version 7.6.8 may cause the web administration interface to become unavailable, resulting in the firewall sending TCP resets to HTTPS requests.ScopeFortiGate 7.6.6 and above.SolutionRoot causeIf the FortiGate belongs to the security fabric, the root is running 7.4.x, and the leaf FortiGate version is 7.6.8: the stability of the web administration service will be affected and application crash autod will be generated.ResolutionUpgrade the FortiGate root to the same version of the leaf FortiGate, or apply the following workaround:config automation setting set fabric-sync disable endTroubleshooting the web interfaceIf the web interface does not respond, verify the current management port settings using the following command:get system global | grep -E "admin-sport|management-port"Run the https and http_auth daemons commands. If no information is shown, review whether the TCP port for the admin port is open, and whether the gnum 10000e and 100

DescriptionThis article describes how to fix an issue where internal-to-internal email traffic is not being processed as expected by the FortiMail Real-Time Scan policy.ScopeFortiMailSolutionThe API integration between FortiMail Cloud and Microsoft 365 is done to enable Real-Time Scanning of internal-to-internal emails. However, the associated History_Logs will not appear as expected.When logging is configured under All Events below Policy -> Real time scanning -> Settings -> Log, the logs will start to appear under History -> Logs, and the applied policies column shows "0:0:0 System", although there is a Real-time scanning policy in place for Internal-to-Internal mail-flow. When the logging option is changed to "On-Match Policy," no logs are generated.The Real-Time Scan policy was configured to match IPv4 traffic, while the internal-to-internal email flow was traversing over IPv6.Due to the IP version mismatch, the email traffic was not matching the configured Real-Time Sc

Hello Fortinet Community,I have installed FortiGate-VM64 FortiOS 8.0.0 in my EVE-NG lab environment.The FortiGate VM boots normally, and I am able to access the GUI login page.Current IssueI can successfully enter my credentials and the GUI appears to authenticate successfully. However, immediately after login, I am logged out and redirected back to the login page.In other words:Open FortiGate GUI. Enter username and password. Authentication appears successful. GUI starts to load. Immediately after that, the session is terminated and I am returned to the login screen.EnvironmentPlatform: EVE-NG Device: FortiGate-VM64 FortiOS: 8.0.0 Build: 0167 Image: FGT_VM64_KVM-v8.0.0.F-build0167-FORTINET.out.kvm.zip Deployment: KVM/EVE-NGLicense StatusThe FortiGate license is showing Up to Date / Active, so there does not appear to be an obvious licensing issue.What I have checkedFortiGate VM is booting normally. GUI is reachable. Username/password are accepted. License status shows up to date. The

FortiClient VPN 7.4.11.0198 on iPadOS 26.7.1 fails to establish an IKEv2 IPsec tunnel to FortiGate running FortiOS 7.4.12 build 2902 when Phase 1 uses AES256-GCM with PRF-SHA384 or PRF-SHA512.FortiGate accepts the Phase 1 proposal:ENCR: AES_GCM_16, 256 bitINTEGR: NONEPRF: PRF_HMAC_SHA2_384 or PRF_HMAC_SHA2_512DH: MODP2048 or MODP3072However, FortiClient does not send the subsequent IKE_AUTH request. FortiGate eventually reports:negotiation timeout, deletingconnection expiring due to phase1 downThese combinations were tested:AES256-GCM / PRF-SHA256 / DH15: worksAES256-GCM / PRF-SHA384 / DH14 or DH15: fails after IKE_SA_INITAES256-GCM / PRF-SHA512 / DH14 or DH15: fails after IKE_SA_INITAES256-CBC / SHA384 / DH15: worksPhase 2 with AES256-GCM works correctly when Phase 1 uses either AES256-GCM/PRF-SHA256 or AES256-CBC/SHA384. The problem occurs with both SAML SSO and local username/password authentication, although authentication is never reached in the failing cases.I reproduced the issu

Hello Everyone , I Hope Youre WellWe have several web services and APIs that are exposed via an FQDN (Fully Qualified Domain Name) rather than a pool of source server IP addresses. Could you help me understand how to configure a service in FortiWeb that uses an FQDN? Is it mandatory to configure a server pool?Thanks!!! 

DescriptionSteps to request a FortiEDR Collector update from the EDR Manager Console.ScopeFortiEDRSolution Go to Administration -> Deployment -> Collector.Click 'Update Collectors':In the 'Update Collector Version' window:Select the checkbox for the desired Collector GroupSelect the checkbox for the operating system installer you want:WindowsmacOSLinuxSelect the required installer version for each OS.Click 'Update':The update will start, and the following message should appear; just click 'Close':The collector will be updated to the requested version.

DescriptionThis article describes why, after upgrading to version 7.6.7, it is not possible to add a new IPv6 address when editing a rule in the policy panel.ScopeFortiProxy version 7.6.7.SolutionWhen trying to add a new IPv6 address in Edit Policy and selecting IPv6 Address, nothing happens:To solve this, first enable the IPv6 Feature in System -> Feature Visibility:Afterwards, it is possible to add IPv6 addresses directly in the Policy Edit menu.

Mostly AI Generated, but results of my own work. After considerable troubleshooting, I've successfully implemented Windows Native Always On VPN (AOVPN) Device Tunnel with FortiGate 7.4.13, using machine-certificate authentication, Microsoft Intune, and Active Directory authorization.First, credit where it's due: Richard Hicks (richardhicks.com) has published excellent documentation on Windows AOVPN that helped tremendously.Also, let's be clear: FortiClient already provides always-on, pre-logon VPN connectivity using machine certificates and, in my experience, does it better than Windows native AOVPN.However, if you're like me and have valid reasons not to use FortiClient VPN, this post is for you.Our EnvironmentWe're using: FortiGate running FortiOS 7.4.13 Windows native IKEv2 Device Tunnel Enterprise CA with machine certificates deployed through Intune SCEP Microsoft Entra hybrid-joined Windows computers Active Directory LDAP for computer authorization Intune-managed split-t

DescriptionSteps to resolve a "PH_DATAPURGER_CMD_FAILURE" error where FortiSIEM does not have access to another node.ScopeFortiSIEM.SolutionWhen the following errors are encountered:phReportMaster[308936]: [PH_REPORT_FILE_RSYNC_FAILED]:[eventSeverity]=PHL_ERROR,[procName]=phReportMaster,[fileName]=ProfileHandler.cpp,[lineNumber]=474,[srcFilePath]= (001멕,[targetHostName]=172.20.28.171,[errorNoInt]=0,[phLogDetail]=Failed to rsync fileOr:phReportMaster[185480]: [PH_DATAPURGER_CMD_FAILURE]:[eventSeverity]=PHL_ERROR,[procName]=phReportMaster,[fileName]=phMiscUtils.cpp,[lineNumber]=4974,[command]=/usr/bin/ssh -i ~admin/.ssh/id_rsa admin@'172.20.28.171' rm -rf '/opt/phoenix/cache/profile.db-shm',[errorNoInt]=255,[phLogDetail]=Failed to run commandUse this on Super leader:su admin - ssh -i ~admin/.ssh/id_rsa admin@Super_node2_IPOr:ssh -i ~admin/.ssh/id_ed25519 admin@Super_node2_IPIt should not work.To fix it:On Super_node1:cat ~admin/.ssh/id_rsa.pubOr:cat ~admin/.ssh/id_ed25519pubCopy the out

DescriptionInstructions to fix ADOM upgrade failure due to a remote certificate invalid error.ScopeFortiManager.SolutionAn Administrative Domain (ADOM) upgrade from version 7.4 to 7.6 fails due to a remote certificate missing its PEM wrapper, resulting in a certificate invalid error.SymptomsWhen attempting to upgrade an ADOM from version 7.4 to 7.6 in FortiManager, the process fails with the following error message:Fail (errno=-2):This remote certificate is invalidRoot causeThe upgrade fails because one or more remote certificates in the ADOM database are stored without the required PEM wrapper (the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- lines). While the certificate may be valid for current operations, the ADOM upgrade process to version 7.6 rejects certificates that do not follow this standard format.ResolutionRestore the PEM wrapper to the affected certificate using a script.Step 1: Identify the problematic certificateSelect Policy & Objects -> Advanced -&g