https://community.fortinet.com On the Forum you can ask questions or take part in discussions. https://community.fortinet.com/support-forum-92/os-upgrade-issue-229774 We currently have a FortiGate firewall running FortiOS version 7.2.11, and we are planning to upgrade the firmware to a recommended and supported version.Could you please share the recommended FortiOS version for our firewall model, along with the correct and supported upgrade path from FortiOS 7.2.11?   Support Forum Sun, 06 Sep 2026 12:41:47 +0200 https://community.fortinet.com/support-forum-92/email-otp-not-received-for-forticlient-ipsec-vpn-via-fortinet-notifications-com-229792 Hello Fortinet Community,We are currently experiencing an issue where users connecting through the FortiClient IPsec remote-access VPN do not receive their email OTP.Environment:FortiGate model: FortiGate 100F FortiOS version/build: v7.6.7 build3704 (Mature) VPN type: IPsec remote-access VPN Two-factor authentication: Email OTP Email service: fortinet-notifications.com Issue started: September 4–5, 2026 Impact: Multiple/all VPN usersThe VPN authentication process reaches the stage where the user is waiting for the email OTP, but no OTP email is received. This configuration was previously working normally.We enabled the following debug commands:diagnose debug resetdiagnose debug console timestamp enablediagnose debug application fnbamd -1diagnose debug application alertmail -1diagnose debug enableThe certificate authentication shown in the debug completes successfully with:Cert status: GOOD auth_cert_successHowever, we did not see an AuthCode being generated or an SMTP connection initiated during the affected VPN login attempt.We also ran:diagnose log alertmail testThe initial test showed:from: fortinet-notifications.com user: (null) tot0], tot1], and tot2] were empty can not start sessionWe understand that this particular test could not start because no alert email recipient was configured, so we are continuing to test again with a valid mailto1 recipient. Support Forum Sun, 06 Sep 2026 08:44:12 +0200 https://community.fortinet.com/support-forum-92/fortigate-30e-recovery-of-a-lost-administrator-account-name-and-password-229793 HelloOn FortiGate 30E with FortiOS v6.2.3 build 1066 (GA), the administrator user name and password have been changed.Unfortunatly the credentials have been lost.The default admin account is disabled or deleted.There is no other account.is there a way to recover the administrator access, without losing the configuration?Thanks for your help.Philippe Support Forum Sun, 06 Sep 2026 07:58:13 +0200 https://community.fortinet.com/support-forum-92/fortigate-vm-6-2-3-eve-ng-on-vmware-workstation-kernel-panic-after-installing-evaluation-license-228894 Hi Team,I am facing an issue with my FortiGate VM running in my lab environment and would appreciate any guidance.Environment:FortiGate VM Image: FortiGate-VM64-KVM v6.2.3 EVE-NG installed on VMware Workstation License: Evaluation (Evolution) license installed via GUIIssue:The FortiGate VM was working normally before installing the evaluation license. After uploading and applying the license through the GUI, the VM initiated a reboot.Since then, the VM has been unable to boot successfully. Instead, it continuously crashes with a kernel panic (double fault) during startup and enters a reboot loop.Below is the console output:FortiGate-VM64-KVM #FortiGate-VM64-KVM # Requesting FortiCare Trial license, proxy:(null)The system is going down NOW !!Please stand by while rebooting the system.Restarting systemPANIC: double fault, error_code: 0x0Kernel panic - not syncing: Machine halted.CPU: 0 PID: 1 Comm: initXXXXXXXXXXX Tainted: P                  4.19.13 #1Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011Call Trace: <#DF> dump_stack+0x63/0x81 panic+0xe2/0x245 df_debug+0x29/0x2b do_double_fault+0x7b/0x8f double_fault+0x1e/0x30RIP: 0010:0xfff0Code: Bad RIP value.RSP: 0018:0000000000000000 EFLAGS: 00010002RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000RDX: 0000000000000623 RSI: 0000000000000000 RDI: 0000000000000000RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </#DF>Kernel Offset: disabledRebooting in 5 seconds..PANIC: double fault, error_code: 0x0CPU: 0 PID: 1 Comm: initXXXXXXXXXXX Tainted: P                  4.19.13 #1Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011RIP: 0010:0xfff0Code: Bad RIP value.RSP: 0018:0000000000000000 EFLAGS: 00010002RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000RDX: 0000000000000623 RSI: 0000000000000000 RDI: 0000000000000000RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000FS:  00007f249b96ffc0(0000) GS:ffff88803aa00000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000000000ffc6 CR3: 000000003edd3000 CR4: 00000000000006f0Call Trace:Kernel panic - not syncing: Machine halted.Kernel Offset: disabledRebooting in 5 seconds..  Support Forum Sun, 06 Sep 2026 01:35:36 +0200 https://community.fortinet.com/support-forum-92/empty-dataset-even-though-the-log-view-shows-results-when-querying-ip-adresses-229796 I struggle to understand why this dataset query shows no result on my FortiAnalyzer instance:SELECT dstport, srcip, dstipFROM $logWHERE $filter AND ipstr(dstip) IN ('172.31.11.80', '172.31.11.83')GROUP BY srcip, dstip, dstportORDER BY dstport, srcipTo be sure, I am getting results if in the Log View I search for:  dstip=172.31.11.80 or dstip=172.31.11.83Any hint? Support Forum Sun, 06 Sep 2026 01:12:02 +0200 https://community.fortinet.com/support-forum-92/dos-policy-tcp-src-session-229794 In DoS Policy »  tcp_src_session option.if i set  Threshold = 30Is it mean 30 session per 60 seconds ? Support Forum Sat, 05 Sep 2026 20:46:41 +0200 https://community.fortinet.com/support-forum-92/fortios-8-0-0-map-e-rejects-jpix-v6-plus-dhcpv6-pd-prefix-as-invalid-end-user-prefix-229795 Hello, I am testing dynamic MAP-E connectivity on a FortiGate-100F running FortiOS 8.0.0 build 0167. The Internet service is So-net over the NTT East FLET'S network in Japan. The VNE service appears to be JPIX “v6 Plus.” DHCPv6-PD is working. The FortiGate receives a /56 delegated prefix and the WAN interface receives an IPv6 address derived from that prefix. The relevant WAN configuration is:  config system interface    edit "x1"        set mode dhcp        set role wan        config ipv6            set ip6-mode delegated            set dhcp6-prefix-delegation enable            set ip6-delegated-prefix-iaid 1            set ip6-upstream-interface "x1"            set ip6-subnet ::1/64            config dhcp6-iapd-list                edit 1                    set prefix-hint ::/56                next            end        end    nextend  After applying this configuration, the VNE diagnostic correctly recognizes the delegated prefix and WAN IPv6 address:  end user ipv6 prefix: 240b:10:xxxx:xx00::/56interface ipv6 addr: 240b:10:xxxx:xx00::1  However, the MAP-E tunnel is not established:  link=0bmr rule ipv6 prefix: ::/0bmr rule ipv4 prefix: 0.0.0.0/0bmr rule br: ::tunnel br: ::tunnel ipv4 addr: 0.0.0.0/0.0.0.0 Map-e rule client: state=initreply_code=0fqdn=rule.map.ocn.ad.jp Map-e DDNS client: state=initreply_code=0fqdn=ipoe-static.ocn.ad.jp  The VNE debug repeatedly reports:  mape_rule_client_timer_func(): invalid end user prefix 240b:10:xxxx:xx00::/56  Packet captures show that: - DHCPv6-PD completes successfully.- The /56 prefix and IPv6 DNS servers are received.- `rule.map.ocn.ad.jp` and `ipoe-static.ocn.ad.jp` are successfully resolved to IPv6 addresses.- No TCP or TLS connection is subsequently sent to the resolved MAP rule server addresses.- The error therefore appears to occur locally in `vned`, before an HTTP request is transmitted. I noticed that the Fortinet DHCP-PD MAP-E documentation uses the OCN servers `rule.map.ocn.ad.jp` and `ipoe-static.ocn.ad.jp`. In this environment, however, the MAP-E provider is expected to be JPIX rather than OCN. Could someone clarify the following? 1. Does FortiOS 8.0.0 support dynamic MAP-E for JPIX “v6 Plus,” or is dynamic MAP-E currently limited to OCN Virtual Connect?2. How does `vned` select the MAP rule distribution server for each Japanese VNE provider?3. Is `rule.map.ocn.ad.jp` hardcoded or selected from an internal provider profile?4. Can the MAP rule server be overridden through the CLI?5. What value is expected for `bmr-hostname`, and does this setting affect rule-server selection?6. Is the `invalid end user prefix` message caused by an internal list of supported OCN IPv6 prefixes?7. Is this a known FortiOS defect or an unsupported-provider limitation? I also checked Fortinet Bug ID 1158975, but this case appears different because DNS servers are received and the OCN hostnames are successfully resolved. Any confirmation of JPIX dynamic MAP-E support, a relevant Bug ID, or the required provider-specific configuration would be appreciated. Support Forum Sat, 05 Sep 2026 20:20:58 +0200 https://community.fortinet.com/support-forum-92/fortiap-and-using-darrp-for-channel-config-vs-manual-228961 Hey everyone, i'm sure the answer always depends but wondering who uses DARRP vs manual channel configuration. I've been using DARRP for a few years now and it works 'fine', but I have noticed sometimes it will over saturate a channel instead of using different ones. We typically reboot the AP and it will pick a different channel and things are fine. I've considered moving to a manual config. The only reason I don't is the obvious, it's manual and would love for DARRP to just work. For a scope we a few campuses and about 250APs.  Support Forum Fri, 04 Sep 2026 20:47:55 +0200 https://community.fortinet.com/support-forum-92/fg-ir-26-156-cve-2026-70465-fix-availability-for-forticlient-free-vpn-only-windows-229524 https://fortiguard.fortinet.com/psirt/FG-IR-26-156FG-IR-26-156 (CVE-2026-70465) advisory states the fix is available in FortiClient Windows 7.4.4 / 7.2.12 and later. However, the free VPN-only agent has not received a new release since 7.4.3 (per the community note that v7.4.4–7.4.8 include no new free VPN-only build).Could you confirm: 1. Is FortiClient Free VPN-only 7.4.3 (build 4726) vulnerable to CVE-2026-70465? 2. If yes, will a patched free VPN-only build be released, or is upgrading to a licensed version the only path to remediation? Thanks in advance. Support Forum Fri, 04 Sep 2026 20:43:03 +0200 https://community.fortinet.com/support-forum-92/forticlient-windows-vpn-only-7-4-3-build-affected-by-cve-2026-70465-229488 Hello,We are using the free FortiClient Windows VPN-only agent, version 7.4.3.Regarding Fortinet PSIRT advisory FG-IR-26-156 / CVE-2026-70465, the advisory lists FortiClient Windows 7.4.0 through 7.4.3 as affected and recommends upgrading to 7.4.4 or later. However, the FortiClient Windows release notes state that versions 7.4.4 through 7.4.7 do not include a new release of the free VPN-only agent, and that users can continue using the 7.4.3 free VPN-only agent. Could a Fortinet representative please clarify the following?Is the latest available free FortiClient Windows VPN-only 7.4.3 build affected by CVE-2026-70465? References:FG-IR-26-156: https://fortiguard.fortinet.com/psirt/FG-IR-26-156FortiClient 7.4.7 release notes: https://docs.fortinet.com/document/forticlient/7.4.7/windows-release-notes/683433/special-notices This is a request for clarification of the public PSIRT advisory’s impact and remediation path for the free VPN-only edition Support Forum Fri, 04 Sep 2026 20:41:56 +0200 https://community.fortinet.com/support-forum-92/our-company-bought-fg1100e-in-2026-229781 I mean, they are easily powerful enough and fit out usecase. No technical problem at all but they were released in 2019 and go eol September 2031. It does not sound clever to me to lose more than half of its lifespan. Support Forum Fri, 04 Sep 2026 20:40:13 +0200 https://community.fortinet.com/support-forum-92/mac-webfilter-browser-extensions-229791 We are testing FortiClient WebFilters and we are trying to test incognito mode extensions. It works on Windows browsers, but not macOS. Windows users get a pop-up asking to approve the new extension. (see example).None of my browsers have any FC extensions. Does this work on macOS?Bonus question: Can this pop-up be suppressed?  Support Forum Fri, 04 Sep 2026 18:18:12 +0200 https://community.fortinet.com/support-forum-92/is-forticlient-vpn-only-7-4-3-4323-compatible-with-macos-26-229471 The FortiClient VPN-only version 7.4.3.4323 has been installed onto a MacBook running macOS 26. Full disk access has been given to fctservctl2 and the network extension FortiTray has been enabled although FortiClientProxy and FortiClientPacketFilter were not present to enable. The settings for this VPN use the public IP address of the FortiGate and various DH Group and encryption levels have been tried but all to no avail. The VPN connection is IPsec VPN and tries connecting for a while then comes back with a connection timeout error. The native IKEv2 client for macOS does not work either. I read somewhere that Fortinet added macOS Tahoe 26 support in FortiClient 7.4.5 but there is no VPN-only version later than 7.4.3. I have also read that SSL-VPN support is being stopped so surely there needs to a new VPN-only version where IPsec VPN can be used. Is there ever going to be a newer VPN-only version released? Or is the option available now FortiClient Standalone? This does not seem to be made clear anywhere and Fortinet support and customer service both defer to this community forum rather than directing me to the FortiClient Standalone version. Support Forum Fri, 04 Sep 2026 18:13:08 +0200 https://community.fortinet.com/support-forum-92/issue-with-fortiems-upgrade-and-access-post-upgrade-191260 We received a notification last Friday regarding the need to upgrade our FortiEMS system. As per the schedule, we initiated the upgrade on Saturday at 1:00 AM.However, since Monday, we have been unable to access FortiEMS. The system continuously displays an "upgrade in progress" status, and refreshing the browser every 10 minutes has not resolved the issue. Support Forum Fri, 04 Sep 2026 17:46:47 +0200 https://community.fortinet.com/fortigate-3/troubleshooting-tip-fgfm-debug-contains-unsuitable-certificate-purpose-when-using-a-3rd-party-ca-generated-certificate-on-fortigate-229790 DescriptionThis article describes how to resolve the failure to establish an FGFM connection between a FortiGate device and a FortiManager when the FGFM debug log on FortiManager indicates 'unsuitable certificate purpose'.ScopeFortiGate, FortiManager.SolutionWhen an FGFM connection fails to establish and the FGFM debug log includes a message that contains the text 'unsuitable certificate purpose', then this mostly likely means that the certificate that is being presented by the FortiGate device to FortiManager during TLS negotiation of the FGFM connection does not have the correct Extended Key Usage (EKU) extension.In the context of the FGFM connection, the FortiGate device takes on the role of a 'client', whilst the FortiManager acts in the 'server' role.The FGFM connection employs mTLS as a means to authenticate the connecting FortiGate device.For mTLS, the certificate that is presented to the 'server' (FortiManager) by the 'client' (FortiGate) needs to contain information about the certificate being used for 'clientAuth' purposes; that information will be found in the certificate EKU field.A lack of 'clientAuth' in the certificate may occur when the certificate has been generated by a 3rd-Party Certificate Authority (CA), rather than the FortiGate's own internal CA. Such a 3rd-party CA could be a well-known public CA but it could also be a private company-internal CA.Background Information: Whilst this particular error condition may not have occurred in the past with 3rd-party-CA issued certificates, it may now be seen to occur due to a recent change (circa autumn 2025) that took place amongst the Internet community to address some security concerns with certificates issued by public CAs.Prior to that time, most public CAs issued certificates which by default included intended function descriptions in the EKU for both 'TLS Web Server Authentication' (which is required for a 'server' role certificate) and 'TLS Web Client Authentication' (which is only really applicable for 'client' role certificates).Public CAs have since changed their certificate issuance process so that their certificates are now only produced with just the 'TLS Web Server Authentication' EKU setting by default.If the 'TLS Web Client Authentication' EKU is required in a certificate, it now needs to be explicitly requested when the certificate is being generated.Further explanations about this EKU change from some of the well-known public CAs can be found here from Sectigo and DigiCert respectively:Deprecation of Client Authentication EKU from Sectigo SSL/TLS certificates.Removing the client authentication EKU from public TLS certificates.Note: Whilst this change in certificate issuance processing is being adopted by all the well-know public CAs, it may also be the case that the EKU values used by private company-internal CAs also may now by default just contain the 'TLS Web Server Authentication' EKU value.The EKU values in the certificate that are (or will be) used in a FortiGate device for the FGFM connection can be checked using either of the following methods:From the FortiGate GUI:Use the 'View Details' option on a selected certificate (select the certificate by going to System -> Certificates) and then look for the 'Extensions' section towards the bottom of the displayed details page - check the 'X509v3 Extended Key Usage' entry for a value of 'TLS Web Client Authentication', as shown in the following extract:From the external machine (which has a copy of the certificate file):Prior to loading the certificate into FortiGate (or after exporting the certificate from FortiGate), it is possible to use a common SSL tool like 'openssl' to view the full certificate details:openssl x509 -noout -text -purpose -in <cert-file>Look for a line that says 'SSL client', as shown in the following extract:... Certificate purposes: SSL client : Yes ...Alternatively, in the main certificate information that is dumped to the screen, look for the 'X509v3 Extended Key Usage' entry and check that it contains the value 'TLS Web Client Authentication', as shown in the following extract:... X509v3 extensions: X509v3 Basic Constraints: CA:FALSE X509v3 Key Usage: Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment X509v3 Extended Key Usage: TLS Web Client Authentication X509v3 Subject Key Identifier ...Related articles:Technical Tip: Setup custom certificate for FGFM protocolTroubleshooting Tip: How to troubleshoot connectivity issues between FortiGate and FortiManagerTroubleshooting Tip: Troubleshooting a FortiGate-FortiManager (FGFM) tunnel issue with CA or SAN verification of a custom certificateTroubleshooting Tip: A guide to FortiGate and certificate issues FortiGate Fri, 04 Sep 2026 16:57:40 +0200 https://community.fortinet.com/fortisiem-216/fortisiem-correlation-latency-229768 Hello i want to know the correlation latency for fortiSIEM 2200G because i cant seem to find it anywhere mentioned in the documentatios FortiSIEM Fri, 04 Sep 2026 16:52:19 +0200 https://community.fortinet.com/support-forum-92/preferred-forticlient-ems-authentication-method-for-mac-computers-managed-via-jamf-saml-ldap-entraid-228069 We are a 100% cloud-based org using M365. We are 85% Windows and 15% Mac. We use FortiClient EMS Cloud to manage/publish ZTNA and VPN connection profiles to users. We have the FortiClient EMS configured with Domain Authentication and connected to our Entra ID tenant. The appropriate groups are assigned, and registration is seamless and it works. I fully understand that Mac OS is very different and does not support  Entra ID authentication with EMS. The Fortinet EMS admin guide says, “FortiClient (macOS) does not support native Entra ID integration with EMS. For the integration to work, macOS endpoints must be managed by Intune or JAMF and enrolled to company portal using Entra ID.” Adding an Entra ID server | FortiClient 7.4.5 | Fortinet Document LibraryThat last sentence says it’s possible to use Entra ID integration for Macs. Our Mac machines are registered to Intune through JAMF PRO and enrolled to Company Portal. Domain Authentication will not work, and I know that. Which registration/authentication methods should I use for these Mac machines to get the same type of user-level and device-level registration in FCEMS that we have for our Windows machines? Support Forum Fri, 04 Sep 2026 15:27:36 +0200 https://community.fortinet.com/support-forum-92/urgent-security-patch-inquiry-cve-2024-21762-fortigate-fg-100f-fortios-7-2-8-229789 Hi everyone,We would like to ask for assistance regarding CVE-2024-21762 on a FortiGate FG-100F currently running FortiOS 7.2.8.Our customer is requesting us to remediate this security vulnerability.Could anyone please confirm whether FortiOS 7.2.8 has already addressed CVE-2024-21762?If not, what is the recommended action and remediation procedure to fix this vulnerability?This is an important security issue and needs to be addressed as soon as possible. Any official guidance or recommendations would be greatly appreciated.Thank you for your support. Support Forum Fri, 04 Sep 2026 15:17:05 +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 Fri, 04 Sep 2026 10:53:01 +0200 https://community.fortinet.com/fortimail-26/technical-tip-how-to-configure-lesser-number-of-log-file-rolled-by-fortimail-to-be-exported-for-backup-purpose-229786 DescriptionThis article describes how to configure lesser number of log file rolled by FortiMail to be exported for backup purposes.ScopeFortiMail.SolutionIf exporting the log files from FortiMail is always required and downloading multiple log files directly from FortiMail is not supported (the download button will be greyed out), the following suggestion can be considered.Navigate to Log & Report -> Log Setting -> Local and configure as per the screenshot.It is also possible to configure using the CLI command below:config log setting local set rotation-size 500 (MB) set rotation-period 365 (Days) end FortiMail Fri, 04 Sep 2026 10:11:13 +0200 https://community.fortinet.com/support-forum-92/forticlient-ems-domain-ldap-authentication-hangs-indefinitely-resolved-229783 SymptomsWe were configuring FortiClient EMS invitations using Domain/LDAP authentication.The environment appeared to be correctly configured:The Active Directory domain was successfully imported into EMS. Users were visible in EMS and could be selected when creating an individual invitation. No errors were reported in the AD Connector logs. EMS synchronization with AD appeared healthy.However, when users attempted to authenticate through the Domain/LDAP invitation workflow, they entered their AD credentials and the authentication window would remain in a continuous loading state indefinitely, without returning any error message. TroubleshootingInitially, no obvious issues were visible in the EMS GUI or AD Connector logs.To investigate further, we enabled Debug Log Mode on EMS and reproduced the issue.The debug logs revealed the following message:Authentication error: User not found in DBThis was unexpected because:The user existed in Active Directory. The user had already been imported into EMS. AD synchronization was working. Root CauseThe issue appeared to be related to a corruption or inconsistency within the EMS database records associated with the managed domain and imported users.Although the users were visible in the EMS interface, the authentication process was unable to properly locate the user record in the EMS database. SolutionWe removed the Managed Domain from EMS and then added it again, allowing EMS to perform a fresh synchronization with Active Directory.After the domain was re-added:Users were imported again. Domain/LDAP authentication started working normally. Invitations authenticated successfully. The indefinite loading behavior disappeared. Support Forum Fri, 04 Sep 2026 09:44:22 +0200 https://community.fortinet.com/fortimail-26/technical-tip-how-to-configure-fortimail-dlp-to-detect-malaysian-identity-card-numbers-229784 DescriptionThis article describes how to configure FortiMail Data Loss Prevention (DLP) to detect Malaysian identity card numbers in email messages and attachments.ScopeFortiMail.SolutionFortiMail DLP can use user-defined sensitive data, including regular expressions, to identify specific information in email traffic.For example, a Malaysian identity card number can be detected using a pattern matching the commonly used format:YYMMDD-SS-####Note:The regular expression should be adjusted according to the organization's actual identity-card format and detection requirements.Create the Scan rule:Go to:Data Loss Prevention -> Rule & Profile -> Rule.Select the appropriate pattern type, such as Regular Expression.Enter the regular expression for the identity card number.For example: \b\d{6}-\d{2}-\d{4}\b.Save the configuration.FortiMail supports user-defined sensitive data, such as words, phrases, and regular expressions.Create a DLP Rule:Go to: Data Loss Prevention -> Rule & Profile -> Profile, select 'New', enter a name.Under Conditions, select New, and configure the condition to check for the previously created sensitive data.Select the email portion to inspect, such as:Body.Attachment.Body and attachment.Select the required action, save the rule.FortiMail DLP rules can specify which part of an email should be checked, including email bodies and attachments.Apply the DLP profile to the policy. FortiMail Fri, 04 Sep 2026 09:35:58 +0200 https://community.fortinet.com/fortigate-3/technical-tip-how-to-use-an-external-ip-address-service-with-an-external-api-external-feeds-api-229782 DescriptionThis article describes how to use an external IP address database as an 'External Feeds' connector with an external application over an API.ScopeFortiGate.SolutionWhen there is a need to use an external IP database with a third party that will use an external API key with the use of an FQDN, follow the following:Go to Security Fabric -> External Connectors -> Create new. After selecting Create New, choose the category External Feeds (IP address). After selecting the IP Address category, it will be necessary to fill in the following: Status -> Enable.Name -> Customize as needed.Update method -> External feed.URL of external resource -> Here is the need for the FQDN + API key given by the third-party service. With this configuration, the external feed with the FQDN+API will start working. FortiGate Fri, 04 Sep 2026 09:06:52 +0200 https://community.fortinet.com/fortigate-3/technical-tip-how-to-solve-this-sts-windows-net-page-can-t-be-found-over-saml-sso-229779 DescriptionThis article describes how to solve the error 'This sts.windows.net page can't be found' after the 2FA page pops up when authenticating over SAML.ScopeFortiGate, IPsec, SSO.SolutionThere are scenarios when connecting to a VPN with SAML authentication where the 2FA screen pops up, but the next error is shown: 'This sts.windows.net page can't be found'.The error means the URL 'IdP single sign-on URL' used by the IdP is wrongly configured on the FortiGate. This can be verified using the next command: FGT_TEST # config user saml FGT_TEST (saml) # edit "XXXXXX" FGT_TEST (XXXXXX) # showInside the 'XXXXX', specify the name of the SAML user profile, which can also be identified by going to User and authentication -> Single Sign-On, and the name of the profile is shown there:Check the URL and see if it is wrong: Correct URL that needs to be verified on the IdP side and also an example on the FortiGate side:  After the URL is fine, the issue should be fixed and not persist. FortiGate Fri, 04 Sep 2026 07:53:07 +0200 https://community.fortinet.com/support-forum-92/installing-policy-package-error-19115 Hello, While I'm trying to install policy package to device, the copy of the package is working fine and then when it enters the state of "Install package to device from commit" the management tunnel goes down for some reason and I'm receiving the following error message "fgfm install run script error(st=2,logsz=150,errno=0 No response from remote" Updating the device, it goes online again but with a Config Status "Conflict" Any advise please? Support Forum Fri, 04 Sep 2026 07:51:08 +0200 https://community.fortinet.com/fortiap-5/technical-tip-why-wireless-clients-does-not-connect-with-802-11ax-when-fortiap-are-managed-on-fortiedge-cloud-229778 DescriptionThis article describes an option needed to enable 802.11ax on FortiAP managed by FortiEdge Cloud.ScopeFortiAP managed by FortiEdge Cloud.SolutionTo enable 802.11ax on FortiAPs managed by FortiEdge Cloud,Verify that the High Efficiency feature is enabled on the SSID configuration.Go to Wireless -> SSID -> Edit and check if High Efficiency is enabled.This option requires an Advanced FortiAP management license. If FortiAP does not have this license, High Efficiency will not be enabled on FortiAP even if the option is enabled on FortiEdge Cloud. FortiAP Fri, 04 Sep 2026 07:48:02 +0200 https://community.fortinet.com/fortiap-5/technical-tip-why-using-hidden-ssids-is-not-a-good-practice-in-enterprise-wireless-networks-229777 DescriptionThis article describes why using a 'hidden' SSID is not considered a good practice in enterprise wireless networks.ScopeFortiAP, FortiGate as a wireless controller, Fortinet LAN Edge.SolutionIt is not considered good practice to use a 'hidden' SSID because the beacon frame is sent with an empty SSID field by the FortiAP. With a sniffer, it is possible to capture the association request from devices that are going to connect, which must include this string. These frames, by their nature, are not encrypted and can be captured easily.Additionally, this behavior is expected. In the situation of using a 'hidden' SSID, the only way clients can discover the network is to use active scanning, where the data of the 'hidden' SSID is visible. See Technical Tip: Wireless Roaming for more information.For iOS, the use of hidden networks is completely discouraged. After some time, the device marks the network as inoperative and does not attempt to connect again. It will not detect the network because the beacon does not have the visible field. This is documented by the device manufacturer. See if the Mac device does not connect to the internet over Wi-Fi and Recommended settings for Wi-Fi routers and access points for more information.Hiding the network name does not prevent it from being detected or protect it against unauthorized access. Due to the way devices search and connect to Wi-Fi networks, using a hidden network can expose information that can be used to identify users and the hidden networks used. To ensure secure access to the network, use the appropriate security settings. Also see Apple Platform Deployment Wi-Fi settings for more information.When using active scanning, all machines send probes. This behavior is worse for enterprise wireless networks because of the number of wireless clients periodically advertising the non-broadcast network name. For example, in an enterprise wireless network that consists of 20 wireless APs and 500 wireless laptops, broadcasting APs periodically advertise the enterprise wireless network name only within the range of the wireless APs. If the wireless APs are configured as non-broadcast, each of the 500 laptops periodically advertises the enterprise wireless network name, regardless of its location. It will flood the RF environment with those frames.See Non-broadcast Wireless Networks with Microsoft Windows for more information.Hidden SSIDs usually delay the network connection time and affect network roaming performance. Their use is not recommended by Fortinet TAC in enterprise networks.Consider using other security alternatives for users, such as 802.1X with WPA-Enterprise. FortiAP Fri, 04 Sep 2026 07:39:43 +0200 https://community.fortinet.com/fortimail-26/technical-tip-extending-the-fortimail-personal-quarantine-message-retention-period-beyond-14-days-229776 DescriptionThis article describes how to extend the retention period for the FortiMail Personal Quarantine beyond the default 14 days by creating a resource profile with the desired retention period and applying it through a recipient policy.ScopeFortiMail.SolutionBy default, FortiMail retains messages in the Personal Quarantine for 14 days, after which the messages are automatically deleted and can no longer be released or reviewed.The retention period is not configured directly in the personal quarantine settings. Instead, it is controlled by the resource profile associated with the recipient through a recipient policy.To extend the retention period, create a resource profile with the desired value and associate it with a recipient policy that matches the users requiring the change:Go to Profile -> Resource and select Create New to create a resource profile, or select an existing profile to edit.Configure the wanted retention period, in days, for messages in the personal quarantine, then select Create to save the resource profile:Go to Policy -> Recipient Policy and select Create New to create a recipient policy, or select an existing policy to edit.Under Sender, enter the pattern matching the users to which the extended retention period applies, for example, their email addresses, email group, or domain:Under Resource Profile, select the resource profile created in step 1.Select OK to save the recipient policy. FortiMail Fri, 04 Sep 2026 07:32:08 +0200 https://community.fortinet.com/support-forum-92/ikev2-remote-access-vpn-wrong-eap-credentials-with-fortiauthenticator-otp-225158 Hello,I currently have SSL VPN active and I want to switch to IPsec VPN (IKEv2 Remote Access).Environment:FortiGate model: FG-101FFortiOS version: 7.4.11VPN type: IKEv2 IPsec Remote AccessAuthentication: FortiAuthenticator 6.5.6 build 1391 (GA) with OTPDirectory: LDAP users and groups from Active DirectoryClient: FortiClient 7.4.3 Hotfix 1 (7.4.3.8758)I am configuring an IKEv2 IPsec remote access VPN that authenticates users via FortiAuthenticator using LDAP credentials and OTP.The VPN connection is not successfully established from FortiClient.Phase 1 (SA_INIT) completes successfully, but the connection fails during user authentication (EAP phase).FortiClient shows the following error:Wrong EAP credentialsHas anyone encountered this issue when using IKEv2 with EAP authentication and FortiAuthenticator OTP?Any suggestions or troubleshooting steps would be appreciated.Thank you. Support Forum Fri, 04 Sep 2026 04:20:59 +0200 https://community.fortinet.com/fortigate-3/troubleshooting-tip-fortigate-admin-login-page-shows-html-code-instead-of-disclaimer-message-207660 Description   This article describes an issue where the FortiGate admin pre-login page displays raw HTML code instead of rendering the 'Pre-login Disclaimer Message' as intended, despite the message format being set to HTML.   Scope   FortiGate v7.2.11, v7.4.8, v7.6.3.   Solution   When a basic HTML pre-login disclaimer is defined, the FortiGate GUI displays the raw HTML code on the login page instead of rendering the formatted message.   For example, defining the following basic HTML pre-login disclaimer causes the login page to display the raw HTML code instead of rendering it.   tau-kvm171 config system replacemsg admin pre_admin-disclaimer-text tau-kvm171 (pre_admin-discla~ext) show config system replacemsg admin "pre_admin-disclaimer-text" set buffer "<!DOCTYPE html> <html lang=\\\"en\\\"> <head> Test </head> <body> Test </body> </html>" set header http set format HTML <----- Format changed to HTML using CLI. end       config system global     set pre-login-banner enable <----- Pre-login should be enabled. end   After accessing the FortiGate, it displays the following raw HTML code:     The issue has been reported with a known issue ID 1153294 and is fixed in v7.6.4, v7.4.9. FortiGate Fri, 04 Sep 2026 01:40:25 +0200 https://community.fortinet.com/fortigate-3/technical-tip-backup-configuration-files-via-tftp-99896 DescriptionThis article describes the command to backup configuration files from the command line using a TFTP server.ScopeFortiGate.SolutionFor more information, refer to the FortiOS CLI reference guides available in the Technical Tip: Differences between FortiGate CLI commands 'execute backup config' and 'execute backup full-config'. execute backup config tftp <filename_str> <server_ipv4> <backup_password_str>] execute backup full-config tftp <filename_str> <server_ipv4> <backup_password_str>]Note:The <backup_password_str>] parameter is optional and can be skipped by pressing Enter after specifying the server IP.When choosing a backup method, use 'full-config' to include all default values for advanced audits or system rebuilds.For example, to backup the FortiGate unit system configuration to a file named fgt.cfg on a TFTP server at IP address 192.168.1.23, use the following command:execute backup config tftp fgt.cfg 192.168.1.23 Note:There is no way to set a source IP or specific interface to the backup configuration. The option is not available. FortiGate Fri, 04 Sep 2026 01:32:59 +0200 https://community.fortinet.com/support-forum-92/best-practices-to-review-configuration-and-rules-for-fortigate-firewall-and-fortiweb-195337 Hello everyone,I’m looking for the best way to review configurations and rules on FortiGate Firewall and FortiWeb. Are there any tools available for this, or benchmarks to follow?Any suggestions would be greatly appreciated!Thank you! Support Forum Fri, 04 Sep 2026 00:33:21 +0200 https://community.fortinet.com/support-forum-92/ztna-and-microsoft-conditional-access-policies-229565 Our company is transitioning from SSL-VPN to ZTNA.  We currently have Microsoft conditional acess policies allowing certain public IP addresses configured for SSL VPN allowing the public IP of the VPN firewall.  Is there anyway for this to work with ZTNA?  Currently, the microsoft logs are showing the public IP of individual users instead of the firewall.   Support Forum Thu, 03 Sep 2026 20:07:40 +0200 https://community.fortinet.com/fortigate-3/troubleshooting-tip-dhcp-status-removed-due-to-conflict-137169 Description This article describes the background of DHCP message exchange and explains the root cause of the DHCP status 'Removed due to conflict'. Scope FortiGate. Solution After completing the DORA process and obtaining the IP address from the DHCP server, the client will perform an ARP probe to verify that no other devices are using the IP address before the probe begins. If an ARP probe receives an ARP response for the same IP address allocated by the DHCP server, the client will send a DHCP decline message to the DHCP server and request a new IP.   When a FortiGate receives a DHCPDECLINE from a specific MAC address for a leased IP, it will deduce that the IP is a duplicate and is in use on the network. FortiGate will store the IP information as 'Removed due to conflict' in the GUI.   For example: Consider a network where a device is configured with 10.0.0.3 as the client IP address. The same IP address falls under the DHCP IP range. FortiGate Config:   config system dhcp server     edit 2         set dns-service default         set default-gateway 10.0.0.1         set netmask 255.255.255.248         set interface "port2"             config ip-range                 edit 1                     set start-ip 10.0.0.2                     set end-ip 10.0.0.6                 next             end     next end   When a client requests the DHCP IP, FortiGate will lease the next available IP from the IP range.   diagnose debug reset diagnose debug application dhcps -1 diagnose debug enable   To stop the debug, run the following commands:    diagnose debug disable diagnose debug reset   0.0.0.0 255.255.255.255 ff:ff:ff:ff:ff:ff 50:1a:45:00:07:00 DHCP Discover - Transaction ID 0x2761267 Debug : DHCPDISCOVER from 50:1a:45:00:07:00 via port2(ethernet) [debug]found a new lease of ip 10.0.0.3 <-------- [debug]added ip 10.0.0.3 mac 50:1a:45:00:07:00 in vd root [debug]packet length 300 [debug]op = 1 htype = 1 hlen = 6 hops = 0 [debug]xid = 67127602 secs = 28 flags = 0 [debug]ciaddr = 0.0.0.0 [debug]yiaddr = 0.0.0.0 [debug]siaddr = 0.0.0.0 [debug]giaddr = 0.0.0.0 [debug]chaddr = 50:1a:45:00:07:00 [debug]filename = [debug]server_name = [debug] host-name = "UNL" [debug] dhcp-message-type = 1 [debug] dhcp-parameter-request-list = 1,15,3,6,44,46,47,31,33,121,249,43 [debug] dhcp-class-identifier = "MSFT 5.0" [debug] dhcp-client-identifier = 1:50:1a:45:0:7:0   A DHCP Offer is sent to the client:   10.0.0.1 10.0.0.3 50:1a:45:00:07:00 50:23:99:00:03:01 DHCP Offer - Transaction ID 0x2761267   DHCPOFFER on 10.0.0.3 to 50:1a:45:00:07:00 via port2(ethernet) [debug]sending on port2(ethernet) [debug]sending using lpf_dhcpd_send_packet [debug]locate_network prhtype(1) pihtype(1) [debug]find_lease(): packet contains preferred client IP, cip.s_addr is 10.0.0.3 [debug]find_lease(): leaving function with lease set [debug]find_lease(): the lease's IP is 10.0.0.3   Followed by a DHCP request from the client and a DHCP ack from FortiGate:   0.0.0.0 255.255.255.255 ff:ff:ff:ff:ff:ff 50:1a:45:00:07:00 DHCP Request - Transaction ID 0x2761267 10.0.0.1 10.0.0.3 50:1a:45:00:07:00 50:23:99:00:03:01 DHCP ACK - Transaction ID 0x2761267   DHCPREQUEST for 10.0.0.3 from 50:1a:45:00:07:00 via port2(ethernet) [debug]deled ip 10.0.0.3 mac 50:1a:45:00:07:00 in vd root [debug]added ip 10.0.0.3 mac 50:1a:45:00:07:00 in vd root [debug]packet length 302 [debug]op = 1 htype = 1 hlen = 6 hops = 0 [debug]xid = 67127602 secs = 28 flags = 0 [debug]ciaddr = 0.0.0.0 [debug]yiaddr = 0.0.0.0 [debug]siaddr = 0.0.0.0 [debug]giaddr = 0.0.0.0 [debug]chaddr = 50:1a:45:00:07:00 [debug]filename = [debug]server_name = [debug] host-name = "UNL" [debug] dhcp-requested-address = 10.0.0.3 [debug] dhcp-message-type = 3 [debug] dhcp-server-identifier = 10.0.0.1 [debug] dhcp-parameter-request-list = 1,15,3,6,44,46,47,31,33,121,249,43 [debug] dhcp-class-identifier = "MSFT 5.0" [debug] dhcp-client-identifier = 1:50:1a:45:0:7:0 [debug] option-81 = 0:0:0:55:4e:4c [debug] DHCPACK on 10.0.0.3 to 50:1a:45:00:07:00 via port2(ethernet) [debug]sending on port2(ethernet)   Once the client completes the DHCP DORA process, it will send an ARP probe to identify any duplicate IPs in the same broadcast network.   50:1a:45:00:07:00 Broadcast ff:ff:ff:ff:ff:ff 50:1a:45:00:07:00 Who has 10.0.0.3? (ARP Probe)   The IP will be assigned to its interface if it does not receive a response. If there is an ARP response, the DHCP client will send the DHCPDECLINE message to the server, notifying it of the IP conflict.   50:fc:cf:00:0b:00 50:1a:45:00:07:00 50:1a:45:00:07:00 50:fc:cf:00:0b:00 10.0.0.3 is at 50:fc:cf:00:0b:00 (duplicate use of 10.0.0.3 detected!)   0.0.0.0 255.255.255.255 ff:ff:ff:ff:ff:ff 50:1a:45:00:07:00 DHCP Decline - Transaction ID 0x2761267     FortiGate debug:   DHCPDECLINE on 10.0.0.3 from 50:1a:45:00:07:00 via port2(ethernet)  <---- [warn]Abandoning IP address 10.0.0.3: declined. [debug]deled ip 10.0.0.3 mac 50:1a:45:00:07:00 in vd root [debug]locate_network prhtype(1) pihtype(1) [debug]find_lease(): leaving function WITHOUT a lease DHCPDISCOVER from 50:1a:45:00:07:00 via port2(ethernet) [debug]found a new lease of ip 10.0.0.4 [debug]added ip 10.0.0.4 mac 50:1a:45:00:07:00 in vd root   At this point, FortiGate learns that the leased IP 10.0.0.3 has a conflict and adds the IP to the list of conflicted leases. The same IP will not be leased to any other client until the expiry time.   execute dhcp lease-list port2 IP MAC-Address Hostname VCI SSID AP SERVER-ID Expiry 10.0.0.4 50:1a:45:00:07:00 UNL MSFT 5.0 2 Mon Jun 19 07:19:45 2023 port2 [Conflicted leases] IP Expiry 10.0.0.2 Mon Jun 12 07:49:15 2023 10.0.0.3 Mon Jun 12 07:49:33 2023     Another scenario:  FortiGate can send an ICMP echo-request to the IP address before it provides the DHCPOFFER to the client. If FortiGate receives an ICMP echo-reply from the IP address, it will abandon that IP address and then store the IP information as 'Removed due to conflict' in the GUI.    Below, FortiGate debug shows when the client behind FortiGate port1 requests an IP address.  FortiGate enables the DHCP server on the port1 interface 192.168.180.1/24.   Note: When using a docking station, failures in the docking station's MAC Address Pass-Through (MAPT) feature may cause the router to misidentify the dock as a separate or duplicate hardware entity. If the dock's Ethernet controller fails to relay the host's unique MAC address, the network may incorrectly flag the connection as a new device or generate a conflict. Remove the docking station to test it.   FortiGate debug:   DHCPDISCOVER from 00:45:6e:64:52:02 via port1(ethernet) [debug]found a new lease of ip 192.168.180.4 [debug]added ip 192.168.180.4 mac 00:45:6e:64:52:02 in vd root [debug]packet length 302 [debug]op = 1 htype = 1 hlen = 6 hops = 0 [debug]xid = afd7d97d secs = 0 flags = 0 [debug]ciaddr = 0.0.0.0 [debug]yiaddr = 0.0.0.0 [debug]siaddr = 0.0.0.0 [debug]giaddr = 0.0.0.0 [debug]chaddr = 00:45:6e:64:52:02 [debug]filename = [debug]server_name = [debug] host-name = "DESKTOP-OLGFQ84" [debug] dhcp-requested-address = 192.168.180.6 [debug] dhcp-message-type = 1 [debug] dhcp-parameter-request-list = 1,3,6,15,31,33,43,44,46,47,119,121,249,252 [debug] dhcp-class-identifier = "MSFT 5.0" [debug] dhcp-client-identifier = 1:0:45:6e:64:52:2 [debug] [pkt]000: 01 01 06 00 7d d9 d7 af 00 00 00 00 00 00 00 00 [pkt]010: 00 00 00 00 00 00 00 00 00 00 00 00 00 45 6e 64 [pkt]020: 52 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [pkt]030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [pkt]040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [pkt]050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [pkt]060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [pkt]070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [pkt]080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [pkt]090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [pkt]0a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [pkt]0b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [pkt]0c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [pkt]0d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [pkt]0e0: 00 00 00 00 00 00 00 00 00 00 00 00 63 82 53 63 [pkt]0f0: 35 01 01 3d 07 01 00 45 6e 64 52 02 32 04 c0 a8 [pkt]100: b4 06 0c 0f 44 45 53 4b 54 4f 50 2d 4f 4c 47 46 [pkt]110: 51 38 34 3c 08 4d 53 46 54 20 35 2e 30 37 0e 01 [pkt]120: 03 06 0f 1f 21 2b 2c 2e 2f 77 79 f9 fc ff [debug]Sending ICMP echo-request to 192.168.180.4 [debug]Received ICMP echo-reply from 192.168.180.4 [warn]Abandoning IP address 192.168.180.4: pinged before offer [debug]deled ip 192.168.180.4 mac 00:45:6e:64:52:02 in vd root   Note: In some cases, docking stations have been reported to cause DHCP IP address conflicts if the laptop is misconfigured or if the docking station has an issue. When troubleshooting a DHCP conflict, verify if the issue still occurs with a device not connected to a docking station. To isolate or rule out a firewall issue in this case, collect ARP, ICMP, and DHCP packet captures, as well as dhcps debug logs.   If an IP pool is configured with the ARP reply option enabled, it may cause an IP address assignment conflict. This can occur because, during the DHCP offer process, when the ping check is performed, the FortiGate itself responds to the ping.     Starting version v7.6, a new feature called 'ip-conflict-detect' has been introduced:   config system global       set ip-conflict-detection enable end   If IP conflict is detected, the FortiGate will generate a log at Log&Report -> System Events -> General System Events.   This feature allows the FortiGate to monitor the network continuously via ARP (IPv4) and NDP (IPv6) to identify any device, not just DHCP clients, that might be 'stealing' or duplicating an IP address already assigned to an interface.   Related article: Technical Tip: Understanding DHCP Server and DHCP Relay functionality on FortiGate FortiGate Thu, 03 Sep 2026 19:36:27 +0200 https://community.fortinet.com/support-forum-92/fortigate-8-0-0-remote-vpn-using-cert-eap-229729 I’ve been straining my brain for weeks on this. It seems like it should be so simple. Is anyone aware of any bugs with Remote IPSEC VPN and 8.0? I have followed this documentation but i’m obviously missing something. I’m attempting to use the Forticlient cert (i was doing my internal pki, but found to check EMS tags i needed to present the EMS cert) and i keep getting hung up here: 1742] fnbamd_auth_session_done-Session done, id=8498898576601171209] __fnbamd_cert_auth_run-Exit, req_id=8498898576601171785] create_auth_cert_session-fnbamd_cert_auth_init returns 0, id=8498898576601171698] auth_cert_success-id=8498898576601171321] fnbamd_cert_auth_copy_cert_status-req_id=8498898576601171329] fnbamd_cert_auth_copy_cert_status-Matched peer user 'Remote-Employee_peer'_1458] fnbamd_cert_auth_copy_cert_status-Cert st 210, req_id=849889857660117356] fnbamd_comm_send_result-Sending result 0 (nid 672) for req 84988985766011, len=2776n360] fnbamd_comm_send_result-Failed send reply (2788, errno 101)o1567] destroy_auth_cert_session-id=8498898576601172047] handle_child_rsp-Auth rsp 84988985766011, session not created, line 76i1293] fnbamd_cert_auth_uninit-req_id=8498898576601171996] fnbamd_ldaps_destroy-s1667] fnbamd_rads_destroy- All the cert checks and EMS checks above are fine, but it fails here every time. Wondering if someone here can help  Support Forum Thu, 03 Sep 2026 19:30:58 +0200 https://community.fortinet.com/support-forum-92/version-7-0-12-pour-gns-3-229706 Bonjour,Impossible de charger une licence d’essai dans GNS 3 au dessus de la version 7.0.12, apparemment Forti ne laisse plus faire.Est-ce que quelqu’un aurait cette image FGT_VM64_KVM-v7.0.12.M-build0523-FORTINET.out.kvm.qcow2 ou une version inférieure ?Merci de votre réponseMike.  Support Forum Thu, 03 Sep 2026 19:23:21 +0200 https://community.fortinet.com/support-forum-92/how-to-export-policies-to-excel-229348 Hi AllI would like to know if there is a method to export FGT Policies into Excel (csv) format.Please advise any available options. Am using FortiOS v7.4.12 Many thanks Support Forum Thu, 03 Sep 2026 17:54:34 +0200 https://community.fortinet.com/fortigate-3/troubleshooting-tip-unable-to-access-the-fortigate-gui-after-changing-its-interface-ip-address-229773 DescriptionThis article describes a scenario where access to the FortiGate GUI is lost after changing the IP address of an interface while the FortiGate is configured as a DHCP server.ScopeFortiGate.SolutionIn this example, user accesses the FortiGate GUI on port3 at 192.168.10.1/24 and port3 has DHCP server enabled.After changing the IP address of port3 to 192.168.11.1, GUI access became unavailable.This occurs because the IP address of port3 was changed, but the DHCP address range was not updated accordingly. As a result, client devices continue to receive IP addresses from the 192.168.10.0/24 subnet, while the FortiGate interface now uses the 192.168.11.0/24 subnet, preventing communication with the GUI.To resolve the issue in the CLI:Use the following command to find which entry belongs to port3. In this case, it is entry #2.config system dhcp server show | grep port3 -f config system dhcp server edit 2 set dns-service default set default-gateway 192.168.11.1 set netmask 255.255.255.0 set interface "port3" config ip-range edit 1 set start-ip 192.168.10.2 set end-ip 192.168.10.254 next end next endAfter knowing the entry number, run the following commands to update the DHCP address range(scope).edit 2 config ip-range edit 1 set start-ip 192.168.11.2 set end-ip 192.168.11.254 next end nextTo resolve the issue on the GUI (if it is possible to access via a different interface):Go to Network -> Interfaces and edit port3.Update the DHCP address range (scope) accordingly.Renew the DHCP lease on the client by running the following command in the Command Prompt of the client.ipconfig /renewVerify that the client has obtained the new IP address by running the command.ipconfigAfter that, the GUI will be accessible again on port3.Related articles:Troubleshooting Tip: Cannot access the FortiGate web admin interface (GUI)Technical Tip: Initial troubleshooting for GUI or CLI access issue FortiGate Thu, 03 Sep 2026 17:19:54 +0200 https://community.fortinet.com/fortigate-3/troubleshooting-tip-troubleshooting-inline-casb-229772 DescriptionThis article describes how to troubleshoot an inline CASB security profile, verify that the expected user action is applied and use WAD debug output to inspect HTTP headers and CASB policy processing.ScopeFortiGate.SolutionThis article assumes that an inline CASB profile, proxy-based inspection, and a full SSL inspection profile are configured. For configuring inline CASB and example configuration see: Inline CASB.In this example, the SaaS application Gmail is configured with the user activity upload-local-file configured to block.The purpose of this user activity is to block file attachments to Gmail emails. The result should show that the file attachment failed.If the file is not being blocked, first check the Inline CASB security event logs. This can be found in the FortiOS GUI under Log & report -> Security Events -> Inline-CASB. Check that the correct action is taken.GUI log example:Raw log example:date=2026-09-02 time=07:31:40 eventtime=1788359500503486416 tz="-0700" logid="2500010000" type="utm" subtype="casb" eventtype="casb" level="warning" vd="root" policyid=1 poluuid="cd238d58-a0c2-51f1-df58-6e00ebbb4bfc" policytype="policy" sessionid=4856 srcip=10.104.0.100 dstip=142.250.137.18 srcport=60524 dstport=443 srcintf="port2" srcintfrole="undefined" srcuuid="92bdd804-a085-51f1-e751-7ef8f6cc624f" dstintf="port1" dstintfrole="undefined" dstuuid="92bdd804-a085-51f1-e751-7ef8f6cc624f" proto=6 url="https://mail.google.com/_/upload?authuser=0&dcp=asu-n" action="block" profile="Google" saasapp="google-gmail" useractivity="google-gmail-upload-local-file" activitycategory="activity-control" msg="CASB access was blocked because it contained banned activity."The log shows that the action was 'block', the URL was 'https://mail.google.com/_/upload?authuser=0&dcp=asu-n', the SaaS application was 'google-gmail', the specific user activity was 'google-gmail-upload-local-file', and the reason for the block was 'CASB access was blocked because it contained banned activity'.If no log is generated or an unexpected action is applied, collect WAD debug output to review how the SaaS application is identified and processed by CASB.To run the WAD debug (replace x.x.x.x with the source IP of the test client):diagnose debug console timestamp enable diagnose wad debug enable category http diagnose wad debug enable category casb diagnose wad debug display pid enable diagnose wad debug enable level verbose diagnose wad filter src x.x.x.x diagnose wad debug show diagnose wad filter list diagnose debug enableTo stop debugging:diagnose wad debug clear diagnose wad filter clear diagnose debug disable diagnose debug resetTo verify the HTTP POST request headers in the WAD debug output, review entries similar to the partial example shown below:POST /_/upload?authuser=0&dcp=asu-n HTTP/1.1 Host: mail.google.com content-length: 80 sec-ch-ua-full-version-list: "Not=A?Brand";v="99.0.0.0", "Google Chrome";v="151.0.7922.174", "Chromium";v="151.0.7922.174" sec-ch-ua-platform: "Windows" sec-ch-ua: "Not=A?Brand";v="99", "Google Chrome";v="151", "Chromium";v="151" sec-ch-ua-bitness: "64" sec-ch-ua-model: "" sec-ch-ua-mobile: ?0 sec-ch-ua-form-factors: "Desktop" sec-ch-ua-wow64: ?0 x-goog-upload-protocol: resumable sec-ch-ua-arch: "x86" x-goog-upload-file-name: upload-test.txt sec-ch-ua-full-version: "151.0.7922.174" content-type: application/x-www-form-urlencoded;charset=UTF-8 x-goog-upload-header-content-type: text/plain x-goog-upload-header-content-length: 22 x-goog-metadata-proto-format: b user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/151.0.0.0 Safari/537.36 x-goog-upload-command: start sec-ch-ua-platform-version: "15.0.0" accept: */* origin: https://mail.google.com x-browser-channel: stable x-browser-year: 2026 x-browser-validation: 1np4czHTgmmEnZuHzsr7dj6pNow= x-browser-copyright: Copyright 2026 Google LLC. All Rights Reserved. x-client-data: CKmdygEIk6HLAQiFoM0BCK3flDAI7d+UMAiX4pQwGKnYlDAYqN6UMBis35Qw sec-fetch-site: same-origin sec-fetch-mode: cors sec-fetch-dest: empty referer: https://mail.google.com/mail/u/0/?service=mail&flowName=GlifWebSignIn&flowEntry=AccountChooser&ec=asw-gmail-globalnav-signin The example shows that the host is 'mail.gmail.com', the POST request is '/_/upload?authuser=0&dcp=asu-n HTTP/1.1', and the filename is 'upload-test.txt'.Check how WAD processed this HTTP post:[v]2026-09-02 07:31:40.503079 [p:2146][r:766] wad_http_marker_uri :1270 path=/_/upload len=9 [v]2026-09-02 07:31:40.503092 [p:2146][r:766] wad_http_parse_host :1649 host_len=15 2026-09-02 07:31:40.503101 [p:2146][r:766] wad_http_parse_host :1681 host=[15]mail.google.com 2026-09-02 07:31:40.503113 [p:2146][r:766] wad_http_str_canonicalize :2196 enc=0 path=/_/upload len=9 changes=0 2026-09-02 07:31:40.503122 [p:2146][r:766] wad_http_str_canonicalize :2198 end=4 path=authuser=0&dcp=asu-n len=20 changes=0 [v]2026-09-02 07:31:40.503130 [p:2146][r:766] wad_http_normalize_uri :2570 host_len=15 path_len=9 query_len=20 2026-09-02 07:31:40.503141 [p:2146][r:766] wad_http_req_detect_special :16175 captive_portal detected: false, preflight=(null) [v]2026-09-02 07:31:40.503152 [p:2146][r:766] wad_http_req_exec_act :14651 dst_addr_type=1 wc_nontp=0 sec_web=1 web_cache=0 req_bypass=1 2026-09-02 07:31:40.503230 [p:2146][r:766] wad_http_srv_attach_req :841 [0x7fb9f440f308] Use old server0x7fb9f41288f8: :0 [v]2026-09-02 07:31:40.503241 [p:2146][r:766] wad_http_req_get_svr :9548 http session 0x7fb9f4bdbf98 req=0x7fb9f440f308 connected [v]2026-09-02 07:31:40.503250 [p:2146][r:766] wad_http_msg_start_setup_proc :2251 msg(0x7fb9f440f308) proc-setup started from: req_casb. [v]2026-09-02 07:31:40.503258 [p:2146][r:766] wad_http_def_proc_msg_plan :2213 msg(0x7fb9f440f308) setting up processor(req_casb) [v]2026-09-02 07:31:40.503275 [p:2146][r:766] wad_casb_profile_match_app_by_host:1058 Hit casb_app:0x7fb9efa9ed70 name:google-gmail [v]2026-09-02 07:31:40.503285 [p:2146][r:766] wad_http_casb_proc_alloc :50 casb:0x7fb9f4eca0f0 added msg:0x7fb9f440f308 2026-09-02 07:31:40.503295 [p:2146][r:766] wad_http_req_setup_casb :169 casb_proc:0x7fb9f4eca0f0 added, profile:Google [v]2026-09-02 07:31:40.503303 [p:2146][r:766] wad_casb_prof_app_proc_header :991 App:google-gmail is processing msg:0x7fb9f440f308 header. [v]2026-09-02 07:31:40.503321 [p:2146][r:766] wad_casb_str_matcher_substr_match :380 Substr matched: "/_/upload?authuser=0&dcp=asu-n" 2026-09-02 07:31:40.503330 [p:2146][r:766] wad_casb_ua_take_action :884 App:google-gmail UA:google-gmail-upload-local-file is taking action: block. 2026-09-02 07:31:40.503340 [p:2146][r:766] __wad_http_build_replmsg_resp :789 Generating replacement message. Google repmsg_id 94 2026-09-02 07:31:40.503458 [p:2146][r:766] wad_casb_ua_take_action :899 App:google-gmail UA:google-gmail-upload-local-file action_result:done 2026-09-02 07:31:40.503470 [p:2146][r:766] wad_http_parse_referer_hline :4181 referer_len 124 2026-09-02 07:31:40.503739 [p:2146][r:766] wad_http_req_proc_drain_body_for_forged_resp:9262 req(0x7fb9f440f308) resp(0x7fb9f4d4bce8) [v]2026-09-02 07:31:40.503753 [p:2146][r:766] wad_http_msg_start_setup_proc :2251 msg(0x7fb9f4d4bce8) proc-setup started from: resp_forward. [v]2026-09-02 07:31:40.503761 [p:2146][r:766] wad_http_def_proc_msg_plan :2213 msg(0x7fb9f4d4bce8) setting up processor(resp_forward) 2026-09-02 07:31:40.503769 [p:2146][r:766] wad_dump_fwd_http_resp :2932 hreq=0x7fb9f440f308 Forward response from Internal: HTTP/1.1 403 Forbidden Content-Type: text/html Cache-Control: no-cache X-Frame-Options: SAMEORIGIN X-XSS-Protection: 1; mode=block X-Content-Type-Options: nosniff Content-Security-Policy: frame-ancestors 'self' Content-Length: 35086The following lines show the request for CASB processing and that the googl-gmail SaaS application was matched:wad_casb_profile_match_app_by_host:1058 Hit casb_app:0x7fb9efa9ed70 name:google-gmail wad_http_casb_proc_alloc :50 casb:0x7fb9f4eca0f0 added msg:0x7fb9f440f308 wad_http_req_setup_casb :169 casb_proc:0x7fb9f4eca0f0 added, profile:GoogleThe HTTP header is being processed:wad_casb_prof_app_proc_header :991 App:google-gmail is processing msg:0x7fb9f440f308 header. wad_casb_str_matcher_substr_match :380 Substr matched: "/_/upload?authuser=0&dcp=asu-nThe action taken was block and a replacement message was generated:wad_casb_ua_take_action :884 App:google-gmail UA:google-gmail-upload-local-file is taking action: block. __wad_http_build_replmsg_resp :789 Generating replacement message. Google repmsg_id 94 wad_casb_ua_take_action :899 App:google-gmail UA:google-gmail-upload-local-file action_result:doneRelated articles:Troubleshooting Tip: How to enable InLine-CASB on FortiGateTechnical Tip: Using the 'diagnose wad debug' command to troubleshoot Explicit Web Proxy related issuesTroubleshooting Tip: Example of WAD debugging for Explicit ProxyTroubleshooting Tip: WAD troubleshooting commandsTroubleshooting Tip: Reasons why WAD debugs might not show any output in the FortiGate CLI FortiGate Thu, 03 Sep 2026 16:19:35 +0200 https://community.fortinet.com/support-forum-92/fortinac-ad-user-cannot-override-itself-if-created-by-radius-229727 HI FNAC adminsFortiNAC-F 7.2.9.I have this scenario:A new AD users (not added to FNAC yet) connects to SSID managed by FNAC from a client having NAC agent FNAC adds it automatically to user DB (created from RADIUS connection) , and it adds it not as “Loaded from Directory”, but just like local user, and remains the same even after AD sync As it didn’t add it as “Loaded from Directory” it doesn’t match my UHP neither my access policy, so it is dropped in isolation So I have to remove the user manually and let it created by LDAP automatically after sometimeMy question:Is there a way to force AD user override existing user created from RADIUS connection Otherwise is there a way just to preload all ad users to FNAC user DB even before any user connects Or any other flexible/automatic solution Support Forum Thu, 03 Sep 2026 15:00:16 +0200 https://community.fortinet.com/support-forum-92/mailfilterd-stuck-at-100-cpu-229770 ​mailfilterd stuck at ~100% CPU, FortiMail 8.0.0 build 183 — cause unclearFortiMail 8.0.0 build 183. mailfilterd sits at ~99.8% CPU continuously (not a spike), RSS grown to ~1.5GB (baseline is usually ~100MB). All other processes idle. Session count (24–50) and bandwidth are normal, so it's not a traffic flood.Enabled diagnose debug application mailfilterd level 8 + duration 30 and pulled the Trace Log. The only thing logged for 10 minutes was:FmailAIClient.cpp:931:ping():entryrepeating once a minute, on a single thread, with no other activity captured — looks like a routine heartbeat, not the actual hot path.I can't figure out what's actually causing the 100% CPU. Any help would be appreciated. Support Forum Thu, 03 Sep 2026 14:26:01 +0200 https://community.fortinet.com/fortigate-3/technical-tip-fortigate-dns-does-not-show-status-ms-state-and-not-dns-resolution-229733 DescriptionThis article describes how to solve the issue when the FortiGate does not show any status at the 'ms' (milliseconds) level, and there is also no DNS resolution.ScopeFortiGate system.SolutionThere are scenarios where the FortiGate does not show any DNS status or 'ms', and the resolution does not work at all. This could be an issue with the daemon at the kernel level that does not initialize correctly. In order to check if the daemon/process is fine, do the following:Check if, after changing the IPs over the DNS and also the protocols, the status is not shown and the screen is white all the time Go to Network -> DNS and check if there is no status. Expected status/MS even in an 'unreachable' state means the DNS daemon is up and running: Also, if checking the process when searching for 'DNS', the process is not there, which means that the process/daemon is not initialized, and because of that, the DNS will never work. In order to solve this issue, a reboot of the FortiGate will be needed in order to initialize the process. A KILL or restart of the process will not work because the process never started in the first place. After doing the reboot, the DNS will start fine and will show the status/MS, and also the resolution will work again. FortiGate Thu, 03 Sep 2026 13:53:02 +0200 https://community.fortinet.com/support-forum-92/forticlient-ems-restrict-vpn-access-based-on-client-public-ip-location-229769 Hi Team,We currently restrict our FortiGate SSL VPN access to users connecting from the UAE region using GeoIP restrictions.However, some vendors are based in Egypt and may RDP into their office PC located in the UAE, and then establish the FortiClient VPN connection from that UAE PC.Is there a way to configure FortiClient EMS to restrict VPN access based on the client’s public IP or location, so that if the actual client is connecting from outside the UAE, the VPN connection is denied?Any recommended configuration or best practice would be appreciated. Support Forum Thu, 03 Sep 2026 13:48:13 +0200 https://community.fortinet.com/support-forum-92/fap-231g-performance-issues-with-30-clients-client-drops-and-roaming-to-distant-aps-229762 Hi Community,I’m experiencing performance issues with FortiAP FAP-231G and would appreciate some advice from anyone who has deployed this model in a high-density environment.When the AP has more than approximately 30 clients connected, especially during Microsoft Teams meetings, I experience the following: Some clients are unexpectedly disconnected from the FAP-231G. Clients are sometimes forced to roam/reconnect to a much farther AP, even though the FAP-231G appears to have good signal strength. The issue is more noticeable during Teams meetings and other traffic-intensive activities. With fewer clients, the AP appears to perform normally.I would like to understand whether this could be related to FAP-231G capacity, radio configuration, client load balancing, roaming thresholds, airtime utilization, or FortiAP/FortiGate configuration.My environment is using FortiGate-managed FortiAPs.Has anyone experienced similar behavior with the FAP-231G? If so:1. What is the recommended number of concurrent clients per FAP-231G in a typical office environment?2. Are there specific 5 GHz/6 GHz, channel width, transmit power, minimum RSSI, or roaming settings that you recommend?3. Could Client Load Balancing, Band Steering, 802.11k/v/r, or Radio Resource Provisioning cause clients to move to a distant AP?4. Are there any known issues or recommended FortiAP firmware versions for this behavior?5. What diagnostics or CLI commands should I collect to determine whether the AP is reaching a capacity or airtime limitation?Any recommendations on how to troubleshoot this would be greatly appreciated.FortiAP: FAP-231GManagement: FortiGateObserved client count: 30+ clientsMain application affected: Microsoft Teams meetingsMain symptoms: Client disconnections and roaming/reconnecting to distant APs  Support Forum Thu, 03 Sep 2026 12:32:16 +0200 https://community.fortinet.com/support-forum-92/fortinac-7-6-5-is-it-possible-to-limit-self-registered-guests-to-1-hour-of-internet-access-per-day-229767 I am using FortiNAC-CA / FortiNAC-OS v7.6.5.0815 (GA) together with a FortiGate and I would like to implement a daily Internet usage limit for self-registered guest users.My requirement is:Guest connects to the Guest Wi-Fi. Guest self-registers through the FortiNAC captive portal. After successful authentication, the guest receives Internet access. The guest is allowed a maximum of 1 hour of Internet access per day. After the 1 hour is consumed, Internet access should be blocked automatically. The guest should not be able to regain access by disconnecting/reconnecting or registering again. After the daily 24-hour reset, the same user/device should receive another 1 hour of access. Ideally, the limitation should be based on the user or device/MAC address, so creating another self-registration session does not bypass the limit.I understand that FortiNAC has Account Duration and Reauth Period, but from the documentation it appears that Account Duration is not a recurring daily quota. For example, FortiNAC states that Account Duration starts when the self-registered guest first logs in and can provide one continuous period of access.My question is:Can this "1 hour per day per user/device" requirement be implemented natively using FortiNAC 7.6.5 and FortiGate?If yes, could someone provide the recommended configuration/design, particularly:FortiNAC Guest Self-Registration Template settings Reauth Period / Account Duration settings FortiNAC Network Access Policy FortiGate firewall configuration How to track the 1-hour daily usage How to prevent users from bypassing the limit by reconnecting or self-registering again How the 24-hour usage counter/reset should be implementedIf it is not supported natively, is there a recommended Fortinet solution using FortiGate, FortiNAC, RADIUS?Any configuration examples or recommended architecture would be greatly appreciated.Thank you. Support Forum Thu, 03 Sep 2026 11:59:46 +0200 https://community.fortinet.com/fortigate-3/troubleshooting-tip-troubleshooting-fortigate-interfaces-remaining-physically-down-np7lite-g-series-229766 DescriptionThis article describes troubleshooting steps when multiple FortiGate interfaces remain physically down and are unable to establish a physical link. NP7Lite-related errors may also be seen during system startup.ScopeFortiGate.SolutionThe NP7Lite-related errors may be seen in the console output during system startup or while the FortiGate is running:NP7LITE_ERR(2026/08/19 10:20:44.642197109 np7lite_hw_mii_cmd:506) :data0 = ffff, phy = 0b, op = 0, cmd = 8031, data = 0000 0000 0000 0000 0000 NP7LITE_ERR(2026/08/19 10:20:44.793448498 np7lite_hw_mii_cmd:506) : data0 = ffff, phy = 09, op = 0, cmd = 8031, data = 0000 0000 0000 0000 0000Follow the steps below to collect the information needed for further troubleshooting:When this behavior occurs, multiple interfaces may remain physically down even when they are administratively enabled.Check the status of the interfaces:diagnose hardware deviceinfo nic <interface_name>Check the system crash log:diagnose debug crashlog readFor FortiGate models using NP7Lite, collect the following outputs:diagnose npu np7lite serdes-status fnsysctl cat /proc/net/np7lite/platform fnsysctl cat /proc/net/np7lite/np7lite_0/x1-log fnsysctl cat /proc/net/np7lite/np7lite_0/x2-logIt is also recommended to collect the console output during system startup if NP7Lite-related errors are displayed.If the interfaces continue to remain physically down, open a ticket with Fortinet TAC Support and provide the logs from this article. See Customer Service Tip: How to create a ticket for Fortinet TAC.TAC will review the information and advise on the appropriate next steps.(If TAC engineer requests this) If the interfaces stay physically down after reboot and the NP7Lite errors continue, back up the config file and proceed with formatting and firmware reload using TFTP. See Technical Tip: Formatting and loading FortiGate firmware image using TFTP.Important: Formatting the FortiGate resets the unit to factory default settings. Make sure the configuration is backed up before this.After reinstalling the firmware, test the FortiGate before restoring the previous configuration.Check whether:The physical interfaces comes up normally.The np7lite_hw_serdes_check error is still present during boot.The NP7Lite logs continue to report initialization errors.The same interfaces remain physically down.If the behavior persists after a firmware installation without restoring the configuration, submit the same collected logs in a new TAC ticket report. FortiGate Thu, 03 Sep 2026 11:36:41 +0200 https://community.fortinet.com/fortigate-3/troubleshooting-tip-isdb-empty-after-upgrade-and-unable-to-update-170243   Description This article describes how to resolve an issue that occurs in some cases after an upgrade between major versions of FortiOS, where the ISDB database may have no entries and may fail to update due to possible corruption in the package. Scope FortiOS v6.0 to v6.4.  Solution On FortiOS 6v.2.11 and above, or v6.4.10 and above, the Internet-service database selected to be downloaded and installed is chosen by FortiOS based on the hardware platform and type and cannot be changed.   The following errors can be seen in updated debug when attempting an update (exec update-now):   [473] __parse_sig_data: Unrecognized digital signature.installUpdateObject[310]-Signature verified for obj 31, ret=0, data_len=9160864, obj_len=9160864, sig_len=0.installUpdateObject[346]-Step 2:Prepare temp file for obj 31installUpdateObject[440]-Failed validation of obj 31doInstallUpdatePackage[1019]-Full obj found for ALCI000doInstallUpdatePackage[1029]-Updating obj ALCI...............upd_act_update[553]-won't retry due to install errordo_update[518]-UPDATE failed   A reboot should be attempted before trying the following. In case a reboot does not help, removing and manually updating the ISDB package may be required:   diagnose internet-service clear /data2/ffdb_appdiagnose internet-service clear /data2/ffdb_map execute update-now   If the reboot or clearing of the ISDB package does not solve the issue, check the internet service database being used. If 'Full Database' is present, change it to 'Mini' by using the following command:   config system global     set internet-service-database mini end Perform the manual update by using the command :     execute update-now   After a successful update, revert the changes to the 'Full' database by using the following command:   config system global     set internet-service-database full end FortiGate Thu, 03 Sep 2026 11:11:23 +0200 https://community.fortinet.com/fortimail-26/troubleshooting-tip-troubleshooting-error-reject-empty-domains-check-sender-domain-is-empty-229764 DescriptionThis article describes how to troubleshoot the error ‘Reject empty domains check: Sender domain is empty.’ScopeFortiMail.SolutionFortiMail history logs show an email rejected with the status Session Domain, caused by an empty sender domain.This occurs when the 'Reject empty domain' setting is enabled within the assigned Session Profile. Under this policy, FortiMail automatically rejects incoming mail if the SMTP envelope (MAIL FROM:) or the initial HELO/EHLO greeting is empty.In the log example above, the rejection was triggered specifically because the SMTP envelope (MAIL FROM:) address was empty. FortiMail Thu, 03 Sep 2026 10:03:58 +0200 https://community.fortinet.com/fortigate-3/technical-tip-recommended-release-for-fortios-116639 DescriptionThis article exists to help users determine the most appropriate software release for FortiOS. The recommendations stated below are the latest as of June 2026 and are reviewed and updated every quarter.The information in this document is not meant to be exhaustive and is intended to serve as general guidance to customers, especially in cases of mass deployments/upgrades. When working with Fortinet SEs, Professional Services, or TAC: it is important to refer to their specific guidance.An additional information section has been added to the bottom of this article for answers to common questions.Subscribe to the RSS feed by selecting the three-dotted menu button to keep up to date on the latest changes to this article (note that this feature is temporarily unavailable as of June 2026).ScopeThis document is a general recommendation of FortiOS software for general customer deployments for general stability and is updated quarterly.For customers who may be leveraging the latest features, the latest FortiOS versions may be more applicable.SolutionProduct FamilyProduct DetailsRecommended Release VersionEnd of Engineering Support Passed (Y/N)Low EndFortiGateRugged-35D6.2.17Y FortiGate-30E6.2.17Y FortiWiFi-30E6.2.17Y FortiGate-30G7.4.11 FortiGate-31G7.4.11 FortiWiFi-30G7.4.11 FortiGate-40F  7.6.6 FortiWiFi-40F7.6.6 FortiGate-40F-3G4G7.6.6 FortiWiFi-40F-3G4G7.6.6 FortiGate-50E6.2.17Y FortiWiFi-50E6.2.17Y FortiGate-51E6.2.17Y FortiWiFi-51E6.2.17Y FortiGate-52E6.2.17Y FortiGate-50G/51G and variants7.6.6 FortiWiFi-50G/51G and variants7.6.6 FortiGate-60E7.4.11 FortiWifi-60E7.4.11 FortiGate-60F7.6.6 FortiWiFi-60F7.6.6 FortiGate-61F7.6.6 FortiWiFi-61F7.6.6 FortiGateRugged-60F7.6.6 FortiGateRugged-60F-3G4G7.6.6 FortiGate-70F7.6.6 FortiGate-71F7.6.6 FortiGateRugged-70F7.6.6 FortiGateRugged-70F-3G4G7.6.6 FortiGate-70G/71G and variants7.6.6 FortiWiFi-70G/71G and variants7.6.6 FortiGate-80E7.4.11 FortiGate-81E7.4.11 FortiGate-80F7.6.6 FortiGate-81F7.6.6 FortiGate-90E7.4.11 FortiGate-90G7.6.6 FortiGate-91G7.6.6 FortiGate-98D-POE6.0.18YMid RangeFortiGate-100E7.2.11Y FortiGate-101E7.2.11Y FortiGate-100F7.6.6 FortiGate-101F7.6.6 FortiGate-120G7.6.6 FortiGate-121G7.6.6 FortiGate-140E7.4.11 FortiGate-200E7.6.6 FortiGate-200F7.6.6 FortiGate-201E7.6.6 FortiGate-201F7.6.6 FortiGate-200G/201G7.6.6 FortiGate-240D6.0.18Y FortiGate-280D6.0.18Y FortiGate-300E7.6.6 FortiGate-301E7.6.6 FortiGate-400E7.6.6 FortiGate-400E-BYPASS7.6.6 FortiGate-401E7.6.6 FortiGate-400F7.6.6 FortiGate-401F7.6.6 FortiGate-500E7.6.6 FortiGate-501E7.6.6 FortiGate-600E7.6.6 FortiGate-600F7.6.6 FortiGate-601E7.6.6 FortiGate-601F7.6.6 FortiGate-800D7.6.6 FortiGate-900D7.6.6 FortiGate-900G7.6.6 FortiGate-901G7.6.6High EndFortiGate-1000D7.6.6 FortiGate-1000F7.6.6 FortiGate-1001F7.6.6 FortiGate-1100E7.6.6 FortiGate-1101E7.6.6 FortiGate-1200D7.0.19Y FortiGate-1500D7.2.13Y FortiGate-1500DT7.2.13Y FortiGate-1800F7.6.6 FortiGate-1801F7.6.6 FortiGate-2000E7.6.6 FortiGate-2200E7.6.6 FortiGate-2201E7.6.6 FortiGate-2500E7.6.6 FortiGate-2600F7.6.6 FortiGate-2601F7.6.6 FortiGate-3000D7.6.6 FortiGate-3000F7.6.6 FortiGate-3001F7.6.6 FortiGate-3100D7.6.6 FortiGate-3200D7.6.6 FortiGate-3200F7.6.6 FortiGate-3201F7.6.6 FortiGate-3300E7.6.6 FortiGate-3301E7.6.6 FortiGate-3400E7.6.6 FortiGate-3401E7.6.6 FortiGate-3500F7.6.6 FortiGate-3501F7.6.6 FortiGate-3600E7.6.6 FortiGate-3601E7.6.6 FortiGate-3700D7.6.6 FortiGate-3700F7.6.6 FortiGate-3701F7.6.6 FortiGate-3800D7.0.19Y FortiGate-3960E7.6.6 FortiGate-3980E7.6.6 FortiGate-4200F7.6.6 FortiGate-4201F7.6.6 FortiGate-4400F7.6.6 FortiGate-4401F7.6.6 FortiGate-4800F7.6.6 FortiGate-4801F7.6.6 FortiGate-5001D6.4.16Y FortiGate-5001E7.6.6 FortiGate-5001E17.6.6Chassis Based FortiGateFortiGate-6000F / 7000E / 7000F7.6.6Virtual MachinesFortiGate-VM64    -        all versions7.6.6Engineering special builds:In certain cases, critical bug fixes are made available on Engineering special builds. These builds are not available on support.fortinet.com. If any issues are encountered specific to the environment which is not already fixed in existing releases, contact Fortinet TAC Support to investigate the issue.Special builds are meant to be deployed for a limited time frame and customers are advised to move to the next maintenance build with their fixes as soon as it is available. Engineering special builds are fully supported by the Fortinet Advanced Support team and, in some specific instances, by Fortinet TAC Support. Note:AC and DC models use the same firmware image. FAQ:What to take into consideration when deciding on the release to use:Review the latest release notes to check if any known issues could impact the deployment.Subscribe and Review relevant PSIRT notifications: FortiGuard Labs - RSS FeedsWhat is taken into consideration for a Recommended Release:Typically Recommended Releases are also labeled as 'Mature' releases.Significant field deployment of 40,000 or more FortiGates that have installed the recommended build.No high-severity vulnerabilities that are without mitigating steps or workarounds.How often the Recommended Release KB article is reviewed:The Recommended Release KB article is reviewed and updated quarterly.Why some platforms differ in releases:New platforms may be on initial New Product Introduction release and will have GA builds in a staggered process after FortiOS GA has been released.Older products may not support the latest recommended FortiOS release and hence the recommended release will be the latest FortiOS the device can support.How to keep up with the latest updates on this article:In the top right corner of the article, select the three-dotted menu button and select 'Subscribe to RSS Feed' (note that this feature is temporarily unavailable as of June 2026).Or login to the Fortinet Community Account and in the top right corner of the article, select the three-dotted menu button and select 'Subscribe'. An email will be received when this page is updated. (Note that this feature is temporarily unavailable as of June 2026.)Related article:Technical Tip: Recommended Release for FortiManager and FortiAnalyzer FortiGate Thu, 03 Sep 2026 09:56:38 +0200 https://community.fortinet.com/fortigate-3/technical-tip-proxy-address-group-saves-only-up-to-10-members-229760 DescriptionThis article describes the behavior when configuring an existing or new proxy address group that consists of more than 10 address object members; it saves only the first 10 entries.The example below, it shows that the Proxy Address Group 'test' consists of 14 members. But when modifying the group itself, it only shows 10 members.But when verified via CLI, the members are still properly set.ScopeFortiGate. SolutionThis is a bug found in FortiOS v7.6.7, and it affects only the GUI's edit/clone flow. A fix is planned to be released in the following versions:FortiOS v7.6.9.FortiOS v8.0.2.As a workaround, modify or configure the proxy address via the CLI instead to avoid triggering the truncation. FortiGate Thu, 03 Sep 2026 09:11:45 +0200 https://community.fortinet.com/fortigate-3/technical-tip-traffic-is-being-reset-by-the-fortigate-because-it-is-not-local-traffic-229758 DescriptionThis article describes the use of the FortiGate interface IP address by another device for connectivity testing.ScopeFortiGate v7.2/v7.4/v7.6.SolutionThe FGT1 uses the FGT2 port4 IP address to initiate a connection to the destination 10.180.4.200:443, but the connection is reset by FGT2.The traffic flows: FGT1 -> [port4 10.176.2.183] FGT2 [port5 10.180.2.183] -> Destination 10.180.4.200:443.The FGT2 sniffer packet output showed that it reset the connection:58.924423 port4 in 10.176.2.183.1221 -> 10.180.4.200.443: syn 1321058524 58.924621 port5 out 10.176.2.183.1221 -> 10.180.4.200.443: syn 1321058524 58.932801 port5 in 10.180.4.200.443 -> 10.176.2.183.1221: syn 2085838994 ack 1321058525 58.932879 port5 out 10.176.2.183.1221 -> 10.180.4.200.443: rst 1321058525The FGT2 debug flow output confirms that the connection is being reset, but it does not indicate the reason for the reset:id=65308 trace_id=72 func=print_pkt_detail line=6019 msg="vd-root:0 received a packet(proto=6, 10.176.2.183:1221->10.180.4.200:443) tun_id=0.0.0.0 from port4. flag , seq 1321058524, ack 0, win 29200" id=65308 trace_id=72 func=init_ip_session_common line=6220 msg="allocate a new session-0009ba43" id=65308 trace_id=72 func=__vf_ip_route_input_rcu line=1989 msg="find a route: flag=00000000 gw-0.0.0.0 via port5" id=65308 trace_id=72 func=__iprope_tree_check line=524 msg="gnum-100004, use int hash, slot=55, len=2" id=65308 trace_id=72 func=fw_forward_handler line=1002 msg="Allowed by Policy-1:" id=65308 trace_id=72 func=ip_session_confirm_final line=3193 msg="npu_state=0x100, hook=4" id=65308 trace_id=73 func=print_pkt_detail line=6019 msg="vd-root:0 received a packet(proto=6, 10.180.4.200:443->10.176.2.183:1221) tun_id=0.0.0.0 from port5. flag , seq 2085838994, ack 1321058525, win 64240" id=65308 trace_id=73 func=resolve_ip_tuple_fast line=6121 msg="Find an existing session, id-0009ba43, reply direction" id=65308 trace_id=73 func=__vf_ip_route_input_rcu line=1989 msg="find a route: flag=80000000 gw-0.0.0.0 via root" id=65308 trace_id=74 func=print_pkt_detail line=6019 msg="vd-root:0 received a packet(proto=6, 10.176.2.183:1221->10.180.4.200:443) tun_id=0.0.0.0 from local. flag [r], seq 1321058525, ack 0, win 0"Note: The flag [r] is RESET.The connection is reset because the traffic is not identified as local traffic, and this is expected. For more information, the local traffic refers to Technical Tip: Local traffic logs and policy ID 0. FortiGate Thu, 03 Sep 2026 08:55:36 +0200 https://community.fortinet.com/fortigate-3/technical-tip-resolving-internet-connectivity-issues-caused-by-duplicate-ha-vmacs-229757 DescriptionThis article describes Internet connectivity issues that may occur after adding a second ISP to a FortiGate HA cluster. The issue can be caused by a duplicate VMAC generated from the HA configuration, which may be detected by the upstream Core Switch and result in incorrect traffic forwarding.ScopeFortiGate.SolutionTo troubleshoot and resolve Internet connectivity issues related to a duplicate HA VMAC, follow these steps:Validate connectivity through the new ISP.After adding the second ISP link to the FortiGate HA cluster, perform connectivity tests through the new Internet connection.Validate connectivity to a public destination such as 8.8.8.8.Perform a traceroute to identify where the traffic stops:execute traceroute 8.8.8.8The traceroute may reach the gateway configured on the new ISP interface and some upstream ISP devices, but subsequent hops may not respond.In some cases, repeated traceroute tests can produce different results, with the trace completing at different hops.This behavior can indicate intermittent forwarding or Layer 2 communication issues between the FortiGate HA cluster and the upstream ISP network.Validate the HA configuration and VMAC.Review the HA configuration and identify the configured Group ID.show system haThe HA Group ID is used as part of the VMAC generation process for the HA cluster.The generated VMAC can be validated with:get system ha statusReview the HA information and compare the VMAC generated by the affected cluster with the VMACs observed in other FortiGate HA clusters connected to the same upstream network.If multiple HA clusters use the same default Group ID, duplicate VMACs can be generated.Validate the upstream Core Switch.Review the MAC address table on the upstream Core Switch and verify whether the VMAC generated by the FortiGate HA cluster is detected on multiple ports or associated with another HA cluster.A duplicate VMAC can cause MAC address table instability, incorrect MAC learning, or traffic forwarding through an unexpected path.The exact validation commands depend on the switch vendor and model.The following conditions should be reviewed:Duplicate VMAC detected in the Core Switch.The same VMAC was learned through multiple interfaces.MAC address movement between ports.MAC address flapping.Traffic was forwarded toward an incorrect FortiGate HA cluster.Multiple HA clusters using the same HA Group ID.Change the HA Group ID.If a duplicate VMAC is confirmed, configure a unique Group ID for the affected FortiGate HA cluster.Navigate to System -> HA.Modify the Group ID and assign a value that does not conflict with other FortiGate HA clusters connected to the same Layer 2 network.CLI example:config system ha set group-id <unique_group_id> endThe Group ID must be unique within the Layer 2 environment where the HA clusters are connected.Changing the Group ID causes a different VMAC to be generated for the HA cluster.Note: Changing the HA Group ID is an HA configuration change and can affect HA operation. The change should be performed during an approved maintenance window according to the environment requirements.Validate the new VMAC.After changing the Group ID, verify the HA status and generated VMAC:get system ha statusConfirm that the new VMAC is different from the VMAC associated with the other HA clusters.Additionally, validate the MAC address table on the upstream Core Switch and confirm that the new VMAC is learned correctly through the expected interface.Validate Internet connectivity.Repeat the connectivity tests through the new ISP link.Test connectivity to a public destination:execute ping 8.8.8.8Perform a new traceroute:execute traceroute 8.8.8.8The traceroute should now progress through the ISP network without the previous intermittent behavior.Refer to the following articles for more information regarding FortiGate HA configuration, VMAC behavior, and HA troubleshooting:Troubleshooting Tip: How to troubleshoot HA synchronization issue using GUI and CLI on FortiGate/FortiProxyHA active-passive cluster setup FortiGate Thu, 03 Sep 2026 08:16:01 +0200 https://community.fortinet.com/support-forum-92/fortitoken-mobile-6-5-0-0030-on-android-16-activation-fails-because-globalftm-fortinet-net-certificate-chain-is-no-longer-trusted-229756 Hi,I am experiencing a FortiToken Mobile activation failure on Android 16 with FortiToken Mobile 6.5.0.0030.The error shown during activation is: "Invalid server certificate - FortiToken Mobile cannot validate the server certificate."I found an older Fortinet Community discussion describing a very similar problem after upgrading to Android 13:FortiToken Mobile cert error on Android 13https://community.fortinet.com/support-forum-92/fortitoken-mobile-cert-error-on-android-13-115185In that thread, the original poster later reported: "Fortinet support said this is bug 765700."Fortinet also documented bug 765700 in the FortiToken Mobile Android 5.2.3 release notes:FTM Android 5.2.3 Known issueshttps://docs.fortinet.com/document/fortitoken/5.2.3/ftm-android-5-2-3-release-notes/999611/known-issuesBug 765700 is described there as: "'Untrusted Certificate' popup throws when activating/completing token transferring or approving/denying Login Requests"Fortinet later listed bug 765700 in the FTM Android 5.3.2 resolved issues:FTM Android 5.3.2 Resolved issueshttps://docs.fortinet.com/document/fortitoken/5.3.2/ftm-android-5-3-2-release-notes/666021/resolved-issuesThe description says that part of the Untrusted Certificate issue was fixed.Interestingly, bug 765700 was still listed as a known issue in FTM Android 5.3.3, specifically mentioning an Untrusted Server Certificate during FortiToken activation:FTM Android 5.3.3 Known issueshttps://docs.fortinet.com/document/fortitoken/5.3.3/ftm-android-5-3-3-release-notes/999611/known-issuesThere is also a Fortinet troubleshooting article for the exact error message:Troubleshooting Tip: Invalid server certificate - FortiToken Mobile cannot validate the server certificatehttps://community.fortinet.com/fortiauthenticator-8/troubleshooting-tip-invalid-server-certificate-fortitoken-mobile-cannot-validate-the-server-certificate-101390My current case is different enough that I cannot confirm whether this is a regression of bug 765700 or a separate issue.The same FortiToken activation code works successfully with FortiToken for Windows. This indicates that the token itself and the Fortinet provisioning service are functional.I investigated the Android failure further.FortiToken Mobile 6.5.0.0030 sends the initial SoftToken.MobileProvisionRequest to: https://globalftm.fortinet.net/SoftToken/Provisioning.asmx/MobileDuring initial provisioning, the application first uses its check_system_certs TLS validation path. If certificate validation fails, the request ends with SSLHandshakeException and the application displays the certificate error dialog.I also checked the application's Android Network Security Configuration. FortiToken Mobile 6.5.0.0030 targets API 35 and trusts several bundled Fortinet certificates plus: <certificates src="system"/> It does not include: <certificates src="user"/>globalftm.fortinet.net currently presents this certificate chain: globalftm.fortinet.net-> DigiCert SHA2 Extended Validation Server CA-> DigiCert High Assurance EV Root CAThe leaf certificate is currently valid from 8 April 2026 until 23 October 2026.On my Android 16 device, DigiCert High Assurance EV Root CA is no longer present in the active Conscrypt APEX trust store: /apex/com.android.conscrypt/cacertsThe old certificate is still present under: /system/etc/security/cacerts but it is absent from the active APEX CA set.To verify this independently of the FortiToken application, I extracted all 120 certificates from the device's Conscrypt APEX trust store and used them as the only CA bundle with OpenSSL.Validation of globalftm.fortinet.net fails:depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High Assurance EV Root CAverify error:num=19:self-signed certificate in certificate chainVerification error: self-signed certificate in certificate chainVerify return code: 19 (self-signed certificate in certificate chain)As an A/B test, I used exactly the same Android CA bundle against: ftc.fortinet.com:8688That endpoint validates successfully:depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root G2depth=1 C = US, O = DigiCert Inc, CN = DigiCert Global G2 TLS RSA SHA256 2020 CA1Verification: OKVerify return code: 0 (ok)This strongly suggests that the problem is specifically related to the certificate hierarchy currently used by globalftm.fortinet.net.Another relevant observation is that changing FortiToken Mobile's "Allow connection to an unverified server" setting does not solve initial token activation.From the application flow, this option is used by other operations such as push authentication and token transfer. The initial provisioning flow, however, simply displays the certificate error after the SSLHandshakeException and terminates the activation attempt.Installing the legacy DigiCert root as an Android user CA also does not appear to be a valid workaround because FortiToken Mobile's Network Security Configuration trusts system certificates but does not include user certificates.Could Fortinet please confirm:Is globalftm.fortinet.net expected to still use the DigiCert High Assurance EV Root CA hierarchy in September 2026? Is this related to bug 765700, a regression of that issue, or a new FortiToken Mobile issue? Is there any supported workaround for Android devices whose current system trust store no longer contains this DigiCert root? Is the certificate for globalftm.fortinet.net planned to be reissued under a currently trusted DigiCert hierarchy?For the moment I have switched the affected FortiGate administrator to email OTP as a workaround.Thanks.Daniel Vedovato Support Forum Thu, 03 Sep 2026 08:00:29 +0200 https://community.fortinet.com/fortigate-3/technical-tip-ddns-fortiguard-not-working-on-fortios-v7-4-10-v7-4-11-v7-4-12-229755 DescriptionThis article describes the issue and the workaround when the DDNS IP is not updating after upgrading to the 7.4.12 version.Scope FortiOS v7.4.10/v7.4.11/v7.4.12.SolutionThe mentioned FortiOS version could be impacted by the following symptom, where the FortiGuard DDNS server is not updating the IP address. The following debug can be executed in order to identify the following error.diagnose debug application ddnscd -1 diagnose debug enableThe following error can be found:error 19 - self-signed certificate in certificate chain error 2 - unable to get issuer certificate (Depth 2, DigiCert High Assurance EV Root CA)The following workarounds can be applied:Workaround 1: Verify if the certificate bundle is on version 1.00064:If the version matches, download the DigiCert High Assurance EV Root CA from the DigiCert portal and import it into the FortiGate trusted certificate: DigiCert Trusted Root Authority Certificates.Workaround 2: Change the default FortiGuard DDNS server. By default, it will contact the following server: 173.243.138.225. This server uses the DigiCert Cert mentioned before; moving to 173.243.138.266 will solve the issue in case workaround 1 does not work.config system fortiguard set fortiguard-anycast disable set ddns-server-ip 173.243.138.226 end Then, the following configuration can be applied to reload the new server IP to be contacted.fnsysctl killall ddnscd diagnose debug application ddnscd -1 diagnose debug enableSolution: Upgrade to the latest FortiOS v7.6.x or the upcoming FortiOS v7.4.13 and above.Related article:Technical Tip: FortiGuard (96.45.45.45, 96.45.46.46) FortiGate Thu, 03 Sep 2026 07:46:29 +0200 https://community.fortinet.com/fortimail-26/technical-tip-resolving-error-142-during-fortimail-cloud-deployment-229754 DescriptionThis article describes the steps to resolve the Error 142 status that occurs during the deployment of a FortiMail Cloud instance. The user experiences this error when attempting to provision a new instance, and it is necessary to follow specific procedures to resolve the issue.ScopeFortiMail Cloud.SolutionTo resolve the Error 142 status during FortiMail Cloud deployment, follow these steps:Submit a provisioning request to the cloud admin team, as self-provisioning is only available for Fortinet System Engineers. If administrators used to have an old tenant. It should have been deleted, and a new request is required.Refer to the Provisioning a FortiMail Cloud tenant documentation for detailed instructions on provisioning a new tenant.Once the deployment is complete, access the FortiMail Cloud instance using the provided credentials and follow the setup wizard to configure the instance.For additional information on accessing and configuring the FortiMail Cloud tenant, refer to the Accessing a FortiMail Cloud tenant. FortiMail Thu, 03 Sep 2026 07:41:30 +0200 https://community.fortinet.com/fortiadc-7/technical-tip-fortiadc-requests-with-long-cookies-not-handled-correctly-229753 DescriptionThis article describes a situation where the FortiADC does not handle requests with long cookies correctly, resulting in a 'Bad Request' response. The article provides a step-by-step solution to resolve this issue.ScopeFortiADC.SolutionTo resolve the issue of the FortiADC not handling requests with long cookies correctly, follow these steps:Log in to the FortiADC GUI and go to Load Balance -> Profile -> Load Balance Profile.Edit the load balancing profile associated with the virtual server (VS) experiencing the issue. In this case, the VS is TEST.In the Load Balance Profile page, scroll down to the Tuning section and increase the Buffer Size value to a larger number, such as 17408.config load-balance profile        edit "TEST"            set tune-bufsize 17408      next  endSelect OK to save the changes.By increasing the buffer size, the FortiADC can handle larger HTTP requests, including those with long cookies. This should resolve the issue of the FortiADC returning a 'Bad Request' response.For more information on configuring load balance profiles, refer to the config load-balance profile CLI reference settings. FortiADC Thu, 03 Sep 2026 07:38:50 +0200 https://community.fortinet.com/support-forum-92/fortinet-60f-229634 Currently, the FortiGate 60F is experiencing an inconvenience when there is an electrical power outage and the equipment starts operating using the UPS.When the power change is produced, the FortiGate apparently falls down and stops allowing network traffic, both incoming and outgoing.The way it has been used to restore the service is to physically disconnect the FortiGate and reconnect it to electrical power. After carrying out this procedure, the equipment normally starts correctly and allows network traffic again.However, on one occasion the FortiGate did not start correctly even after disconnecting and connecting it again, which increases concern about the cause of the problem. Support Forum Wed, 02 Sep 2026 23:06:10 +0200 https://community.fortinet.com/support-forum-92/ipsec-vpn-and-mac-os-tahoe-225749 Hi, Has anyone had any luck getting FortiClient vpn working on Tahoe? so far iv had 0 success .All windows based clients work fine however Support Forum Wed, 02 Sep 2026 19:10:00 +0200 https://community.fortinet.com/fortindrcloud-59/fortiguard-outbreak-alert-wp2shell-rce-229751 DescriptionFortiGuard Labs have observed exploitation attempts targeting the WP2Shell RCE (CVE-2026-63030 & CVE-2026-60137).CVE-2026-63030 is a REST API route confusion vulnerability in WordPress which allows an unauthenticated remote attacker to bypass intended endpoint restrictions and invoke protected functionality, which can be chained with CVE-2026-60137 to achieve SQL injection and ultimately execute arbitrary code on the server.CVE-2026-60137 is a SQL injection vulnerability in WordPress which allows an unauthenticated remote attacker to inject arbitrary SQL queries and, when chained with CVE-2026-63030, potentially execute arbitrary code on the server.Below are the affected and patched WordPress version ranges for CVE-2026-63030 and CVE-2026-60137:CVE-2026-63030Affected VersionsPatched Versions6.9.0 - 6.9.46.9.57.0.0 - 7.0.17.0.2CVE-2026-60137Affected VersionsPatched Versions6.8.0 - 6.8.56.8.66.9.0 - 6.9.46.9.57.0.0 - 7.0.17.0.2CVE IDCVE-2026-63030CVE-2026-60137NDR Cloud Detection RuleFortiNDR Cloud v26.3+Detection Rule NameCategoryPrimary MITRE IDFortiGuard Outbreak Alert: WordPress REST API SQL Injection - CVE-2026-63030/60137Attack: ExploitationT1190 - Exploit Public-Facing ApplicationPlaybookN/AThreat HuntingFortiNDR Cloud users can use the following IOCs from Fortinet to hunt for "WP2Shell RCE" related activities.IOC source: WP2Shell RCE | Indicators of CompromiseAll IOCs relating to "WP2Shell RCE" have been added to Threat Intelligence Intel.Suricata/DPI CoverageCustomers can create custom investigation/detention using the DPI and Suricata signatures below:DPI:DPI Vulnerability ID (dpi_vuln_id)DPI Alert Signature61474WordPress.REST.API.batch-route.SQL.InjectionSuricata:Suricata Signature IDSuricata Signature2071233ET WEB_SPECIFIC_APPS WordPress Core wp2shell Remote Code Execution (CVE-2026-63030 & CVE-2026-60137) M12071234ET WEB_SPECIFIC_APPS WordPress Core wp2shell Remote Code Execution (CVE-2026-63030 & CVE-2026-60137) M2Other Fortinet ProductsFor more details regarding mitigating the vulnerability by utilizing Fortinet products, refer to WP2Shell RCE. FortiNDRCloud Wed, 02 Sep 2026 18:01:40 +0200 https://community.fortinet.com/support-forum-92/odd-dns-servfail-from-fortinet-s-dns-servers-229746 nslookup v4-aws.api.intuit.com 96.45.45.45Server: dns1.fortiguard.netAddress: 96.45.45.45*** dns1.fortiguard.net can't find v4-aws.api.intuit.com: Server failednslookup v4-aws.api.intuit.com 96.45.46.46Server: dns2.fortiguard.netAddress: 96.45.46.46*** dns2.fortiguard.net can't find v4-aws.api.intuit.com: Server failed Support Forum Wed, 02 Sep 2026 17:26:35 +0200 https://community.fortinet.com/fortigate-3/troubleshooting-tip-application-bandwidth-widget-shows-high-values-that-does-not-match-any-logs-229750 DescriptionThis article describes an issue where high bandwidth usage is displayed in the Application Bandwidth widget but does not correspond to any logs on the device or to traffic statistics collected through the CLI.ScopeFortiOS v7.6.6, v7.6.7, v8.0, v8.0.1.SolutionWhen the Application Bandwidth Widget is viewed on the FortiGate dashboard, a large amount of bandwidth usage may be displayed for a particular Application ID.Upon checking further logs there will be no logs or sessions matching for this traffic.The following debug commands can be used to verify session for a particular Application ID.diagnose sys traffic app-stats list <application ID>To identify the Application ID hover over to the application in question as shown below:The example below shows output where the receive/send byte counters indicate little to no traffic for a specific application, while the Application Bandwidth widget displays significantly higher bandwidth usage for the same application.diagnose sys traffic app-stats list 40568 vd-id=0 app-id=40568 cat-id:25 flags=0x1 tx=(77108 bytes 210 pkt) rx=(61749 bytes 245 pkt) ses_cnt=8This behavior is identified in FortiOS v7.6.6. A resolution is planned for an upcoming FortiOS v7.6.x release and FortiOS v8.0.x release.Refer to the following document to add the Application Bandwidth Widget:FortiView application bandwidth widget. FortiGate Wed, 02 Sep 2026 17:16:19 +0200 https://community.fortinet.com/fortigate-3/troubleshooting-tip-ha-out-of-sync-due-to-otdt-database-mismatch-after-migrating-from-standalone-to-ha-229749 DescriptionThis article describes an HA out-of-sync condition for the 'rule.otdt' table after migrating a standalone FortiGate into an HA cluster.This can occur when the existing FortiGate contains OT Detection Definitions (OTDT) downloaded while a valid FortiGuard OT Security Service entitlement was present, but the newly added HA member does not have the corresponding OT database.ScopeFortiOS v7.4.1 and above.SolutionAfter forming the HA cluster, System -> HA may report 'rule.otdt' is out of sync.Verify the checksum on both HA members:diagnose sys ha checksum show global | grep -i otdtFor example, the original standalone FortiGate may contain a populated OTDT database:FGT-01(Primary) (global) # diagnose sys ha checksum show global | grep -i otdt rule.otdt: ef25e7dd5d6071f8e387ac722a11cfd3While the newly added HA member does not:FGT-02(Secondary) (global) # diagnose sys ha checksum show global | grep -i otdt rule.otdt: 00000000000000000000000000000000In Security Profiles -> Virtual Patching Signatures, the original standalone FortiGate may also show previously downloaded OT signatures, while the newly added HA member shows no corresponding signatures.Note: The Virtual Patching Signatures menu must first be enabled under System -> Feature Visibility.The differing 'rule.otdt' checksums indicate that the OTDT database is populated on only one HA member.If the FortiGuard OT Security Service is required:Ensure that both HA members have a valid FortiGuard OT Security Service entitlement. If the entitlement is not currently present, it must be purchased and activated for both FortiGate's before the required OT definitions can be downloaded.Once purchased and activated, on the primary FortiGate, navigate to System -> FortiGuard -> Update Licenses & Definitions Now.After the license and definition update has completed, follow the manual HA synchronisation procedure described in: Technical Tip: Procedure for manual synchronization for HA out-of-sync issue.If the FortiGuard OT Security Service is no longer required:The FortiGate containing the residual OTDT database may need to be formatted and rebuilt so that both HA members have the same OT database state.Important: Back up the FortiGate configuration before performing any formatting, rebuild, or redeployment procedure.Refer to the following Technical Tip for the complete procedure, and associated considerations: Technical Tip: Formatting and loading FortiGate firmware image using TFTP.Note: For FortiGate-VM, the appliance will need to be redeployed rather than following the hardware formatting procedure. Ensure that a configuration backup is taken before redeployment and that any applicable VM licensing requirements are considered.After the affected FortiGate has been rebuilt and HA synchronization has completed, verify the checksum again:diagnose sys ha checksum show global | grep -i otdtThe 'rule.otdt' mismatch should no longer be present.Related articles:Technical Tip: 'system.fortiguard' is not syncing because of auto-firmware-upgrade making HA out-of-syncTroubleshooting Tip: HA out of sync due to Hardware Revision mismatch on FortiGate 90GTroubleshooting Tip: HA out of sync due to IPS sensor configuration mismatch FortiGate Wed, 02 Sep 2026 17:02:31 +0200 https://community.fortinet.com/fortigate-3/troubleshooting-tip-https-gui-access-failure-in-fortigate-v7-6-4-and-later-with-an-error-failed-to-connect-to-tmp-http-authd-req-connection-refused-in-crashlog-output-225879 Description This article describes the issue where FortiGate GUI access is not working in firmware version 7.6.4 and later. However, SSH access to the device continues to function normally. Scope FortiGate. Solution After upgrading to firmware version 7.6.4 or later, the GUI may display an 'ERR_CONNECTION_REFUSED' error. In the below sniffer output, it can be seen that the firewall is sending the RST packet in response to the SYN (connection initiation). port2 in 10.2.2.2.58189 -> 10.1.1.1.443: syn 3366770127port2 out 10.1.1.1.443 -> 10.2.2.2.58189: rst 0 ack 3366770128 Access to the GUI may fail for administrators when using either the internal or external IP address of the FortiGate, while SSH access continues to function normally. Modifying the HTTPS management port does not resolve the issue. The following crashes may be observed in the 'diagnose debug crashlog read' output: FGT # diagnose debug crashlog read 2310: 2026-03-20 13:18:26 <02374> Node.JS restarted: (unhandled rejection)2311: 2026-03-20 13:18:26 <02374> "Failed to connect to /tmp/http_authd_req: Connection refused."2312: 2026-03-20 13:18:26 <02374>2313: 2026-03-20 13:18:26 <02374> Node.JS restarted: (unhandled rejection)2314: 2026-03-20 13:18:26 <02374> "Failed to connect to /tmp/http_authd_req: Connection refused."   Starting with FortiOS v7.6.4, a new internal daemon called http_authd has been introduced. This daemon centralizes the administrative web authentication and authorization functions required by web service processes. After upgrading to FortiOS v7.6.4, administrators may notice a new process named http_authd appearing in system process listings, such as diagnose sys top or fnsysctl ps. The following debug commands can be used to view authentication-related logs: diagnose debug resetdiagnose debug console timestamp enablediagnose debug application http_authd -1diagnose debug enable To stop debugging, run: diagnose debug disablediagnose debug reset No output is seen in the httpsd and http_authd debug output of 'diagnose debug application http_authd -1' when attempting to access the GUI of the FortiGate. This issue can be resolved by restarting the http_authd process. Refer to the document: Technical Tip: How to restart/kill one or several processes on the FortiGate with CLI commands. If the issue persists after restarting the http_authd process, review system event logs for indicators of malicious or brute-force attempts targeting FortiGate administrative access. Upon confirmation, disable HTTPS access on the public-facing interface. config system interface    edit <external-interface-name>        unset allowaccessend FortiGate Wed, 02 Sep 2026 16:56:46 +0200 https://community.fortinet.com/fortimanager-27/troubleshooting-tip-error-999-entry-not-exist-detail-no-fortilink-interface-exists-for-fsp-managed-switch-entry-not-exist-detail-no-fortilink-interface-exists-for-fsp-managed-switch-229748 DescriptionThis article describes how to resolve the FortiManager configuration push error that shows 'No fortilink interface exists for fsp managed-switch - entry not exist. detail: No fortilink interface exists for fsp managed-switch'.ScopeFortiManager.SolutionError:Vdom copy failed: error -999 - entry not exist. detail: No fortilink interface exists for fsp managed-switch - entry not exist. detail: No fortilink interface exists for fsp managed-switch.It stems from the 'export-to' feature, which exports certain FortiSwitch ports to other VDOMs. Currently, FortiManager does not fully support configuring this feature, particularly in central management mode. At this time, adding or modifying the 'export-to' attribute directly from FortiManager is not supported. Any such changes need to be made directly on the FortiGate device and then synchronised with FortiManager. To resolve the issue, disable FortiSwitch central management in FortiManager by editing the ADOM that manages the FortiGates: Go to System Settings -> ADOMs.Select the appropriate ADOM and select Edit.Navigate to Central Management.Uncheck FortiSwitch.Select OK.Related document:Managing ADOMs FortiManager Wed, 02 Sep 2026 16:23:38 +0200 https://community.fortinet.com/fortigate-3/technical-tip-behavior-of-dio-module-on-fortigate-rugged-models-when-setting-default-and-opposite-modes-when-the-device-is-on-or-off-229747 DescriptionThis article describes the behavior of the DIO module on FortiGate rugged models when setting default and opposite modes.ScopeFortiGate Rugged Models.SolutionCommandsDescriptionCommentsexecute digital-io set-output defaultDIO's default operational mode.When the device is ON:NC-COM CloseNO-COM OpenWhen the device is OFF:NC-COM CloseNO-COM Open execute digital-io set-output oppositeDIO's opposite operational mode.When the device is ON:NC-COM OpenNO-COM CloseWhen the device is OFF:NC-COM CloseNO-COM Open Related article:Technical Tip: Overview of the Digital Input/Output (DIO) Module in FortiGate Rugged 70F Series FortiGate Wed, 02 Sep 2026 16:19:00 +0200 https://community.fortinet.com/support-forum-92/fortios-7-4-11-unexpected-issues-229736 Hello everyone! Recently we upgraded our Fortigate (120G HA Active-Passive cluster) from 7.2.11 to 7.4.11, and different problems started to occur.Some users spontaneously lose access to the Internet with ERR_TUNNEL_CONNECTION_FAILED (we use explicit proxy with Kerberos authentication and deep ssl inspection). It happens at random times and with random users, lasts usually up to 2-3 minutes, then works as usual.FortiGates started to randomly reboot with the message "Fortigate had experienced an unexpected power off!", there's no CPU/RAM issue, usually mem is around 40%, and proc is around 10-12%. Due to fast HA failover users don't feel the interruption, but it's definitely not a good sign. Before the update both NGFW had worked for 367 days.Anyone experienced similar issues? Any workarounds? Or should I just be rolling back to 7.2.11?Any advice and help will be appreciated. Thank you in advance! Support Forum Wed, 02 Sep 2026 16:10:36 +0200 https://community.fortinet.com/fortinet-community-experience-251/reporting-fortinet-community-issues-227019 Are you seeing something in the Fortinet Community that is not working as expected? For example, a page not loading, a button not working, or a display issue? Reply to this thread to report Community-site issues. Note: This thread is for issues with the Fortinet Community site itself. If you’re reporting a problem with a Fortinet product, please use the appropriate Fortinet support channel for that product. Additional details are available at: https://www.fortinet.com/support/contact. Please include:A brief description of what’s happening The expected outcome A link to the issue if possible or the section you are experiencing the issue Screenshots and/or error messages Your browser and operating system  We will let you know when we have reviewed the issue and started the investigation. We may not reply to every post, but we will follow up if we need more details or when there is news to report. Thank you for identifying these issues. Your reports help keep the Community running smoothly as possible for everyone! Fortinet Community Experience Wed, 02 Sep 2026 16:06:38 +0200 https://community.fortinet.com/support-forum-92/in-super-admin-profile-i-am-not-seeing-admin-user-mean-i-do-not-have-super-admin-accoutn-229744   Support Forum Wed, 02 Sep 2026 15:55:10 +0200 https://community.fortinet.com/support-forum-92/fortianalyzer-remote-logs-not-displaying-on-fortigate-gui-after-fortianalyzer-upgrade-faz-7-4-11-227635 ScenarioEnvironment with multiple FortiGate firewalls connected to a FortiAnalyzer VM for centralized log collection and analysis.Environment VersionsFortiAnalyzer VM: 7.4.11FortiGate: 7.2.13Fabric ADOM enabledSome FortiGate devices operating in HA cluster modeAfter upgrading the FortiAnalyzer from version 7.4.6 to 7.4.11, the FortiGate devices stopped displaying FortiAnalyzer logs directly from the FortiGate GUI.SymptomsWhen accessing logs from the FortiGate GUI:Log & Report → Forward Traffic / Event Logsthe page remained completely blank.However:FortiAnalyzer continued receiving logs normallyDevices remained online in Fabric View / Device ManagerLogs were visible directly in the FortiAnalyzer GUINo explicit communication or authorization errors were displayedAdditionally, the following behaviors were observed:Analytics (actual/config days) above 100%Archive Usage above 90%diagnose dvm device list showing:conn: unknownconf: unknowndev-db: unknownThis initially suggested a possible database, DVM, or analytics issue.Root CauseThe issue was related to the source IP used by the FortiGate for communication with the FortiAnalyzer.After the FortiAnalyzer upgrade, the Remote Log Retrieval/API session validation became more strict regarding source consistency.On FortiGate HA clusters, when no source-ip is configured, the FortiGate may use different interfaces/IPs for:log uploadAPI requestsremote log retrieval sessionsThis causes the FortiAnalyzer remote query session to fail silently, resulting in a blank log page on the FortiGate GUI.SolutionConfigure a fixed source-ip for FortiAnalyzer communication.For HA environments, it is highly recommended to use a Loopback interface IP.Example:config log fortianalyzer setting    set status enable    set server "IP FAZ(X.X.X.X)"    set serial "FAZVMXXXXXXXXXXX"    set upload-option realtime    set source-ip "xxx.xxx.xxx.xxx"endAfter applying the configuration:Remote logs immediately became visible again on the FortiGate GUINo further issues were observedRecommendations / Best PracticesFor environments using:FortiAnalyzer VMHA clustersSD-WANmultiple WAN linksFabric ADOMit is strongly recommended to:Configure set source-ipPrefer Loopback interface IPsUse stable management-plane routing toward FortiAnalyzerThis helps maintain consistent:API sessionsFabric communicationRemote Log RetrievalLog upload stabilityespecially after upgrades or failover events.Additional NotesAlthough storage/analytics warnings were present:Archive Usage > 90%Analytics > 100%they were not the root cause of the issue.The FortiAnalyzer continued processing and storing logs normally.The actual issue was the inconsistent source IP used during FortiAnalyzer remote query sessions. Support Forum Wed, 02 Sep 2026 15:11:53 +0200 https://community.fortinet.com/forticlient-4/troubleshooting-tip-forticlient-vpn-configuration-backup-or-restore-does-not-respond-after-an-in-place-upgrade-229743 DescriptionThis article describes an issue where FortiClient VPN configuration backup or restore fails silently after an in-place upgrade.After selecting Backup or Restore and selecting OK, the dialog closes without displaying an error, but no backup file is created, and no configuration is restored.Other symptoms may include VPN connections missing from the system tray menu or different FortiClient versions being displayed between the GUI and system tray components.ScopeFortiClient VPN-Only.SolutionThe issue occurs when legacy FortiClient binaries remain after an in-place upgrade, causing inconsistent component versions and disrupting IPC communication between the GUI, system tray, and service components.The recommended solution is to perform a clean reinstallation:Uninstall FortiClient from Windows Settings -> Installed apps.Reboot the endpoint.Install the required FortiClient version again.If reinstallation is not immediately possible, use FCConfig.exe to back up or restore the configuration, which is normally located in 'C:\Program Files\Fortinet\FortiClient'.Steps:Open Command Prompt (CMD) and navigate to the FortiClient installation directory:cd "C:\Program Files\Fortinet\FortiClient"Then run the required FCConfig.exe command to export the configuration:FCConfig.exe -m all -f C:\temp\fct_backup.conf -o export -p <password>To import the configuration:FCConfig.exe -m all -f C:\temp\fct_backup.conf -o import -p <password>Notes:The password used with FCConfig.exe must contain at least 8 characters.Ensure that the destination folder already exists before running the export command. FortiClient Wed, 02 Sep 2026 14:55:39 +0200 https://community.fortinet.com/fortimanager-27/technical-tip-how-to-delete-used-fortiswitch-vlan-229742 DescriptionThis article describes how to delete used FortiSwitch VLANs.ScopeFortiManager-VM, FortiManager appliances.SolutionWhen a VLAN configured under FortiSwitch Manager -> FortiSwitch VLANs needs to be deleted, it must first be unassigned from the switch-controller managed-switch -> ports configuration.After the VLAN has been unassigned, select the VLAN to delete and select the Delete button.Step 1: Under FortiSwitch Manager -> FortiSwitch VLANs, Right-click VLAN interface -> Where Used. Then unassign it from the used template.Step 2: Re-check if the VLAN interface is used.Step 3: Select the VLAN interface and select the Delete button. FortiManager Wed, 02 Sep 2026 14:47:43 +0200 https://community.fortinet.com/fortisiem-34/troubleshooting-tip-how-to-fix-the-fortisiem-windows-agent-constantly-restarting-229740 DescriptionThis article describes how to fix an issue where the FortiSIEM Windows Agent process keeps restarting.ScopeWindows Agent v4.x.x - v7.4.x.SolutionReview the Agent's log under C:\Program Files\Fortinet\FortiSIEM\logs\cms.log.The following error may be present in the cms.log file:FortiSIEMWinRTWrapper::LoadLib - Main Signature is not valid for C:\Program Files\Fortinet\FortiSIEM\FortiSIEM.WinRTWrapper.dllTo fix this, go to C:\Program Files\Fortinet\FortiSIEM\.Right-click the file FortiSIEM.WinRTWrapper.dll -> Properties -> Digital Signature -> Select Fortinet Signature -> Details. If the signature is not valid, select View Certificate and Install certificate.Note: The Windows host must have internet access to install the certificate. Also, it is recommended to run the latest Windows OS patches/updates. FortiSIEM Wed, 02 Sep 2026 13:41:46 +0200 https://community.fortinet.com/support-forum-92/deploying-ipsec-profiles-via-intune-without-ems-license-224681 Hi everyone,I’m planning to migrate from SSL VPN to IPsec VPN. Here’s the situation:The FortiClient app is already installed on users’ devices, and I need a way to deploy the IPsec VPN profile to those devices via Intune (all devices are managed by Intune).I’m currently using the VPN-only version of FortiClient, and as far as I know, deploying VPN profiles centrally requires an EMS license.Could you please advise if there’s any alternative solution in this case?Thanks Support Forum Wed, 02 Sep 2026 13:40:04 +0200 https://community.fortinet.com/support-forum-92/vip-rule-229739 i have newly created VIP rule to publish local microsoft dynamic test server to the internet to access anywhere, but the vip rule not hit any packets.attached the rule screenshot and policy, any help from the community team would be appreciated  Support Forum Wed, 02 Sep 2026 12:50:58 +0200 https://community.fortinet.com/fortigate-3/technical-tip-how-to-allow-let-s-encrypt-traffic-through-the-fortigate-to-devices-located-behind-the-fortigate-179001 Description This article discusses Let's Encrypt traffic (i.e. certificate request/renewal using the ACME protocol) and how it can be allowed to reach devices behind the FortiGate. There will also be some discussion regarding methods of hardening this access and limiting it to Let's Encrypt only. Scope FortiGate. Solution When connecting with Let's Encrypt (LE) and requesting a certificate using the ACME protocol, certain traffic flows need to be allowed for the operation to succeed: In the Outgoing direction (i.e. the webserver/device -> Let's Encrypt's servers), it is necessary to allow HTTPS (TCP/443) traffic. ACME uses HTTPS messages between the user and the LE servers for communication that is separate from the challenge traffic itself. In the Incoming direction (i.e. LE server -> the webserver/device), it is necessary to allow either HTTP (TCP/80) or potentially HTTPS (TCP/443) depending on what the Let's Encrypt user supports. TCP/80 is associated with the HTTP-01 challenge type, which is the recommended and most common challenge issued by Let's Encrypt. TCP/443 is associated with the TLS-ALPN-01 challenge type. See Let's Encrypt's documentation for more information on Challenge Types: https://letsencrypt.org/docs/challenge-types/.   Allowing Let's Encrypt Traffic. For the Outgoing traffic, a simple Firewall Policy that allows the webserver/ACME Client to reach the Internet is all that is required.   For Incoming traffic, it will be necessary to create a Virtual IP (VIP) or Virtual Server on the FortiGate as well as a corresponding Firewall Policy to allow traffic from Let's Encrypt to reach your webserver. This assumes that the webserver is not directly reachable from the Internet and requires incoming Port Forwarding/Destination NAT to be reached (i.e. the server has a private IP address). See the following links for general documentation on creating VIPs (either using Services or with individual port forwards):   Virtual IP with services Virtual IPs with port forwarding   If it is not desired to have an inbound Destination NAT then it is possible to use a simple incoming Firewall Policy to allow Internet access. If the webserver is meant to be accessed from the Internet then it is possible to already have incoming Firewall Policies, in which case it is possible to re-use the existing inbound policies.   Notes on allowing TCP/80. Let's Encrypt's own Best Practice page suggests enabling TCP/80 access through the firewall (i.e. the FortiGate) for Let's Encrypt (see: https://letsencrypt.org/docs/allow-port-80/). Just to summarize the points in the previous document and add a few more: HTTP requests via TCP/80 can be redirected to HTTPS (TCP/443 or another custom port) on many platforms with web GUIs. This allows TCP/80 available for HTTP-01 ACME challenges while still ensuring that users of the web service are still upgraded to secure HTTPS connections. For example, the FortiGate and FortiClient EMS both have HTTPS-based web GUIs that support redirecting insecure HTTP requests to HTTPS instead. Incoming requests for TCP/80 in this scenario are just to satisfy the ACME challenge requirements, as ACME would utilize the HTTPS-based connection mentioned in the Outgoing direction for sending/receiving info related to the certificate request itself. Notes regarding inspecting/restricting ACME Challenges for security reasons. For the HTTP-01 challenge, it is possible to add additional protection by configuring a Web Application Firewall (WAF) profile on the FortiGate (or other appropriate product like FortiWeb) and applying it to the inbound Firewall Policy that allows TCP/80 traffic. More specifically, it is possible to create a WAF profile that enforces an HTTP Method Policy that only allows GET requests to GET requests to '/.well-known/acme-challenge/' (no quotation marks). /.well-known/acme-challenge/ is the directory that Let's Encrypt checks on the webserver (it uses a pseudorandom token string for each request). Restricting incoming HTTP methods to ONLY requests that contain this URL will significantly limit the access that outside Internet hosts have to the web server. The default ALL rule can be modified to block all other HTTP requests by setting the Allowed HTTP Methods to 'OTHERS'.     Important: Do not apply SSL/TLS deep-inspection to TLS-ALPN-01 challenge traffic. Let's Encrypt sends a TLS Client-Hello towards the web server with the Application-Layer Protocol Negotiation (ALPN) header set to 'tls-alpn-01' and it expects a TLS Server Hello sent back by the webserver using a self-signed certificate that contains the acmeIdentifier extension. Applying deep-inspection on the FortiGate would result in the FortiGate disrupting the TLS-ALPN-01 challenge (since it will intercept the connection and present its certificate. Additionally, there is no benefit to deep-inspecting the TLS-ALPN-01 challenge, as the challenge itself is done at the TLS network layer (i.e. there is no content to inspect). Certain applications (such as the HTTPS-based admin web GUIs on FortiGate) may not be appropriate for Internet users to access, but it can be still desired to benefit from Let's Encrypt certificates served via the TLS-ALPN-01 challenge (i.e. HTTP-01 might not be an option). In those scenarios, it is recommended to change the HTTPS listening port used for admin web GUIs to something OTHER than TCP/443. This would allow TCP/443 inbound to meet the TLS-ALPN-01 challenge requirements without exposing access to a device's admin web GUI.   Related articles: Technical Tip: ACME certificate with certificate management services other than Let's Encrypt on v7.0.2 and above Technical Tip: Let's Encrypt failing to provision due to VIP configured on port 443 FortiGate Wed, 02 Sep 2026 11:25:34 +0200 https://community.fortinet.com/support-forum-92/cloudflare-real-ip-on-fortigate-229738 I have a VIP IP address defined on my Fortigate Firewall, and I'm using Cloudflare with a proxy enabled. When I log the source on the firewall, I only see the Cloudflare IP address. Is it possible to see the incoming VIP traffic as if it were the real IP address? Support Forum Wed, 02 Sep 2026 10:55:26 +0200 https://community.fortinet.com/forticnapp-63/technical-tip-how-to-troubleshoot-forticnapp-vs-code-extension-229737 DescriptionThis article describes the steps to install and troubleshoot the FortiCNAPP Visual Studio Code extension, which is a tool to detect vulnerabilities in code before committing changes.ScopeFortiCNAPP, Visual Studio Code.This article is aimed towards FortiCNAPP Code Security users who want to use the Visual Studio Code extension for Software Composition Analysis (SCA), Static Application Security Testing (SAST), and Infrastructure as Code (IaC) scanning in a local development environment.SolutionRunning scans and results:Open the project workspace in Visual Studio Code, and select FortiCNAPP extension icon.Start all scans via the Scan button, or run scan independently (IaC, SAST, or SCA or Run all scans).Review results in the Problem View, and navigate to files by using the Issues tree view that allows opening related files.Troubleshooting:When trying to scan, the following message appear at the lower right corner: 'You must install the IaC component within the Lacework CLI before you can run a scan'.It is still possible to run the scans without upgrading to the latest updates, but scans will not benefit from the latest release features.If an error occurs while running scans, extract the extension logs: go the Output panel: In Visual Studio Code, go to View -> Output -> Select 'Extension Host' from the drop-down. Then use the 'save output as' or 'export Logs' option to get full logs.If any issue occurs while scanning, verify this independently in the FortiCNAPP CLI. The following is an example for an SCA scan that saves output in FortiCNAPP the JSON format, and saves the file for investigation.lacework sca scan <directory> -f lw-json -o <output location and filename>Related document:For instructions on how to install the extension, see VS Code in the documentation. FortiCNAPP Wed, 02 Sep 2026 10:29:53 +0200 https://community.fortinet.com/support-forum-92/fortiendpoint-ems-cloud-fortiedr-installation-fails-on-windows-11-229343 Hi,I would like to know if anyone else is experiencing similar issues with FortiEndpoint EMS Cloud and the integrated FortiEDR feature.Our environment is currently running:FortiClient EMS Cloud: 7.4.7 build 2194 (Mature) FortiClient: 7.4.7 Windows 11 25H2: Build 26200.8875 FortiEDR Engine assigned by EMS: 5.2.8.0044Originally, we noticed that some endpoints using the same EMS policies and profiles had FortiEDR working and connected, while others showed FortiEDR Disabled in FortiClient and Disconnected in FortiEDR Cloud.Both working and affected endpoints are operating in the same environment and network, which makes the different behavior seem questionable. We are also seeing the same issue on endpoints in customer environments, so it does not appear to be limited to a single device or network.We also tested multiple FortiClient versions, including 7.4.4, 7.4.5, and 7.4.6, but the behavior remained the same.On affected endpoints, the Collector reported:FortiEDR Detected incompatible manager. Missing registration informationAfter working with Fortinet TAC, we used the FortiEDR Cleanup Tool to completely remove the old Collector installation.Since then, FortiEDR can no longer be installed on the affected endpoint through either:EMS Cloud Deployment a newly generated FortiEndpoint installerEMS reports:Deployment state 150 - Deployment ErrorNsloInstallFailedWindows Event Viewer shows that MsiExec.exe crashes while installing the FortiEDR component:Event name: BEX64Application: MsiExec.exeFaulting module: MSIxxxx.tmp_unloadedModule version: 7.4.7.2003Exception code: c0000005The subsequent MsiInstaller event reports:Product: Fortinet Endpoint Detection and Response PlatformProduct version: 5.2.8.44Installation status: 1603TAC confirmed that FortiEndpoint version 26.3 currently supports only FortiEDR Collector 5.2.8.0044 for Windows and is checking internally why the installer crashes.Has anyone else seen:FortiEDR becoming Disabled/Disconnected on otherwise identical endpoints? NsloInstallFailed / Deployment Error 150 when installing the EDR feature? MsiExec.exe crashing with 0xc0000005 while installing EDR 5.2.8.0044?Kind Regards,MG4 Support Forum Wed, 02 Sep 2026 10:10:34 +0200 https://community.fortinet.com/support-forum-92/is-forticlient-7-4-3-4726-still-safe-to-use-229735 We are currently evaluating our options and already have a quotation prepared for a licensed FortiClient solution, which is awaiting final approval and signature. Our organization has two FortiGate firewalls with active licenses and has been using FortiClient VPN Free Edition 7.4.3.4726 as our VPN client.Approximately 20 days ago, one of our security partners advised us to remove or upgrade FortiClient VPN 7.4.3 due to a reported vulnerability. As a result, we upgraded to FortiClient VPN 7.4.8. However, we later discovered that this version appears to require FortiClient EMS for ongoing management, leaving us uncertain about the most appropriate temporary solution.We have been unable to determine whether FortiClient VPN Free Edition 7.4.3.4726 remains secure for continued use. The software is still available for download, and discussions in community forums appear to reference different CVEs than the ones currently under review.As part of our evaluation process, we would like to understand whether temporarily continuing to operate the free FortiClient VPN client introduces any known security risks.Specifically, we are trying to determine:Whether FortiClient VPN Free Edition 7.4.3.4726 is affected by CVE-2026-70465 or any other recently disclosed FortiClient vulnerabilities. Whether the affected component exists in the VPN-only Free Edition, or only in the fully licensed FortiClient product with additional security features enabled. Which FortiClient VPN version is currently recommended by Fortinet for organizations temporarily using the free VPN client while transitioning to a licensed FortiClient deployment.Any guidance or clarification you can provide would be greatly appreciated. the other forum topic i mentioned: Technical Tip: List of CVE fixes in FortiClient Free VPN v7.4.3 for Windows only | Community kind regards,Jeremy Support Forum Wed, 02 Sep 2026 09:45:59 +0200 https://community.fortinet.com/fortindrcloud-59/fortiguard-outbreak-alert-joomla-sp-page-builder-rce-229734 DescriptionJoomla SP Page Builder is a drag-and-drop page builder extension for Joomla that lets you create responsive, professional websites without coding.CVE-2026-48908 is an unrestricted file upload vulnerability in the SP Page Builder extension for Joomla with the asset.uploadCustomIcon controller task exposed without authentication which allows an unauthenticated remote attacker to upload an arbitrary PHP file to the web root and execute arbitrary code on the server.The following versions of SP Page Builder extension for Joomla is vulnerable to CVE-2026-48908:< 6.6.2CVE IDCVE-2026-48908NDR Cloud Detection RuleFortiNDR Cloud v26.3+Detection Rule NameCategoryPrimary MITRE IDFortiGuard Outbreak Alert: Joomla SP Page Builder Arbitrary File Upload - CVE-2026-48908Attack: ExploitationT1190 - Exploit Public-Facing ApplicationPlaybookN/AThreat HuntingFortiNDR Cloud users can use the following IOCs from Fortinet to hunt for "Joomla SP Page Builder RCE" related activities.IOC source: Joomla SP Page Builder RCE | Indicators of CompromiseAll IOCs relating to "Joomla SP Page Builder RCE" have been added to Threat Intelligence Intel.Suricata CoverageCustomers can create custom investigation/detections using the DPI and Suricata signatures below:DPI:DPI Vulnerability ID (dpi_vuln_id)DPI Alert Signature61172Joomla!.SP.Page.Builder.Arbitrary.File.UploadSuricata:Suricata Signature IDSuricata Signature100109828ATR EXPLOITATION Joomla! SP Page Builder Arbitrary File Upload - CVE-2026-48908Other Fortinet ProductsFor more details regarding mitigating the vulnerability by utilizing Fortinet products, please refer to Joomla SP Page Builder RCE. FortiNDRCloud Wed, 02 Sep 2026 09:27:32 +0200 https://community.fortinet.com/fortigate-3/technical-tip-examining-the-administrators-cpu-memory-and-sessions-widgets-on-a-fortigate-vm-running-fortios-v8-0-229732 DescriptionThis article describes the Administrators, CPU, Memory, and Sessions widgets available by default on the dashboard of a FortiGate VM running FortiOS v8.0. It explains the information provided by these widgets and how corresponding FortiOS CLI commands can be used to verify the displayed administrator access, system resource utilization, and active sessions.The default dashboard widgets on a FortiGate VM can be grouped by their primary purpose into three categories: system-oriented dashboard information, platform/service-oriented dashboard information, and administrative and operational monitoring dashboard information. For system-oriented dashboard information, refer to Technical Tip: Discovering the System Information Widget on a FortiGate VM Running FortiOS v8.0. For platform/service-oriented dashboard information, refer to Technical Tip: Exploring the licenses, Virtual Machine, FortiGate Cloud, and Security Fabric widgets on a FortiGate VM running FortiOS v8.0. This article focuses on the administrative and operational monitoring dashboard information provided by the Administrators, CPU, Memory, and Sessions widgets.ScopeFortiGate VM, FortiOS v8.0.0, VMware Workstation Pro 17.SolutionOn the dashboard, the Administrators, CPU, Memory, and Sessions widgets are displayed on the Status page. The Administrators widget shows current administrator access, while the CPU and Memory widgets display system resource utilization. The Sessions widget displays the current number of active sessions and session utilization.The Administrators widget displays the current administrator access by connection type. In the example shown, the widget reports 1 Console, 0 FortiExplorer, and 1 HTTPS connection, and identifies the administrator as admin with the super_admin profile.The 1 Console connection corresponds to the active VMware console connection to the FortiGate VM. When the console session times out and returns to the FortiGate VM prompt, refreshing the dashboard causes the 1 Console entry to disappear from the Administrators widget.The corresponding CLI commands can be used to verify the administrator information displayed in the Administrators widget.For information on accessing the FortiGate CLI, refer to the Fortinet Administration Guide: Connecting to the CLI.get system info admin status get system admin list The CPU widget displays CPU utilization over the selected time period. The available intervals are 1 minute, 10 minutes, 30 minutes, 1 hour, 12 hours, and 24 hours. In the example shown, the widget is set to a 1-minute interval and reports a current usage of 7%, while the graph shows CPU utilization during the selected period.The corresponding CLI command can be used to verify the CPU utilization information displayed in the CPU widget.The FortiGate VM used in this example is configured with 1 vCPU, which is why the CLI output includes CPU0 only. If additional vCPUs are allocated to the VM, the CLI output includes the corresponding additional CPU entries.get system performance statusThe CLI output includes additional CPU state parameters such as user, system, nice, idle, iowait, irq, and softirq. For more information, refer to the Fortinet Document Library: system performance status, and the Fortinet Community article: Technical Tip: Explaining the 'get system performance status' output.The Memory widget displays memory utilization over the selected time period. The available intervals are 1 minute, 10 minutes, 30 minutes, 1 hour, 12 hours, and 24 hours. In the example shown, the widget is set to a 1-minute interval and reports a current usage of 56%, while the graph shows memory utilization during the selected period.The corresponding CLI command can be used to verify the memory utilization information displayed in the Memory widget.get system performance statusThe CLI output reports total memory, used memory, free memory, and freeable memory. Total represents the total system memory available to FortiGate, used represents memory currently in use, free represents memory currently unused, and freeable represents cached memory that can be reclaimed if needed.The CLI output reports 2,043M of total memory, with 1,143M used, corresponding to 56.0% memory utilization. It also reports 582M free memory (28.5%) and 318M freeable memory (15.5%).The Memory widget displays memory utilization as a whole-number percentage, while the CLI output may provide the utilization with decimal precision. In this example, the 56% displayed by the widget corresponds to the 56.0% reported by the CLI.The Sessions widget displays the number of active sessions over the selected time period. The available intervals are 1 minute, 10 minutes, 30 minutes, 1 hour, 12 hours, and 24 hours. In the example shown, the widget is set to a 1-minute interval and reports 5 current sessions, while the graph shows the number of active sessions during the selected period.The corresponding CLI command can be used to verify the session information displayed in the Sessions widget.diagnose sys session listThe CLI output reports a total of 5, which corresponds to the 5 current sessions displayed in the Sessions widget.The Administrators, CPU, Memory, and Sessions widgets provide useful dashboard information for monitoring administrator access, system resource utilization, and active sessions on a FortiGate VM. The corresponding FortiOS CLI commands can be used to verify the information presented by these widgets and provide additional detail when needed. FortiGate Wed, 02 Sep 2026 07:56:29 +0200 https://community.fortinet.com/fortimail-26/troubleshooting-tip-fortimail-cloud-rejects-google-calendar-notifications-with-a-550-domain-not-protected-error-229731 DescriptionThis article describes why email notifications generated by Google Calendar are rejected by FortiMail Cloud with a 550 error stating that the domain is not a protected domain and explains how to create a dedicated routing rule in Google Workspace so these notifications are delivered correctly.ScopeFortiMail.FortiMail Cloud.Google Workspace.SolutionGoogle Calendar generates meeting invitations and notification messages from the address calendar-notification@google.com, which belongs to Google rather than to a domain protected by FortiMail Cloud. Google Workspace delivers messages from this address through a path that differs from the normal mail flow used to route mail through FortiMail Cloud. FortiMail Cloud then rejects the message because the sending domain does not match a domain protected by the tenant. The rejection appears in the Google Workspace delivery log as a permanent error similar to the following:550 5.7.1 Domain example.com is not a protected domainOther Google-generated system notifications can show the same behavior, such as Drive share notifications sent from drive-shares-dm-noreply@google.com.To resolve the issue, create a dedicated routing rule in Google Workspace so Google-generated notifications are routed directly to the FortiMail Cloud instance protecting the domain.Log in to the Google Admin Console and go to Apps -> Google Workspace -> Gmail -> Routing.Select Add another rule and configure the following settings.Name: enter a descriptive name, for example, Relay internal calendar invites.Email messages to affect: Select Internal, sending, and Internal, receiving.Add another expression: Select the Envelope filter, then Pattern match, and enter a regular expression that matches the sender address, for example, ^calendar-notification@google\.com$.If the above matches, do the following: Select Modify Message, then Route, then Change Route, and select the destination host configured to relay mail to FortiMail Cloud, for example, a custom relay pointing to the FortiMail Cloud MX hosts assigned to the domain:example-com-1.fortimailcloud.com example-com-2.fortimailcloud.comIn the Envelope recipient section, select 'Only affect specific envelope recipients', and enter the internal domain pattern, for example, ^calendar-notification@google\.com$.Save the routing rule.Send a test Google Calendar invitation to a recipient within the protected domain, and confirm that the notification is delivered successfully.FortiMail Cloud assigns two MX hosts to each protected domain, named after the domain.Confirm that the routing rule points to the correct hosts before saving the rule. FortiMail Wed, 02 Sep 2026 07:49:34 +0200 https://community.fortinet.com/fortigate-3/technical-tip-entry-not-found-error-when-trying-to-add-remote-ldap-server-to-authentication-scheme-on-fortigate-229730 DescriptionThis article describes an 'Entry not found' error when trying to add a remote LDAP server to an authentication scheme on a FortiGate.ScopeFortiGate.SolutionWhen using an authentication scheme and authentication rule with an LDAP server, an 'Entry not found' error may appear when applying the configuration.This is due to the LDAP configuration, where the attribute group-member-check is set to group-object, and the member-attr field is also set.LAB-DEV (FortiGate TEST) # show config user ldap edit "FortiGate TEST" set server "ips.fortinet.net" set cnid "uid" set dn "cn=users,cn=accounts,dc=local" set type regular set username "sdwd" set password ENC acytnPXBScmMoihctkwhfUvt+yiBebOKos2kQoQD9rJvzy5RVheu+Rl/ZXMhnxSHs4XfA5UO/LoUizQjpzJUNUHoxjTTZx3hjX0pKcja7xTWsKKUTtHPRLca0JhsTxVFho1bJGlb1TRH+itaL/zEayo/aTPZDngDvDKBz2SSx9IVsQhQx8VFVklTyPQ8HEa9RmHYellmMjY3dkVA set group-member-check group-object set secure ldaps set port 636 set member-attr "memberof" next endSolution:FortiGate blocks or fails to select an LDAP server when mixing member of attributes with Object ID-based group matching due to a conflict between user-attribute and group-object evaluation schemes.To resolve this issue, unset group-member-check and member-attr to the default config.LAB-DEV (root) # config user ldap LAB-DEV (ldap) # edit "FortiGate TEST" LAB-DEV (FortiGate TEST) # unset group-member-check LAB-DEV (FortiGate TEST) # unset member-attr LAB-DEV (FortiGate TEST) # end LAB-DEV (root) # Now the LDAP server can be used for authentication, and an authentication rule can be created on the firewall.Related article:Technical Tip: LDAP user authentication using Member Attribute match FortiGate Wed, 02 Sep 2026 07:45:25 +0200 https://community.fortinet.com/fortisiem-216/best-practise-to-add-postgresql-to-fortisiem-214105  Hello everyone,Has anyone already integrated PostgreSQL with FortiSIEM?I couldn’t find any reference in the External System Configuration Guide, and I also haven’t come across any parser or predefined event types for PostgreSQL.From my point of view, the integration should be possible via JDBC, similar to Oracle or other databases. However, I don’t have any hands-on experience with PostgreSQL audit logging or integration, and neither do my customers.Does anyone have an idea or experience to share? Otherwise, I guess it will be a matter of trial and error. :)Best regards,Alex FortiSIEM Tue, 01 Sep 2026 21:53:40 +0200 https://community.fortinet.com/support-forum-92/lose-internet-use-vpn-forticlient-200308 I am currently using MACOS Sonoma when I use FortiClient and connect to the client but I have no access to my internet. I even tried using the router to add a new wheel and nothing worked I can't ask the client to change their settings outside. I need a solution I saw a video on the internet saying that Sonoma has a VPN problem.   Link youtube: watch?v=F60PBFlhjMQ&t=30s   But is it really Sonoma?     Support Forum Tue, 01 Sep 2026 21:09:40 +0200 https://community.fortinet.com/support-forum-92/ssl-vpn-blocks-internet-traffic-split-dns-connection-when-connected-but-only-for-a-specific-user-109896 So, MS Surfaces and Forticlient VPN have been one of my Nemesis' at a specific site for a specific user. Previously when we upgraded his Surface Pro a few years ago, when he'd connect via SSL VPN, internet connectivity would slow way down, at that time we were using the free Forticlient and got permission from Fortinet to get a trial version of the paid client to see if issue was FC related.  After a lot of back and forth, the issue was resolved and I and the user was happy.  I am going to review that ticket again and make sure there wasn't some kind of work around put in place that may be affecting this. Fast forward to the beginning of June, we replaced his Surface and used our typical tool (TransWiz) to transfer his existing Windows profile to new machine, he was happy.  A few days later I get advised that when FortClient Free VPN is connected ALL internet traffic that's not across the link stops, example if I have a remote session with him I loose connectivity.  Also he can't use Zoom or email etc.  None of this is normal with his prior machine  and this does not occur for the 30 other users either (mix of both Mac and PC laptops and other Surfaces) For troubleshooting, removed and reinstalled FC, then installed latest version from 2 weeks ago, no change.  Further testing indicates this ONLY occurs with his AD specific VPN user login and it doesn't matter which Windows Profile we use, his, a local admin or domain admin, all experience the same issue.  While logged into any windows profile, if I use a different user for the FC connection, no issues are all. It works as expected and the split connection also works as expected. Background:All SSL VPN Connections require MFA, when connection comes in, the firewall (100E) checks the internal radius server which checks AD and then forwards the request to external MFA server, the MFA app on the iPhone then requests approval and if approved, the VPN connection is allowed. Any ideas or suggestions?   Support Forum Tue, 01 Sep 2026 21:03:56 +0200 https://community.fortinet.com/support-forum-92/fortigate-vm-under-hyper-v-evaluation-license-fails-web-gui-loops-at-login-229705 Hello!I just recently downloaded the Hyper-V image for FortiGate-VM, version 8.The VM boots fine, no issues, the CLI is accessible through SSH.When comes time to apply the evaluation license, it seems to fail (using the “exec vm-license-options” command).On the Web GUI, the evaluation license seems to apply (by logging in with my Fortinet account) but after a reboot, it says “No License” in the system status.Then, in the Web GUI, I login, briefly see the “what’s new” video pop up and then it pops back to the login screen.Any ideas?Thanks!EDIT: I forgot to add that when running “exec vm-license” it requires a token, which I do not have. Support Forum Tue, 01 Sep 2026 21:02:37 +0200 https://community.fortinet.com/support-forum-92/fortigate-90g-can-t-connect-to-comcast-dns-servers-229726 I have a brand new out of the box Fortigate 90g.  I’m setting it up, and I get to Network → DNS, and I enter Comcast’s DNS servers (Since it’s on a comcast line).  The firewall immediately says the IPs are unreachable, however, I also told the device to run a dhcp server, and hand out comcast dns as the dns on the leases.  The clients are fine, they can resolve addresses all day, no problem it’s something with the fortigate itself, it can’t “use” these addresses.  It’s also saying it’s unable to connect to FortiGuard servers for support info.I tried doing the execute ping command from the cli, it dropped a few packets at first, then was 100%. Is there some filter or something I should turn off (web filter on the WAN interface, maybe? ) that’s causing this?  the IP addresses I’m using are 75.75.75.75 and 75.75.76.76 thanks. Support Forum Tue, 01 Sep 2026 20:15:46 +0200 https://community.fortinet.com/support-forum-92/install-firmware-227914 dear mam/sir, i need to upgrade the firmware of the fortinet this is my client’s fortinet to repair fortinet i want firmware of FWF40C3912006020 fortiwifi -40c  thank you Tejesh Maharjan Support Forum Tue, 01 Sep 2026 19:51:35 +0200 https://community.fortinet.com/forticlient-4/technical-tip-forticlient-installer-creating-in-airgap-network-on-forticlient-ems-205276 DescriptionThis article describes the creation of a FortiClient installer in an air-gap network.ScopeFortiClient EMS v7.4.SolutionFrom v7.4, Forticlient EMS requires additional steps to create Forticlient installer and requires a TAC ticket.Below are the steps to create a FortiClient installer: Log in to EMS, select FortiClient Installer, and select Add. Select More options -> select 'This EMS has no internet connection', and enter a Release and Patch (the build number is optional).Note: Enter the version number if it is not available from the drop down due to air gap setup. Select the required Security features. Add the Invitation and add the required fields. If the Invitation code is not created, select 'create one here' and then select Yes. Create an Invitation code: Select the invitation code previously created, select 'Next' and then download the .json file.  Raise a TAC ticket and attach the .json file. The TAC team will provide a package installer. FortiClient Tue, 01 Sep 2026 16:38:37 +0200 https://community.fortinet.com/fortigate-3/technical-tip-ha-out-of-sync-when-ip-pool-names-differ-between-cluster-members-229728 DescriptionThis article describes an HA sync failure where the secondary shows Not Synchronized and points at firewall.policy, when firewall.ippool is excluded from HA sync in system vdom-exception.ScopeFortiGate.SolutionGUI shows the secondary as Not Synchronized with a firewall.policy.Compare checksums on both members.diagnose sys ha checksum show root firewall.policyFind a policy that matches and one that does not, and compare them.show full-configuration firewall policy <id>Check full config from both members.show full-configuration firewall policyList the pool objects on both members.show firewall ippoolCheck the exclusion list on both members.show system vdom-exceptionIf firewall.ippool is in the list, the pools are meant to be different.Example:If ippool output shows:BES-prod-FGTFW-AZ-A(Primary) # show firewall ippool config firewall ippool edit "SNAT-SFTP-AZ-A" set startip 10.25.204.7 set endip 10.25.204.7 next edit "SNAT-Portal-AZ-A" set startip 10.25.204.8 set endip 10.25.204.8 next edit "SNAT-MQ-AZ-A" set startip 10.25.204.9 set endip 10.25.204.9 next edit "SNAT-AS2-AZ-A" set startip 10.25.204.10 set endip 10.25.204.10 next edit "SNAT-Peppol-AZ-A" set startip 10.25.204.11 set endip 10.25.204.11 next edit "SNAT-OFTP2-AZ-A" set startip 10.25.204.12 set endip 10.25.204.12 next edit "SNAT-WS-AZ-A" set startip 10.25.204.13 set endip 10.25.204.13 next endBES-prod-FGTFW-AZ-B(Secondary) # show firewall ippool config firewall ippool edit "SNAT-SFTP-AZ-B" set startip 10.25.204.39 set endip 10.25.204.39 next edit "SNAT-Portal-AZ-B" set startip 10.25.204.40 set endip 10.25.204.40 next edit "SNAT-MQ-AZ-B" set startip 10.25.204.41 set endip 10.25.204.41 next edit "SNAT-AS2-AZ-B" set startip 10.25.204.42 set endip 10.25.204.42 next edit "SNAT-Peppol-AZ-B" set startip 10.25.204.43 set endip 10.25.204.43 next edit "SNAT-OFTP2-AZ-B" set startip 10.25.204.44 set endip 10.25.204.44 next edit "SNAT-WS-AZ-B" set startip 10.25.204.45 set endip 10.25.204.45 next endThe primary only has the -AZ-A objects, the secondary only has -AZ-B.This output shows the same services, same order, different names and different addresses.Neither member had the other member's objects, so neither could resolve the other's policy.Follow the steps below to fix the issue:Give the pool objects the same name on both members, and leave the addresses alone.Step 1. Rename on the secondary first:The secondary is passing no traffic as standby, so there is no impact. Doing it first also means the primary's push will land cleanly afterward.On the secondary:config firewall ippool rename "SNAT-SFTP-AZ-B" to "SNAT-SFTP" rename "SNAT-Portal-AZ-B" to "SNAT-Portal" rename "SNAT-MQ-AZ-B" to "SNAT-MQ" rename "SNAT-AS2-AZ-B" to "SNAT-AS2" rename "SNAT-Peppol-AZ-B" to "SNAT-Peppol" rename "SNAT-OFTP2-AZ-B" to "SNAT-OFTP2" rename "SNAT-WS-AZ-B" to "SNAT-WS" endCheck the addresses did not change:show firewall ippoolSNAT-SFTP should still be 10.25.204.39.Step 2. Rename on the primary:On the primary:config firewall ippool rename "SNAT-SFTP-AZ-A" to "SNAT-SFTP" rename "SNAT-Portal-AZ-A" to "SNAT-Portal" rename "SNAT-MQ-AZ-A" to "SNAT-MQ" rename "SNAT-AS2-AZ-A" to "SNAT-AS2" rename "SNAT-Peppol-AZ-A" to "SNAT-Peppol"                 rename "SNAT-OFTP2-AZ-A" to "SNAT-OFTP2" rename "SNAT-WS-AZ-A" to "SNAT-WS" endFortiOS updates every policy that used the old name automatically. FortiGate Tue, 01 Sep 2026 16:18:39 +0200 https://community.fortinet.com/support-forum-92/new-circuit-changing-ip-addresses-229659 Hello,We are moving store suites and AT&T is changing their IP address.So we need help updating the new IP address configurations.The move occurs this Saturday, 29th at 5 PM PST.Can we schedule a time to make changes?  Support Forum Tue, 01 Sep 2026 16:16:39 +0200 https://community.fortinet.com/support-forum-92/can-we-restore-config-from-an-expired-trial-fortigate-vm-to-a-new-vm-instance-229672 We have a FortiGate-VM running on a trial/evaluation license that expired on July 2 (about 2 months ago). We're planning to deploy a new FortiGate-VM instance (same IPs) and push the existing configuration backup to it, then license the new instance properly.Is it possible to restore a config backup taken from an expired trial VM onto a newly deployed VM instance with a different serial number? Support Forum Tue, 01 Sep 2026 16:12:28 +0200 https://community.fortinet.com/support-forum-92/fg-ir-26-156-is-forticlient-vpn-only-also-vulnerable-229709 We have become aware of the following security advisories regarding a vulnerability in FortiClient:https://fortiguard.fortinet.com/psirt/FG-IR-26-156https://advisories.ncsc.nl/2026/ncsc-2026-0296.htmlWithin our organization, we exclusively use FortiClient VPN-only for Windows. We do not use the full FortiClient client or FortiClient EMS.Therefore, we would like to know whether the vulnerability described in FG-IR-26-156 also affects the FortiClient VPN-only client.Additionally, we would appreciate clarification on the following:* Is FortiClient VPN-only affected by this vulnerability?* If so, which versions are affected?* Which version does Fortinet recommend installing to address the vulnerability?* Is an updated version of FortiClient VPN-only currently available?* Does the VPN-only client update automatically, or do we need to manually deploy the updated version to all our laptops?We would appreciate your clarification so that we can take the appropriate measures if necessary.Kind regards,CLNSHT Support Forum Tue, 01 Sep 2026 15:50:30 +0200 https://community.fortinet.com/forticlient-4/technical-tip-how-to-install-latest-forticlient-software-on-the-ubuntu-v24-04-199638 DescriptionThis article describes how to install FortiClient in Ubuntu Noble v24.04.ScopeFortiClient v.7.4.0, FortiClient v.7.4.6.SolutionFortiClient is an all-in-one comprehensive endpoint security solution that extends the power of Fortinet's Advanced Threat Protection to end-user devices.This software can be installed on multiple platforms, such as Windows, Android, IOs, Linux, and MacOS.Linux OS comes in multiple flavors, each using different package managers to manage installed applications. This means that the software that is installed on each flavor needs its dependencies to work properly. The package Manager is responsible for those dependencies.For Ubuntu v24.04, those dependencies are not automatically installed but need some manual work from the end-user to have a FortiClient up and running.On the first installation attempt, the following error message may appear:sudo dpkg -i forticlient_vpn_7.4.0.1636_amd64.deb Selecting previously unselected package forticlient. (Reading database ... 127445 files and directories currently installed.) Preparing to unpack forticlient_vpn_7.4.0.1636_amd64.deb ... Unpacking forticlient (7.4.0.1636) ... dpkg: dependency problems prevent configuration of forticlient: forticlient depends on libappindicator1 (>> 0) | libayatana-appindicator1 (>> 0); however: Package libappindicator1 is not installed. Package libayatana-appindicator1 is not installed. dpkg: error processing package forticlient (--install): dependency problems - leaving unconfigured Processing triggers for hicolor-icon-theme (0.17-2) ... Processing triggers for gnome-menus (3.36.0-1.1ubuntu3) ... Processing triggers for desktop-file-utils (0.27-2build1) ... Errors were encountered while processing: forticlient FortiClient v7.4.6 depends on libnss3-tools:sudo dpkg -i forticlient_vpn_7.4.6.1867.M_amd64.deb dpkg: dependency problems prevent configuration of forticlient: forticlient depends on libnss3-tools (>= 3.21); however: Package libnss3-tools is not installed. However, when trying to install dependencies manually, another error is encountered:sudo apt install libappindicator1 Reading package lists... Done Building dependency tree... Done Reading state information... Done Package libappindicator1 is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package 'libappindicator1' has no installation candidate For FortiClient v7.4.6:sudo apt install libnss3-tools To fix this issue, dependencies need to be manually downloaded and installed before FortiClient installation. Step 1: Check Ubuntu version:lsb_release -a  Step 2. Install updates and upgrades:sudo apt update && sudo apt upgrade -y  Step 3: Download dependencies: Required packages can be downloaded manually via HTTP or using wget from the CLI:cd Downloads/ wget -O libappindicator1.deb http://ftp.de.debian.org/debiarmn/pool/main/liba/libappindicator/libappindicator1_0.4.92-7_amd64.deb wget -O libdbusmenu.deb http://ftp.de.debian.org/debian/pool/main/libd/libdbusmenu/libdbusmenu-gtk4_18.10.20180917~bzr492+repack1-3_amd64.deb Step 4: Install packages:sudo apt install -y ./libappindicator1.deb ./libdbusmenu.deb  Step 5: Clean the 'Downloads' folder from downloaded packages to preserve space:rm ./lib*  Step 6: Download FortiClient from support.fortinet.com or from FortiClient Product Downloads where contact details to get the download link are needed: In this case, a temporary link is provided.wget https://filestore.fortinet.com/forticlient/forticlient_vpn_7.4.0.1636_amd64.deb   Step 7: Install FortiClient:$ sudo apt install -y ./forticlient_vpn_7.4.0.1636_amd64.deb  After the final step, FortiClient should be visible under the apps section and a connection can be established once a tunnel is created: FortiClient Tue, 01 Sep 2026 15:25:03 +0200 https://community.fortinet.com/fortisoar-community-217/widgets-and-connectors-json-schema-229629 Hello, there!I often need to cross check the referenced documentation when working with widgets and connectors info.json files to validate their schema, whether it's to add a new functionality or review existing ones.If anyone here has their JSON schema to be automatically used in IDEs/code editors, it would be highly appreciated if you could share it, please. FortiSOAR community Tue, 01 Sep 2026 15:19:53 +0200 https://community.fortinet.com/support-forum-92/vpn-ipsec-remote-access-up-but-no-traffic-221472 I try to build VPN remote access using ipsec to preparing upgrade my fortigate production from 7.2 to 7.6 on my lab.My fortigate lab use version 7.6.4 and after i create vpn tunnel, the forti client is connected and get the ip address but the client is not able to reach to anywhere. The firewall policy and static routing was working fine.Open case to the fortigate support and they also feel strange with this issue. Someone here can help how to toubleshoot?Here my VPN config===========================config vpn ipsec phase1-interface edit "VPN-RA" set type dynamic set interface "port1" set ike-version 2 set peertype any set net-device disable set mode-cfg enable set proposal aes128-sha1 set add-route disable set comments "VPN Remote Access" set dhgrp 5 20 set wizard-type dialup-forticlient set transport auto set fortinet-esp enable set ipv4-start-ip 10.64.200.20 set ipv4-end-ip 10.64.200.50 set dns-mode auto set save-password enable set client-auto-negotiate enable set client-keep-alive enable set psksecret ENC xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx next end config vpn ipsec phase2-interface edit "VPN-RA" set phase1name "VPN-RA" set proposal aes128-sha1 set dhgrp 5 20 set comments "VPN: VPN-RA -- Created by VPN wizard" next end Here my routing===========================config router static edit 1 set distance 1 set sdwan-zone "SDWAN_INTERNET" next edit 2 set dst 192.168.100.0 255.255.255.0 set gateway 192.168.100.1 set device "port2" next edit 3 set dst 10.64.200.0 255.255.255.0 set device "VPN-RA" next end Here my firewall policies===========================config firewall policy edit 3 set name "LAN to LAN" set uuid 9be61642-ebbf-51f0-c819-41d789e59def set srcintf "ss_vlan100" "ss_vlan110" "ss_vlan120" "ss_vlan140" "loopback" "VPN-RA" set dstintf "ss_vlan100" "ss_vlan110" "ss_vlan120" "ss_vlan140" "loopback" "VPN-RA" set action accept set srcaddr "all" set dstaddr "all" set schedule "always" set service "ALL" set logtraffic all next end Here my forticleint status, i ping to my loopback interface but timeoutThe routing was pushed to the client Support Forum Tue, 01 Sep 2026 14:22:30 +0200 https://community.fortinet.com/support-forum-92/transfer-license-to-a-new-fortigate-device-143645 My FortiGate 100F, has been damaged by lightning. We have purchased a new FortiGate 100F. We want to transfer the license (2 years subscription) from the damaged FortiGate 100F to a new one FortiGate 100F. I wanted to transfer the license directly, but unfortunately I have already registered the new FortiGate 100F on my account, so I can't transfer the license.Can anyone help me?Many thanks. Support Forum Tue, 01 Sep 2026 14:01:03 +0200 https://community.fortinet.com/support-forum-92/issues-on-iphone-with-forticlient-vpn-229703 My customers are can connect our VPN using their Windows PCs, Android Phones , MacOS PCs successfully. iPhone users also were could be connecting but for a while, I guess after latest update on App Store, they cannot connect to our VPN.We have a custom TOTP authentication server with Radius.All the other FortiClient VPN users on other devices still connecting , and also we have not changed anything in our Forti or Radius.Just Apple iPhone FortiClient VPN users cannot connecting.  Support Forum Tue, 01 Sep 2026 13:10:07 +0200 https://community.fortinet.com/support-forum-92/configure-ntp-on-forticlient-ems-7-4-4-219893 Hi EMS adminsOn EMS 7.4.3 I was able to configure NTP via OS config files (chrony).But on 7.4.4 there is no access to sh/bash and I can't find anywhere some command to set it up with emscli.In emscli cmd ref I just found this command but nothing said about setting time server.https://docs.fortinet.com/document/forticlient/7.4.4/ems-cli-reference/239339/execute-timeAny useful info would  e appreciated. Support Forum Tue, 01 Sep 2026 13:00:14 +0200