https://community.fortinet.com On the Forum you can ask questions or take part in discussions. https://community.fortinet.com/support-forum-92/nse-4-fortios-7-6-what-actually-helped-you-prepare-230299 I’m currently preparing for NSE 4 on FortiOS 7.6, and one thing I’ve noticed is that going through the study material and actually being able to troubleshoot a FortiGate scenario are two very different things.So I wanted to hear from people who have recently prepared for or passed the exam.What helped you the most?Hands-on FortiGate labs Fortinet Training Institute material Fortinet documentation and KB articles Practice questions CLI troubleshooting Real-world troubleshooting scenariosPersonally, I’ve found that combining the official material with hands-on practice makes it much easier to understand where the gaps are. I’ve also used CertsInfinity as an additional certification-preparation resource for reviewing topics and getting extra practice.For those who have already taken NSE 4, how did you balance theory and hands-on practice, and what would you recommend spending more or less time on? Support Forum Thu, 01 Oct 2026 00:18:16 +0200 https://community.fortinet.com/fortisiem-34/technical-tip-fortisiem-migration-and-clickhouse-configuration-procedure-220767 DescriptionThis article describes how to migrate FortiSIEM data from one system to another when ClickHouse is used as the online storage backend.ScopeFortiSIEM.SolutionThis guide focuses on ClickHouse-based deployments. The same methodology can be adapted for other storage types; however, ClickHouse is the primary scope of this document.   Requirements:Both the source and target FortiSIEM systems must meet the following requirements:Same FortiSIEM version: This is strongly recommended, though database upgrades are possible if required.Online storage: ClickHouse.Valid license for the target FortiSIEM system. Migration steps:Copy the CMDB backup (Source -> Target).Notes: The CMDB backup is located on the source FortiSIEM at /data/archive/cmdb/. The CMDB backup file must be copied to the /tmp directory on the target FortiSIEM. For example: phoenixdb_202X-XX-XXTXX-XX-XX. Capture the original database values (target).Before restoring the CMDB, capture the existing system configuration values on the target system. psql -U phoenix -d phoenixdb -c "select id,value, property from ph_sys_conf" > ph_sys_conf_orig.txt To view the captured file: cat ph_sys_conf_orig.txt Collect and save all passwords.Run the following commands and securely store the output. Each command returns a password that must be saved in case the FortiSIEM system needs to be reverted during or after the process. phLicenseTool --showSvnPassword phLicenseTool --showDatabasePassword phLicenseTool --showRedisPassword phLicenseTool --showServicePassword Restore the CMDB.Stop Services on the Target FortiSIEM.systemctl stop crond.service systemctl stop phxctl phtools --stop all phstatus killall -9 java killall -9 phMonitor phstatus Restore the database. /opt/phoenix/deployment/db_restore.sh /tmp/phoenixdb_xxxxx Reset database IPs on the target FortiSIEM.Replace x.x.x.x with the Target FortiSIEM IP address. psql -U phoenix -d phoenixdb update ph_sys_server set ip_addr='x.x.x.x' where id=1; delete from ph_sys_server where mode in (3,1); update ph_sys_conf set value='https://x.x.x.x/svn' where property='svn_url'; Restart the App Server and re-upload the license.Start FortiSIEM services:phxctl start Upload the license using the following URL: https://x.x.x.x/phoenix/licenseUpload.jsf Optional: restore GUI access (test user): If GUI access is unavailable after migration, a temporary administrative user can be created using the following command: psql -U phoenix phoenixdb -f /opt/phoenix/deployment/add-super-admin.sql Credentials:Username: test_fsm.Password: Test*123. Disable notifications (optional).This step removes email configuration from the default notification templates. psql -U phoenix phoenixdb update ph_sys_conf set value='' where property='Mail_Server'; Clean cluster configuration (UI).Navigate to: Admin -> Settings -> Cluster Config. Remove the old Workers' IPs.Update all IPs to point to the Supervisor.Save.Password synchronization: Update database and admin passwords.Update the database password: db_password=`phLicenseTool --showDatabasePassword` psql -U phoenix phoenixdb -c "ALTER USER phoenix WITH PASSWORD '${db_password}';" Restart database-related processes:phtools --start phQueryMaster phtools --start phRuleMaster Capture the database password again. phLicenseTool --showDatabasePassword Update the admin password file (use the password provided during step 3 and change the password below). su admin vi /tmp/passwd.txt Add:AS_ADMIN_PASSWORD= A12G7XXgDn@8 AS_ADMIN_ALIASPASSWORD= A12G7XXgDn@8 AS_ADMIN_NEWPASSWORD= A12G7XXgDn@8 Save the file and exit. Sync the admin password.Run the following commands: /opt/glassfish/bin/asadmin --user admin --passwordfile /tmp/passwd.txt change-admin-password /opt/glassfish/bin/asadmin --user admin --passwordfile /tmp/passwd.txt update-password-alias phdbpwd Hostname and SSH keys: Update Hostname using the built-in-utility: configFSM.sh Continue selecting Next / OK.At Configure Supervisor, choose option 3.Continue until completion. Add SSH Public Keys (UI).Admin -> License -> Nodes. Admin SSH key. su - admin ssh-keygen -t rsa -b 4096 cat /opt/phoenix/bin/.ssh/id_rsa.pub HA user SSH key: cat /home/pghauser/.ssh/id_rsa.pub Redis and ClickHouse Cleanup: Clear the Redis Cache for ClickHouse. Capture the Redis password. (The password shown here will reflect the source system due to the migration. This will be cleaned up in a later step.) cat /opt/phoenix/config/phoenix_config.txt | grep redis_auth= Connect to Redis with the password from step 1. redis-cli -p 6666 -a <redis_password> List ClickHouse Keys: keys '*clickhouse*' Delete keys individually: del "cache:phDataManager:clickhouseQuery:21192" del "cache:ClickHouse:clickhouseConfig" del "cache:phDataManager:clickhouseQuery:21193" del "cache:phDataManager:clickhouseLogIntegrity" del "cache:phDataManager:clickhouseTableEngine" del "cache:ClickHouse:clickhouseNodes" del "cache:phDataManager:clickhouseLogIntegrityConsolidationActive" del "cache:ClickHouse:clickhouseKeeperNodes" Run the ClickHouse Cleanup script. /opt/phoenix/phscripts/clickhouse/cleanup_clickhouse.sh Update ClickHouse cluster configuration in the GUI. Navigate to Admin -> Settings -> ClickHouse Cluster.Configure Supervisor only for Keeper, Data, and Query.Test and Save. Redis Sync (update all folders from the password result). phLicenseTool --showRedisPassword Update file below with correct Redis Password: /opt/phoenix/config/phoenix_config.txt  /opt/node-rest-service/ecosystem.config.js /opt/phoenix/redis/bin/redis_ops.sh /opt/phoenix/redis/conf/6666.conf Notes:Make sure the entry for redis_auth OR redis_auth_6379 in the files are updated correctlyStop the ClickHouse monitor. killall -9 phClickHouseMonitor Backup configuration files. (This is a single code block. Copy the entire snippet and paste it on the target system.) for f in /opt/node-rest-service/ecosystem.config.js \ /opt/phoenix/redis/bin/redis_ops.sh \ /opt/phoenix/redis/conf/6666.conf \ /opt/phoenix/config/phoenix_config.txt \ /opt/phoenix/config/svnlite.properties; do cp "$f" "${f}_orig" done Run the script to update the Redis password across all necessary configuration files: /opt/phoenix/deployment/jumpbox/ph_update_dr_configs.py  Restart services:Restart Apache and postgres.service httpd restart systemctl restart postgresql-$(postgres -V | awk '{print $3}' | cut -d. -f1).service Restart Redis.rm -f /opt/phoenix/redis/conf/6666.conf cd /opt/phoenix/redis/bin/ ./redis_ops.sh stop ./redis_ops.sh start Restart Node services: su admin pm2 restart all Verification.Allow 10–25 minutes for Redis to stabilize.Monitor logs: tail -f /opt/phoenix/log/phoenix.log | grep -i redis Expected log message: Redis connection is healthy Once this message appears consistently, Redis synchronization is complete. Clean residual hosts from the CMDB.Some legacy ClickHouse nodes from the source system may still appear in the CMDB, and errors may be encountered when attempting to delete them. Verify the hostnames that need to be removed from the CMDB.Log into the console of the target device and access the database. psql -U phoenix -d phoenixdb Disable all triggers on the ph_device table to allow deletion without triggering foreign key constraint errors:ALTER TABLE ph_device disable TRIGGER ALL; Delete the devices using the exact hostnames:DELETE FROM ph_device WHERE name IN ( 'keeper01.net', 'keeper02', 'super01.net', 'testworker01.net', 'testworker02.net' ); Re-enable all triggers on the ph_device table: ALTER TABLE ph_device enable TRIGGER ALL; Exit the database and verify that the devices have been removed from the UI. FortiSIEM Thu, 01 Oct 2026 00:08:34 +0200 https://community.fortinet.com/support-forum-92/ldap-authentication-and-internet-access-issue-230273 hello,we have recent internet access issues following our shift from IP-based access control to LDAP authentication on the FortiGate firewall.Previously, users accessed the internet based on their IP addresses. As part of our security enhancements, we are transitioning to identity-based trust using LDAP authentication. Currently, users are unable to browse because the firewall policies for LDAP,  FSSO agent on fortinet is green and up.the policy not hitting any traffic,some sessions are failing to trigger authentication correctly.   Support Forum Wed, 30 Sep 2026 23:42:27 +0200 https://community.fortinet.com/support-forum-92/fortigate-vm-v8-0-1-trial-license-activates-successfully-but-gui-immediately-logs-out-hyper-v-230294 FortiGate-VM64-HV Trial Issue on Hyper-VPlatform:- Hyper-V (Server 2019) Gen 1 virtual machine- FortiGate-VM64-HV v8.0.1 build0245 (GA.F)- Trial LicenseIssue:The trial license activation completed successfully and the CLI shows "License Status: Valid". However, after logging into the web GUI, I logged out immediately.CLI access works normally.Network Connectivity:- Can ping 8.8.8.8 successfully- Default route configured via 192.168.1.254 on port1Relevant Output:FGT-VM64-HV-NZVQOU # get system statusVersion: FortiGate-VM64-HV v8.0.1 build0245 (GA.F)First GA patch build date: 260421Current Security Level: HighFirmware Signature: certifiedLicense Status: ValidVM Resources: 1 CPU/1 allowed, 1694 MB RAM/2048 MB allowedHostname: FGT-VM64-HV-NZVQOUOperation Mode: NATCurrent virtual domain: rootMax number of virtual domains: 10Virtual domains status: 1 in NAT mode, 0 in TP modeCurrent HA mode: standaloneBranch point: 0245Release Version Information: GAFortiOS x86-64: YesRouting Table:S* 0.0.0.0/0 [15/0] via 192.168.1.254, port1C  192.168.1.0/24 is directly connected, port1HTTPS Debug:Session key request authorized for admin.Completed GET request for "/api/v2/monitor/system/usb-log" (HTTP 200)The debug appears to indicate successful login and successful API requests, but the GUI still logs out or displays a blank page.Has anyone seen this behavior with FortiGate-VM64-HV v8.0.1 trial deployments on Hyper-V? Tested:Edge InPrivate Chrome Incognito Direct access to /ng License is now Valid CLI access works normally Support Forum Wed, 30 Sep 2026 23:35:19 +0200 https://community.fortinet.com/fortigate-3/technical-tip-how-to-fix-the-error-unable-to-connect-to-fortiguard-servers-on-fortios-versions-7-6-7-and-7-4-12-230240 DescriptionThis article describes the process to resolve the issue 'Unable to connect to FortiGuard servers', which is a lack of connectivity to FortiGuard Servers.ScopeFortiGate, FortiOS version 7.6.7, FortiOS version 7.4.12, FortiOS version 7.4.13.SolutionFigure 1 and Figure 2. Errors in GUI:Whenever this error happens, there are 2 possible scenarios.FortiGate with one of 3 security profiles activated (Web-filter, Antispam, Virus Outbreak prevention) with fewer than 10 servers in the list.FortiGate without a security profile enabled.Whatever of both cases represents a lack of communication with FortiGuard, and it needs to be fixed by adding FortiGuard Global DNS Servers, so the process is outlined below:Run the 'diagnose debug rating' command to identify the number of servers currently reached, or make sure one of 3 security profiles required is enabled.Add FortiGuard global DNS servers. config system fortiguard set fortiguard-anycast disable set protocol udp set port 8888 set sdns-server-ip 200.91.112.220 208.91.112.220 173.243.140.53 210.7.96.53 end Force a signature update.diagnose debug application update -1 diagnose debug enable execute update-now Let the debug process run, and once it stalls, stop it using the 'diagnose debug disable' command. Run the 'diagnose debug rating' command repeatedly until the server count increases, so that many more IP addresses will be seen.Related documents:Technical Tip: FortiGate unable to access several FortiGuard services due to CRL scope errors (September 2026)Troubleshooting Tip: Unable to connect to FortiGuard serversUnable to connect to FortiGuard servers FortiGate Wed, 30 Sep 2026 18:44:59 +0200 https://community.fortinet.com/support-forum-92/can-any-one-give-me-configuration-sample-for-gre-over-dynamic-ipsec-for-fortigate-firewall-230284 Is it possible to Gre over Dynamic IPsec between Fortigate & mikrotik.Can any one give me configuration sample for gre over dynamic ipsec for fortigate firewall? Support Forum Wed, 30 Sep 2026 18:27:41 +0200 https://community.fortinet.com/fortigate-3/troubleshooting-tip-show-firewall-address-cli-output-does-not-display-set-associated-interface-after-querying-an-interface-subnet-address-object-230297 DescriptionThis article describes an issue where the FortiGate CLI command 'show firewall address <name>' does not display the 'set associated-interface' line if an address object of type 'interface-subnet' was queried previously in the same CLI session.ScopeFortiGate, FortiOS v7.4.x, FortiOS v7.6.x.SolutionWhen querying firewall address objects in the CLI, the output may differ depending on the order of commands run in the same SSH or GUI console session.When querying an address object of type 'interface-subnet' (such as an interface-bound address) and then query an address object that has an associated interface (such as a MAC address object), the 'set associated-interface' line will not be displayed in the second query's output.The configuration itself is not lost or deleted. Upon opening a new CLI session and querying the object again, the 'associated-interface' attribute appears normally.Reproduction steps:Consider two address objects configured on the FortiGate:config firewall address edit "VLAN201 address" set type interface-subnet set subnet 192.168.222.0 255.255.255.0 set interface "VLAN201" next edit "MAC-ADDR-TEST" set type mac set comment "Test MAC Address Object" set associated-interface "VLAN201" set macaddr "00:02:FF:FF:FF:FF" next endOn a new CLI session, query the MAC address object:# show firewall address MAC-ADDR-TEST config firewall address edit "MAC-ADDR-TEST" set uuid f6b79150-8a92-51f1-4e88-c7b87ba3ae2e set type mac set comment "Test MAC Address Object" set associated-interface "VLAN201" set macaddr "00:02:FF:FF:FF:FF" next endThe line 'set associated-interface "VLAN201"' is displayed correctly.In the same CLI session, query the interface-subnet address object:show firewall address "VLAN201 address" config firewall address edit "VLAN201 address" set uuid d600d660-8a92-51f1-5d80-c00bdcc80af1 set type interface-subnet set subnet 192.168.222.0 255.255.255.0 set interface "VLAN201" next endQuery the MAC address object again in the same session:# show firewall address MAC-ADDR-TEST config firewall address edit "MAC-ADDR-TEST" set uuid f6b79150-8a92-51f1-4e88-c7b87ba3ae2e set type mac set comment "Test MAC Address Object" set macaddr "00:02:FF:FF:FF:FF" next endThe line 'set associated-interface "VLAN201"' is missing from the output.This behavior can affect automation scripts or configuration backups that collect object details sequentially in a single SSH session, leading to incomplete configuration exports.Workarounds:Run each CLI query in a separate SSH connection.Enter the object context directly to check the configuration:config firewall address edit "MAC-ADDR-TEST" show endNote:This behavior is tracked under known issue #1324322. It has already been resolved in FortiOS 8.0.1 and later, and a fix is scheduled for the upcoming FortiOS 7.6.9 release. FortiGate Wed, 30 Sep 2026 17:37:26 +0200 https://community.fortinet.com/fortigate-3/technical-tip-fortianalyzer-event-handler-behavior-when-triggering-automation-stitches-on-another-fortigate-230296 DescriptionThis article describes the behavior of FortiAnalyzer Event Handlers when triggering Automation Stitches configured either on the FortiGate that generated the event or on another FortiGate device.ScopeFortiAnalyzer, FortiGate.SolutionConsider the following scenario:FortiGate-A and FortiGate-B send logs to the same FortiAnalyzer.A log from FortiGate-A triggers a FortiAnalyzer Event Handler.The Automation Stitch is configured on FortiGate-B.FortiGate-A and FortiGate-B are not part of the same Security Fabric.In this scenario, the Automation Stitch on FortiGate-B is not triggered. This behavior is expected by design. To trigger the Automation Stitch on FortiGate-B, add both FortiGate devices to the same Security Fabric and connect FortiAnalyzer to the Security Fabric root.Consider another scenario:FortiGate-A and FortiGate-B sends logs to the same FortiAnalyzer.A log from FortiGate-A triggers a FortiAnalyzer Event Handler.The Automation Stitch is configured on FortiGate-A.FortiGate-A and FortiGate-B are not part of the same Security Fabric.In this scenario, the Automation Stitch on FortiGate-A is triggered normally. FortiGate Wed, 30 Sep 2026 17:05:01 +0200 https://community.fortinet.com/support-forum-92/does-ems-support-mac-forticlient-auto-updates-230295 We are a new customer running FC 7.4.8 on 400+ Tahoe 26.6 Macs. We need to verify if Macs can be auto-updated from our EMS (Example: When 7.4.9 drops, can our Macs get updated silently/automatically like other popular VPN/Security solutions)? I'm unable to find any official documents on this. Support Forum Wed, 30 Sep 2026 16:35:11 +0200 https://community.fortinet.com/support-forum-92/fortigate-gui-logs-out-immediately-after-successful-login-in-eve-ng-229437 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 problem occurs immediately after successful GUI authentication.I would like to understand what could cause the FortiGate GUI session to be immediately terminated after successful login.Could this be related to:FortiOS 8.0.0 VM image? EVE-NG/KVM compatibility? System time/date or NTP? HTTPS/SSL certificate or browser session/cookie issue? Admin session settings? FortiGate VM resources? License/VM registration? Any known issue with FortiOS 8.0.0 build 0167?Could someone please suggest the CLI commands or troubleshooting steps I should run to identify why the GUI session is being terminated immediately after login?Thank you. Support Forum Wed, 30 Sep 2026 15:54:03 +0200 https://community.fortinet.com/fortiproxy-30/troubleshooting-tip-fortiproxy-proxy-authentication-troubleshooting-230293 DescriptionThis article describes proxy authentication problems. Identify where authentication fails before resetting a password.ScopeFortiProxy, FortiProxy VM.SolutionCheck the authentication rule and identity mapping:show authentication rule show authentication scheme show user group diagnose wad user listVerify the rule matches the client and selects the intended scheme. Review the matched traffic policy and required user/group. For LDAP or RADIUS, inspect the configured server object, reachability, and server-side logs. For LDAPS, verify the certificate chain and server name.For Kerberos, verify the proxy FQDN, SPN/keytab, DNS and time synchronization. For SAML, inspect the IdP result and returned identity/group claims. An LDAP password test does not validate Kerberos tickets, SAML, MFA, or proxy policy matching.Test the relevant backend once:diagnose test authserver ldap ? diagnose test authserver radius ?Use the argument syntax shown on the target build with an authorized test account. The generated CLI reference documents these command families but does not enumerate their arguments. Avoid repeated tests against a locked account and exclude passwords from saved transcripts.Backend success with browser failure shifts the investigation toward rule selection, group resolution, client credentials, or the chosen authentication method. A timeout points toward connectivity or backend availability; a rejection requires the server-side reason, such as invalid credentials, expiry, or lockout.Collect one short authentication debug output:For a failure handled by FNBAMD, coordinate with other administrators before resetting debug settings. Start logging, reproduce once, and stop immediately; these diagnostics may include sensitive identity information and unrelated login attempts.diagnose debug reset diagnose debug console timestamp enable diagnose debug application fnbamd -1 diagnose debug enableAfter reproducing the failure, stop and clean up:diagnose debug disable diagnose debug reset diagnose debug console timestamp disableIf the failure is in WAD, Kerberos, SAML, or the client before FNBAMD is invoked, an empty FNBAMD trace is inconclusive. Request a client-filtered WAD or method-specific trace using the syntax for that build. Do not enable unrestricted verbose WAD logging on a busy proxy. FortiProxy Wed, 30 Sep 2026 15:47:16 +0200 https://community.fortinet.com/fortiproxy-30/technical-tip-fortiproxy-source-port-exhaustion-troubleshooting-230292 DescriptionThis article describes a scenario when new outbound connections intermittently fail under load while established connections may continue. Verify commands on the installed release.ScopeFortiProxy.FortiProxy VM.SolutionCheck System Events at the failure time for “High source port usage” or “Source port exhaustion” (available from 7.2.3).The high-usage warning alone does not mean exhaustion. Save the source IP, destination IP/port and timestamp from the event.Evidence to look for: message ID 36885, LOG_ID_EVENT_SYSTEM_VD_PORT_EXHAUST. This identifies a source-port exhaustion event; it is not a sample customer log.Record resource use, session load and configured outgoing IPs during healthy and failing periods:get system performance status diagnose sys session stat show web-proxy globalCapture the affected server or upstream proxy connection. Stop with Ctrl+C after one reproduction:diagnose sniffer packet any 'host <upstream-IP> and tcp' 4 0 lA matching exhaustion event with no corresponding outbound SYN supports local allocation failure. SYN retransmissions show that a port was allocated for that attempt; investigate the network, server and upstream NAT. Session count alone cannot prove port exhaustion.Possible solution:For confirmed explicit-proxy exhaustion, configure additional valid outgoing IPs, following Fortinet’s forwarding-server guidance. Provision these addresses on the appropriate interface and ensure routing, return traffic and upstream allowlists are correct before applying: config web-proxy global set explicit-outgoing-ip <existing-IP> <additional-IP> endPreserve all required existing addresses: set replaces the list. If exhaustion is on an upstream NAT device, expand capacity there. Reduce unnecessary connection churn where possible; do not clear all sessions or restart WAD as the default fix.Verify:Retest under comparable load. Confirm whether the new connections succeed, the intended source addresses appear, and exhaustion events stop. Restore previous settings if the change fails.  FortiProxy Wed, 30 Sep 2026 15:42:35 +0200 https://community.fortinet.com/fortiproxy-30/troubleshooting-tip-fortiproxy-password-and-login-troubleshooting-230291 DescriptionThis article describes the difference between incorrect credentials from management access restrictions, account lockout, remote-server failures.ScopeFortiProxy.SolutionIdentify the login path.Record whether the failure is GUI/SSH/console administrator access or a browser proxy prompt. Capture the exact error, username format, source IP, time, authentication method, affected users, and recent password changes. Determine whether the account is local, LDAP, RADIUS, or federated.No login page or SSH connection indicates an access-path problem first. A rejected login requires account and authentication checks. An HTTP 407 can be a normal proxy challenge; repeated challenges after credential submission require investigation.Check administrator access from a working admin session: get system status show system admin show full-configuration system global show system password-policy show system interface Check trusted hosts, enabled management protocols and ports, account type, remote group mapping, and password policy. Review admin-lockout-threshold and admin-lockout-duration without changing them. Check event logs and stop repeated retries until the lockout period has elapsed.If a local administrator works but a remote administrator fails, investigate the remote authentication server and group mapping. Verify MFA separately from the password. A successful console login with failed HTTPS/SSH access points toward management restrictions or the service path.Reset a confirmed local administrator passwordUse an existing authorized super_admin account. Confirm that the selected account already exists before editing it; editing a nonexistent name can create an unintended object. Keep the working session open and test a second session after the change.config system admin edit "<existing_admin_name>" set password <new_password> endNote: Do not paste a real password into case notes or a shared terminal recording. For remote accounts, perform password recovery at the identity provider. If all administrator access is lost, obtain the model/build-specific recovery procedure from TAC; do not assume legacy maintainer access or factory-reset the production unit.  FortiProxy Wed, 30 Sep 2026 15:41:32 +0200 https://community.fortinet.com/fortiproxy-30/technical-tip-fortiproxy-mtu-and-mss-troubleshooting-230290 DescriptionThis article describes large downloads stall while small pages work. An MTU mismatch or blocked Path MTU Discovery feedback may cause this, but the symptom alone does not confirm it.ScopeFortiProxy.FortiProxy VM.SolutionCapture one failed download. Start before opening a new connection; stop with Ctrl+C.diagnose sniffer packet any 'host <client-IP> or host <server-IP> or icmp' 4 0 lUse GUI packet capture and export to Wireshark for packet-size analysis. Look for repeated large packets without ACK progress and ICMP “Fragmentation needed” messages. Retransmissions alone do not prove an MTU problem.Test an ICMP-responsive IPv4 peer on the affected path. Record existing ping options first.execute ping-options view-settings execute ping-options reset execute ping-options df-bit yes execute ping-options data-size 1472 execute ping <peer-ip> execute ping-options data-size 1372 execute ping <peer-ip> execute ping-options reset1472 bytes tests a 1500-byte IPv4 packet; 1372 tests 1400 bytes. Repeatable success only at smaller sizes supports further MTU investigation. Ping failure alone is inconclusive, and locally generated ping may use a different path. Restore previous nondefault ping options.Correct the confirmed MTU mismatch or allow the required ICMP feedback. If MSS clamping is needed, apply it to the affected TCP connection. Example: a confirmed 1400-byte IPv4 path gives a base MSS of 1360.Open a new connection and repeat the download. Confirm completion and normal ACK progress. Restore original settings if the change does not help.Note:Changing client-side MSS may not affect the server-side connection. Confirm any FortiProxy interface MSS setting changes the intended SYN before relying on it. FortiProxy Wed, 30 Sep 2026 15:39:38 +0200 https://community.fortinet.com/fortiproxy-30/troubleshooting-tip-fortiproxy-npu-and-packet-drop-troubleshooting-230289 DescriptionThis article describes how to localize packet loss reported as NPU drops. Establish the actual drop location before changing acceleration settings. A proxy error, a NIC drop counter, and an ASIC drop counter are different evidence.Scope FortiProxySolutionEstablish the platform and affected traffic: get system status get hardware status get system performance status diagnose ?Record the exact model, build, uptime, HA member, operating mode, client IP, destination, proxy port, and failure time with timezone. Identify whether the failure affects explicit proxy, transparent proxy, or forwarding traffic.Note: The FortiProxy v7.6.6 CLI reference does not list a 'diagnose npu' command family. Do not import FortiGate NP6 or NP7 commands or assume the appliance contains either processor. If local help exposes NPU diagnostics, obtain the model-specific counter commands and meanings from TAC. For a VM, inspect the vNIC and hypervisor path.Collect interface and resource evidence: diagnose hardware deviceinfo nic ? diagnose netlink interface list diagnose sys session stat diagnose sys top 1 20 5Use the NIC command syntax displayed by local help to inspect each relevant physical port. Save two snapshots, 30 to 60 seconds apart, while reproducing the issue. Record RX/TX packets, errors, discards, link speed and duplex; collect the peer switch counters over the same interval.Capture both proxy connections: diagnose sniffer packet any 'host <client_ip>' 4 200 ldiagnose sniffer packet any 'host <server_ip>' 4 200 lUse two CLI sessions for concurrent captures; press Ctrl+C if the packet limit is not reached. Record the client-to-proxy and proxy-to-server tuples separately, including any source NAT.FortiProxy packet drop analysis and next actions.Locate the first missing packet.Correlate endpoint or switch SPAN captures with FortiProxy captures. Explicit proxy terminates the client connection and creates a separate server connection, so sequence numbers cannot be compared directly across the two legs.If the request never reaches FortiProxy, inspect the upstream devices. If it reaches FortiProxy but no server connection follows, inspect the matched policy, authentication, DNS, WAD, and system memory. If the server request leaves without a response, inspect the server and return path.If packets are present on the external wire but missing from a local capture, investigate capture visibility as well as hardware or driver drops. An empty software capture alone does not establish where a packet was lost.Validate a suspected hardware drop.Where the exact model exposes NPU counters, record the processor and port mapping, counter name, and before/after values during one controlled test. Correlate the counter delta with the affected direction and external captures. Counters that also rise during successful traffic are insufficient evidence of the reported failure.Do not disable acceleration globally or change ASIC thresholds as an initial test. FortiProxy Wed, 30 Sep 2026 15:36:42 +0200 https://community.fortinet.com/fortisoar-35/troubleshooting-tip-how-to-resolve-content-hub-sync-failure-and-connector-installation-issue-230288 DescriptionThis article describes how to troubleshoot and resolve issues related to connector installation and Content Hub synchronization failures.ScopeFortiSOAR.SolutionWhen installing the connector, it may show as 'successful', but not actually be installed.Force a content hub synchronization as outlined in Troubleshooting Tip: Steps to diagnose content hub synchronization errors.It may also fail with the error below:[error] You do not have delete access on solutionpacks module Synchronization to content-hub failedIf it does:Enable the Delete permission for the Solution Pack module under the role assigned to the user.Run the Content Hub sync again.Install the connector. FortiSOAR Wed, 30 Sep 2026 15:29:30 +0200 https://community.fortinet.com/fortisiem-216/fortisiem-shards-and-replicas-230285 Hello all,If I have one Supervisor node and then add one Worker node in the same shard, the Supervisor would be Replica 1 and the Worker would be Replica 2.The Hot Tier on the Supervisor is /dev/sde, mounted on /data-clickhouse-hot-1, while on the Worker it is /dev/sdc, also mounted on /data-clickhouse-hot-1.I have two questions: Should the output of df -h for both disks be exactly the same? When I open Admin → Setup → Storage → Online, the Hot Tier lists only the path of the Supervisor, as shown in the attached screenshot. Is this normal? Also, what if the event database is stored only on the Worker nodes? How should this deployment be configured?  FortiSIEM Wed, 30 Sep 2026 14:42:06 +0200 https://community.fortinet.com/fortiedr-20/technical-tip-installing-fortiedr-for-ios-ipad-with-microsoft-intune-230287 DescriptionThis article describes the installation of the FortiEDR iOS Mobile Collector via Microsoft Intune as a Store app. It monitors URL reputation in real time and blocks bad sites. It needs iOS 15 or later (Fortinet: FortiEDR iOS User Guide). Mobile Collectors are supported from FortiEDR 7.2.1 (Fortinet: Supported operating systems).The FortiEDR mobile has three parts:FortiEDR console: turn on mobile and get an activation code.Intune: push the FortiEDR app to the devices.User: open the app, enter the code and username, and allow the VPN.ScopeFortiEDR Mobile Application with Microsoft Intune.SolutionGet the activation code from FortiEDR:Follow the following instructions to get an activation code from the FortiEDR console:Requesting and obtaining a mobile installer | FortiEDR/XDR 7.2.3 | Fortinet Document Library.Keep the email that contains the App Store QR code, the activation code, and instructions.Keep the activation code; it will be needed in Step 3.Add the iOS store app:Go to Apps -> All Apps -> Create and choose iOS store app.Select Search the App Store, find FortiEDR, and select it (Microsoft).Set the Minimum operating system to iOS 15.Assign as Required to a pilot group first, then to all target groups.For VPP, keep the license type as Device.Intune reinstalls a Required app if a user deletes it.Here are the step-by-step instructions for adding FortiEDR mobile in Microsoft Intune:Activate the app on each deviceSend users the activation code (or QR code) from Step 1 and these steps. Each user does this once (Fortinet: Download and access FortiEDR iOS).Verify and TroubleshootIntune: Apps -> FortiEDR -> Device install status Status InstallediPad: Settings -> General -> VPN & Device Management FortiEDR VPN is ConnectedFortiEDR Central Manager: Inventory. The device appears as a mobile CollectorRelated Articles:Supported operating systems | FortiEDR/XDR 7.2.3 | Fortinet Document Library‎FortiEDR App - App Store FortiEDR Wed, 30 Sep 2026 14:36:50 +0200 https://community.fortinet.com/fortisiem-34/troubleshooting-tip-collector-registration-fails-despite-successful-tcp-443-connectivity-230286 DescriptionThis article describes an issue where a FortiSIEM Collector cannot complete registration with the Supervisor even though DNS resolution and basic TCP/443 connectivity are successful.ScopeFortiSIEM.SolutionThe Collector remains in the No Connection state, and the Phoenix services remain down after attempting registration.Basic connectivity checks may be successful:nc -vz <supervisor_fqdn> 443curl -vk https://<supervisor_fqdn>However, no Collector registration request may be observed in the Supervisor backend logs.During troubleshooting, capture the traffic while running the Collector provisioning command:tcpdump -nn -i any 'tcp port 443'Then execute the registration:/opt/phoenix/bin/phProvisionCollector --add <username> '******' <supervisor_ip> <org_name> <collector_name>In a successful registration, phProvisionCollector generates TCP/443 traffic to the Supervisor with data exchanged in both directions. The provisioning process then returns:This collector registered successfully. Waiting for reboot...If nc/curl connectivity is successful but no TCP/443 traffic is generated during phProvisionCollector, the issue is not limited to basic port connectivity. Review the complete network path between the Collector and Supervisor.Check for:Firewall or security policies.Proxy/NAT configuration.IPS or SSL inspection.Network routing or filtering.Collector-side network issues.For comparison, a successful registration shows traffic similar to:Collector_IP > Supervisor_IP.443: Flags Supervisor_IP.443 > Collector_IP: Flags Collector_IP > Supervisor_IP.443: Flags [P.]Supervisor_IP.443 > Collector_IP: Flags [P.]Once the network path has been verified, retry the Collector registration.If no registration traffic is generated from the Collector, consider redeploying the Collector if the network/security path has been confirmed as functional. FortiSIEM Wed, 30 Sep 2026 14:21:57 +0200 https://community.fortinet.com/support-forum-92/p2p-remote-gre-ip-ping-problem-when-created-gre-tunnel-with-mikrotik-230062  I have a query, I created gre tunnel & then gre interface at the fortigate side  & mikrotik side can't be able to ping remote gateway IP (p2p) which was created fortigate gre interface remote gateway with ping access. But can be able to ping from mikrotik side p2p IP which are using fortigate gre interface local ip. Gre  tunnel showing also up from fortigate side.What is the issue & how to solve it please help me urgently. Using fortigate version is 7.6.7    Support Forum Wed, 30 Sep 2026 14:15:37 +0200 https://community.fortinet.com/support-forum-92/relaying-mails-from-exchange-online-via-fortimail-to-external-in-a-secure-way-228519 Hello all,we have an Exchange Hybrid setup with all our mailboxes on-prem. We need to let graph send emails via Exchange Online but we would need to relay these emails via our Fortimail appliance. So the Exchange Online environment does not send these itself without going through the Fortimail first. We found this in the cookbook:How to integrate FortiMail into Microsoft 365 | FortiMail Appliance and VM 7.4.0 | Fortinet Document LibraryAnd this technical guideline:Technical Tip: Office365 Secure Relay via FortiMail to avoid unauthorized email relay | CommunityAnd it seems like we can’t let graph talk directly to our on-prem Exchange servers:https://learn.microsoft.com/en-us/graph/hybrid-rest-support So we wondered how does the Technical Tip from fortinet make sure that we are not risking the relaying of unwanted emails. The authenticated part in the technical guideline does not apply here, no? Because our user mailboxes are all on-prem? And regarding the cookbook: our concern is that we might be at risk of becoming an open relay to all other Exchange Online Tenants because of the access control to allow relaying from all of the Microsoft IPs? What are the necessary steps to - if possible - only let our own MS365 tennant relay emails via FML? Thank you very much and best regards Support Forum Wed, 30 Sep 2026 14:14:52 +0200 https://community.fortinet.com/fortisiem-34/troubleshooting-tip-collector-online-upgrade-fails-during-rpm-stage-230283 DescriptionThis article describes how to troubleshoot a FortiSIEM Collector online upgrade that fails during the RPM stage due to repository or package management issues.ScopeFortiSIEM.SolutionBefore proceeding with the upgrade, verify that the Collector has access to the required FortiSIEM repositories over HTTPS/443.The following URLs should be allowed:update.fortiguard.net os-pkgs-cdn.fortisiem.fortinet.com os-pkgs-r8.fortisiem.fortinet.com os-pkgs-r9.fortisiem.fortinet.comFrom the Collector CLI, verify the repository configuration:dnf repolist dnf clean all && dnf makecacheIf the repository commands complete successfully, proceed with the upgrade from the point where it previously failed.If the upgrade fails at the following point:dnf module reset all modulesRun the RPM upgrade playbook in step mode:ansible-playbook /usr/local/upgrade/upgrade-rpm.yml --stepContinue through the prompts until the dnf module reset all modules task is reached. Select Continue for this task and allow the playbook to proceed with the remaining upgrade steps.After completion, verify the Collector version from both the CLI and GUI and confirm that the Collector health is Normal and all required services are running. FortiSIEM Wed, 30 Sep 2026 14:07:06 +0200 https://community.fortinet.com/fortiadc-7/technical-tip-how-to-view-traffic-log-for-agentless-application-gateway-aag-application-or-website-230282 DescriptionThis article describes how to view the traffic log for the Agentless Application Gateway (AAG) application or website.ScopeFortiADC and FortiADC VM version 8.0.3 or later.SolutionFor 'Web App - Internal' App Bookmark Type AAG, go to:Log & Report -> Traffic Log and select Application Access from the drop-down menu.For 'Web App - Internal - Advanced' App Bookmark Type AAG go to:Log & Report -> Traffic Log and select the respective SLB type from the drop-down menu.For both A and B, ensure that the respective Virtual Server has the Traffic Log option enabled: FortiADC Wed, 30 Sep 2026 14:02:46 +0200 https://community.fortinet.com/fortisoar-35/troubleshooting-tip-how-to-resolve-pre-processing-rules-module-not-being-visible-after-a-fortisoar-upgrade-230281 DescriptionThis article describes an issue that occurs after a FortiSOAR upgrade where the pre-processing rule module is not visible.ScopeFortiSOAR version 7.6.5.SolutionIf the pre-processing rule module is not visible after the FortiSOAR upgrade, follow these steps.First, check the upgrade logs: /var/log/cyops/upgrade-fortisoar-7.6.Error migration: SQLSTATE[23505]: Unique violation: 7 ERROR: duplicate key value violates unique constraint "name_unique" DETAIL: Key (name, collection)=(Export Records As CSV, 3af01eb9-0887-415b-b7fd-4d45a9d2760f) already exists."If a similar error is observed, perform the followingDelete the duplicate record from the UI as reported in the error.Run the following:sudo -u nginx php /opt/cyops-api/bin/console doctrine:migrations:migrate --no-interactionThen publish the modules.Note: Make sure to take a VM snapshot before making the changes. FortiSOAR Wed, 30 Sep 2026 13:58:00 +0200 https://community.fortinet.com/fortigate-3/technical-tip-testing-the-fortigate-rest-api-to-pull-firewall-policy-hit-count-and-other-cmdb-monitor-data-using-a-windows-batch-script-230279 DescriptionThis article describes how to quickly validate that the FortiGate REST API is working, and how to pull commonly-needed data like firewall policies list, policy hit counts, schedules, custom services, and service groups using a simple Windows batch (.bat) script and curl. This is a fast way to confirm API connectivity/authentication before building a larger automation, integration, or reporting workflow around the FortiGate REST API.ScopeFortiGate (tested on FortiOS 7.6.7, FortiGate-VM). Applicable to any FortiGate model that supports the REST API (api/v2/cmdb and api/v2/monitor endpoints). Requires a Windows machine with curl available (built into Windows 10/11) and network reachability to the FortiGate's admin (HTTPS) interface.SolutionCreate a dedicated REST API administrator on the FortiGate.Create a separate administrator of type REST API Admin. This keeps API access auditable and makes it possible to scope/restrict it independently of GUI/SSH admin access.Go to System -> Administrators -> Create New and select REST API Admin.Give it a Username (e.g. REST-API) and select an Administrator profile. super_admin is used here for testing read access across all endpoints, but for production use it is recommended to create a custom profile with only the read permissions actually needed (see the 'It is recommended to create a new profile...' warning shown below).A prompt will appear asking for admin password confirmation before the account is created.Once confirmed, FortiGate generates the API key. This is shown only once. Copy it immediately and store it securely (e.g. a password manager/vault). If it is lost, generate a new key from the administrator's settings.The new account now appears under System -> Administrators, grouped separately from the local System Administrator account, under REST API Administrator.Note: Depending on where the script will run from, ensure the following:The interface the FortiGate is reached on has HTTPS (and ideally not HTTP) enabled under admin access.If Trusted Hosts is enabled on the REST API admin account, the source IP of the machine running the script must be included, or API calls will be rejected.Build the batch script.The script below uses curl to call several FortiGate REST API endpoints with the API key as a Bearer token, and saves each response as a JSON file. For example, C:\RestAPI\Output\. Save this script file as a .bat file on the Desktop. For example: 'C:\Users\abc\Desktop\API.bat'.@echo off REM ==== VARIABLES ==== set IP=10.5.210.127 set TOKEN=gpccbmgHz8hpn13qyc6GHggqm7tr6w set VDOM=root set SERIAL=FGVM01TM25005725 set BASE=C:\RestAPI set OUTDIR=%BASE%\Output REM ==== COMMON HEADERS ==== set HDR_AUTH=Authorization: Bearer %TOKEN% set HDR_ACC=Accept: application/json echo Starting FortiGate Data Collection... REM ==== FIREWALL POLICY ==== curl -k -H "%HDR_AUTH%" -H "%HDR_ACC%" "https://%IP%/api/v2/cmdb/firewall/policy?vdom=%VDOM%&page=1&page_size=500" -o "%OUTDIR%\FirewallPolicy_%SERIAL%.json" REM ==== FIREWALL SCHEDULE ==== curl -k -H "%HDR_AUTH%" -H "%HDR_ACC%" "https://%IP%/api/v2/cmdb/firewall.schedule/onetime?vdom=%VDOM%&page=1&page_size=500" -o "%OUTDIR%\FirewallSchedule_%SERIAL%.json" REM ==== CUSTOM SERVICES ==== curl -k -H "%HDR_AUTH%" -H "%HDR_ACC%" "https://%IP%/api/v2/cmdb/firewall.service/custom?vdom=%VDOM%&page=1&page_size=500" -o "%OUTDIR%\FirewallServiceCustom_%SERIAL%.json" REM ==== SERVICE GROUP ==== curl -k -H "%HDR_AUTH%" -H "%HDR_ACC%" "https://%IP%/api/v2/cmdb/firewall.service/group?vdom=%VDOM%&page=1&page_size=500" -o "%OUTDIR%\FirewallServiceGroup_%SERIAL%.json" REM ==== FIREWALL HIT COUNT ==== curl -k -H "%HDR_AUTH%" -H "%HDR_ACC%" "https://%IP%/api/v2/monitor/firewall/policy?vdom=%VDOM%" -o "%OUTDIR%\FirewallPolicyHit_%SERIAL%.json" echo Completed FortiGate Data Collection. PauseAdjust before running:IPManagement IP/FQDN of the FortiGate (or VIP/port if HTTPS admin access is on a non-default port, e.g. IP:PORT).TOKENThe API key generated in Step 1.VDOMVDOM to query (root if VDOMs are disabled or the root VDOM is desired).SERIALUsed only to tag the output filenames, set to the unit's serial number or any preferred identifier.BASE / OUTDIRLocal folder where the script and its output live. Make sure OUTDIR exists before running, or add an mkdir line.Security note: -k tells curl to skip certificate validation, which is convenient for lab/testing but should not be used long-term against a production FortiGate. Instead import a trusted certificate on the FortiGate's admin HTTPS interface and drop -k from the script. Additionally, avoid hard-coding the API key in a script that will be shared or committed to source control; consider prompting for it or reading it from an environment variable/secret store.Run the script and confirm the API responses.Double-click API.bat (or run it from a cmd prompt). Each curl call prints its own transfer-progress meter, and the script reports completion when all five API calls have finished.Check the Output folder. One JSON file should have been created per API call, named using the %SERIAL% value from the script. A non-trivial file size (i.e. more than a few bytes) confirms the FortiGate actually returned data rather than an empty/error response.Each JSON file can now be opened directly, or parsed with a script/tool of choice. For example:FirewallPolicy_.json — full firewall policy table (cmdb/firewall/policy)FirewallPolicyHit_.json — real-time policy hit counters (monitor/firewall/policy)FirewallSchedule_.json — one-time firewall schedules (cmdb/firewall.schedule/onetime)FirewallServiceCustom_.json — custom services (cmdb/firewall.service/custom)FirewallServiceGroup_.json — service groups (cmdb/firewall.service/group)Troubleshooting quick checks:If a JSON file comes back empty, very small, or containing an HTTP error instead of data:Confirm HTTPS admin access is enabled on the interface being queried, and that the port in the URL matches the configured admin-sport if it has been changed from 443.Confirm the API key is current. Keys are only displayed once at creation; if it was regenerated, update TOKEN in the script.If Trusted Hosts is enabled on the REST API admin account, confirm the machine's source IP is permitted.Confirm the Administrator profile assigned to the REST API admin actually has read access to the endpoint being queried (a restrictive custom profile is a common cause of a 403 /empty response).Test a single endpoint directly from a browser or curl on its own (outside the script) to isolate whether the issue is the API itself or the script/variables. FortiGate Wed, 30 Sep 2026 13:11:54 +0200 https://community.fortinet.com/fortiswitch-36/troubleshooting-tip-fortiswitch-108-model-ssh-issue-in-versions-7-6-6-7-6-7-7-6-8-230193 DescriptionThis article describes an issue where, after upgrading FortiSwitch 108 to versions 7.6.6, 7.6.7, or 7.6.8, SSH access to the switch may fail.ScopeFortiSwitch 108 running versions 7.6.6, 7.6.7, or 7.6.8.SolutionWhile performing SSH to the FortiSwitch, the message below appears:host:~$ ssh admin@FortiSwitch IP admin@FortiSwitch IP's password: client_loop: send disconnect: Broken pipeWhile collecting sshd application debug, the following message appears on the FortiSwitch, and it fails at this point:SSH: send packet: type 51 SSH: receive packet: type 50 SSH: userauth-request for user ansible service ssh-connection method publickey SSH: attempt 1 failures 0The issue is fixed in FortiSwitch version 7.6.9.Workaround:From the FortiSwitch console, regenerate the SSH keys using:execute ssh-regen-keys FortiSwitch Wed, 30 Sep 2026 12:58:37 +0200 https://community.fortinet.com/fortigate-3/troubleshooting-tip-fortigate-process-known-issue-and-troubleshooting-resource-list-230278 DescriptionThis article lists the various processes running on the FortiGate and aims to correlate the Known Issue affecting the specific processes and the available troubleshooting resource. ScopeFortiGate/FortiOSSolutionProcess NameResource TypeResourceFortiOS Fix AvailableauthdTroubleshootingTechnical Tip: High CPU/memory with FSSO and authdKnown Issue - #1009884Technical Tip: 'authd' Consumes High CPU when 'idp-single-logout-url' is not configured under SAML Configuration7.4.5, 7.6.1Known Issue - #1304366Technical Tip: Captive Portal authentication fails with ERR_EMPTY_RESPONSE after upgrading to FortiOS v7.6.7 or v8.0.0-bmc.userTroubleshootingTroubleshooting Tip: High CPU usage on bcm.user after the upgrade to v6.4.x, v7.0.x and v7.2xbgpdKnown Issue - #1049721Troubleshooting Tip: How to identify and fix memory leak Issues caused by BGP daemon on the FortiGate7.4.5, 7.6.1cmdbsrvKnown Issue - #1223876Technical Tip: cmdbsvr process consuming high CPU on secondary unit due to large address group configuration7.6.7, 8.0.0Known Issue - #1114873Technical Tip: CPU Utilization of 'cmdbsrv' daemon remains high for approximately 11 minutes after rebooting FortiGate7.6.3Known Issue - #1173177Troubleshooting Tip: Firewall policy config change in a FortiGate with a large number of policies causing high CPU usage7.4.9, 7.6.5, 8.0.0cmdbsvr_cfgsave / cmdbsvr_ipropeKnown IssueTroubleshooting Tip: CPU Spikes after a configuration changeCheck details in the articlecsfdTroubleshootingTroubleshooting Tip: Troubleshooting Security Fabric Issuescw_acdKnown Issue - #1209209Troubleshooting Tip: IPsec VPN connection fails with error 'twin connection detected'7.6.5, 8.0.0Known IssueTechnical Tip: High memory due to the cw_acd process and potential causes | CommunityCheck details in the articleKnown Issue - #1101583Troubleshooting Tip: FortiAP go offline when the FortiOS cw_acd process becomes stuck at 99% CPU usage7.4.8, 7.6.3dhcpdTroubleshootingTechnical Tip: How to troubleshoot core of a high CPU issue due to DHCP processTroubleshootingTechnical Tip: High memory usage caused by DHCPD daemonKnown Issue - #1164174Troubleshooting Tip: The DHCPD process crashes with a signal 11 segmentation fault, preventing the assignment of a DHCP IP address7.4.9, 7.6.4, 8.0.0eap_proxyKnown Issue - #923164Technical Tip: EAP_Proxy consuming high CPU after upgrade to FortiOS v7.2.5 or v7.4.07.4.1fcnacdKnown Issue - #1007809Troubleshooting Tip: FortiGate unit with version 7.4.3 enters conserve mode due to AnonPages (fcnacd process) using a high amount of memory usage7.4.4, 7.6.0Known Issue - #1223402Troubleshooting Tip: FCNACD high memory on Chassis FortiGate7.4.x, 7.6.x, 8.0.x - Not AffectedfgtlogdTroubleshootingTechnical Tip: High memory usage in the fgtlogd process when API queries to add or remove objectsfnbamdTroubleshootingTechnical Tip: Workaround for auth proccess fnbamd stalling when a high volume of SSL connections are being authenticatedTroubleshootingTroubleshooting Tip: RADIUS server stuck at 'connecting' state when configuring a RADIUS server on GUIKnown Issue - #1244268Technical Tip: 'fnbamd' daemon consumes high CPU and crashes7.4.12, 7.6.7, 8.0.0Known Issue - #1003373Technical Tip: 'fnbamd' Daemon Consumes High Memory when Secure STARTTLS is Configured for LDAP7.6.1forticlddTroubleshootingTroubleshooting Tip: FortiCloud connection failure TroubleshootingTechnical Tip: How to troubleshoot FortiGate Cloud internal errorfortilinkdKnown Issue - #945779Troubleshooting Tip: How to stabilize the CPU when the consumption is on 100% due to FortiLink processes7.4.2harelayKnowledge / TroubleshootingTechnical Tip: Harelay processhasyncTroubleshootingTroubleshooting Tip: Troubleshooting methodology of hasync process high CPU usagehttpsdTroubleshootingTroubleshooting Tip: High CPU usage due to httpsd daemon on FortiGateTroubleshootingTroubleshooting Tip: FortiGate High CPU Usage and Web GUI Accessibility Issues due to httpsd processTroubleshootingTechnical Tip: CPU high when HTTPS is enabled on an interface in a multiple VDOM environmentTroubleshootingTechnical Tip: GUI is not reachable after an upgradeKnown Issue - #1256988Troubleshooting Tip: Unable to access FortiGate GUI because of high CPU due to httpsd process7.6.7, 8.0.0Known Issue - #1249113Troubleshooting Tip: Excessive memory consumption by httpsd daemon triggers memory conserve mode on FortiGate7.6.7, 8.0.1Known Issue - #1268947Troubleshooting Tip: High CPU with 100% softIRQ when creating or editing a VLAN Interface in the GUI7.6.7, 8.0.0Known Issue - #1007566Technical Tip: High CPU usage and slow GUI loading when modifying Address Group members (Known Issue)7.4.6, 7.6.1Known Issue - #1055740Troubleshooting Tip: High CPU usage issue when USB disk with many files is connected7.4.10, 7.6.5, 8.0.0http_authdKnown Issue - #1256988Technical Tip: Brute-Force Attacks may cause the device to enter Conserve Mode with multiple http_authd daemons after upgrading to FortiOS v7.6.67.6.7, 8.0.0Known Issue -#1256988Technical Tip: High CPU utilization caused by http_authd-Known Issue - #1233052Troubleshooting Tip: HTTPS GUI access fails on FortiGate v7.6.5 while SSH remains accessible7.6.7, 8.0.0Known Issue - #1219648Troubleshooting Tip: Unable to access GUI in firmware version 7.6.4 and above7.6.7, 8.0.0ikedTroubleshootingTechnical Tip: How to use TCP as transport for IKE/IPsec trafficKnown Issue - #1257646Technical Tip: High CPU observed when using session resumption for Dialup IPSec users using IKEv27.4.12, 7.6.7, 8.0.0Known Issue - #1081951Technical Tip: IKE daemon consumes high Memory after upgrade to v7.4.57.4.6, 7.6.1iked.sessionKnown Issue - #1117910Technical Tip: Workaround for high CPU usage taking by 'iked.session' daemon in v7.6.17.6.3initXXXXXXXXXXXKnown Issue - #953709Troubleshooting Tip: High CPU utilization due to the initXXXXXXXXXXX process7.4.4ipsengineKnowledge/TroubleshootingTechnical Tip: Introduction of IPS processKnowledge/TroubleshootingTroubleshooting Tip: Understanding high CPU usage on FortiGate VM with DPDK enabledTroubleshootingTechnical Tip: High CPU/Failopen mode due to GRE traffic increasing IPSEngine loadKnown IssueTechnical Tip: Insufficient memory during FortiGuard update may cause high CPU use in ipshelper and ipsenginelinkmtdKnown Issue - #1167426Troubleshooting Tip: High CPU usage of linkmtd daemon when link-monitor or fail-detect is enabledlog_seKnown Issue - #1141733Technical Tip: High CPU issue due to log_se process7.4.8, 7.6.4, 8.0.0miglogdTroubleshootingTechnical Tip: No memory logs seen in FortiGateTroubleshootingTroubleshooting Tip: Logs are not displayed in FortiViewKnown Issue - #1265180Technical Tip: Singular miglogd process consumes high CPU7.4.12, 7.6.7, 8.0.1Known Issue - #1292012Troubleshooting Tip: Log showing 'Fortinet Secure Module Violation: process-smiglogd]' after upgrade to FortiOS v8.0.08.0.1nodeTroubleshootingTroubleshooting Tip: High memory usage of node processTroubleshootingTroubleshooting Tip: How to identify and fix memory leak issues caused by node scripts on FortiGate firewallsTroubleshootingTroubleshooting Tip: Unable to stop the GUI packet capture tool running on FortiGate GUIKnown Issue - #1267107Troubleshooting Tip: Node process increases memory usage every 8 hours7.6.7, 8.0.0Known Issue - #1227167Troubleshooting Tip: Conserve mode triggered by node process in FortiOS v7.4.x and v7.6.x-Known Issue - #1149411Troubleshooting Tip: Conserve mode triggered by node process memory leak in FortiOS v7.4.8 and v7.6.37.4.9, 7.6.5, 8.0.0Known Issue - #1011833Troubleshooting Tip: 'node' Daemon consumes high amounts of CPU/Memory causing slow FortiGate GUI response7.4.8, 7.6.3Known Issue - #1087924Technical Tip: High Node.js daemon memory usage triggers Conserve Mode on Secondary HA Unit in HA cluster7.6.3openvmtoolsKnowledgeTroubleshooting Tip: High CPU behavior cause by the openvmtools processradvdTroubleshootingTechnical Tip: FortiGate RADVD Daemon Utilizing High CPUsnmpdTroubleshootingTechnical Tip: SNMP process is not listeningTroubleshootingTechnical Tip: High CPU Usage by the SNMPD ProcessKnown Issue - #1093042Technical Tip: High memory usage caused by the SNMPD Daemon7.4.8, 7.6.1scanunitdTroubleshootingTechnical Tip: Scanunitd causes high CPU load when scanning unknown malware TroubleshootingTroubleshooting Tip: High CPU Usage by scanunitd Daemon when Antivirus is set to scan Windows UpdatesmbcdTroubleshootingTechnical Tip: High memory smbcd usage due to too many AD event logs TroubleshootingTechnical Tip: High memory on SMB client daemonsrc-visTroubleshootingTechnical Tip: Transient high system CPU condition with src-vis CPU loadTroubleshootingTechnical Tip: High memory usage by src-visvmdTroubleshootingTechnical Tip: How to check Azure Linux Agent (waagent) version and status for FortiManager / FortiAnalyzer AzurevoipdKnown Issue - #1276335Troubleshooting Tip: FortiGate high memory usage due to VoIP daemon8.0.1wadKnowledge / TroubleshootingTechnical Tip: Overview of WAD process structureKnowledgeTechnical Tip: WAD process on FortiGate models with 2 GB RAMTroubleshootingTechnical Tip: Automatically restart WAD worker processesTroubleshootingTechnical Tip: High memory due to the WAD cert-manager processTroubleshootingTechnical Tip: High memory of the wad process due to object ssl.fts.str.fstr_buffer_bytes buffer usageTroubleshootingTechnical Tip: How to clear utilization of the disk partition from the WAD process on FortiGateTroubleshootingTroubleshooting Tip: High WAD user-info CPU usage due to too many discovered devicesTroubleshootingTroubleshooting Tip: WAD CPU spikes due to configuration changesKnown Issue - #1078385Technical Tip: WAD (wad-config-notify) process consumes high Memory after upgrade to v7.4.4, v7.4.5, v7.6.07.4.6, 7.6.1Known Issue - #898182Technical Tip: FortiGate WAD 'user-info' sub-process pinning a single CPU core to 100%, causing network instability7.6.3Known Issue - #1056600Technical Tip: High CPU usage and wad crash (signal 11) after upgrade to FortiOS 7.4.87.4.9, 7.6.1Known Issue - #1025078, #1086315Troubleshooting Tip: Memory Leak and Stuck Sessions When Using Virtual Server (VIP)7.4.8, 7.6.3Known Issue - #1214017Troubleshooting Tip: High memory usage when adding external threat feeds with a large number of similar patterns7.4.12, 7.6.5, 8.0.0wpad_acKnown Issue - #983526Troubleshooting Tip: SSIDs not broadcasting after the HA failover due to 'wpad_ac' process consuming high CPU7.4.4urlfilterKnown Issue - #1230414Technical Tip: Logical serial number feature may cause the Urlfilter process Memory leak7.4.10, 7.6.7, 8.0.0zebos_launcherTroubleshootingTechnical Tip: High Memory Utilization on FortiGate by 'zebos_launcher'Known Issue - #1279665Technical Tip: High CPU Utilization by the zebos_launcher process on the secondary FortiGate8.0.1Related articles:Technical Tip: Short list of processes on the FortiGateTechnical Tip: How to list processes in FortiOSTechnical Tip: FortiOS process to CPU associationTechnical Tip: Differences in process memory usage between commandsTechnical Tip: Optimize FortiGate-VM performance by configuring CPU interrupt affinityTroubleshooting Tip: IPsec CPU core saturation on FortiGate VM in AWSTechnical Tip: High iowait CPU usage and processes in D state when FortiGate free memory is low (Known Issue)Troubleshooting Tip: How to identify the CPU core used by a daemon processTroubleshooting Tip: FortiGate CPU Profiling FortiGate Wed, 30 Sep 2026 12:48:14 +0200 https://community.fortinet.com/fortigate-3/troubleshooting-tip-fsso-collector-agent-disconnected-from-fortigate-due-to-authentication-password-230277 DescriptionThis article describes a troubleshooting scenario where the Fortinet Single Sign-On (FSSO) Collector Agent shows as disconnected on the FortiGate firewall, and outlines the steps to verify server permissions and resolve the connection issue by resetting the authentication password.ScopeFortiGate, FSSO Collector Agent (Windows Server).SolutionWhen the FSSO Collector Agent fails to connect to the FortiGate firewall, it is recommended to first rule out local permission issues on the Windows Server before troubleshooting the authentication parameters.Follow these steps to diagnose and resolve the connection issue:Verify Windows Server Permissions.Ensure that the necessary folder, registry, and service permissions are correctly applied for the FSSO service on the Windows Server:Registry Permissions: Open the Windows Registry Editor and verify that there is full access to the following path: [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Fortinet\FSAE\collectoragent]Folder Permissions: Navigate to the installation directory (C:\Program Files (x86)\Fortinet\FSAE) and ensure that the folder has full access permissions.Service Account Privileges: Check the Windows Services (services.msc) and confirm that the account running the FSSO Collector Agent service is a member of the local Administrators group.Restart the FSSO Service:After verifying that all permissions are correct, restart the FSSO service on the Windows server. Check the FortiGate to see if the connection is restored. If the FSSO agent remains disconnected after multiple service restarts, the issue may be related to the password complexity between the FortiGate and the Collector Agent.Reset the FSSO Authentication Password.In some scenarios, a complex password or unsupported characters can cause the authentication between the firewall and the Collector Agent to fail silently.On both the FSSO Collector Agent and the FortiGate firewall, change the FSSO password to a simple, basic string (for example: 123456).Check the FSSO status on the FortiGate firewall. The status should now change to Connected.Once the connection is successfully established, try changing the password but with adequate complexity and verify the connection remains stable after the final password change. FortiGate Wed, 30 Sep 2026 11:46:32 +0200 https://community.fortinet.com/fortigate-3/technical-tip-enable-logging-of-user-dns-enquiries-when-fortigate-is-configured-as-a-dns-server-230276 DescriptionThis article describes how to enable logging of user DNS enquiries when a FortiGate is configured as a DNS server for the local client devices.As described in the configuration guide below (title "FortiGate DNS server"), FortiGate can be configured as DNS server to resolve DNS requests from clients on the local network on the FortiGate interface. But by default, FortiGate does not record users’ DNS enquiries. See FortiGate DNS server for more information. Configure DNS database:config system dns-server edit <name> set dnsfilter-profile {string} set doh {enable | disable} set doh3 {enable | disable} set doq {enable | disable} set mode {recursive | non-recursive | forward-only} set ssl-cert <certificate_name> next end config system dns-database edit <name> ... end next end ScopeFortiGate.SolutionIf it is required to record the user DNS enquiries, a dns-filter profile with option 'set log-all-domain enable' like the following can be created.Create a DNS-filter with the option 'set log-all-domain enable'. config dnsfilter profile edit "test-dns-filter" config ftgd-dns config filters edit 1 set category 26 set action block next edit 2 set category 61 set action block next edit 3 set category 86 set action block next edit 4 set category 88 set action block next end end set log-all-domain enable nextApply the DNS-filter to 'dns-server'.config system dns-server edit "port4" set dnsfilter-profile "test-dns-filter" next end Result: In this case, FortiGate itself is configured to use FortiGuard as DNS with encryption by DNS over HTTPS (DoH). Client's DNS requests to FortiGate are not encrypted. Only FortiGate’s own outgoing DNS requests are encrypted. FortiGate log can record the clients’ DNS enquiries.For example:config system dns set primary 96.45.45.45 set secondary 96.45.46.46 set protocol doh set server-hostname "globalsdns.fortinet.net" set log all end date=2026-06-02 time=13:08:45 eventtime=1780376925339073313 tz="+0800" logid="1500054000" type="utm" subtype="dns" eventtype="dns-query" level="information" vd="root" policyid=0 sessionid=919957 srcip=10.97.97.210 srcport=52337 srccountry="Reserved" srcintf="port4" srcintfrole="undefined" dstip=10.97.97.10 dstport=53 dstcountry="Reserved" dstintf="root" dstintfrole="undefined" proto=17 profile="test-dns-filter" xid=8800 qname="www.ft.com" qtype="A" qtypeval=1 qclass="IN" FortiGate Wed, 30 Sep 2026 11:40:44 +0200 https://community.fortinet.com/fortisiem-34/technical-tip-how-to-verify-if-old-events-in-clickhouse-still-exist-after-event-retention-period-is-over-229665 DescriptionThis article describes how to verify if old events in ClickHouse still exist after the event retention period is over.ScopeFortiSIEM.SolutionIt has been observed that some of the older events from previous months still exist while checking from Admin -> Settings -> Database -> Online data for Clickhouse deployment.This behavior is mainly observed when older events are not covered by the Retention policy.The commands below provide details about the number of retention days for the events.This information can be useful for comparing the number of retention days defined in the retention policy.Run both of the following commands on the ClickHouse Data node:clickhouse-client -q "from fsiem.events_replicated select distinct(toIntervalDay(retentionDays));" The command below provides details about the oldest and newest event dates covered by retentionDays:clickhouse-client -q "SELECT     retentionDays,     min(toDate(phRecvTime)) AS oldest_date,     max(toDate(phRecvTime)) AS newest_date,     count() AS events FROM fsiem.events_replicated WHERE phRecvTime >= now() - INTERVAL 1095 DAY GROUP BY retentionDays ORDER BY retentionDays;" FortiSIEM Wed, 30 Sep 2026 11:25:07 +0200 https://community.fortinet.com/fortisiem-216/fsiem-tier-structure-230262 Hello Guys,In version 7.5.1, while expanding the tier structure, can we add a “cold” tier without adding a “warm” tier? We’d like to do this using NFS as well. Thank youBest Regards FortiSIEM Wed, 30 Sep 2026 11:03:52 +0200 https://community.fortinet.com/fortisiem-216/best-practice-for-fortisiem-7-4-0-to-7-5-1-ha-migration-with-clickhouse-on-prem-230025 Hi Everyone,I need help to migrate a FortiSIEM deployment to new VMs in an on-prem VMware environment and could use some guidance on the proper workflow.Current setup: FortiSIEM 7.4.0 (Single-node Supervisor) on on-prem VMware ClickHouse datastore with ~400 GB of event logs Target setup: FortiSIEM 7.5.1 High Availability (HA) on brand-new VMs in the same on-prem VMware infrastructure Main concern:I need to make sure all 400 GB of ClickHouse event logs, along with the CMDB configurations and /svn data, are transferred over completely safely without corruption or data loss.Since we are changing both the architecture (Single Node > HA) and the version (7.4.0 > 7.5.1) on fresh VMs, I want to avoid schema mismatches or broken log indexes. Most KB articles I found (like KB173251) seem to cover older versions with flat-file EventDB rather than ClickHouse.What is the recommended step-by-step process to achieve this safely? Are there any specific KBs or official guides for moving ClickHouse data across VMware VMs in 7.x?Thanks in advance for any help! FortiSIEM Wed, 30 Sep 2026 10:53:24 +0200 https://community.fortinet.com/fortigate-3/technical-tip-fortios-ipsec-connected-client-shows-the-warning-message-two-factor-authentication-not-enabled-230275 DescriptionThis article describes a default behavior when connecting to an IPSec dial-up VPN tunnel with an eap-method enabled in the phase1-interface settings.Scope FortiOS versions 7.4.x, 7.6.x, 8.0.x.SolutionThere are several articles and documents explaining how to configure the EAP method in an IPsec dial-up IKEv2; therefore, this article does not cover it:IPsec IKEv2 VPN 2FA with EAP and certificate authenticationSSL VPN to IPsec VPN MigrationTroubleshooting Tip: Using IKEv2 for a dial-up IPsec tunnel with a RADIUS server and local userLDAP authentication with IKEv2 using UDP or TCP as transportAll the above IPsec remote connections end up with the same result: fail or succeed. This article explains why, in the FortiGate GUI -> Dashboard -> Network -> IPsec page, the connected user has a warning message: ‘Two-factor authentication not enabled’.This message is an expected warning message for any user group source (RADIUS, LDAP, SAML, or LOCAL) configured as a source object either in a firewall policy for an IPsec tunnel or directly in phase1-interface with EAP-method authentication enabled. A field, the ‘Two-factor Authentication’ attribute, is tied to the EAP method: FortiOS shows a warning message if two-factor authentication is not enabled when FortiGate is acting as an EAP authenticator/server, or two-factor is bypassed while using SAML-based authentication. DUO server configured as an LDAP server was not tested.Below are three outputs of the same remote user 'facuser01' while connecting as a RADIUS client and using SAML-based authentication.The screenshot below was taken for a remote RADIUS user ‘facuser01’ connected to the IPsec dial-up tunnel without 2FA enabled on the remote RADIUS server:Screenshot for the same user 'facuser01' with two-factor authentication is enabled on the remote RADIUS server:Screenshot of the same 'facuser01' while connecting to the IPSec via SAML-based authentication method. FortiAuthenticator acts as an IdP server. In the FortiClient GUI, the user was prompted for a 2FA code, but this request is bypassed by FortiGate and, as a result, 'two-factor authentication' is shown as disabled: FortiGate Wed, 30 Sep 2026 10:35:37 +0200 https://community.fortinet.com/support-forum-92/vpn-profile-configuration-via-intune-for-windows-11-users-230221 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. Support Forum Wed, 30 Sep 2026 10:09:46 +0200 https://community.fortinet.com/support-forum-92/fortimail-ibe-webmail-how-to-block-prevent-save-as-230274 We use FortiMail’s webmail for IBE secure mail exchange.The Webmail interface allows users to download the de-crypted emails using “save as” without any encryption. These mails are saved as decrypted plain email format (.eml)How can we disable this function in Webmail?Is piping the WebGUI through a reverse proxy/WAF to block this particular button the only way? Support Forum Wed, 30 Sep 2026 09:39:37 +0200 https://community.fortinet.com/forticlient-4/technical-tip-resolution-for-forticlient-windows-vulnerability-cve-2026-84386-230272 DescriptionThis article describes the impact of CVE-2026-84386 on FortiClient for Windows and provides the necessary versions for remediation.Scope FortiClient/EMS.SolutionCVE-2026-84386 affects the fortimon3 kernel driver installed with the Antivirus feature of FortiClient for Windows. A locally authenticated administrator can use an anti-exploit communication port exposed by the driver to terminate arbitrary processes. This vulnerability is rated Medium (CVSSv3 4.7), is not remotely exploitable, and requires administrator privileges on the endpoint.Affected versions:FortiClient for Windows v7.4.0 up to v7.4.7.FortiClient for Windows v7.2.0 up to v7.2.1.Fixed versions:FortiClient for Windows v7.4.8.FortiClient for Windows v8.0.0.FortiClient standalone:FortiClient standalone is an unmanaged VPN client that does not include the Antivirus feature. Because the fortimon3 driver belongs to the Antivirus feature, FortiClient Standalone is not exposed to this issue.Verification steps:To verify if an endpoint is vulnerable, perform the following steps:Open a command prompt as administrator.Run the following command: fltmc filtersCheck the output for a filter named fortimon3.Verify if the file C:\Windows\System32\drivers\fortimon3.sys exists on the system.If the fortimon3 filter is not listed and the fortimon3.sys file is not present, the vulnerable component is not installed, and no remediation is required. FortiClient Wed, 30 Sep 2026 08:00:10 +0200 https://community.fortinet.com/fortigate-3/troubleshooting-tip-bgp-session-established-with-isp-but-internet-access-is-not-working-230271 DescriptionThis article describes how to troubleshoot Internet connectivity issues when the BGP session with the ISP is in an established state.ScopeFortiGate.SolutionTopology:Symptoms:BGP session is established.Ping to 8.8.8.8 is not working.Troubleshooting:Verify whether the default route has been successfully installed in the routing table.The default route is not installed in either the routing table or the BGP routing table. Therefore, verify whether the default route is being received from the ISP through BGP neighbor 100.100.1.2.The output shows that the default route is being received from the ISP. However, the route is not installed in the BGP table. This indicates that the route may be rejected by an inbound routing policy, such as an incorrectly configured route-map or prefix-list.The route-map RM-ISP1-IN-PRIMARY is configured with a default action of permit, so it does not explicitly deny the default route. However, the route-map references the prefix-list PL-ISP1-IN. Therefore, verify the prefix-list configuration.The prefix-list PL-ISP1-IN is configured with a default action of permit, but the default route is incorrectly configured as 0.0.0.0/8 instead of 0.0.0.0/0.Because soft-reconfiguration is enabled for the ISP BGP neighbor, the default route is still displayed in the received-routes output. However, when the received route is evaluated against the configured prefix-list, it does not match 0.0.0.0/8 and is therefore not accepted into the BGP table.To resolve the issue, correct the prefix from 0.0.0.0/8 to 0.0.0.0/0 in prefix-list PL-ISP1-IN.After correcting the prefix-list referenced by the inbound route-map, perform a BGP soft reset in the inbound direction to re-evaluate the received routes.After the BGP soft reset, verify that the default route is now installed in the BGP table and the main routing table.Internet connectivity should now be restored.The above scenario is one example of how to troubleshoot an Internet connectivity issue when the BGP session is established. Other possible causes include:An incorrectly configured prefix-list referenced by the inbound route-map.A route-map-in configured with a deny action.A prefix-list configured with a deny action.The default route not being advertised by the ISP.BGP route-selection criteria preventing the route from being installed.An unreachable BGP next hop.Other inbound routing-policy configuration issues. FortiGate Wed, 30 Sep 2026 07:50:41 +0200 https://community.fortinet.com/support-forum-92/ssl-vpn-connection-failure-230265 Unable to connect to SSL VPN after firmware upgrade to v7.6.7. The connection goes to 10% then I get the following error message: "Unable to establish the VPN connection. The VPN server may be unreachable."  Support Forum Wed, 30 Sep 2026 01:53:47 +0200 https://community.fortinet.com/forticlient-4/technical-tip-forticlient-ems-auto-connect-a-vpn-tunnel-97414 Description   This article describes how to configure a FortiClient to auto-connect to a VPN tunnel. Scope All FortiClient versions. All FortiGates. All FortiClient EMS versions. Solution   Auto-connecting a VPN tunnel requires preliminary configuration on both the FortiGate and the FortiClient.   When specifying Auto-connection, only one tunnel can be set to auto-connect.   FortiGate.   SSL VPN Web Portal Tunnel Mode Settings:     config vpn ssl web portal     edit "full-access"         set auto-connect enable         set keep-alive enable         set save-password enable     next end   IPSec VPN Dial-up Settings. Enabling the 'Save Password', 'Auto Connect', and 'Always UP' options in the GUI is only possible when initially creating the VPN tunnel.     Modifying/disabling the 'Save Password', 'Auto Connect', and 'Always UP' options is only possible through the CLI afterwards.   config vpn ipsec phase1-interface     edit "FortiClients"         set xauthtype auto         set reauth disable         set authusrgrp "VPNUsers"         set save-password enable         set client-auto-negotiate enable         set client-keep-alive disable         set psksecret ENC   "tunnel_password"         set keepalive 10     next end   FortiClient. Enabling the 'Auto Connect', 'Always UP', or 'Save Password' options can only be done by editing the FortiClient XML configuration file (on non-managed installations).   From the FortiClient GUI, go to File -> Settings -> System. Back up the configuration. Edit the backup XML configuration file.   Locate the VPN tunnel section. Locate the [<show_remember_password>], [<show_alwaysup>], and [<show_autoconnect>] tags. Enable the tags by adding a [1] to the tags. Save the XML configuration. Restore the configuration to the FortiClient.   Note: Auto-connection settings are only set on FortiClient after the first tunnel connection.   For example:   <?xml version="1.0" encoding="utf-8"?> <forticlient_configuration generatedby="EMS-1.0.3.0107" policy="VPN_Only">     <version>5.4.1</version>     <vpn>         <sslvpn>             <connections>                 <connection>                     <name>                         <![CDATA[172.17.97.156_SSL]]>                     </name>                     <server>172.17.97.156:10443</server>                     <username />                     <password />                     <prompt_username>1</prompt_username>                     <ui>                         <show_remember_password>1</show_remember_password>                         <show_alwaysup>1</show_alwaysup>                         <show_autoconnect>1</show_autoconnect>                     </ui>                 </connection>             </connections>         </sslvpn>         <ipsecvpn>             <connections>                 <connection>                     <name>                         <![CDATA[172.17.97.156_IPSec]]>                     </name>                     <type>manual</type>                     <ui>                         <show_remember_password>1</show_remember_password>                         <show_alwaysup>1</show_alwaysup>                         <show_autoconnect>1</show_autoconnect>                         <show_passcode>1</show_passcode>                     </ui>                 </connection>             </connections>         </ipsecvpn>         <options> <autoconnect_tunnel>[tunnel_name]</autoconnect_tunnel>  <- Use Windows LDAP credentials for both VPN tunnel and Windows logon. <autoconnect_only_when_offnet>1</autoconnect_only_when_offnet>  <- Auto-connect the VPN tunnel only when off-net. <disable_connect_disconnect>1</disable_connect_disconnect>  <- Prevent disconnection. <show_vpn_before_logon>1</show_vpn_before_logon>  <- Optional. <use_legacy_vpn_before_logon>1</use_legacy_vpn_before_logon>   <- Optional. <keep_running_max_tries>0</keep_running_max_tries>  <- Retry count. <use_windows_credentials>1</use_windows_credentials>  <- Use Windows LDAP credentials for both VPN tunnel and Windows logon.         </options>     </vpn> </forticlient_configuration>   FortiClient EMS. When using a FortiClient EMS to push Profiles, enable the 'Remember Password', 'Always Up', and 'Auto Connect' options from under the VPN tunnel settings. Locate the Policy. Edit the tunnel. Go to Advanced Settings. Enable 'Remember Password', 'Always Up', and 'Auto Connect' options. Save the Profile. Sync the Profile to Endpoint.   IPSec VPN Tunnel:     SSL VPN Tunnel:   For VPN connection with ZTNA TAG secure posture validation, in Remote Access -> General is required to select Enable Secure Remote Access and select the preferred connection.      Related documents: IPsec VPN and SSL VPN Save password, auto connect, and always up IPsec VPN and SSL VPN Technical Tip: How to activate 'Save Password', 'Auto Connect', and 'Always Up' in FortiClient Technical Tip: Secure remote access configuration guide   Note: The following features are not supported in the FortiClient v6.2.X - v7.0.12, v7.2.X and v7.4.X free versions: VPN auto-connect/always-up. VPN before logon. On-net/off-net. Host check features. Central management No feedback option & no diagnostic tool under help/info page. IKEv2 is not supported on FortiClient 6.2.x free version. TAC support. FortiClient Wed, 30 Sep 2026 00:44:20 +0200 https://community.fortinet.com/support-forum-92/restrict-ipsec-remote-access-vpn-by-country-fortigate-201g-v7-4-12-230263 Hi Team,I configured IPsec Remote Access (Dialup) for FortiClient users (Windows, macOS, Android) on FortiGate 201G – FortiOS 7.4.12. How can I restrict VPN access based on Geo-IP, so users can connect only from a specific country?Thanks. Support Forum Tue, 29 Sep 2026 19:41:53 +0200 https://community.fortinet.com/support-forum-92/vpn-ipsec-dialup-authenticates-local-user-but-not-with-fortitoken-230266 Due to the lack of support of the SSL VPN, I am migrating the FortiClients VPN to IPSec. Created a new IPSec Dialup config and the tunnel worked fine for a local user. However when I enable the Fortitoken for the user (I receive the token in the email) but the tunnel never goes up and FortiClient show “time out” msg. Sniffing the traffic is possible to see my local peer trying to connect on port 500/4500 but get no answer back from the firewall. Once I try the user without the token it goes completely fine. Any ideas? Cheers Support Forum Tue, 29 Sep 2026 18:04:45 +0200 https://community.fortinet.com/support-forum-92/kernel-boot-trap-between-forticlient-and-dell-pro-3-14260-230222 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 have an idea of the cause, we sadly can’t deploy our brand new computers due to that.   Support Forum Tue, 29 Sep 2026 17:10:17 +0200 https://community.fortinet.com/support-forum-92/new-migration-tool-available-looking-for-feedback-229788 Hi all,I've made a free firewall migration tool, now available on GitHub: https://github.com/gateshift/gateshiftIt's still in beta, and feedback from people who actually do this work would be welcome.If you run firewall migrations or optimizations, give it a try and let me know where it falls short.  Support Forum Tue, 29 Sep 2026 16:45:41 +0200 https://community.fortinet.com/fortiadc-7/troubleshooting-tip-getting-502-bad-gateway-error-when-accessing-website-or-application-using-the-agentless-application-gateway-aag-230264 DescriptionThis article describes the solution for a situation where a '502 Bad Gateway' error appears while accessing a website or application using the Agentless Application Gateway (AAG).ScopeFortiADC and FortiADC VM version 8.0.3 or later.SolutionThe user receives '502 Bad Gateway' error when trying to access the website or application through the AAG portal.When using the 'Web App - Internal' App Bookmark Type, it only supports the same HTTP/HTTPS protocols for the front end (External) and back end (Server).If the front end is using HTTPS, the back end must also use HTTPS.Example:If the front end is using HTTP, the back end must also use HTTP.Example:When the front end and the back end are using different protocols, the user will receive the '502 Bad Gateway' error.Example:For a front end and back end using different protocols, use the the 'Web App - Internal - Advanced' App Bookmark Type, which is available in FortiADC version 8.0.3 or later.Refer to documentation at the end of this article for more information on the 'Web App - Internal - Advanced' configuration.Related documents:Agentless Application Gateway - New Features in FortiADC 8.0.3Step 9: Configuring Virtual Servers for "Web App - Internal - Advanced" Applications FortiADC Tue, 29 Sep 2026 16:40:18 +0200 https://community.fortinet.com/support-forum-92/suddenly-cant-connect-to-forticlient-ssl-vpn-230252 Recently upgraded my Fortigates to 7.4.5 - tested VPN - all fine.Gone to work from home and can no longer connect - stops at 10%I have tried absolutely everything I have seen online for example DIsabling IPV6 on both my network adapters and on my router.lowering MTUchecking all policieschanging DNS settingsloads of other things. The only thing I found that lets me connect is first connecting to Cloudflare one Traffic + DNS (UDP)I have checked and there no IP’s blocked on my Fortigates. No other user has reported a problem.I am on Youfibre. I cannot access many websites i need when connected to Cloudflare so this isn’t a permanent solution. Any ideas? The logs don’t seem to show many any errors of the time i’m trying to connect either. TIA Support Forum Tue, 29 Sep 2026 16:37:01 +0200 https://community.fortinet.com/support-forum-92/problems-with-version-7-6-6-in-fortios-230259 I upgraded my E-series FortiGate from version 7.6.3 to version 7.6.6. After the upgrade to 7.6.6, I lost connectivity to several networks that had been working without issues on version 7.6.3.I checked the configuration, and the static routes and policies remained unchanged; however, we had no connectivity. We had to downgrade back to version 7.6.3. Connectivity was restored after reverting to the previous version.Has anyone else encountered this scenario? I’ve reviewed the release notes and found nothing regarding configuration loss or any changes that might explain this behavior.Has anyone else experienced something similar?NOTE: My FortiGate has FortiLink configured with a FortiSwitch. I am not sure if this could be a compatibility issue. However, upon reviewing the release notes, I haven't found anything related to this type of behavior. Support Forum Tue, 29 Sep 2026 16:28:40 +0200 https://community.fortinet.com/forticlient-4/technical-tip-how-to-uninstall-a-managed-forticlient-in-windows-machines-94084 Description   This article describes the steps that need to be taken to uninstall a managed FortiClient using the FC Removal Tool.   Scope   FortiClient EMS v6.0+, v6.2+, v6.4+, v7.0+, v7.2+ v7.4+. Solution   Sometimes, there is a need to force the FortiClient uninstallation from an endpoint that has no connection with EMS; therefore, a special tool will be needed for that. In this case, it will be using the FortiClient Removal tool. Follow all the steps that need to be taken to accomplish this task.   Access the site 'https://support.fortinet.com' login with the credentials and navigate to 'Support' -> 'Firmware Download':     In 'Select Product', choose the option 'FortiClient', select 'Download', and then 'Windows':       Navigate to the needed version, in this example, it is chosen 'v7.00 / 7.4 / 7.4.0', then download the FortiClientTools, select 'HTTPS':     Copy the Tools to the machine that needs the FortiClient to be uninstalled and boot the Windows in 'Safe Mode'. Tip: To ask the Windows endpoint to boot in safe mode without the need for pressing the F8 button during startup, open a Command Prompt and type the following: bcdedit /set {default} safeboot minimal. Then reboot the system:     Go to the directory where the tools were copied, unzip the file, and access the 'SupportUtils' folder:     Execute the 'FCRemove.exe' as administrator:     A warning message will appear, read it and select 'OK' to proceed:   Another warning message stating that it will be necessary to reboot the system, for the uninstallation to be completed, select 'Yes' to proceed: Tip: It is also possible to select 'No', and configure the system to boot in normal mode prior to reboot. To ask the Windows endpoint to boot in normal mode without the need for pressing the F8 button, open a Command Prompt and type the following: bcdedit /deletevalue safeboot. Then it is possible to manually reboot the system:     The system will reboot and the uninstallation will be completed with success:     Now the system does not have the FortiClient installed anymore. Note: For the tool to function, FortiClient needs to be shut down from the taskbar.  FortiClient Tue, 29 Sep 2026 16:19:26 +0200 https://community.fortinet.com/support-forum-92/ztna-causing-windows-built-in-applications-slowness-230124 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.   Support Forum Tue, 29 Sep 2026 15:57:28 +0200 https://community.fortinet.com/fortigate-3/technical-tip-azure-fortigate-vm-generation-1-to-generation-2-migration-procedure-230261 DescriptionThis article describes the general steps required to migrate Generation 1 VMs to Generation 2 VMs in Microsoft Azure.ScopeFortiGate-VM on Microsoft Azure.SolutionCurrently, there is no direct upgrade path from Generation 1 to Generation 2 FortiGate-VM instances. Microsoft only supports this migration for specific Windows and Linux images. Therefore, the FortiGate-VM needs to be redeployed as a Generation 2 instance, after which the configuration backup and license must be reapplied.Prerequisites:The new FortiGate VM (Gen2) must be deployed in the same Azure region as the existing FortiGate VM.The licensing type of the new FortiGate must match the existing FortiGate. A direct conversion from BYOL to PAYG or vice versa is not supported.The old and new FortiGate VMs must run the same FortiOS version. Therefore, the existing FortiGate VM must first be upgraded to a FortiOS version that is available for Generation 2 VMs through the Azure Marketplace. Restoring a configuration file from an older FortiOS version to a newer version is not recommended, as it requires manual modification of the file headers and may result in parsing issues due to syntax changes between different FortiOS versions.(Optional) Since this guide covers simply swapping the interfaces from the old VM to the new VM, there is no need to explicitly deploy an HA template for the new Generation 2 VM. A single-VM template can be used instead, while ensuring that the selected VM size supports the required number of NICs based on the existing topology.Requirements for the BYOL license type:The new FortiGate (Gen2) VM must be licensed first. Once the license has been successfully activated, the backup configuration from the old FortiGate (Gen1) VM can be restored.Before applying the license to the new FortiGate, the existing FortiGate should be shut down. To avoid licensing duplication errors, the license can be removed from the old FortiGate before shutting it down by running:execute vm-license-options reset execute update-nowInternet connectivity is required for the initial license activation of the new VM. This may require temporary Internet access through a Public IP address directly assigned to the FortiGate NIC.Important notes:When attaching the interfaces from the old FortiGate VM to the new FortiGate VM, it is important to maintain the same interface order/sequence. Breaking the sequence may cause interface enumeration issues where, for example, NIC-1 in the portal does not correspond to port1 after the FortiGate boots up.If FortiGate_CA is used for deep inspection, the new FortiGate CA certificate must be imported to the client devices.For HA deployments using an SDN connector, if Managed Identity is used, the required roles must be assigned to the new VMs in the same way as on the existing VMs. If a Service Principal is used, no further action is required, as the Application ID and secrets are already stored in the backup configuration that will be restored.To avoid unexpected failover during the HA migration process, temporarily disable HA override and start the migration with the secondary VM, which has the lower priority.Console access is required to access and configure the interfaces after the interface swap, allowing the configuration to be restored on the new VMs.Single-VM deployment migration procedure:Download the backup configuration file from the old VM and shut down the VM.Create a new FortiGate (Gen2) VM in the same Azure region and resource group.License the new FortiGate (Gen2) VM. Once the license has been successfully activated, restore the backup configuration from the old VM.Shut down the new Gen2 FortiGate after the configuration has been restored. Use console access to monitor the boot status if SSH or GUI access is unavailable at this stage.Detach all interfaces from the new Gen2 VM, except for the primary interface. The primary interface cannot be detached unless another interface is available to assume the primary role.Detach NIC-1 (Primary) from the Gen1 VM and attach it to the Gen2 VM.Attach one of the previously detached interfaces from the Gen2 VM to the Gen1 VM.Detach NIC-2 from the Gen1 VM and attach it to the Gen2 VM.If more than 2 interfaces are present in the existing topology, re-attach the remaining interfaces to the new Gen2 VM, ensuring that the interface numbering or alphabetical order matches the order displayed in the Azure Portal.Once all interfaces have been attached, boot the new FortiGate VM and verify that it is operating correctly.Clean up any resources that were automatically deployed by the Azure Marketplace.HA Active-Passive or Active-Active using SDN connector or ELB/ILB:Download the backup configuration files from both the primary and secondary VMs. Shut down the secondary VM first to minimize downtime. If the maintenance window allows for downtime, both VMs can be shut down.Create a new FortiGate (Gen2) VM in the same Azure region and resource group. If a single-VM template is used, ensure that the selected VM size supports the same number of NICs as the existing deployment. Repeat the single-vm deployment for each FortiGate VM in the existing cluster. Alternatively, an HA template can be used, which automatically deploys 2 FortiGate VMs.License the new secondary FortiGate (Gen2) VM. Once the license has been successfully activated, shut down the VM.Detach all interfaces from the new Gen2 VM, except for the primary interface. The primary interface cannot be detached unless another interface is available to assume the primary role.Detach NIC-1 (Primary) from the secondary Gen1 VM and attach it to the new Gen2 VM.Attach one of the previously detached interfaces from the Gen2 VM to the Gen1 VM.Detach the remaining NICs from the secondary Gen1 VM and attach them to the Gen2 VM, ensuring that the interface numbering or alphabetical order matches the order displayed in the Azure Portal.Once all interfaces have been attached, boot the new Gen2 FortiGate VM. Using console access, re-configure at least one management interface and enable HTTPS or SSH access so that the backup configuration can be restored.Access the secondary Gen2 VM through the configured HTTPS or SSH connection and restore the backup configuration.Once the secondary Gen2 VM is online and operating correctly, repeat the same migration procedure for the Primary Gen1 FortiGate VM.Clean up any resources that were automatically deployed by the Azure Marketplace.Note: If the configuration backup is restored while the VM has fewer NICs attached than the number of interfaces configured in the backup, the configuration will not be imported correctly. Therefore, the backup configuration must be restored only after the same number of NICs as those defined in the configuration file have been attached to the FortiGate VM.Related documents:Technical Tip: FortiGate-VMs in Microsoft Azure using Generation 1 vs Generation 2 VMsSupport for Generation 2 VMs on AzureMANA support for Network Virtual Appliances (NVAs)Technical Tip: FortiGate-VMs in Microsoft Azure running on MANA (Microsoft Azure Network Adapter) enabled hosts FortiGate Tue, 29 Sep 2026 15:46:22 +0200 https://community.fortinet.com/fortimanager-27/technical-tip-update-the-fortimanager-serial-number-on-multiple-devices-via-script-230260 DescriptionThis article describes how to automatically update the FortiManager serial number on multiple FortiGate devices after a license change that causes an FGFM tunnel disconnection and not being able to manage these devices from the FortiManager.ScopeFortiManager, FortiGate.SolutionThere are specific cases when the FortiManager serial number may change due to one of the following situations:VM License expired and a new license was uploaded.VM License is updated via FortiFlex.RMA. FortiGate devices associated with the original serial number would be disconnected from the FortiManager and display the status of FGFM tunnel as down. To resolve this without manually configuring each device, create and run a CLI script to update the central management settings for multiple devices or groups.There are 2 scenarios when the FortiGate device doesn't have VDOMs and the case when FortiGate has multiple VDOMs. For each case, there will be a slight difference in script content.Case 1 - FortiGate doesn't have VDOMs.Create a CLI script with the following commands:config system central-management set serial-number <FMG_SN> endReplace <FMG_SN> with the new FortiManager serial number.Install the script on the group of FortiGate devices without VDOMs.Run the script on the FortiGate devices using the option to run script on: 'Remote FortiGate Directly (via CLI)' rather than on the 'Device Database' to ensure the FGFM connection to FortiManager is not lost.Result:-------Executing time: Tue Sep 15 11:39:37 2026-----------   Starting log (Run on device) boson-50 (global) config system central-management boson-50 (central-management) set serial-number "FMGVMSTMXXXXXXXX" boson-50 (central-management) end ----------------End of Log------------------------- Case 2 - FortiGate has multiple VDOMs.Create a CLI script with the following commands:config global config system central-management set serial-number <FMG_SN> endReplace <FMG_SN> with the new FortiManager serial number.Install the script on the group of FortiGate devices with multiple VDOMs.Run the script on the FortiGate devices. Select the option to run script on: 'Remote FortiGate Directly (via CLI)'.Result:-------Executing time: Tue Sep 15 11:39:37 2026-----------   Starting log (Run on device) boson-50 config global boson-50 (global) config system central-management boson-50 (central-management) set serial-number "FMGVMSTMXXXXXXXX" boson-50 (central-management) end ----------------End of Log------------------------- Note: There are limitations related to specific CLI commands used in scripts to avoid invalid or sensitive configurations being made on the Device Database. The full list of CLI commands affected by this limitation can be found here: Technical Tip: FortiManager failed to execute script in the Device Database.Related documents:Technical Tip: FortiManager failed to execute script in the Device DatabaseTechnical Tip: How to configure 'fmg-source-ip' from FortiManager using TCL Script FortiManager Tue, 29 Sep 2026 15:38:49 +0200 https://community.fortinet.com/fortigate-3/technical-tip-fsso-resource-list-230258 DescriptionThis article provides a list of FSSO-related documentation, both community articles and official Fortinet documentation.ScopeFSSO, FortiOS, FortiAuthenticator.SolutionFSSO (Fortinet Single-Sign-On) is a mechanism by which FortiGate (or FortiProxy) devices may learn user logins from various sources (most commonly Windows AD) without requiring the user to authenticate actively to the device.User identity and group membership information can then be used to apply tailored firewall policies and security profiles and restrict or allow access to resources as necessary to maintain a secure and transparent environment.Explaining FSSO:These articles are a good starting point for understanding FSSO concepts, components, and operating modes.Technical Tip: Explaining FSSO - a primer — broad overview of FSSO, its components, login processing, DNS/group lookup, ignore lists, and troubleshooting pointers.Technical Tip: A basic explanation of FSSO DC Agent mode — a focused explanation of DC Agent mode in simplified terms.Technical Tip: FSSO choose between DC Agent mode or Polling mode — a comparison between DC Agent and Polling mode.Technical Tip: How to switch FSSO operation mode from Standard Mode to Advanced Mod — a comparison between standard and advanced mode, when to use which mode and how to switch.Technical Tip: Comparing the limitations of an FSSO local poller (FSSOD) with an FSSO collector agent — useful for understanding FortiGate local polling limitations.FortiGate documentation: FSSO — explains FSSO architecture, FortiAuthenticator as a central source, agent-based FSSO, and agentless FSSO.FortiAuthenticator documentation: Fortinet Single Sign-On — FortiAuthenticator-side FSSO overview, including supported collection methods and polling behavior.Basic configuration of FSSO Agents:These are the community resources that help with Collector Agent/DC Agent/polling-related setup and behavior.Technical Tip: How to install the FSSO Collector Agent — a guide on how to install the FSSO Collector Agent.Technical Tip: Restricting a Fortinet Single Sign On Agent Service (FSSO) service account — how to configure the FSSO Agent service account with the minimum required privileges.Technical Tip: FSSO Agent in polling mode — configuration/behavior for polling-based collection.Technical Tip: Configure FSSO in DC Agent mode — configuration/behavior for DC Agent-based collection.Technical Tip: Windows event IDs used by FSSO in WinSec polling mode — useful for understanding which Windows log events FSSO monitors.Technical Tip: FSSO Group Filter configured on Collector Agent — how to configure FSSO group filter on Collector Agent (standard mode).Technical Tip: How FSSO Collector Agent performs name resolution — explains workstation/IP resolution behavior.Technical Tip: Disable the DNS resolution of the FSSO DCAgent — DNS behavior control for DC Agent deployments.Technical Tip: How and why to use the 'Ignore User List' option in FSSO Collector Agent — how to suppress selected accounts from FSSO processing.Technical Tip: Excluding IP addresses from FSSO logon events — ignore-list behavior for IP ranges.FortiGate documentation: FSSO using Syslog as source — shows a non-Agent source that can still feed FSSO sessions.Technical Tip: A guide to FSSO redundancy — how to configure an FSSO setup redundantly.Configuration on FortiGate:These resources cover how FSSO is added on the FortiGate side.FortiGate documentation: Fortinet single sign-on agent — FortiGate connector for agent-based FSSO.FortiGate documentation: Poll Active Directory server — FortiGate agentless polling connector.Technical Tip: Configure Fortinet Single Sign On (FSSO) for SSL-VPN users via Syslog — an example of how to configure FSSO to capture SSLVPN user logins via syslog.Configuration on FortiAuthenticator:These articles cover FortiAuthenticator as the FSSO collector/source, including Mobility Agent, polling, filters, and SAML-related FSSO behavior.FortiAuthenticator documentation: FortiAuthenticator Windows event log sources — FortiAuthenticator polling source configuration.FortiAuthenticator documentation: FortiAuthenticator Syslog sources — FortiAuthenticator syslog collection.FortiAuthenticator documentation: FortiAuthenticator RADIUS accounting sources— FortiAuthenticator RADIUS accounting collection.Technical Tip: FortiAuthenticator FSSO with DC Agent — FortiAuthenticator as collector with DC Agent.Technical Tip: Configure FortiAuthenticator as Collector Agent and in Polling mode — FortiAuthenticator polling-mode configuration.Technical Guide: A detailed guide to FSSO Mobility Agent — FortiAuthenticator Mobility Agent setup.Technical Tip: FSSO Filtering — FortiAuthenticator global pre-filtering and FortiGate-specific filtering.FortiAuthenticator documentation: FSSO Portal Services — portal-based authentication sources that can generate FSSO sessions.FortiAuthenticator documentation: FSSO SAML authentication — FortiAuthenticator SAML-based FSSO behavior.FortiAuthenticator REST API Solution Guide: SSO authentication — API-driven creation of FSSO sessions.FortiAuthenticator documentation: SAML FSSO with FortiAuthenticator and Okta — example showing FortiAuthenticator acting as the SP and forwarding FSSO information to FortiGate.FortiAuthenticator documentation: SSOMA for native Microsoft Entra ID joined workstation — SSOMA example with Entra ID joined workstations.FortiClient XML Reference: SSOMA configuration — endpoint-side SSOMA settings.Troubleshooting:This section provides an overview of available FSSO troubleshooting documentation.Troubleshooting Tip: FortiAuthenticator FSSO troubleshooting — structured troubleshooting flow for FortiAuthenticator, including monitor pages, logs, filters, and FortiGate communication checks.Troubleshooting Tip: FSSO Complete troubleshooting for TAC tickets — comprehensive FSSO troubleshooting guide.Technical Tip: How FSSO works and how to troubleshoot FSSO — general operational and troubleshooting guidance.Troubleshooting Tip: When using FSSO based on RADIUS Accounting, FortiGate fails to apply correct policy — RADIUS-accounting parsing and policy-match troubleshooting.Troubleshooting Tip: How to troubleshoot FSSO agentless polling mode issue — agentless polling troubleshooting.Technical Tip: Optimization of FSSO workstation IP address verification — IP verification tuning. FortiGate Tue, 29 Sep 2026 14:51:16 +0200 https://community.fortinet.com/support-forum-92/fortigate-fw-upgrade-limitations-230257 Hello community,Product: FortiGate-90GThe device is currently running FortiOS 7.4.7 build 2731.Its FMWR/support contract expired on 11 July 2025.FortiCloud SSO access is currently being blocked with Attack ID 20000021 because the installed FortiOS version is affected by CVE-2026-24858. I would therefore like to update the device to a security-fixed FortiOS release. However, due to the expired support contract, the FortiGate does not permit the upgrade through FortiGuard and the FortiCare portal does not allow me to download the firmware image manually. I am not requesting access to a newer major/minor FortiOS branch. I would like to remain within the existing FortiOS 7.4.x branch and upgrade only to the current security-fixed patch release, preferably FortiOS 7.4.12.Is it possible for the the official FortiOS 7.4.12 firmware image for this FortiGate-90G to be provided, or can someone from this community enable another supported method of upgrading this device to 7.4.12 for security remediation?Or, if a direct upgrade from 7.4.7 to 7.4.12 is not supported, please provide the required intermediate firmware image(s), such as FortiOS 7.4.8, and advise on the supported upgrade path. I would also appreciate clarification regarding the required firmware upgrade mechanism introduced in FortiOS 7.4.8 for FortiGate appliances with invalid support contracts.Since this device is currently running 7.4.7, it appears unable to make use of that mechanism. My objective is specifically to remediate the security vulnerability and restore FortiCloud SSO functionality while remaining within the existing FortiOS 7.4.x branch.Thanks,Alex  Support Forum Tue, 29 Sep 2026 14:43:01 +0200 https://community.fortinet.com/fortisoar-35/troubleshooting-tip-fortisoar-displays-a-configuration-wizard-error-after-upgrading-to-7-6-5-230256 DescriptionThis article describes how to resolve an issue where, after upgrading FortiSOAR to version 7.6.5, accessing the appliance through SSH displays a configuration wizard error message with a blue screen:'FortiSOAR is already configured. Exiting the configuration wizard.'ScopeFortiSOAR version 7.6.5.SolutionAfter logging in to FortiSOAR through SSH, the following configuration wizard may be displayed even though FortiSOAR is already configured.Log in as csadmin and switch to the root shell:sudo -sCheck whether config-vm.sh is still being called from /home/csadmin/.bash_profile.grep 'config-vm.sh' /home/csadmin/.bash_profileExample output:[csadmin@fortisoardev ~]$ grep 'config-vm.sh' /home/csadmin/.bash_profile # config-vm.sh removes its call from this script once vm configuration is successful sudo /opt/cyops/scripts/config-vm.shIf the following active line is present:sudo /opt/cyops/scripts/config-vm.shEdit /home/csadmin/.bash_profile and either remove the line or comment it out.For example:sudo /opt/cyops/scripts/config-vm.shSave the changes and exit the current SSH session.Log in to FortiSOAR again through SSH and verify that the configuration wizard is no longer displayed.Cause:The behavior occurs when the call to config-vm.sh remains active in /home/csadmin/.bash_profile after FortiSOAR has already been configured.As a result, the configuration script is invoked during login and detects that the system configuration has already been completed. FortiSOAR Tue, 29 Sep 2026 14:26:44 +0200 https://community.fortinet.com/customer-service-42/customer-service-tip-partner-portal-overview-including-technical-support-chat-and-customer-service-chat-230255 DescriptionThis article describes the chat support options available to partners through the Partner Portal, including Technical Support Chat and Customer Service Chat.ScopePartner Portal.SolutionAs of June 2026, Partners can access both Technical Support chat and Customer Support chat options based on the Partner’s account access and permissions. Chat OptionAvailabilityKey ConditionCustomer Service Chat.Available to all partner users irrespective of access and permissions.Can be accessed without switching to a customer account.Technical Support Chat.Available only to partners connected to a customer account with access to Technical web chat.Partners must select the appropriate customer account and have the required permissions.As a partner, the Customer Service Chat option is the only one available by default. To initiate a Technical Support Chat, the customer must first grant the partner 'Web Chat' access through the Partner Role in their Support Portal account.Once access has been granted, partners must log in to the Partner Portal, then switch to the corresponding connected customer account and initiate a Technical web chat. To proceed, the partner must select a serial number with active support under the customer’s account. If there are no serial numbers associated with the account, or if the device does not have an active support, a technical webchat cannot be initiated.For further details on creating a Partner role as a customer, refer to the following:Creating a Partner role as a CustomerPartner role FAQ Customer Service Tue, 29 Sep 2026 14:20:09 +0200 https://community.fortinet.com/fortigate-3/troubleshooting-tip-radius-configuration-purged-when-pushing-policy-package-to-fortigate-devices-via-fortimanager-212154 Description   This article describes an issue where RADIUS configurations on newly added FortiGate devices are removed after pushing a policy package from FortiManager.   Scope   FortiGate, FortiManager.   Solution   FortiGate is added in FortiManager, andthe  connection status is up:     Policy package assigned to the device:     Radius Config present on the FortiGate before policy package push:     The policy package is pushed by creating a new policy, and the installation preview logs clearly show that the RADIUS server configuration is being purged:       On the FortiGate, the RADIUS configuration is no longer visible as it has already been removed.     FortiManager purges the RADIUS server configuration because it is not referenced in any firewall policy. During a policy package installation, FortiManager is expected to remove radius configurations that have zero references.   The recommended approach is to create the RADIUS server configuration directly in FortiManager, include it in the relevant policy package, and then use the Install Wizard to deploy the package to the FortiGate.       When the policy package is pushed, FortiManager installs the RADIUS configuration, and this time the configuration is not purged.     After the policy package is installed, the RADIUS configuration is present on the FortiGate.   FortiGate Tue, 29 Sep 2026 14:13:55 +0200 https://community.fortinet.com/fortigate-3/technical-tip-using-auto-script-combining-with-automation-stitch-and-save-the-output-on-fortigate-where-sending-the-output-to-a-destination-is-not-possible-230254 DescriptionThis article describes how to run an auto-script called by an automation stitch and save the output on FortiGate when sending the output to a destination is not possible.ScopeFortiGate.SolutionWhile using automation stitches, the CLI script action uses the auto-script capability to execute the script commands. The size of the output for the script execution is controlled by the auto-script feature's output size (10MB by default). By default, when the automation stitch, with a CLI Script type action is triggered, an auto-script called autod[0] is automatically generated. The output of the script can be fed as a variable (%%results%%) into the next action in the stitch, and since it is intended to be temporarily run at the request of the stitch, dumping the results to an external location via email, FTP, or webhooks, it is immediately deleted after execution.Related Article:Technical Tip: Automatic auto-script generation due to automation stitch If it is required to keep the results on FortiGate for some time due to the nature of the issue to be monitored, a custom auto-script can be configured and called by CLI script action. In this way, the collected outputs can be displayed and captured later. Note: Since the resources on FortiGate will be used to save these outputs, care must be taken to avoid resource issues on FortiGate. This article provides an example of how to configure an auto-script to capture CPU-related outputs throughout the given time and store them on FortiGate after a High CPU event is triggered. Create an auto-script :config system auto-script edit "collect_cpu_resources" set interval 30 set repeat 10 set script "execute time get system performance status diagnose sys session full-stat diagnose sys session exp-stat diag sys top 1 30 3 diag sys mpstat 1 5 diag hardware sysinfo interrupts diag snmp ip frags diagnose hardware sysinfo shm diagnose hardware sysinfo conserve diag hardware sysinfo memory diag hardware sysinfo slab fnsysctl cat /proc/net/snmp fnsysctl cat /proc/softirqs get system ha status" set output-size 30 next end The options need to be considered while configuring auto-script:'interval'  --> Repeat interval in seconds.'repeat'   --> Number of times to repeat this script (0 = infinite).'script'   --> List of FortiOS CLI commands to repeat.'output-size'  --> Number of megabytes to limit script output to (10 - 1024, default = 10).'timeout'  --> Maximum running time for this script in seconds (0 = no timeout). Create the cli-script type automation-action: config system automation-action     edit "action_collect_cpu_resources"         set action-type cli-script         set script "execute auto-script start collect_cpu_resources"         set accprofile "super_admin"     next end The default High CPU automation trigger can be used: config system automation-trigger     edit "High CPU"         set description "A FortiGate has high CPU usage."         set event-type high-cpu     next end Create the automation stitch: config system automation-stitch     edit "high_cpu_automation_stitch"         set trigger "High CPU"         config actions             edit 1                 set action "action_collect_cpu_resources"                 set required enable             next         end     next end  With this configuration, FortiGate would start collecting the script output by running the script 10 times with 30-second sleeps, or roughly five minutes. Following execution, the output of the script can be examined using execute auto-script result collect_cpu_resource  Related articles:Technical Tip: Automated scripts (auto-script). Execution, testing and verification explained with examplesTechnical Tip: How to run auto-script and send the output to FTP/TFTP server FortiGate Tue, 29 Sep 2026 13:52:36 +0200 https://community.fortinet.com/fortinac-28/technical-tip-send-a-tagged-vlan-via-radius-146942 Description   This article describes the key traits of normal RADIUS responses that usually include the untagged VLAN for a port with the attribute 'Tunnel-Private-Group-Id'. There are specific cases when the RADIUS response should include a tagged VLAN instead. For example: an IP Phone that does not support Voice VLAN VSAs and is pre-configured with a tagged VLAN.   Scope   FortiNAC.   Solution   There is a standardized way to implement this as shown in RFC 4675. The attribute is Egress-VLAN-Name (type 58) or Egress-VLANID. The Egress-VLAN-Name parameter consists of a VLAN name entry and a flag that dictates whether frames on the VLAN are tagged or untagged.   This is also documented on the FortiSwitch Administration guide. See the guide for instructions on how to use the Egress-VLAN-Name attribute, which is easier (more human readable) than using Egress-VLANID. In FortiSwitch, this can be achieved by adding the value 1 before the VLAN description. For example, if the description is 'Voice', the attribute should be configured with the string '1Voice'.   To achieve this, a new set of attribute groups needs to be created in FortiNAC:     Make sure that FortiNAC sends only this new set of attributes on the RADIUS replay. By default, FortiNAC will try to merge the default group attributes with the new attributes it finds in 'Additional RADIUS Attribute Group'.     The solution is to set the 'Default RADIUS Attribute Group' to None at the network device level and set the group attribute manually (in this case, the 'RFC_Vlan-FSW-T' group created manually) for the logical network of the Voice VLAN.     The RADIUS response should look like this:   10:58:00.509417 IP (tos 0x0, ttl 64, id 48974, offset 0, flags anone], proto UDP (17), length 68) 10.0.0.5.1812 > 192.168.1.102.43139: RADIUS, length: 40 Access-Accept (2), id: 0x58, Authenticator: 450688f3a54b47a401007509fb7a88a8 Tunnel-Type Attribute (64), length: 6, Value: Tag Unused] VLAN Egress-VLAN-Name Attribute (58), length: 8, Value: Tagged (0x31) Voice Tunnel-Medium-Type Attribute (65), length: 6, Value: Tag Unused] 802   The authentication session should look like this:   port4 : Mode: mac-based (mac-by-pass enable) Link: Link up Port State: authorized: ( ) Dynamic Allowed Vlan list: 540 Dynamic Untagged Vlan list: EAP pass-through : Enable Auth Order : MAB-dot1x Auth Priority : Legacy EAP egress-frame-tagged : Enable EAP auto-untagged-vlans : Enable Allow MAC Move From : Disable Dynamic Access Control List : Disable Quarantine VLAN (4093) detection : Enable Native Vlan : 512 Allowed Vlan list: 512,540,4093 Untagged Vlan list: 512,4093 Guest VLAN : Auth-Fail Vlan : AuthServer-Timeout Vlan : Switch sessions 1/80, Local port sessions:1/20 Client MAC Type Traffic-Vlan Dynamic-Vlan 80:5e:c0:d6:6f:39 MAB 540 540 Sessions info: 80:5e:c0:d6:6f:39 Type=MAB,,state=AUTHENTICATED,etime=12,eap_cnt=0 params:reAuth=3600 user="80-5E-C0-D6-6F-39",security_grp="FNAC-Radius",fortinet_grp=""   The VLAN config:   config switch vlan edit 540 set description "Voice"   Related article: Technical Tip: How to send tagged voice VLAN to FortiSwitch via FortiNAC RADIUS attributes FortiNAC Tue, 29 Sep 2026 13:52:11 +0200 https://community.fortinet.com/support-forum-92/auto-transmit-power-230253 Currently testing FAP241K with Fortiswitch 148F-FPOE, Currently Auto transmit power is set to 17 to 20 dBm with target dBm at -70. Not using any DFS channel. Poe mode is high.why is it even with just a single AP, transmit power never goes above 17?To go higher requires setting it to percentage. 100% can go up to 28 dbm, changing it back to auto and it get stuck at 28 dbm. Any ideas?  Support Forum Tue, 29 Sep 2026 13:49:29 +0200 https://community.fortinet.com/fortiaigate-255/troubleshooting-tip-fortiaigate-shows-error-warning-tls-found-a-certificate-rather-than-a-key-in-the-pem-for-the-private-key-230251 DescriptionThis article describes troubleshooting steps for the error 'Warning: tls: found a certificate rather than a key in the PEM for the private key'.ScopeFortiAIGate.SolutionWhen installing the FortiAIGate, there's error 'Warning: tls: found a certificate rather than a key in the PEM for the private key' prompted.A: Verify the tls key is correct.kubectl get secret fortiaigate-tls-secret -n fortiaigate -o jsonpath="{.data.tls\.key}" | base64 -dExample:The output above shows '-----BEGIN CERTIFICATE-----' which is incorrect.The correct output should shows '-----BEGIN PRIVATE KEY-----', as shown below:B: Verify the certificate referenced in the 'values.yaml' is correct.Check the certificate name:grep "key:" <helm_chart_path>/fortiaigate/values.yamlExample:The output above shows the certificate name is 'dflt.key'.Verify the certificate is correct:cd fortiaigate/files/certificate/ cat dflt.keyExample:The output above shows '-----BEGIN CERTIFICATE-----' which is incorrect.Correct the certificate accordingly and verify the certificate again:cd fortiaigate/files/certificate/ cat dflt.keyExample:C: Reload FortiAIGate and verify the certificate.helm upgrade fortiaigate ./fortiaigate -n fortiaigate -f ./fortiaigate/values.yaml kubectl get secret fortiaigate-tls-secret -n fortiaigate -o jsonpath="{.data.tls\.key}" | base64 -d FortiAIGate Tue, 29 Sep 2026 13:28:25 +0200 https://community.fortinet.com/support-forum-92/ipv6-limitation-in-radius-nas-ip-field-230180 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 Support Forum Tue, 29 Sep 2026 11:33:29 +0200 https://community.fortinet.com/fortigate-3/troubleshooting-tip-not-able-to-view-facebook-block-logs-ssl-block-logs-show-in-application-control-230248 DescriptionThis article describes why there are SSL logs when Facebook is blocked in application control logs.ScopeFortiGate.SolutionIn the Application Control profile, if both SSL and Facebook applications are blocked under Application Override, the traffic will be logged as an SSL block because the SSL application has a higher priority and is evaluated first.Since the SSL application is currently matched first, FortiGate generates SSL block logs. To see Facebook block logs, move the Facebook application filter above the SSL application in the Application Control profile by dragging it to the top in the GUI. This ensures Facebook is matched and logged before SSL.Through the CLI, move the Facebook application entry above the SSL application entry so that Facebook is matched first and the corresponding block logs are generated. Execute the following commands:FGT60F-13 #config application list FGT60F-13 (list) #edit default FGT60F-13 (default) #config entries FGT60F-13 (entries) #sh config entries edit 2 set application 15895 set log disable next edit 1 set application 15832 next edit 3 set action pass next end FGT60F-13 (entries) #move 2 before 1 FGT60F-13 (entries) #sh config entries edit 2 set application 15895 set log disable next edit 1 set application 15832 next edit 3 set action pass next end FGT60F-13 (entries) #end FGT60F-13 (default) #endRelated documents:Configuring an application sensorTechnical Tip: Configure Application overrideTechnical Tip: Using the CLI to change the order of the IPV4, traffic shaping, local-in and SD-WAN policy list, VIP, SSL VPN Authentication RulesNote:Some AppCTRL signatures might require SSL Deep Inspection (DPI) enabled, and, with a simple certificate inspection, the configuration would not work. Check if a particular signature requires DPI on the FortiGuard webpage by searching for the specific AppCTRL Signature. FortiGate Tue, 29 Sep 2026 11:20:16 +0200 https://community.fortinet.com/fortimanager-27/troubleshooting-tip-fortimanager-generates-unset-logtraffic-when-installing-a-policy-package-to-fortigate-230247 DescriptionThis article describes an issue where FortiManager does not retain 'set logtraffic all' when processing firewall policies through the Global Database. During policy package installation, FortiManager sends 'unset logtraffic' to FortiGate, causing a configuration verification mismatch and installation retries.ScopeFortiManager versions 7.6 and 8.0.SolutionThe firewall policies on FortiGate are configured with 'set logtraffic all'.After the device configuration is retrieved into the FortiManager Device Database and the policy package is imported into the ADOM Database, the affected policies show logging as disabled instead of retaining logtraffic all.During policy installation, FortiManager generates the following commands.config vdom edit example_vdom config firewall policy edit 1 unset logtraffic next edit 2 unset logtraffic next endThe installation verification report identifies a difference between the device configuration and the configuration to be installed:---> generating verification report (vdom example_vdom: firewall policy 1:logtraffic) remote original: all to be installed: (vdom example_vdom: firewall policy 2:logtraffic) remote original: all to be installed: The remote original: all entry shows the existing logging setting on FortiGate.The empty to be installed: entry corresponds to the unset value generated by FortiManager.FortiManager then retries the installation and sends the same commands:------- Start to retry -------- FortiGate # config vdom FortiGate (vdom) # edit example_vdom FortiGate (example_vdom) # config firewall policy FortiGate (policy) # edit 1 FortiGate (1) # unset logtraffic FortiGate (1) # nextThe issue has been identified and fixed on FortiManager versions 7.6.8 and 8.0.1. FortiManager Tue, 29 Sep 2026 11:04:30 +0200 https://community.fortinet.com/support-forum-92/forticlient-vpn-connection-time-out-230137 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. Support Forum Tue, 29 Sep 2026 10:56:17 +0200 https://community.fortinet.com/fortisiem-216/fortisiem-false-positive-icmp-traffic-triggering-port-based-outbound-insecure-protocol-traffic-from-non-guest-network-detected-rule-230246 Ran into a false positive where ICMP traffic was matching a rule built to detect cleartext protocol usage (e.g. Telnet, FTP, POP3, IMAP) based on destination TCP/UDP port. Root cause: ICMP has no concept of ports, but some device (palo alto firewall) parsers appear to map the ICMP type/code value into the destination port field during normalization. If that mapped value happens to fall within the port list used by the rule (21, 23, 109, 110, 143, etc.) but never checked the IP protocol. So, the SubPattern matches even though no actual cleartext protocol traffic occurred. Fix: Added an explicit filter to the SubPattern to exclude ICMP traffic outright, rather than relying solely on port matching:Attribute: IP Protocol Operator: != Value: 1This is joined with AND to the existing filters (destination port IN list, source/destination IP zone checks, event type). Since it's a system rule, I cloned it, added the filter to the clone, and disabled the original to avoid duplicate incidents.also,As the description mentions, it checks for TCP/UDP, so we can add a check for that.Attribute: IP Protocol Operator: IN Value: 6,17 FortiSIEM Tue, 29 Sep 2026 10:32:05 +0200 https://community.fortinet.com/fortiisolator-53/technical-tip-resolving-wrong-download-url-issue-in-fortiisolator-230242 DescriptionThis article describes a solution to the issue where the download link in FortiIsolator uses the public IP address instead of the FQDN. The user experiences this issue when accessing FortiIsolator via an external FQDN and attempting to download a file within the isolated session.ScopeFortiIsolator.SolutionTo resolve the wrong download URL issue in FortiIsolator, follow these steps:Navigate to FortiIsolator -> Certificates -> Manage. This will redirect to the certificates webpage. Locate the Restore Server Certificates by File section.Upload the server certificate and enter the Fully Qualified Domain Name (FQDN) in the Domain Name field.Then the system will be rebooted. After the reboot, ftnt.js will use the domain name to access the file.Following these steps should make the download link in FortiIsolator use the FQDN instead of the public IP address, resolving the issue. FortiIsolator Tue, 29 Sep 2026 10:06:01 +0200 https://community.fortinet.com/fortinac-f-57/technical-tip-troubleshooting-java-lang-stackoverflowerror-when-loading-groups-230241 DescriptionThis article describes how to investigate an issue where the FortiNAC groups view does not display entries and the request to retrieve group details fails with java.lang.StackOverflowError.The procedure covers browser-side confirmation, application-log collection, read-only database inspection, and the evidence required before correcting a group relationship.ScopeFortiNAC.SolutionIdentify the failure signature:The Groups view may show a nonzero Total value while Displayed remains 0.In the reported case, the following request failed with HTTP 500:GET /actions/system/group/all-group-details/The corresponding application log contained the following exception:WARN yams.RestExceptionMapper - url: https://<FortiNAC>:8443/actions/system/group/all-group-details/ java.lang.StackOverflowError: null at org.hibernate.loader.entity.CacheEntityLoaderHelper.loadFromSessionCache(CacheEntityLoaderHelper.java:88) at org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:512) at org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:208) at org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:327) at org.hibernate.event.internal.DefaultLoadEventListener.doOnLoad(DefaultLoadEventListener.java:108) at org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:74)A full stack trace will be needed for proper investigation.Correlate the browser request with the application log:Open the browser developer tools, select Network -> Preserve log.Reproduce the issue once, and inspect the request’s status, query parameters, and response body. Chrome exposes these details through the Headers, Payload, and Response tabs.At the same time, monitor from FortiNAC CLI:diagnose tail -F output.masterAfter reproducing the failure, press Ctrl+C to stop the live capture. Then download the log snapshot: Technical Tip: How to get a debug log report from FortiNAC-CA or FortiNAC-Manager.Perform read-only database inspection:Access database shell:execute db-shellObtain Group count:SELECT COUNT(*) AS group_row_count FROM `Group`;Example output:MariaDB Bbsc]> SELECT -> COUNT(*) AS group_row_count -> FROM `Group`; +-----------------+ | group_row_count | +-----------------+ | 140 | +-----------------+ 1 row in set (0.000 sec)Review recently modified groupsSELECT `ID`, `name`, `LAST_MODIFIED_DATE` FROM `Group` ORDER BY `LAST_MODIFIED_DATE` DESC, `ID` DESC LIMIT 50;Example output:MariaDB Bbsc]> SELECT -> `ID`, -> `name`, -> `LAST_MODIFIED_DATE` -> FROM `Group` -> ORDER BY -> `LAST_MODIFIED_DATE` DESC, -> `ID` DESC -> LIMIT 50; +------------------+-----------------------------------------+------------------ ---+ | ID | name | LAST_MODIFIED_DAT E | +------------------+-----------------------------------------+------------------ ---+ | 1421994961006596 | ROGUE_CLIENTS | 2026-09-28 15:02: 10 | | 1497703305695260 | testgroup_host | 2026-09-28 04:01: 00 | | 1497703305654299 | testgroup_user | 2026-09-28 04:01: 00 | | 1497703305453593 | fortinacgrp_host | 2026-09-28 04:01: 00 | | 1497703305383960 | fortinacgrp_user | 2026-09-28 04:01: 00 | | 1468957178937353 | testou5_host | 2026-09-28 04:01: 00 | | 1468957178880007 | testou5_user | 2026-09-28 04:01: 00 | | 1468957178806277 | testou4_host | 2026-09-28 04:01: 00 | | 1468957178732547 | testou4_user | 2026-09-28 04:01: 00 | | 1468957178613761 | testou3_host | 2026-09-28 04:01: 00 | | 1468957178531871 | testou3_user | 2026-09-28 04:01: 00 | | 1468957178392605 | testou2_host | 2026-09-28 04:01: 00 | | 1468957178290203 | testou2_user | 2026-09-28 04:01: 00 | | 1468957178175513 | testou1_host | 2026-09-28 04:01: 00 | | 1468957178060823 | testou1_user | 2026-09-28 04:01: 00 ---+ 15 rows in set (0.001 sec) Provide logs to TAC:output.master logs.Database outputs.browser error from FortiNAC GUI.Browser logs from Developer Tools (Headers, Payload, and Response tabs). FortiNAC-F Tue, 29 Sep 2026 09:27:03 +0200 https://community.fortinet.com/forticlient-4/troubleshooting-tip-web-filter-extension-disabled-when-switching-between-on-fabric-and-off-fabric-230239 DescriptionThis article explains how to resolve an issue where the Web Filter browser extension disables the 'Allow in incognito' option when a user switches between On-Fabric and Off-Fabric network states.ScopeFortiClient/EMS.SolutionThe issue occurs when the FortiClient Web Filter extension resets the 'Allow in incognito' setting during the transition between On-Fabric (office) and Off-Fabric (remote) network environments. This prevents users from browsing in incognito mode and may block navigation entirely.To resolve this issue, follow these steps:Update FortiClient to v7.4.8 or higher.Configure the Web Filter profiles to ensure the extension remains active during network transitions. Refer to Technical Tip: Enable Web Filter only when the user is Off-Fabric/Off-Net when connected to public internet for detailed configuration of On-Fabric and Off-Fabric settings.In the On-Fabric profile, enable the following options to prevent the plugin from being uninstalled during transitions:Keep Extension when Endpoint is Off-FabricEnable Web Filter Browser Plugin for web FilteringModify the Web Filter profile via XML configuration to disable the forced enable of private mode. Locate the following parameter in the XML:<force_enable_in_private_mode>Change the value of this parameter to 0.Save the changes and wait for the FortiClient endpoint to synchronize the new configuration.Related articles:Troubleshooting Tip: Allow InPrivate or Incognito windows when a web browser plugin for Web Filtering is enabled FortiClient Tue, 29 Sep 2026 09:07:52 +0200 https://community.fortinet.com/fortigate-3/technical-tip-unable-to-view-phase1-and-phase2-proposals-configured-through-gui-230238 DescriptionThis article describes why it is not possible to view phase1 and phase2 proposals configured through GUI.Scope FortiGate,IPSEC VPN.SolutionWhen the tunnel is created using the wizard, default proposals and DH group will be configured.Through the GUI, it is not possible to view the configured proposals.However, it is also possible to view the configured proposals through CLI.config vpn ipsec phase1-interface edit "test1" set interface "port1" set peertype any set net-device disable set proposal aes128-sha256 aes256-sha256 aes128-sha1 aes256-sha1 set comments "VPN: test1 (Created by VPN wizard)" set wizard-type static-fortigate set remote-gw 1.1.1.1 set psksecret ENC c6eJYeLwio/E1T22iTjsj3pWAnY8DPMCl/uc29FFdsMAM1pLgZp8X6K/Xu9aJ6i2W2q7/5HDQRBVLZ0aEjX2mavOtgXmgRHeMND4cwRgfTQxRR3cxF/JQPhly/Re2LVlxNyDsbgQEyN1lBlYhuB9AG+IipNUev3+clVxbFDPFm+EnYAY3xLcEZel/eAQtkGloLtlyFlmMjY3dkVA next end config vpn ipsec phase2-interface edit "test1" set phase1name "test1" set proposal aes128-sha1 aes256-sha1 aes128-sha256 aes256-sha256 aes128gcm aes256gcm chacha20poly1305 set comments "VPN: test1 (Created by VPN wizard)" set src-addr-type name set dst-addr-type name set src-name "test1_local" set dst-name "test1_remote" next end To view the proposals configured through GUI, it is required to select Convert To Custom Tunnel.After selecting convert to custom tunnel, it is possible to view the configured proposals and edit the proposals.Note:While creating a tunnel using the wizard, by default, IPV4 policies and static routes will be created. However, when tunnel is created using custom settings, configure the IPV4 policy and static route manually.Related articles:Technical Tip: How to configure VPN Site to Site between FortiGates (Using VPN Setup Wizard)Troubleshooting Tip: IPsec VPNs tunnels FortiGate Tue, 29 Sep 2026 09:03:56 +0200 https://community.fortinet.com/fortigate-3/technical-tip-real-server-health-check-monitoring-does-not-follow-the-correct-vrf-route-230236 DescriptionThis article describes the VIP Real Server health check monitoring behavior when a non-default VRF is used to reach the real servers.ScopeFortiGate, FortiOS v8.0.0.SolutionPrevious to v8.0.0 when a non-default VRF was used to reach the VIP real Servers, FortiGate device used to send the traffic to that servers through the correct associated VRF interface.For example, the default VRF on the FortiGate is VRF 0; however, if a different VRF was used to reach the servers VRF 10, for example, on FortiGate versions previous to v8.0.0 the traffic uses the correct VRF interface:FortiGate-100F-NAT (global) # get system status Version: FortiGate-100F v7.6.7 b260601Real server IPs are 192.168.200.20, 192.168.200.21, and 192.168.200.110.VRF 10 (interface VLAN LAN_VRF_10) is used to reach those servers.FortiGate-100F-NAT (root) # get router info routing-table details 192.168.200.110 Routing table for VRF=0 Routing entry for 0.0.0.0/0 Known via "static", distance 1, metric 0, best * vrf 0 192.168.170.1, via wan1, origin 2 vrf 0 201.164.181.209, via wan2 inactive, origin 2 Routing table for VRF=10 Routing entry for 192.168.200.0/24 Known via "connected", distance 0, metric 0, best * is directly connected, LAN_VRF_10Traffic for the health-check monitor is properly sent over that interface:FortiGate-100F-NAT (ldb-monitor) # show full firewall ldb-monitor TCP_test config firewall ldb-monitor edit "TCP_test" set type http set interval 10 set timeout 2 set retry 3 set port 80 set src-ip 0.0.0.0 set http-get "/test" set http-match '' set http-max-redirects 0 next endFortiGate-100F-NAT (root) # diagnose sniffer packet any 'host 192.168.200.110 and tcp port 80' 4 0 l interfaces=[any] filters=[host 192.168.200.110 and tcp port 80] 2026-09-17 20:28:47.829003 LAN_VRF_10 out 192.168.200.99.23500 -> 192.168.200.110.80: syn 1315305826 2026-09-17 20:28:47.829013 lan out 192.168.200.99.23500 -> 192.168.200.110.80: syn 1315305826 2026-09-17 20:28:48.828883 LAN_VRF_10 out 192.168.200.99.23500 -> 192.168.200.110.80: syn 1315305826 2026-09-17 20:28:48.828891 lan out 192.168.200.99.23500 -> 192.168.200.110.80: syn 1315305826 2026-09-17 20:28:49.869013 LAN_VRF_10 out 192.168.200.99.23506 -> 192.168.200.110.80: syn 3617798999 2026-09-17 20:28:49.869019 lan out 192.168.200.99.23506 -> 192.168.200.110.80: syn 3617798999 2026-09-17 20:28:50.868881 LAN_VRF_10 out 192.168.200.99.23506 -> 192.168.200.110.80: syn 3617798999 2026-09-17 20:28:50.868890 lan out 192.168.200.99.23506 -> 192.168.200.110.80: syn 3617798999However, on version 8.0.0, health-check traffic is wrongly sent over the default VRF 0.FortiGate-100F-NAT (global) # get system status Version: FortiGate-100F v8.0.0.F-build0167FortiGate-100F-NAT (root) # get router info routing-table details 192.168.200.110 Routing table for VRF=0 Routing entry for 0.0.0.0/0 Known via "static", distance 1, metric 0, best * vrf 0 192.168.170.1, via wan1, origin 2 vrf 0 201.164.181.209, via wan2 inactive, origin 2 Routing table for VRF=10 Routing entry for 192.168.200.0/24 Known via "connected", distance 0, metric 0, best * is directly connected, LAN_VRF_10FortiGate-100F-NAT (root) # diagnose sniffer packet any 'host 192.168.200.110 and tcp port 80' 4 0 l interfaces=[any] filters=[host 192.168.200.110 and tcp port 80] 2026-09-17 20:32:18.248543 wan1 out 192.168.170.21.22473 -> 192.168.200.110.80: syn 1919159506 2026-09-17 20:32:19.248526 wan1 out 192.168.170.21.22473 -> 192.168.200.110.80: syn 1919159506 2026-09-17 20:32:20.258739 wan1 out 192.168.170.21.22479 -> 192.168.200.110.80: syn 2620584971 2026-09-17 20:32:21.277685 wan1 out 192.168.170.21.22479 -> 192.168.200.110.80: syn 2620584971This behavior is associated with the known issue 1301104, fixed on FortiOS version 8.0.1, where the setting 'vrf-select' was added to the health check configuration:FortiGate-100F-NAT (global) # get system status Version: FortiGate-100F v8.0.1,build0245,260909 (GA.F) First GA patch build date: 260421By default, the FortiGate unit will use the default VRF 0 to send the traffic, but the correct VRF can be defined under the firewall ldb-monitor configuration:FortiGate-100F-NAT (TCP_test) # show full-configuration config firewall ldb-monitor edit "TCP_test" set type http set interval 10 set timeout 2 set retry 3 set port 80 set src-ip 0.0.0.0 set http-get "/test" set http-match '' set http-max-redirects 0 set vrf-select 0 next endFortiGate-100F-NAT (root) # diagnose sniffer packet any 'host 192.168.200.110 and tcp port 80' 4 0 l interfaces=[any] filters=[host 192.168.200.110 and tcp port 80] 2026-09-17 20:36:34.176647 wan1 out 192.168.170.21.22473 -> 192.168.200.110.80: syn 1919159506 2026-09-17 20:36:35.176538 wan1 out 192.168.170.21.22473 -> 192.168.200.110.80: syn 1919159506 2026-09-17 20:36:36.216689 wan1 out 192.168.170.21.22479 -> 192.168.200.110.80: syn 2620584971 2026-09-17 20:36:37.216535 wan1 out 192.168.170.21.22479 -> 192.168.200.110.80: syn 2620584971 2026-09-17 20:36:39.216550 wan1 out 192.168.170.21.22479 -> 192.168.200.110.80: syn 2620584971FortiGate-100F-NAT (root) # config firewall ldb-monitor FortiGate-100F-NAT (ldb-monitor) # edit TCP_test FortiGate-100F-NAT (TCP_test) # set vrf-select 10 FortiGate-100F-NAT (TCP_test) # end FortiGate-100F-NAT (TCP_test) # show firewall ldb-monitor TCP_test config firewall ldb-monitor edit "TCP_test" set type http set port 80 set http-get "/test" set http-max-redirects 0 set vrf-select 10 next endThen traffic is sent over the correct VRF interface:FortiGate-100F-NAT (root) # diagnose sniffer packet any 'host 192.168.200.110 and tcp port 80' 4 0 l interfaces=[any] filters=[host 192.168.200.110 and tcp port 80] 2026-09-17 20:37:19.236784 LAN_VRF_10 out 192.168.200.99.10650 -> 192.168.200.110.80: syn 2644793773 2026-09-17 20:37:19.236795 lan out 192.168.200.99.10650 -> 192.168.200.110.80: syn 2644793773 2026-09-17 20:37:20.236553 LAN_VRF_10 out 192.168.200.99.10650 -> 192.168.200.110.80: syn 2644793773 2026-09-17 20:37:20.236562 lan out 192.168.200.99.10650 -> 192.168.200.110.80: syn 2644793773 2026-09-17 20:37:21.276682 LAN_VRF_10 out 192.168.200.99.10653 -> 192.168.200.110.80: syn 200516687 2026-09-17 20:37:21.276689 lan out 192.168.200.99.10653 -> 192.168.200.110.80: syn 200516687 2026-09-17 20:37:22.276564 LAN_VRF_10 out 192.168.200.99.10653 -> 192.168.200.110.80: syn 200516687 2026-09-17 20:37:22.276573 lan out 192.168.200.99.10653 -> 192.168.200.110.80: syn 200516687 FortiGate Tue, 29 Sep 2026 08:10:42 +0200 https://community.fortinet.com/fortisiem-34/troubleshooting-tip-unable-to-start-appsvr-due-to-incomplete-backup-restore-process-of-fortisiem-hardware-appliance-230235 DescriptionThis article describes the resolution of an issue when AppSvr does not start due to an incomplete backup restore process of a hardware FortiSIEM Appliance.Scope FortiSIEM hardware.SolutionIt has been observed that AppSvr does not initialize properly after restoring a hardware backup.The following errors have been observed while checking in AppSvr server logs.tail -f /opt/glassfish/domains/domain1/logs/server.log Exception in thread "main" java.lang.NullPointerException: Cannot invoke "org.glassfish.hk2.api.DynamicConfigurationService.createDynamicConfiguration()" because "dcs" is nullThese errors occur when the hardware backup has not been restored properly.Backup restore logs need to be checked from /opt/hwbackup/fsm-hw-restore-<date>-<hour-minute>.log.Make sure that the appliance has been connected using a serial console cable physically and not virtually. Virtual connection to Appliance during restore process gets terminated automatically when Appliance gets rebooted automatically.If hardware backup was not completed properly, it needs to be re-run again using the below commands.cd /opt/hwbackup ./fsm_hw_restore_from_backup.sh FortiSIEM Tue, 29 Sep 2026 07:47:21 +0200 https://community.fortinet.com/fortigate-3/troubleshooting-tip-fortios-version-8-0-fortiai-top-up-token-is-not-visible-after-registering-sku-lic-faitoken-1m-230234 DescriptionThis article describes the behavior observed after registering SKU 'LIC-FAITOKEN-1M', where FortiAI topped-up token information is not displayed on the 'Settings' page.ScopeFortiOS v8.0.0.SolutionFor more information about FortiAI requirements and tokens, refer to Requirements and tokens 8.0.0.To provide a more streamlined approach to FortiAI token management, the FortiAI-Assist top-up license allows tokens to be managed across multiple products under the same FortiCare account. These account-based token top-up licenses can be centrally tracked and managed from a single page within the FortiCare account.After activating token SKU 'LIC-FAITOKEN-1M', there is no topped-up token information available on the FortiAI token settings page.The issue is caused by the API incorrectly reporting both 'account_total_tokens' and 'account_tokens_remaining' as '0', despite the successful registration of the top-up token SKU (LIC-FAITOKEN-1M). As a result, the additional tokens are not reflected in the account's total token allocation or remaining token balance.Resolution.The fix is included in FortiOS v8.0.1.The settings pane appears as follows after applying the fix. FortiGate Tue, 29 Sep 2026 07:42:06 +0200 https://community.fortinet.com/fortisiem-216/fortisiem-moving-old-online-data-to-archive-in-clickhouse-deployment-229206 Hello everyone.I want to move old online data before I enabled Archiving to Archive storage. Since Clickhouse Archive only moves incoming logs as it comes, I swear I saw some commands to move old data to Archive but cannot find it now. Does any of you have experience with this? FortiSIEM Tue, 29 Sep 2026 07:39:42 +0200 https://community.fortinet.com/fortigate-3/troubleshooting-tip-ip-bad-header-alerts-are-being-logged-to-event-logs-after-enabling-dos-policies-230233 DescriptionThis article describes why 'IP.Bad.Header' alerts are being logged to event log after enabling DoS policies while those logs were not generated before DoS policy introduction.ScopeFortiGate.SolutionDescription:After the introduction of any DoS policy in FortiGate, 'IP.Bad.Header' alerts may be logged in the event logs.The alerts are similar to the following example:date=2026-09-28 time=02:15:34 devname="FortiGate" logid="0720018432" type="utm" subtype="anomaly" eventtype="anomaly" level="alert" vd="one-vdom" severity="critical" srcip=1.1.1.1 dstip=2.2.2.2 srcintf="LAN" action="dropped" proto=6 service="tcp/0" count=20 attack="IP.Bad.Header" attackid=127 policyid=0 ref="http://www.fortinet.com/ids/VID127" msg="anomaly: IP.Bad.Header, repeats 20 times since last log" crscore=50 craction=4096 crlevel="critical"This indicates the detection of IP packets with invalid header length.IP packets with invalid header length are blocked by Fortigate by default.For more details about protocol header checking and one configuration parameter available, see Technical Tip: Protocol header checking.Resolution:All packets accepted by a FortiGate pass through a network interface and are processed by the TCP/IP stack. Then if DoS policies have been configured the packet must pass through these as well as automatic IP integrity header checking.IP integrity header checking reads the packet headers to verify if the packet is a valid TCP, UDP, ICMP, SCTP or GRE packet. The only verification that is done at this step to ensure that the protocol header is the correct length. If it is, the packet is allowed to carry on to the next step. If not, the packet is dropped.DoS policy feature is one of the three reasons behind automatic IP integrity checking:Interface policy (1)DoS policy(2), andACL policy(3) all perform the IP integrity header check.This is the first step before evaluating those policies.If IP header length check fails or the packet is a fragmented packet, the packet will be dropped and a log will be generated.There is no means to disable this verification or the log generated.For more details on the DoS feature in FortiOS, seethe following documents and Knowledge Base articles:Technical Tip: How to configure DoS policyParallel Path Processing(1) Interface policies(2) DoS policy(3) Access control lists FortiGate Tue, 29 Sep 2026 07:23:14 +0200 https://community.fortinet.com/fortigate-3/troubleshooting-tip-fortigate-vm-ha-peers-remain-as-separate-clusters-due-to-different-vcpu-counts-230231 DescriptionThis article describes an issue where FortiGate-VM HA peers fail to form a cluster and remain as separate clusters due to different vCPU counts.ScopeFortiGate-VM.SolutionFortiGate-VM HA members are required to have the same number of CPUs.When the vCPU count is different between the FortiGate-VMs, the HA configuration and heartbeat connectivity can appear correct, but the peers may remain in separate clusters.For example, consider three FortiGate-VMs configured in the same HA group. Two units have 4 vCPUs and one unit has 2 vCPUs.Run the following command on each FortiGate-VM to check the CPU resources detected by FortiOS:get system statusThe two FortiGate-VMs with 4 vCPUs show:VM Resources: 4 CPU/4 allowed, 3881 MB RAMThe FortiGate-VM with 2 vCPUs shows:VM Resources: 2 CPU/2 allowed, 3881 MB RAMIn this scenario, the two FortiGate-VMs with matching CPU counts successfully form an HA cluster.Verify the cluster status using:get system ha statusThe two 4-vCPU units are members of the same cluster:number of member: 2 HA-4CPU-A, FGVM04TM25003924, HA cluster index = 0 HA-4CPU-B, FGVM04TM22000285, HA cluster index = 1However, the FortiGate-VM with 2 vCPUs remains in a separate one-member cluster:number of member: 1 HA-2CPU, FGVM02TM22000874, HA cluster index = 0If the HA peers remain in separate clusters, verify heartbeat connectivity using:diagnose sniffer packet <heartbeat_interface> 'ether proto 0x8890' 6 10 lIn this example:diagnose sniffer packet port4 'ether proto 0x8890' 4 10 l Using Original Sniffing Mode interfaces=[port4] filters=[ether proto 0x8890] pcap_lookupnet: port4: no IPv4 address assigned 2026-09-27 02:56:30.189308 port4 -- Ether type 0x8890 printer hasn't been added to sniffer. 2026-09-27 02:56:30.263387 port4 -- Ether type 0x8890 printer hasn't been added to sniffer. 2026-09-27 02:56:30.346479 port4 -- Ether type 0x8890 printer hasn't been added to sniffer. 2026-09-27 02:56:30.389298 port4 -- Ether type 0x8890 printer hasn't been added to sniffer. 2026-09-27 02:56:30.472950 port4 -- Ether type 0x8890 printer hasn't been added to sniffer. 2026-09-27 02:56:30.556495 port4 -- Ether type 0x8890 printer hasn't been added to sniffer. 2026-09-27 02:56:30.589364 port4 -- Ether type 0x8890 printer hasn't been added to sniffer. 2026-09-27 02:56:30.673147 port4 -- Ether type 0x8890 printer hasn't been added to sniffer. 2026-09-27 02:56:30.746481 port4 -- Ether type 0x8890 printer hasn't been added to sniffer. 2026-09-27 02:56:30.789226 port4 -- Ether type 0x8890 printer hasn't been added to sniffer.The heartbeat capture on the 2-vCPU FortiGate-VM shows FGCP heartbeat packets from both 4-vCPU members. This confirms that Layer 2 heartbeat communication between the HA peers is available even though the 2-vCPU unit does not join the cluster.When heartbeat connectivity is working but the FortiGate-VMs remain in separate clusters, compare the VM Resources output from get system status on all HA members.The CPU count reported by FortiOS must be the same on the FortiGate-VM HA members.Correct the vCPU allocation on the FortiGate-VM with the mismatched CPU count. After making the change, run:get system statusConfirm that the CPU count reported by FortiOS matches the other HA member or members.The FortiGate-VM should be able to join the HA cluster when the CPU count and the other HA requirements match. FortiGate Tue, 29 Sep 2026 07:19:06 +0200 https://community.fortinet.com/fortigate-3/troubleshooting-tip-high-https-cpu-utilization-and-ldap-tree-failure-with-ldaps-on-fortigate-after-upgrade-to-fortios-v7-6-6-230230 DescriptionThis article describes an issue where the httpsd process consumes high CPU utilization, and the LDAP Distinguished Name (DN) tree fails to load when accessing an LDAPS configuration through the FortiGate GUI after upgrading to FortiOS 7.6.6.The issue occurs on a FortiGate running FortiOS v7.6.6 build 3652.The issue occurs when navigating to:User & Authentication -> LDAP Servers -> Edit LDAP Server -> Browse.Under normal conditions, the LDAP Distinguished Name Query / LDAP Tree should load successfully.ScopeFortiGate FortiOS v7.6.6.SolutionWhen accessing the LDAP configuration and selecting Browse under the LDAP Distinguished Name Query / LDAP Tree, the LDAP tree does not populate.At the same time, the httpsd process starts consuming excessive CPU.Example:diagnose sys top 1 20 2512:10:40 PM up 16 days, 3 hours and 27 minutes 15U, 0N, 12S, 73I, 0WA, 0HI, 0SI, 0ST; 3708T, 1349F httpsd 22072 R 99.5 1.1 1     node 1608 S 9.4 5.0 2 12:10:41 PM up 16 days, 3 hours and 27 minutes 14U, 0N, 10S, 76I, 0WA, 0HI, 0SI, 0ST; 3708T, 1349F httpsd 22072 R 99.9 1.1 1 The overall system CPU utilization may not always appear extremely high because the high utilization is associated primarily with the affected httpsd worker/core.Run the following command to check overall CPU utilization:get system performance statusThen monitor the running processes:diagnose sys top 1 20 25The httpsd process can be observed continuously consuming close to 100% CPU when the issue is occurring.Crash Information:After restarting the  HTTPS daemon, a crash was observed.The crash log reports: 2026-04-06 12:27:06 <22564> firmware FortiGate-70G v7.6.6,build3652b3652,260127 (GA.M) (Release) 292: 2026-04-06 12:27:06 <22564> application httpsd 293: 2026-04-06 12:27:06 <22564> *** signal 11 (Segmentation fault) received *** 294: 2026-04-06 12:27:06 <22564> Register dump: 295: 2026-04-06 12:27:06 <22564> R0: 0000000000005824 R1: 0000007fb8950b68 R2: 000000000000005b 296: 2026-04-06 12:27:06 <22564> R3: 0000007fb8719490 R4: 0000007fb9904fd8 R5: 0000000000000000 297: 2026-04-06 12:27:06 <22564> R6: 0000007fbf639a60 R7: 0000000000000001 XR: 00000000000000ac 298: 2026-04-06 12:27:06 <22564> R9: 0000007fb847cb34 R10: 0000000000000000 R11: 0000007fbf6d9b38 299: 2026-04-06 12:27:06 <22564> R12: 0000000000001050 R13: 0000000003e64230 R14: 00000000000000c0 300: 2026-04-06 12:27:06 <22564> R15: 0000000000000066 IP0: 0000007fba02b560 IP1: 0000007fb8c455c0 301: 2026-04-06 12:27:06 <22564> PR: 000000000000000c R19: 0000000000000000 R20: 0000007fba031000 302: 2026-04-06 12:27:06 <22564> R21: 0000007fb8950b68 R22: 00000000ffffffff R23: 0000007fb5e54100 303: 2026-04-06 12:27:06 <22564> R24: 0000007fb5e54000 R25: 0000000000000001 R26: 0000000069d3f975 304: 2026-04-06 12:27:06 <22564> R27: 0000000000000001 R28: 0000007fb3913000 FP: 0000007fe8540950 305: 2026-04-06 12:27:06 <22564> fault_address: 0000000000000000 sp: 0000007fe8540950 306: 2026-04-06 12:27:06 <22564> pc: 0000007fb8c455cc lr: 0000007fb990500c 307: 2026-04-06 12:27:06 <22564> pstate: 20000000 (nzCv daif -PAN -UAO) 308: 2026-04-06 12:27:06 <22564> Backtrace: 309: 2026-04-06 12:27:06 <22564> g0x7fb8c455cc] => /lib/libc.so.6 {0x7fb8b80000} => ?? ??:0 310: 2026-04-06 12:27:06 <22564> g0x7fb990500c] => /lib/libsysapi.so {0x7fb9680000} => my_free at ././migbase/sysapi/base/ssl_utils.c:1545 (discriminator 1) 311: 2026-04-06 12:27:06 <22564> g0x7fb86c228c] => /lib/libcrypto.so.3 {0x7fb8500000} => ?? ??:0 312: 2026-04-06 12:27:06 <22564> g0x7fb848edc4] => /lib/libssl.so.3 {0x7fb83e0000} => ?? ??:0 313: 2026-04-06 12:27:06 <22564> g0x7fb83a5338] => /lib/libldap.so.2 {0x7fb8360000} => ?? ??:0 314: 2026-04-06 12:27:06 <22564> g0x7fb83a1694] => /lib/libldap.so.2 {0x7fb8360000} => ?? ??:0 315: 2026-04-06 12:27:06 <22564> g0x7fb83a3468] => /lib/libldap.so.2 {0x7fb8360000} => ?? ??:0 316: 2026-04-06 12:27:06 <22564> g0x7fb8371768] => /lib/libldap.so.2 {0x7fb8360000} => ?? ??:0 317: 2026-04-06 12:27:06 <22564> g0x7fb838786c] => /lib/libldap.so.2 {0x7fb8360000} => ?? ??:0 318: 2026-04-06 12:27:06 <22564> g0x7fb8370c84] => /lib/libldap.so.2 {0x7fb8360000} => ?? ??:0 319: 2026-04-06 12:27:06 <22564> g0x7fb8386e84] => /lib/libldap.so.2 {0x7fb8360000} => ?? ??:0 320: 2026-04-06 12:27:06 <22564> g0x7fb8379658] => /lib/libldap.so.2 {0x7fb8360000} => ?? ??:0 321: 2026-04-06 12:27:06 <22564> g0x7fb8379754] => /lib/libldap.so.2 {0x7fb8360000} => ?? ??:0 322: 2026-04-06 12:27:06 <22564> g0x7fb9afe5fc] => /lib/libsysapi.so {0x7fb9680000} => connect_ldap_server at ././migbase/sysapi/ldap_search/fg_ldap.c:385 323: 2026-04-06 12:27:06 <22564> g0x5592f30ba4] => /bin/httpsd {0x5592364000} => ldapjson_search at ././fortiweb/modules/api/api_ldap.c:1374 (discriminator 44) 324: 2026-04-06 12:27:06 <22564> g0x5592f3129c] => /bin/httpsd {0x5592364000} => ldap_service_query at ././fortiweb/modules/api/api_ldap.c:1548 325: 2026-04-06 12:27:06 <22564> g0x5592f15618] => /bin/httpsd {0x5592364000} => api_endpoint_execute_handler at ././fortiweb/modules/api/api_endpoint.c:930 (discriminator 1) 326: 2026-04-06 12:27:06 <22564> g0x5592f16034] => /bin/httpsd {0x5592364000} => endpoint_process_req_vdom at ././fortiweb/modules/api/api_endpoint.c:1193 327: 2026-04-06 12:27:06 <22564> g0x5592f17be4] => /bin/httpsd {0x5592364000} => endpoint_process_req at ././fortiweb/modules/api/api_endpoint.c:1903 328: 2026-04-06 12:27:06 <22564> g0x5592f18cb0] => /bin/httpsd {0x5592364000} => endpoint_handle_req at ././fortiweb/modules/api/api_endpoint.c:2095 329: 2026-04-06 12:27:06 <22564> g0x5592ee2084] => /bin/httpsd {0x5592364000} => fweb_module_handler at ././fortiweb/modules/apache_module.c:767 330: 2026-04-06 12:27:06 <22564> g0x55930d3c4c] => /bin/httpsd {0x5592364000} => ap_run_handler at ././apache2/server/config.c:170 (discriminator 7) 331: 2026-04-06 12:27:06 <22564> g0x55930d4610] => /bin/httpsd {0x5592364000} => ap_invoke_handler at ././apache2/server/config.c:446 332: 2026-04-06 12:27:06 <22564> g0x559311e26c] => /bin/httpsd {0x5592364000} => ap_process_async_request at ././apache2/modules/http_request.c:453 333: 2026-04-06 12:27:06 <22564> g0x559311e414] => /bin/httpsd {0x5592364000} => ap_process_request at ././apache2/modules/http_request.c:490 334: 2026-04-06 12:27:06 <22564> g0x5593116284] => /bin/httpsd {0x5592364000} => ap_process_http_sync_connection at ././apache2/modules/http_core.c:220 335: 2026-04-06 12:27:06 <22564> g0x55930d887c] => /bin/httpsd {0x5592364000} => ap_run_process_connection at ././apache2/server/connection.c:43 (discriminator 7) 336: 2026-04-06 12:27:06 <22564> g0x55930efad8] => /bin/httpsd {0x5592364000} => child_main at ././apache2/server/prefork.c:677 337: 2026-04-06 12:27:06 <22564> g0x55930efdbc] => /bin/httpsd {0x5592364000} => make_child at ././apache2/server/prefork.c:782 338: 2026-04-06 12:27:06 <22564> g0x55930f0048] => /bin/httpsd {0x5592364000} => perform_idle_server_maintenance at ././apache2/server/prefork.c:885 (discriminator 3) 339: 2026-04-06 12:27:06 <22564> g0x55930f06ec] => /bin/httpsd {0x5592364000} => prefork_run at ././apache2/server/prefork.c:993 340: 2026-04-06 12:27:06 <22564> g0x55930eaf6c] => /bin/httpsd {0x5592364000} => ap_run_mpm at ././apache2/server/mpm_common.c:96 (discriminator 7) 341: 2026-04-06 12:27:06 <22564> g0x55930ea874] => /bin/httpsd {0x5592364000} => httpsd_main at ././apache2/server/main.c:851 342: 2026-04-06 12:27:06 <22564> g0x55926105e8] => /bin/httpsd {0x5592364000} => fg_exit at ././fgtutil/fg_exit.h:40  (inlined by) fortiexecve at ././sysinit/fortiexec.c:911 343: 2026-04-06 12:27:06 <22564> &0x559261468c] => /bin/httpsd {0x5592364000} => run_initentry at ././sysinit/init.c:997 344: 2026-04-06 12:27:06 <22564> &0x5592614c4c] => /bin/httpsd {0x5592364000} => run_initlevel at ././sysinit/init.c:1121 345: 2026-04-06 12:27:06 <22564> &0x5592618270] => /bin/httpsd {0x5592364000} => initd_mainloop at ././sysinit/init.c:2824 346: 2026-04-06 12:27:06 <22564> &0x5592618db8] => /bin/httpsd {0x5592364000} => main at ././sysinit/init.c:3316 347: 2026-04-06 12:27:06 <22564> &0x7fb8bb0544] => /lib/libc.so.6 {0x7fb8b80000} => ?? ??:0 348: 2026-04-06 12:27:06 <22564> &0x7fb8bb0618] => /lib/libc.so.6 {0x7fb8b80000} => ?? ??:0 349: 2026-04-06 12:27:06 <22564> fortidev 7.0.0.0006 Crash log interval is 3600 secondsThe relevant call path is:httpsd   |   +-- ldap_service_query        |        +-- ldapjson_search             |             +-- connect_ldap_server                  |                  +-- libldap                       |                       +-- libssl                            |                            +-- libcryptoThis indicates that the issue is associated with the HTTPSD LDAP query path when establishing/processing the LDAPS connection.The workaround is to switch the LDAP connection from LDAPS to STARTTLS or disable secure LDAP.This issue is resolved and is scheduled to be fixed in FortiOS v7.6.9 FortiGate Tue, 29 Sep 2026 07:16:20 +0200 https://community.fortinet.com/support-forum-92/fyi-dos-policy-in-7-6-uses-sd-wan-zones-and-not-interfaces-230228 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.  Support Forum Tue, 29 Sep 2026 05:45:08 +0200 https://community.fortinet.com/support-forum-92/fortinac-failed-to-perform-snmp-connect-when-adding-a-fortigate-230213 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 Trusted Hosts settings were updated.If you see this error despite successful ping and matching SNMP credentials, check Trusted Hosts before assuming the issue is with the SNMP password or network path. Restrict the entry to FortiNAC’s specific source IP rather than opening administrative access broadly.This is only as per my Experience, if there is any other solutions, please help to answer.ThanksSarayu Jaladharan Support Forum Mon, 28 Sep 2026 22:06:48 +0200 https://community.fortinet.com/support-forum-92/fortigate-vm-in-hyper-v-fortilink-230190 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 someone could point out what I'm doing wrong or what I'm missing Support Forum Mon, 28 Sep 2026 20:54:32 +0200 https://community.fortinet.com/support-forum-92/ipsec-vpn-not-able-to-differentiate-remote-access-and-site-to-site-vpn-230195 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 Support Forum Mon, 28 Sep 2026 20:30:34 +0200 https://community.fortinet.com/support-forum-92/advice-migrating-from-60e-to-70g-230188 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? Support Forum Mon, 28 Sep 2026 20:29:34 +0200 https://community.fortinet.com/support-forum-92/unable-to-access-fortiguard-servers-since-a-few-days-fw40f-v7-2-10-build-1706-230189 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 Support Forum Mon, 28 Sep 2026 20:22:17 +0200 https://community.fortinet.com/support-forum-92/fortigate-web-filtering-firewall-blocking-internal-staff-from-accessing-external-tax-payroll-tool-230214 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 or SSL decryption issue.Has anyone experienced a similar issue where a specific web tool or financial calculator gets flagged or blocked? Which specific FortiGate setting or log filter should I check to fix this smoothly without compromising overall security policies?Any advice or troubleshooting steps would be greatly appreciated. Thanks in advance! Support Forum Mon, 28 Sep 2026 19:43:46 +0200 https://community.fortinet.com/support-forum-92/fortinet-certificate-issue-when-trying-to-access-our-portal-229964 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 Support Forum Mon, 28 Sep 2026 19:23:01 +0200 https://community.fortinet.com/fortigate-3/troubleshooting-tip-ike-saml-portal-presents-fortinet-factory-certificate-following-an-acme-renewal-230225 DescriptionThis article describes an issue where a functional IPsec VPN with SAML authentication (IKE-SAML) suddenly begins presenting the default Fortinet_Factory certificate instead of the configured public certificate.ScopeFortiOS, IKE-SAML, ACME Certificate.SolutionStep 1: The IKE-SAML authentication portal, managed by the authd daemon, utilizes the global auth-cert parameter. Ensure that the ACME certificate remains explicitly mapped in the user settings:config user setting set auth-cert "My_ACME_Cert" endStep 2: If the configuration is correct but the Fortinet_Factory certificate is still presented post-renewal, the system is encountering a known software limitation regarding the ACME certificate update process.Although the ACME client successfully renews and stores the certificate, the authd process fails to dynamically reload the updated certificate and private key into active memory. Consequently, authd invalidates the existing auth-cert binding and defaults to the factory certificate.Step 3: Until a permanent fix is released to support dynamic certificate reloads for authd, the global administrative certificate can be overridden to bypass the cached listener state. This override forces the FortiGate to correctly serve the renewed ACME certificate on the IKE-SAML port:config system global set admin-server-cert "My_ACME_Cert" endNotes:The official configuration for the SAML SP certificate remains under config user setting. The admin-server-cert override is strictly a temporary workaround to restore VPN service following an ACME renewal until a permanent patch is available.The admin-server-cert parameter globally controls the certificate presented by the FortiGate for administrative HTTPS access (GUI) and REST API connections. By applying this workaround, the FortiGate management interface will begin presenting the ACME certificate. If administrators access the FortiGate GUI using an IP address or a hostname that does not match the Subject Alternative Name (SAN) of this ACME certificate, a browser certificate warning will be displayed upon logging in. FortiGate Mon, 28 Sep 2026 17:18:02 +0200 https://community.fortinet.com/support-forum-92/apple-devices-disappears-229958 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.  Support Forum Mon, 28 Sep 2026 17:10:52 +0200 https://community.fortinet.com/fortigate-3/troubleshooting-tip-packet-loss-after-failback-on-redundant-interfaces-due-to-stale-npu-sessions-np6-np6xlite-230224 DescriptionThis article describes an issue where persistent packet loss occurs after a failback event on a redundant interface. During the transition, traffic that was hardware-offloaded may continue to egress through the standby member interface, leading to dropped packets and network instability.ScopeFortiGate, Redundant Interfaces, NP6/NP6XLite.SolutionWhen a redundant interface transitions (failover and failback), the active member changes. On FortiGate platforms equipped with NP6 or NP6XLite Network Processing Units (NPUs), hardware-offloaded sessions are not automatically flushed from the NPU during this transition (due to a hardware limitation where the parameter is flush: n).Consequently, sessions that were offloaded while the backup member was active remain programmed to use that backup interface in the hardware. When the primary interface recovers (failback), software-processed traffic switches correctly to the primary member, but the stale offloaded sessions continue to transmit traffic out of the standby member using the HA Virtual MAC (VMAC), resulting in persistent packet loss.Note: Newer NPU architectures, such as NP7, handle session flushing natively during interface transitions and are not affected by this specific issue).To verify and temporarily resolve the issue while a permanent software fix is developed, disable ASIC offloading on the specific firewall policies handling the affected traffic. This forces traffic to be processed by the CPU, which cleanly handles the failover/failback transition without retaining stale egress ports.Identify the firewall policies responsible for the affected traffic.Disable hardware offloading on those policies using the following CLI command:config firewall policy edit <policy_id> set auto-asic-offload disable next endClear the affected sessions:diagnose sys session filter clear diagnose sys session filter policy <policy_id> diagnose sys session clearNote: Disabling 'auto-asic-offload' will increase CPU utilization as the traffic is no longer accelerated by the NPU. Monitor system resources closely. FortiGate Mon, 28 Sep 2026 17:07:29 +0200 https://community.fortinet.com/support-forum-92/anomaly-with-google-chrome-extensions-forticlient-229926 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 recommendations would be greatly appreciated. Support Forum Mon, 28 Sep 2026 16:22:38 +0200 https://community.fortinet.com/fortigate-3/troubleshooting-tip-ha-out-of-sync-due-to-firewall-address-ems-all-unknown-clients-230223 DescriptionThis article describes how to resolve HA synchronization issue occurs due to a firewall address named 'EMS_ALL_UNKNOWN_CLIENTS.ScopeFortiOS.SolutionFortiGate HA may go out of sync because of a 'firewall address EMS_ALL_UNKNOWN_CLIENTS' error which appears in the secondary unit's debug logs.Primary:Firewall1 (global)# diag sys ha checksum show <vdom name> firewall.address EMS_ALL_UNKNOWN_CLIENTS: d106754b6212ae3dc012c202c031bbe7 <------------- EMS_ALL_UNMANAGEABLE_CLIENTS: 4585d4988d4eef3680835022db081527 FABRIC_DEVICE: 6a049a41cadb13867414d85a0568ce3a FCTEMS_ALL_FORTICLOUD_SERVERS: ec3e78adc6fd3e502bd76f7b196b6781 FIREWALL_AUTH_PORTAL_ADDRESS: 57d98fd72dff07e7688bf309251c406a SSLVPN_TUNNEL_ADDR1: 0a29bdb72da820bb68d96632441386b7 all: 859fa292a33f3adf7606cfc9921d2cac euce1-120-mssp.sentinelone.net: 850498030aab5d6bf109b0227a5dfeb1 gmail.com: 0a5e8b27363cf70fc24393527438f6e4 login.microsoft.com: db70a1e02fb31d99f6bd4c83a00c55ce login.microsoftonline.com: 6b59fbb3f5edb9d1facafa583e046a0f login.windows.net: 56da07533f60891ea83aa91363108592 none: 82e28499bd762f2db3325875744e7d08 wildcard.dropbox.com: b1d70476aebf7c27de7e85a85d5444e3 wildcard.google.com: ba346e787a4a806b687676ff419427d8Secondary:firewall2 (global) # diag sys ha checksum show <vdom-name> firewall.address ------->EMS_ALL_UNKNOWNS_CLIENTS missing EMS_ALL_UNMANAGEABLE_CLIENTS: 4585d4988d4eef3680835022db081527    FABRIC_DEVICE: 6a049a41cadb13867414d85a0568ce3a FCTEMS_ALL_FORTICLOUD_SERVERS: ec3e78adc6fd3e502bd76f7b196b6781 FIREWALL_AUTH_PORTAL_ADDRESS: 57d98fd72dff07e7688bf309251c406a SSLVPN_TUNNEL_ADDR1: 0a29bdb72da820bb68d96632441386b7 all: 859fa292a33f3adf7606cfc9921d2cac euce1-120-mssp.sentinelone.net: 850498030aab5d6bf109b0227a5dfeb1 gmail.com: 0a5e8b27363cf70fc24393527438f6e4 login.microsoft.com: db70a1e02fb31d99f6bd4c83a00c55ce login.microsoftonline.com: 6b59fbb3f5edb9d1facafa583e046a0f login.windows.net: 56da07533f60891ea83aa91363108592 none: 82e28499bd762f2db3325875744e7d08 wildcard.dropbox.com: b1d70476aebf7c27de7e85a85d5444e3 wildcard.google.com: ba346e787a4a806b687676ff419427d8This object is a dynamic address listed under Policy & Objects -> ZTNA -> Security Posture tags.There is no reference to this object. It is still not possible to delete it from the primary unit and add it to the secondary unit.config firewall address edit "EMS_ALL_UNKNOWN_CLIENTS" set uuid e57d2928-b8b8-51f1-c5fd-51ce7576949e set type dynamic set sub-type ems-tag set comment '' set associated-interface '' set color 0 set fabric-object disable set obj-tag '' set obj-type ip set tag-detection-level '' set tag-type '' next endTo resolve this issue, Modify the address object from the CLI as follows:firewall1 # config firewall address firewall1 (address) # edit EMS_ALL_UNKNOWN_CLIENTS firewall1 (address) # unset sub-type firewall1 (address) # set type mac firewall1 (address) # set macaddr cc:48:3a:4e:f5:52 firewall1 (address) # next firewall1 (address) # endThe address object will be updated as follows:config firewall address edit "EMS_ALL_UNKNOWN_CLIENTS" set uuid e57d2928-b8b8-51f1-c5fd-51ce7576949e set type mac set macaddr "cc:48:3a:4e:f5:56" //some random mac address next endAfter that, delete the address object from the CLI:firewall1 # config firewall address firewall1 (address)# delete EMS_ALL_UNKNOWN_CLIENTS firewall1 (address)# endConfirm the address object has been removed from ZTNA -> Security posture tag.After deleting the object 'EMS_ALL_UNKNOWN_CLIENTS', the HA status changes to 'In-sync'.Confirm the HA status with the following CLI command:get system ha status FortiGate Mon, 28 Sep 2026 16:21:16 +0200 https://community.fortinet.com/fortisiem-34/technical-tip-how-to-migrate-all-fortisiem-data-to-another-machine-173251 Description This article describes how to migrate all the data from a FortiSIEM to another machine. Scope FortiSIEM. Solution When there are issues with an initial FortiSIEM machine, the appliance has been replaced because of hardware issues or other reasons, it is necessary to migrate all the data from the original machine to the new one.    Follow the next steps to migrate all the data:   Context: Next steps can be applied in the next conditions: From Hardware machine to New Hardware machine. From VM to new VM. From Hardware to new VM and vice-versa.   Requirements: Targeted FortiSIEM requires to be in the same: Version (ex: v7.1.4): The use of the same version is recommended but it is also possible to upgrade the database if needed by following the optional steps in the 'Upgrade CMDB version' section. Mode (Enterprise or Service Provider). Online storage has to be EventDB or NFS (when using clickhouse, it is necessary to go through Clickhouse Backup-Restore). Important: Take a note of all specific modifications done earlier in the FortiSIEM to make work properly, such as: Appserver heap size memory set in /opt/glassfish/domains/domain1/config/domain.xml. Redis memory size set in /opt/phoenix/redis/conf/6666.conf. SSL certificates and /etc/httpd/conf.d/ssl.conf. Syslog-TLS and its certificates configuration. Save /opt/phoenix/config/phoenix_config.txt. If possible, note the result of the phLicenseTool --showDatabasePassword command. Keep the config_bak.xml from the next command from super as backup: srvpass=`phLicenseTool --showServicePassword`curl -u "1:${srvpass}" -k https://localhost:443/phoenix/rest/config/systemConfigHa | xmllint --format - > /tmp/config_bak.xml   Any other specific service configuration. Those will have to be reported in new/future versions of FortiSIEM.   Building the FortiSIEM target: Install the new FortiSIEM Super and follow all the steps till the FortiSIEM is licensed and running stable.   Transferring the data: Here is the list of valuable FortiSIEM data: /cmdb => database where all discovered devices are listed with their credentials, FortiSIEM configuration, and incidents. /svn => devices configurations. /data => devices events received.   Restoring the CMDB and SVN: On the original FortiSIEM, take the /data/archive/cmdb/phoenixdb_202X-XX-XXTXX-XX-XX file and transfer it to the targeted FortiSIEM on /tmp directory.   Example from new (or targeted) FortiSIEM CLI:   rsync -az root@ORIGINAL_FortiSIEM_IP:/data/archive/cmdb/phoenixdb_202X-XX-XXTXX-XX-XX /tmp   Stop all the services except the database service from the targeted FortiSIEM:   systemctl stop phxctl.service phxctl stop Stopping phoenix ...@Fri Jun 28 11:29:27 CEST 2024, Stopping backend process ...@Fri Jun 28 11:29:53 CEST 2024, Stopping apache ...@Fri Jun 28 11:29:54 CEST 2024, Stopping phAnomaly master...Stopping phAnomaly master...Terminated@Fri Jun 28 11:29:57 CEST 2024, Stopping phAnomaly worker...Stopping phAnomaly worker...Terminated@Fri Jun 28 11:30:03 CEST 2024, Stopping phGenerativeAI...Stopping phGenerativeAI...@Fri Jun 28 11:30:07 CEST 2024, Stopping phClickHouseMonitor...@Fri Jun 28 11:30:07 CEST 2024, Stopping application server ...@Fri Jun 28 11:30:32 CEST 2024, Stopping postgres ...Stop the Api Nodejs Sevice..Cleaning the Redis for APIStopping the Redis for API systemctl start postgresql-13 <----- Change this value to the correct PostgreSQL version. systemctl status postgresql-13   Run the restoration command (this may take some time along the amount of data) :   /opt/phoenix/deployment/db_restore.sh /tmp/phoenixdb_202X-XX-XXTXX-XX-XX Restore database phoenixdb from /tmp/phoenixdb_202X-XX-XXTXX-XX-XX ... Successfully restored phoenixdb from /tmp/phoenixdb_202X-XX-XXTXX-XX-XX   Upgrade the CMDB version (optional steps, follow this only if the FortiSIEM target is on the upper version):   tablelist=`psql -U phoenix phoenixdb -At -c "select tablename from pg_catalog.pg_tables where tablename like 'ph_malware_%';" | tr '\n' ',' | sed 's#,$##g'`psql -U phoenix phoenixdb -c "truncate table $tablelist ;"psql -U phoenix phoenixdb -c "vacuum $tablelist ;" threeMonthsAgo=`date -d '-90 day' +"%s000"`psql -U phoenix phoenixdb -c "delete from ph_incident where last_seen_time < ${threeMonthsAgo}" sh /opt/phoenix/deployment/db_upgrade.sh /tmp | tee -a /tmp/db_migration.log...DB schema is upgraded to new version 7.2.1 successfulyGRANTDatabase is upgraded successfully rm -rf /opt/phoenix/cache/REPLACE_BY_IP_OF_THE_SUPER /opt/glassfish/domains/domain1/generated/ /opt/glassfish/domains/domain1/osgi-cache/   Update the hardware ID:   hardware_id=`phgetUUID`psql -U phoenix phoenixdb -c "update ph_sys_conf set value='$hardware_id' where property = 'hardware_id';"   Update the IP address if it is not the same as the original FortiSIEM:   new_ip='type_your_new_ip_here'psql -U phoenix phoenixdb -c "update ph_sys_server set ip_addr='${new_ip}' where mode=2 and ( role is NULL or role = 0 );"psql -U phoenix phoenixdb -c "update ph_sys_conf set value = 'https://${new_ip}/svn' where property = 'svn_url';"psql -U phoenix phoenixdb -c "update ph_health_status set host_ip='${new_ip}' where nodetype=0;"   Restore SVN:   rsync -az root@ORIGINAL_FortiSIEM_IP:/svn/ /svn   Reset service, database and redis password:   systemctl start phxctl.service phxctl start curl -u "super/admin:XXXXXXXX" -X PUT -k https://localhost/phoenix/rest/custMgmt/service/changePwdphtools --change-svc-passwd force   If curl and/or phtools commands are rejecting an 403 error code, upload the license at:     https://super_ip/phoenix/licenseUpload.jsf   At this stage, most of the ph services should be running except phRule processes where database password update will fix it with next commands:   db_password=`phLicenseTool --showDatabasePassword` psql -U phoenix phoenixdb -c "alter user phoenix password '$db_password'" /opt/phoenix/deployment/jumpbox/ph_update_dr_configs.py `phLicenseTool --showRedisPassword` rm -f /opt/phoenix/redis/conf/6666.conf reboot   From that moment, FortiSIEM can be used and receive new events.   Restore the specific configurations backed up earlier at Requirements section   Restoring the EventDB/NFS: After the online storage is configured and mounted, run the next command from the new FortiSIEM super CLI as root to start transferring the events:   nohup rsync -az --progress root@ORIGINAL_FortiSIEM_IP:/data/eventdb/ /data/eventdb > /tmp/transfered_files.txt 2>&1 &   Follow the transfer with this command:   tail -f /tmp/transfered_files.txt FortiSIEM Mon, 28 Sep 2026 15:05:12 +0200 https://community.fortinet.com/fortinac-28/technical-tip-fortinac-f-v7-6-7-deletes-microsoft-intune-hosts-after-mdm-poll-230220 DescriptionThis article describes an issue where FortiNAC-F v7.6.7 deletes hosts imported from Microsoft Intune shortly after the MDM poll.ScopeFortiNAC-F with a Microsoft Intune MDM service connector.SolutionAfter upgrading to FortiNAC-F v7.6.7, hosts imported from Microsoft Intune may be removed from the FortiNAC database shortly after each MDM poll, even though the devices are still enrolled in Intune. Affected endpoints lose their MDM registration and can be treated as rogue hosts until the next poll.This happens when Remove Hosts Deleted from MDM Server is enabled on the Intune service connector, and results in the following messages in output.master:2026-09-05 14:33:03.436 +0100 [local-task-scheduler_MdmManager-1] DEBUG yams.MSInTuneServer - checkForDeletedDevices starting for MDM Intune 2026-09-05 14:33:03.471 +0100 [local-task-scheduler_MdmManager-1] DEBUG yams.MSInTuneServer - Total number host records that are no longer managed by MDM and will be removed: 13 2026-09-05 14:33:03.471 +0100 [local-task-scheduler_MdmManager-1] DEBUG yams.MSInTuneServer - deleteHosts() [1497759055417360, 1497774980198411, 1497778528444424, ...]These messages may only be visible with the MSInTuneServer debug module enabled.diagnose debug plugin enable MSInTuneServerTo disable the module after verifying the logs.diagnose debug plugin disable MSInTuneServerThis issue is resolved in FortiNAC-F v7.6.8.Workaround:Go to Network -> Service Connectors and edit the Microsoft Intune service connector.In the connector settings, disable the following options, then select Save:Remove Hosts Deleted from MDM ServerEnable Network DetailsRelated article:Troubleshooting Tip: MDM registration issues FortiNAC Mon, 28 Sep 2026 14:42:48 +0200 https://community.fortinet.com/forticloud-products-44/technical-tip-guide-for-mssp-migrating-to-forticloud-organization-to-register-and-manage-cloud-services-230219 DescriptionThis article describes the process to migrate a Managed Security Services Providers (MSSP) setup, usually consisting of a master account and multiple sub-accounts, to a FortiCloud Organization.ScopeFortiCloud version 26.3.FortiCloud Services' infrastructure supports multitenancy solutions for managed security service providers (MSSP). This article describes how the FortiCloud Organization service can help provide a centralized account management system when an MSSP needs to register multiple Cloud services.SolutionFortiCloud is the Fortinet’s secure, unified cloud platform delivering security with unified account management, cloud management and wide range of cloud services.When an MSSP needs to register multiple instances of cloud services, the MSSP often finds that FortiCloud requires a separate account for each cloud instance. To facilitate centralized account management, it is necessary to create an Organization Portal.FortiCloud Organization service.FortiCloud is Fortinet’s secure, unified cloud platform delivering security with unified account management, cloud management, and a wide range of cloud services.Before describing an example of this deployment, let’s get familiar with the FortiCloud organization structure:Organization: An organization is a hierarchy comprised of Organization Units (OU) and Member AccountsRoot Account (Parent OU): The RA is the account that created the organization. It is responsible for managing the organization, creating IAM users, and adding and deleting sub-OUs. It also invites members to join an organization.Sub-OU: It helps to organize member accounts with a maximum of three levels of OUs.Member Accounts: A Member Account is a FortiCloud account that joins the Organization.Organization administrative IAM user: Once Member Accounts are added to the OUs, it is possible to create an Organization administrative IAM user that can create and manage IAM users for the Organization OUs.Now, let’s see the step-by-step process to migrate a standard setup of an MSSP into an MSSP Organization:Select the account to be the Root Account, which will be responsible for managing the Organization. Log in to FortiCloud and, in the Service Menu, select 'Organizations':The Root Account of the new organization can be an existing account, for example, the MSSP master account or a new FortiCloud account created explicitly to manage the organization.By selecting 'Create Organization' (see image above), it will be show the following window:Then, the Set up Organization page will open, and it is possible to select 'Upload the Organization Structure' (refer to chapter 'To create an organization with the Bulk Import template' in FortiCloud Documentation - Creating an organization) or enter the Organization Name and Description:Now, it is time to create Creating new Member Accounts or invite existing accounts to join the Organization. For the scenario we are describing in this article, the MSSP provider could invite all the sub-accounts of their managed users to join the organization and create new member accounts for new managed customers.Inviting MSSP sub-accounts to join the new MSSP organization.A 'Member Account' (sub-account) must have an Invitation Token to join an organization. The MSSP Root Account must generate the Invitation Tokens and send them to the sub-accounts.To generate the tokens, go to the Invitation Token page and select Generate Token. The Generate Token dialog opens.MSSP must send the Invitation Tokens to the sub-accounts via SMS, Teams, or Email with the instructions to join the MSSP Organization. When the member accounts reply to the invitation, the MSSP Root Account must verify the invitation and accept the request to join.Once member accounts are added to the OUs, the root account can create one or more organization administrative IAM users that can create and manage IAM users for the organization OUs. Refer to the Identity & Access Management (IAM) service for more details.Finally, once the MSSP organization is deployed, when logging into FortiCloud, a selection of OU/account will be displayed based on their Permission Profile. MSSP users can select the OU or account to access from the tree.It is important to note that each user's scope is restricted based on the Permission Profiles assigned to them.Related articles:Technical Tip: MSSP migration to OUTechnical Tip: FortiGate Cloud Organizations basic deployment example FortiCloud Products Mon, 28 Sep 2026 14:32:11 +0200 https://community.fortinet.com/fortiproxy-30/troubleshooting-tip-measure-the-traffic-impact-of-a-configuration-change-using-disk-log-roll-events-230217 DescriptionThis article describes how to measure the relative traffic throughput of a unit using the disk log roll events it already writes, without SNMP polling, an external monitoring system, or any additional data collection.Traffic logs are written to a file of a fixed maximum size. When the file is full, the unit archives it, starts a new one, and records a roll event. Because the size threshold does not change, the time between two roll events is inversely proportional to the volume of traffic being logged. A shorter interval means more traffic, and a longer interval means less. This makes it possible to quantify the impact of a change or an incident after it has ended, from logs the unit has already collected.ScopeFortiProxy, FortiGate. Traffic logging to local disk must be enabled.SolutionWhen this is useful:The method applies in the following situations:A change was made during production hours, and the impact must be quantified afterwards from logs alone.An intermittent degradation is reported after it has ended, with no live capture or monitoring data for that window.A mitigation must be validated before and after a maintenance window with a measured figure rather than an impression.The unit has no SNMP monitoring configured.Step 1: Confirm the disk logging settings.show log disk settingNote the values of max-log-file-size and roll-schedule. The comparison is valid only if max-log-file-size is identical in both windows being compared. If it was changed between them, the result is meaningless.Step 2: Collect the roll events.execute log filter category 1 execute log filter field logid 0100032011 execute log filter start-line 1 execute log filter view-lines 500 execute log displayCategory 1 is the event log. Confirm the category number on the unit with:execute log filter category ?The output contains entries in this form:date=2026-09-04 time=02:18:19 logid="0100032011" type="event" subtype="system" level="information" action="roll-log" reason="file-size" log="tlog"Step 3: Keep only the size-based rolls.Use only entries with reason="file-size". A roll caused by roll-schedule or by a manual roll carries no throughput information, and including it distorts the result. Additionally, filter for the log type of interest, such as log="tlog" for traffic logs.Step 4: Calculate.Take the time difference between consecutive roll events in each window. Use the median rather than the mean, so that a single outlier does not dominate the result.relative throughput = baseline median interval / measured median intervalExample:On a unit where an administrator reported a traffic drop after a configuration change:Normal operation: median interval between rolls 30 seconds.During the reported event: median interval between rolls 55 seconds.30 / 55 = 0.55. The unit was passing approximately 55% of its normal logged traffic during the event, so approximately 45% was lost.This figure was produced entirely from logs the unit had already written, several days after the event, with no live data collection.Conditions for a valid comparison:Both windows must match in all of the following. If any one differs, the comparison is not valid:max-log-file-size unchanged.The same logging destination. Do not compare a disk-logging window against one where logs were sent only to FortiAnalyzer.The same logging scope. A change to logtraffic on policies, to extended-log, or to which policies log at all, changes the number of bytes written per session.The same log type, compared against itself.No firmware upgrade between the two windows, because the log schema can change.Limitations:It measures logged traffic. Sessions on policies with logging disabled are not visible to it. It is a valid before-and-after comparison on the same unit, and it is not a substitute for an interface counter when absolute volume is required.It shows the size of an impact, not its cause.Its resolution is limited by the roll interval. A unit that rolls once per hour cannot resolve a two-minute event. Where finer resolution is needed and the disk can support it, max-log-file-size may be reduced before a planned test, and must then be left unchanged for both windows.Using the method to validate a change:Because no preparation is required, the same measurement can be taken on both sides of a maintenance window:Before the change, make one representative configuration change and collect the roll events.Apply the change under test.Make a comparable configuration change and collect the roll events again.Compare the median intervals.This converts a subjective assessment into a measured ratio, using output the unit produces on its own.Related article:Troubleshooting Tip: Getting 'Disk log has rolled' message in logs FortiProxy Mon, 28 Sep 2026 14:23:57 +0200 https://community.fortinet.com/fortigate-3/troubleshooting-tip-dlp-and-antivirus-scan-up-to-the-uncompressed-oversize-limit-limit-in-proxy-mode-230216 DescriptionThis article describes the interaction between DLP and antivirus and the uncompressed-oversize-limit.ScopeAll FortiOS versions.SolutionThe following article shows the interaction between the uncompressed-oversize-limit and the antivirus and DLP modules and its implications for memory-related resource usage.A general explanation of oversize limits is covered in the article: Technical Tip: Maximum oversize threshold.Down below is an example with very high oversize limits for demonstration:config firewall profile-protocol-options edit "oversize_unc_500MB" set oversize-log enable config http set ports 80 unset post-lang set oversize-limit 300 set uncompressed-oversize-limit 500 set block-page-status-code 200 end next endHow do antivirus and DLP interact with this setting.The antivirus and DLP scan up to this threshold, and this is buffered in memory, which will stress resources based on what is configured in the profile-protocol-options.This can be seen when performing a scanunit debug.diagnose debug console timestamp enable diagnose sys scanunit stats diagnose sys scanunit vdom-stats all diagnose sys scanunit filter clear diagnose sys scanunit debug file-filter enable diagnose sys scanunit debug level verbose diagnose sys scanunit debug show diagnose debug enable Down below is an example of the behavior in action. The file filelists.xml.gz is being scanned and is about 75MB in size, but uncompressed it would be about 1GB.2026-08-14 13:20:21 su 944 job 1221 HTTP: begin scan 2026-08-14 13:20:21 su 944 job 1221 scan file 'filelists.xml.gz' bytes 77261980 2026-08-14 13:20:23 su 944 job 1221 AV engine file info results for 'filelists.xml.gz' 2026-08-14 13:20:23 su 944 job 1221 state: 3 ftypeCount: 1 encrypted: 0 need-data: 0 2026-08-14 13:20:23 su 944 job 1221 top-level: 11 : gzip 2026-08-14 13:20:23 su 944 job 1221 engine file-types: 1 2026-08-14 13:20:23 su 944 job 1221 0 => 11|0 : gzip 2026-08-14 13:20:23 su 944 job 1221 DLP: start archive level 0 scan 'filelists.xml.gz' 2026-08-14 13:20:23 su 944 job 1221 DLP: scanning file 'filelists.xml.gz' type 11 len 77261980 buffer-type none decoded 0 archive_is_blocked 0 checking 1 of 1 rules 2026-08-14 13:20:23 su 944 job 1221 DLP: Matching rule 0 2026-08-14 13:20:23 su 944 job 1221 DLP: file type 3 did not match. 2026-08-14 13:20:23 su 944 job 1221 DLP: file_scan no match found. 2026-08-14 13:20:23 su 944 job 1221 DLP: done archive level 0 scan 'filelists.xml.gz' result 0 2026-08-14 13:20:27 su 944 job 1221 AV engine file info results for '(null)' 2026-08-14 13:20:27 su 944 job 1221 state: 3 ftypeCount: 1 encrypted: 0 need-data: 0 2026-08-14 13:20:27 su 944 job 1221 top-level: 94 : [N/A] 2026-08-14 13:20:27 su 944 job 1221 engine file-types: 1 2026-08-14 13:20:27 su 944 job 1221 0 => 94|0 : [N/A] 2026-08-14 13:20:27 su 944 job 1221 DLP: start archive level 1 scan '<unknown>'Now the file is being decompressed by the DLP, and 524288000 bytes are buffered. These are 500MB exactly, as configured in the profile-protocol-options.2026-08-14 13:20:27 su 944 job 1221 DLP: scanning file '<unknown>' type 94 len 524288000 buffer-type xml decoded 0 archive_is_blocked 0 checking 1 of 1 rules 2026-08-14 13:20:27 su 944 job 1221 DLP: Matching rule 0 2026-08-14 13:20:27 su 944 job 1221 DLP: file type 3 did not match. 2026-08-14 13:20:27 su 944 job 1221 DLP: file_scan no match found. 2026-08-14 13:20:27 su 944 job 1221 DLP: done archive level 1 scan '<unknown>' result 0 2026-08-14 13:20:27 su 944 job 1221 scan return status 0 2026-08-14 13:20:27 su 944 job 1221 HTTP: done scan 2026-08-14 13:20:27 su 944 job 1221 not wanted for analytics: post-transfer scan submission is disabled at protocol level (m 2 r 0) 2026-08-14 13:20:27 su 944 job 1221 send result (rc 1) 2026-08-14 13:20:27 su 944 job 1221 close Since this is buffered into memory, it can be observed that memory goes high while these larger files are being inspected. Based on the example above, the diagnose sys top-all command shows the scanunit workers going high in memory consumption. With high oversize limits configured, this can easily push a device into memory conserve mode.FGT # diagnose sys top-all 1 20 1 Run Time: 43 days, 13 hours and 38 minutes 20U, 0N, 13S, 65I, 0WA, 0HI, 2SI, 0ST; 16010T, 5164F scanunit-worker 22884 R < 96.5 6.7 2 scanunit-worker 22921 R < 96.0 9.3 4 scanunit-worker 22934 R < 94.5 9.4 5 scanunit-worker 22880 S < 49.7 0.3 6 Workaround.There is no workaround to this other than to lower the oversize limits in the profile-protocol-options. FortiGate Mon, 28 Sep 2026 13:55:58 +0200 https://community.fortinet.com/fortisiem-34/technical-tip-how-to-run-analytics-query-for-checking-incidents-triggered-by-rules-230212 DescriptionThis article describes how to run an analytics query for checking which incidents were triggered by rules.ScopeFortiSIEM.SolutionWhile running queries for any of the incidents triggered by a particular respective rule event type, the query may not yield any results.For example, while running a query for a Rule - Sudden User Location Change or Event Type: PH_RULE_USER_MON_SUDDEN_LOC_CHANGE, it does not show any results, as shown in the following screenshot.The query needs to be fine-tuned and run as follows:System Event Category IS NOT NULL Event Type IN PH_USER_MON_SUDDEN_LOC_CHANGEThis will provide valid results about incidents triggered by the respective rule.Similarly, the query can be run for any of the rules. The event type of a rule can be found in Step 1 while editing a rule. FortiSIEM Mon, 28 Sep 2026 12:49:26 +0200 https://community.fortinet.com/fortimail-26/troubleshooting-tip-how-to-fix-fortimail-error-error-14094458-ssl-routines-ssl3-read-bytes-tlsv1-unrecognized-name-230211 DescriptionThis article describes how to fix the error 'error:14094458:SSL routines:ssl3_read_bytes:tlsv1 unrecognized name' when FortiMail is integrated with the Microsoft Exchange through EWS 'API_Integration', when FortiMail is integrated with Microsoft Exchange through the API using EWS, and it is unable to list the Users from the Microsoft Exchange side (Listed Subscribed Users).ScopeFortiMail.SolutionWhen FortiMail connects to Exchange EWS, it sends an HTTPS request similar to 'https://<exchange-server>/EWS/Exchange.asmx'.During the TLS handshake, FortiMail sends an SNI (Server Name Indication) hostname. The Exchange-side web server/reverse proxy/load balancer must recognize that hostname.If the Exchange environment has, for example: Mail1.lab.com, but FortiMail is configured with a hostname that is not configured on the Exchange/IIS/reverse-proxy side, the server may return: 'unrecognized name'.To fix this error, update the DNS_Server that is configured on the Exchange_Server to have a Hostname for the FortiMail.After updating the DNS_Server with a Hostname for FortiMail, the issue is resolved. FortiMail Mon, 28 Sep 2026 12:46:15 +0200 https://community.fortinet.com/fortimanager-27/troubleshooting-tip-how-to-fix-a-reloadconffail-invalid-value-error-caused-by-invalid-widget-during-retrieve-add-230210 DescriptionThis article describes how to resolve a 'reloadconffail|invalid value' error that occurs when adding a FortiGate device or retrieving its configuration in FortiManager.ScopeFortiGate, FortiManager.SolutionThe 'reloadconffail|invalid value' error occurs when the FortiGate configuration contains a reference to an object that no longer exists. In this example, there is an interface that is renamed, but the old interface name remains referenced within a GUI dashboard widget.To identify the specific cause of the failure, run the following command on the FortiGate CLI:diagnose test deploymanager reloadconf <device_id>The following is the example output:Retriving configuration file from FGT... Configuration file import succeeded. Reloading configuration file... Error: Configuration reload error. .... >command(set system sso-admin gui-dashboard widget.7:interface vpn-zscaler-pri) detail(datasrc invalid. object: system sso-admin gui-dashboard widget interface 7. detail: vpn-zscaler-pri. solution: data not exist)> add reference fail: command(set system sso-admin gui-dashboard widget.7:interface vpn-zscaler-pri) detail(datasrc invalid. object: system sso-admin gui-dashboard widget interface 7. detail: vpn-zscaler-pri. solution: data not exist)cdb_parse_file: runtime error 131: datasrc invalid. object: system sso-admin gui-dashboard widget.7:interface. detail: vpn-zscaler-pri. solution: data not exist -This output shows there is a missing value in the FGT configuration which is a interface that has been used in a widget (vpn-zscaler-pri)The output indicates the exact command and object causing the failure. The error states datasrc invalid. object: system sso-admin gui-dashboard widget.7:interface. detail: vpn-zscaler-pri. solution: data not exist indicates that widget 7 references a non-existent interface named 'vpn-zscaler-pri'.This widget was created with interface with 'vpn-zscaler-pri' but after renaming that interface, the widget was not updated on FortiGate and kept the old interface name.To resolve the issue, remove the faulty widget from the FortiGate CLI by following these steps:Find the admin who has the faulty widget.Remove the faulty widget from the FortiGate CLI.The following is an example using the output above:config system admin edit <admin-name> config gui-dashboard edit 2 config widget delete 7 end end endRetrieve the configuration from FortiGate or try to add it again. FortiManager Mon, 28 Sep 2026 12:36:42 +0200 https://community.fortinet.com/fortigate-3/troubleshooting-tip-system-federated-upgrade-causes-ha-desync-207758 DescriptionThis article describes an issue where a 'system.federated-upgrade' checksum causes an HA desync. Or when it impedes creating a cluster from scratch.ScopeFortiGate.SolutionWhile hovering over the HA device, it will show 'system.federated-upgrade' has a mismatch in checksum values. This error is triggered in different scenarios.Scenario 1: When the fabric upgrade is enabled on the HA devices, and after the targeted firmware upgrade is finished, the cluster still goes out-of-sync. If HA reservation management is enabled, log in to the secondary device via the GUI and disable the Fabric upgrade.The following is what the configuration looks like: FortiGate-60F # config global FortiGate-60F (global) # config system federated-upgrade FortiGate-60F (federated-upgrade) # sh config system federated-upgrade     set status ready     set upgrade-id 2     set ha-reboot-controller "FGT60FTK2000YYYY"         config node-list             edit "FGT60FTK2000YYYY"                 set timing scheduled                 set time 05:25 2025/06/12 UTC                 set setup-time 11:56 2025/06/11 UTC                 set upgrade-path 7-2-11             next         end endBut while deleting from the CLI, it returns the error: FortiGate-60F # config global FortiGate-60F (global) # config system federated-upgrade  FortiGate-60F (federated-upgrade) # config node-list FortiGate-60F (node-list) # delete FGT60FTK20006777 Federated upgrade cannot be configured directly. Please use 'execute federated-upgrade ...' to configure. command_cli_delete:6898 delete table entry FGT60FTK2000YYYY unset oper error ret=-39 Command fail. Return code -39Solution:To disable the fabric-upgrade, execute the following command:FortiGate-60F (global) # execute federated-upgrade cancel This will cancel the upgrade. If the upgrade is immediate or scheduled to happen very soon, some nodes may have already gone down for upgrade. Do you want to continue? (y/n)y FortiGate-60F (global) # show system federated-upgrade config system federated-upgrade      set status disabled endNote:The config system federated-upgrade command is read-only. Attempting to configure federated upgrade using the config command will show the following error message:Federated upgrade cannot be configured directly. Please use 'execute federated-upgrade ...' to configureOnce the command is executed, the status will be changed to disabled, wait for a while, and the HA status will show in-sync. See Upgrading all device firmware by following the upgrade path (federated update).If the HA status does not return to In Sync:Perform a manual synchronization, or,Reboot the primary node to resolve the discrepancy.Scenario 2:There is a different configuration available in primary and secondary units:Example with override disabled:In the primary FortiGate:config system federated-upgrade     set status disabled      set initial-version 'firmware-7.6.4'     set starter-admin 'super_admin' end   In the secondary FortiGate:config system federated-upgrade     set status disabledThis difference may also be both if the primary has federated-upgrade enabled, but the secondary does not. Alternatively, both may have the feature enabled but a different scheduled time. In all of these cases, the synchronization will not be possible.Example with override enabled:FG unitSNFG-100F3 (primary)FG100FTK190XXXXXFG-100F6 (secondary)FG100FTK190YYYYYPrimary FortiGate before clustering with peer:config system federated-upgrade set status initialized set source forced-upgrade set upgrade-id 2 set ha-reboot-controller "FG100FTK190XXXXX" config node-list edit "FG100FTK190XXXXX" set timing immediate set maximum-minutes 70 set setup-time 09:49 2026/09/27 UTC set upgrade-path 7-6-7 next end set initial-version 7-6-6-3652 set starter-admin "daemon_admin" endSecondary FortiGate before clustering with peer:config system federated-upgrade set status disabled set starter-admin "daemon_admin" endAfter connecting them through heartbeat interfaces, the primary FortiGate status shows as follows:config system federated-upgrade set status initialized set source forced-upgrade set upgrade-id 2 set ha-reboot-controller "FG100FTK190XXXXX" config known-ha-members edit "FG100FTK190XXXXX" next edit "FG100FTK190YYYYY" next end set initial-version 7-6-6-3652 set starter-admin "daemon_admin" config node-list edit "FG100FTK190XXXXX" set timing immediate set maximum-minutes 70 set setup-time 09:49 2026/09/27 UTC set upgrade-path 7-6-7 next end end This shows the SN of the secondary as an ha-member.In the secondary unit, if federated-upgrade was not enabled before connecting with the primary, the result after connecting is:config system federated-upgrade     set status initialized     set source forced-upgrade     set upgrade-id 2     set ha-reboot-controller " "FG100FTK190XXXXX"     config known-ha-members         edit "FG100FTK190XXXXX"         next         edit "FG100FTK190YYYYY"         next     end     set initial-version 7-6-6-3652     set starter-admin "daemon_admin" endThis shows the status of 'initialized' inherited from the primary, as well as the SN of the primary as 'reboot-controller', but there is no node-list.When this happens, the only way to synchronize them again is to disable the federated-upgrade in the units. This cannot be done with CLI commands:FG100F-3 # config system federated-upgrade FG100F-3 (federated-upgrade) # set status disabled FG100F-3 (federated-upgrade) # end Federated upgrade cannot be configured directly. Please use 'execute federated-upgrade ...' to configure. object set operator error, -39 discard the setting Command fail. Return code -39 FG100F-3 # execute federated-upgrade cancel The existing upgrades cannot be cancelled. Command fail. Return code 1 It will not be possible to configure the node-list on the primary or on the secondary.Solution:A case with override disabled:The primary unit was rebooted.The primary unit became the secondary unit.The issue was still observed in the new primary FortiGate.Issue the following commands in the new primary FortiGate:execute ha synchronize stop execute ha synchronize start diagnose sys ha checksum recalculateUse the last command three times.A case with override enabled:The primary unit rebooted. After the reboot, the primary unit loses the federated-upgrade configuration temporarily, so if the second had it disabled, they can synchronize. After the reboot, the status is as follows:On the primary unit:FG100F-3 # execute federated-upgrade status Global devices: Local devices: Includes this FortiGate: no Local status: disabledOn the secondary, it changes its status to 'disabled' instead of 'initialized' (as the primary result of the synchronization):secondary's external files are not in sync with the primary's, sequence:3. (type CERT_LOCAL) FG100F-6 # FG100F-6 # FG100F-6 # execute federated-upgrade secondary's external files are not in sync with the primary's, sequence:4. (type CERT_LOCAL) status Global devices: Local devices: Includes this FortiGate: no Local status: disabledFinally, they can synchronize and create the cluster.After the FGCP cluster builds, the feature is enabled by default again. This time, it will be aligned in both units.For more information on Fabric-upgrades, refer to Upgrading all devices. To sync HA manually, refer to Technical Tip: Procedure for HA manual synchronization. FortiGate Mon, 28 Sep 2026 12:23:26 +0200 https://community.fortinet.com/fortiweb-40/technical-tip-how-to-interpret-logd-debug-output-to-verify-log-generation-and-local-storage-on-fortiweb-230208 DescriptionThis article describes how to interpret the logd debug output on FortiWeb to verify whether log entries are being generated and processed by the logging service.The article focuses on identifying the relevant logd messages in the debug output and correlating them with a test traffic request.ScopeFortiWeb.SolutionCLI command:Open an SSH session to FortiWeb and run the following commands:diagnose debug disable diagnose debug reset diagnose debug timestamp enable diagnose debug application logd 7 diagnose debug enableGenerate a test request through a Server Policy configured to generate the relevant log type while the debug is running.After completing the test, disable the debug:diagnose debug disable diagnose debug resetA successful logging sequence should contain the following stages.Confirm that logd receives the traffic log.Look for:###### Recv a traffic logThis indicates that the logd process has received a traffic log generated by FortiWeb.Verify the traffic log details.Review the Local Detail output and confirm that it contains the expected traffic information, such as:type=traffic subtype="https" status=success policy="Lab_Tasks_Policy" http_retcode=200 server_pool_name="Ubuntu_Server" http_host="10.5.X.X:1443"These fields can be used to correlate the logd output with the test request and confirm that the expected Server Policy and backend server were involved.Confirm that logd starts writing the log to disk.Look for this:Begin to write disk.This indicates that logd is proceeding with local disk storage of the traffic log.Confirm that the traffic log is written to the log-disk file.Look for entries similar to:Open existing log file '/var/log/fwlog/root/disklog/tlog(2026-09-28-11:17:29).log' with linkWhich should be followed by:Write log item Traffic log 1 msg_id 000000122761These messages indicate that the traffic log has been written to the local log-disk file.A successful sequence from Recv a traffic log through Write log item Traffic log confirms that FortiWeb is receiving the traffic log, processing it, and storing it locally.Example:The following output shows a successful traffic-log processing sequence:If the expected logd messages are not observed:If Recv a traffic log is not displayed, verify that the test traffic is reaching FortiWeb and that the relevant logging option is enabled.If Recv a traffic log is displayed but Begin to write disk is not observed, investigate the logd processing stage.If Begin to write disk is displayed but the log file/write messages are not observed, further investigation of local log storage may be required. FortiWeb Mon, 28 Sep 2026 11:42:23 +0200 https://community.fortinet.com/fortigate-3/technical-tip-explanation-of-ruleid-0-generated-in-global-dlp-policy-logs-230207 DescriptionThis article describes an occurrence where Data Loss Prevention (DLP) log entries display ruleid=0 even when multiple explicit rules are fully configured within the DLP profile. This behavior indicates that profile-level logging or archiving features are active for specific protocols.ScopeFortiOS.SolutionHere is an example of a DLP raw log entry in which ruleid=0 is displayed.Sep 27 12:34:46 100.100.100.100 date=2026-09-27 time=12:34:46 devname="FortiGate" devid="FGTxxxxxxx" eventtime=1790493286000000000 tz="+0200" logid="0954024577" type="utm" subtype="dlp" eventtype="dlp" level="notice" vd="root" ruleid=0 filtertype="none" filtercat="none" severity="medium" policyid=5 poluuid="c1fc7ebc-0ff0-51f0-49ed-779fe6573d21" policytype="proxy-policy" sessionid=51625285 epoch=1995608521 eventid=1 srcip="10.10.10.10" srcport=57346 srccountry="Reserved" srcintf="port1" srcintfrole="undefined" dstip="20.20.20.20" dstport=443 dstcountry="Germany" dstintf="port2" dstintfrole="undefined" dstuuid="6ae7196a-f381-51ef-372e-f34d34744d5" proto=6 service="HTTPS" filetype="unknown" direction="outgoing" action="log-only" hostname="login.microsoftonline.com" url="https://login.microsoftonline.com/2ba8a4bf-3d7a-478b-b8d1-85eae49436ef/saml" agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:140.0) Gecko/20100101 Firefox/140.0" httpmethod="POST" referralurl="www.example.com:8008/" filename="saml" filesize=5096 profile="Global Policy" rawdata="[req] Content-Type=application/x-www-form-urlencoded"The ruleid=0 value is not used to identify a default DLP rule, an additional rule configured with ID 0, or an unmatched DLP signature.The appearance of ruleid=0 in DLP logs does not indicate an unmatched detection error or a missing rule configuration. Instead, ruleid=0 is used when a DLP log is generated by the DLP profile itself, as a result of the summary-proto or full-archive-proto settings.config dlp profile     edit "<profile_name>"         set full-archive-proto <protocols>         set summary-proto <protocols>     next end'full-archive-proto' - Protocols to always content archive.'summary-proto' - Protocols to always log summary.When these options are active, the device is instructed to log or archive 100% of the session traffic for the configured protocols (such as http-get and http-post), regardless of whether any specific user-defined DLP rules have been triggered.Consequently, ruleid=0 is assigned to signify that the log event is attributed to the DLP profile itself rather than an individual rule match.Therefore, ruleid=0 should not be interpreted as a default rule, a policy-level firewall match, or an unmatched DLP detection. It is used to indicate that the event was generated by the configured protocol-level logging or archiving functionality of the DLP profile.This behavior is expected. FortiGate Mon, 28 Sep 2026 11:36:25 +0200 https://community.fortinet.com/forticloud-products-44/technical-tip-how-to-get-support-for-security-awareness-and-training-product-230206 DescriptionThis article describes deployment and support options for the FortiSAT (Security Awareness and Training product).ScopeSecurity Awareness and Training - FortiSAT.SolutionThe FortiSAT product has 2 service components:The InfoSec Awareness and Training Service.The Phishing Simulator Service.Users may purchase one service or the other, or both services. The SKU(s) issued will determine what service(s) the user is entitled to.Follow these steps to initialize and configure the new FortiSAT service(s).To review the detailed steps or attempt the setup:Create a FortiCloud account (if not already created).Register the product code(s) with the steps outlined in Registering the service using the service contract (to initialize the license(s) / service(s) if not already registered).Access the service from: https://fortisat.forticloud.com.Configure the service(s) using the FortiSAT Administration Guide.(Note: Access to this documentation is available only after a FortiCloud account is created.)Links to configuration steps:Note: As with the documentation above, access to the documentation in the links below are available only after a FortiCloud account is created.Step 1 - Domain verification and customization.Once initialized, verify the email domain(s). Refer to Verifying domain ownership.Once completed, the training URL can be customized (create a subdomain to the registered domain) by creating 'A' records using the appropriate URL (depending on the license level). Note: Different license level options are currently in the development stage.Verifying the DNS TXT and 'A' records have been successfully created: How to verify your DNS TXT and A records have been added correctly and have been successfully propagated.Step 2 (Optional) - Configure an SMTP account for sending of Security Awareness and Training Service communications (training invites, due date reminders, congratulations email, scheduled reports, etc.)Configuring an SMTP email address for sending training-related correspondenceStep 3 - Managing Users.Manage users via the Users page: Users.User Sync (LDAP Server).User Sync (SCIM) - Auto-provisioning using Microsoft Entra/Azure/O365 or Google Workspace Directories: SCIM Provisioning.Step 4 (Optional) - Customizing the appearance and notification templates.It is possible to customize the notification templates using this article: Email templates.Step 5 - Campaign Management.See Manage Campaigns (Training and Phishing).Additional resources:Nano Videos and Classroom Curriculum:Access support by opening a ticket here: Security Awareness and Training Service Support site (select Infosec/Security Awareness and Training Service from the What is your request related to? drop-down menu), or by sending an email to infosec_awareness@fortinet.com (one email per question/incident / enhancement) and providing a detailed description with steps to reproduce and screenshots (if applicable).For a description of module content, refer to Fortinet Security Awareness and Training Service Course Modules.To plan the campaigns, refer to these documents (this information is also covered in the Manager modules included in the service):Setting Goals and Planning Your Security Awareness and Training ProgramPlanning the Security Awareness and Training Calendar FortiCloud Products Mon, 28 Sep 2026 11:36:10 +0200