https://community.fortinet.com On the Forum you can ask questions or take part in discussions. https://community.fortinet.com/support-forum-92/troubleshooting-tip-fortisiem-ha-supervisor-node-shows-outdated-cmdb-because-the-database-replica-is-not-streaming-231011 This article describes how to identify a Supervisor with DB node whose PostgreSQL replica stopped following the database Leader after a failover or switchover. It also describes how to rebuild the replica and how to detect the issue before it affects the cluster. Support Forum Fri, 30 Oct 2026 22:45:25 +0100 https://community.fortinet.com/fortimanager-27/fortimanager-version-7-6-8-trying-to-install-ssl-ssh-profile-settings-that-are-not-supported-on-2gb-fortigate-devices-230815 DescriptionTroubleshooting steps for installation failure in FortiManager version 7.6.8 due to the 'udp-not-quic' option under 'config firewall ssl-ssh-profile' when installing to FortiGate models with 2GB of memory.ScopeFortiManager.  SolutionIn version 7.6.8, FortiManager has added some lines to the configuration to push. For example:config firewall ssl-ssh-profile edit "custom-deep-inspection" config https set udp-not-quick allow end config dot set udp-not-quick allow end next endWhen installing on FortiGate models with 2GB of memory, this change causes the installation to fail.These models do not support this option in FortiOS version 7.6.This behavior is due to a known issue, with ID 1352524.Workaround: Set 'udp-not-quic' to 'block' in the affected SSL/SSH profiles.Set udp-not-quic to block in the https and dot sections of the affected SSL/SSH profiles.Go to Policy & Objects -> Advanced.Select the CLI Configurations tab.In the left pane, under firewall, select ssl-ssh-profile.Select the affected profile (for example, custom-deep-inspection), then select Edit.In the Edit firewall ssl-ssh-profile window, scroll to the https section and set udp-not-quic to block.Scroll to the dot section and set udp-not-quic to block.Select OK.Repeat steps 4 to 7 for each SSL/SSH profile that is used by the 2GB FortiGate devices.Install the policy package again.Note: Some models may not accept this setting. For example, a comment on this article reports 'Operation not supported. detail: object not support' on a FortiGate 50G. Contact Fortinet Support if the error persists.Fix: A fix is expected in FortiManager firmware versions 7.6.9 and 8.0.3.Related document:Known issues FortiManager Fri, 30 Oct 2026 20:58:47 +0100 https://community.fortinet.com/fortigate-3/fortigate-enters-conserve-mode-after-upgrading-to-fortios-7-6-8-ipsengine-7-01200-230996 DescriptionThis article describes an issue with the default IPSEngine 7.01200 that is being distributed with the installation of FortiOS 7.6.8. The IPSEngine will be installed for FortiOS through the upgrade process or a fresh installation. ScopeFortiOS 7.6.8.SolutionAfter upgrading or installing FortiOS 7.6.8, a FortiGate configured with an IPS profile may face an issue with conserve mode caused by IPSEngine:FGT # diagnose sys top-mem 20 ipsengine (32351): 4935072kB ipsengine (32350): 1898962kB ipsengine (32349): 1341961kB ipsengine (32352): 697470kB node (3604): 94104kB mvl.user (2258): 81701kBThe output for crashlog will show the following:FGT # diagnose debug crashlog read | grep "conserve mode" 2026-10-16 10:26:40 green="13075 MB" msg="Kernel enters memory conserve mode 2026-10-16 10:27:24 green="13075 MB" msg="Kernel exits memory conserve mode" 2026-10-16 12:33:56 green="13075 MB" msg="Kernel enters memory conserve mode 2026-10-16 12:39:56 green="13075 MB" msg="Kernel exits memory conserve mode" 2026-10-17 12:31:16 green="13075 MB" msg="Kernel enters memory conserve mode 2026-10-17 12:31:16 green="13075 MB" msg="Kernel exits memory conserve mode" 2026-10-17 14:03:53 green="13075 MB" msg="Kernel enters memory conserve mode 2026-10-17 14:03:53 green="13075 MB" msg="Kernel exits memory conserve mode" 2026-10-17 17:14:07 green="13075 MB" msg="Kernel enters memory conserve mode 2026-10-17 17:14:07 green="13075 MB" msg="Kernel exits memory conserve mode" 2026-10-18 08:59:53 green="13075 MB" msg="Kernel enters memory conserve mode 2026-10-18 08:59:53 green="13075 MB" msg="Kernel exits memory conserve mode"The result of "get system performance status" also shows high memory usage:FGT # get sys perf status CPU states: 0% user 1% system 0% nice 99% idle 0% iowait 0% irq 0% softirq ---Omitted--- Memory: 98991688k total, 86703372k used (87.6%), 11693452k free (11.8%), 594864k freeable (0.6%)This issue has been resolved in IPSEngine 7.01204. Log a ticket with Support to obtain IPSEngine 7.1204 if an IPS profile is used on the FortiGate. FortiGate Fri, 30 Oct 2026 20:32:35 +0100 https://community.fortinet.com/blogs-103/fortinet-video-library-october-2026-roundup-231010 Fortinet Video Library — October 2026 Roundup Hi everyone, here are 12 full-length videos published on Fortinet’s official Video Library YouTube channel during October, checked through October 30. I’ve grouped them by product and included YouTube and video.fortinet.com links. Shorts are excluded.FortiGate & FortiOSOct. 28 — FortiOS 8.0.1: Configuring Hashed External Feeds to Block WebsitesYouTube | Fortinet Video Library Oct. 27 — FortiOS 8.0: Steering SD-WAN Traffic Based on Underlay BandwidthYouTube | Fortinet Video Library Oct. 22 — FortiOS 7.6.8: Configuring Application Hold Timer to Hold Newly Created Application SignaturesYouTube | Fortinet Video Library Oct. 13 — FortiOS 8.0: Using IPAM for Dual-Stack IPsec VPN Remote Endpoints' IPv6 Address AssignmentYouTube | Fortinet Video Library Oct. 8 — FortiOS 7.6.7: Enabling NPU Offloading for IPsec VPN over VNE Interfaces to Improve PerformanceYouTube | Fortinet Video Library Oct. 6 — FortiOS 8.0.1: Configuring User-Defined Application Classifications to Application SignaturesYouTube | Fortinet Video Library Oct. 5 — FortiOS 8.0.1: Using the Setup Wizard to Choose or Skip Initial Firewall Policy SetupYouTube | Fortinet Video LibraryFortiManager CloudOct. 7 — FortiManager Cloud 8.0: Remote FortiGate GUI AccessYouTube | Fortinet Video LibraryFortiAnalyzerOct. 1 — FortiAnalyzer 8.0: Agentic AI - Alert Triage AgentYouTube | Fortinet Video LibraryFortiAuthenticatorOct. 26 — What's New in FortiAuthenticator 8.0.4YouTube | Fortinet Video LibraryFortiSwitchOct. 23 — Introducing the FortiSwitch AX9000G SeriesYouTube | Fortinet Video LibraryThreat ResearchOct. 29 — FortiGuard Outbreak Alert (Walkthrough): PHP2Shell Remote Code Execution VulnerabilitiesYouTube | Fortinet Video LibraryHave a topic you'd like to see covered in a future video? Let us know in the comments!Thanks for watching, check out video.fortinet.com for videos categorized by product, and subscribe to our YouTube channel for the most up-to-date videos.  Blogs Fri, 30 Oct 2026 19:29:58 +0100 https://community.fortinet.com/fortigate-3/administrator-sso-authentication-fails-after-upgrade-to-fortios-7-6-8-230826 DescriptionAfter upgrade to FortiOS 7.6.8, administrator SSO authentication fails. FortiOS access requires a local administrator or a RADIUS/LDAP/TACACS+ administrator account.ScopeFortiOS 7.6.8.SolutionAfter upgrade, administrator SSO will fail with the error message "Single Sign-On Failed", without presenting any option to enter an SSO administrator credential.The following FortiOS login methods are confirmed affected by the issue:Administrator FortiCloud SSO.Administrator third-party SSO, for example see Technical Tip: Configuring SAML SSO login for FortiGate administrators with Entra ID acting as SAML IdP.Security Fabric SSO with root FortiGate as IdP, for example see Configuring single-sign-on in the Security Fabric.Confirmed not affected:VPN user SSO authentication.Other FortiOS versions including FortiOS 7.2.14, 7.4.13, 7.6.7 and 8.0.2.Local administrator authentication.Remote administrator authentication using RADIUS/LDAP/TACACS+.While access to the FortiGate from FortiManagement Cloud (FortiGate Cloud) is technically not affected, SSO authentication to the FortiGate is still not possible over this management path.Issue matching:To confirm the issue, check the FortiOS crashlog for a matching "FORTISM Violation" from the time of the access attempt. This can be done by accessing the FortiGate using a local administrator account and executing diagnose debug crashlog read | grep YYYY-MM-DD .FGT-A(Primary) # diagnose debug crashlog read | grep 2026-10-20 6545: 2026-10-20 11:09:52 domain=WEB_AUTH domainid=37 acl=write msg="[FORTISM Violation: pid-236, 6546: 2026-10-20 11:09:52 api-open_w(), path-/tmp/ftnt1_sp_metadata.xml]." 6547: 2026-10-20 11:10:24 domain=WEB_AUTH domainid=37 acl=write msg="[FORTISM Violation: pid-236, 6548: 2026-10-20 11:10:24 api-open_w(), path-/tmp/ftnt1_sp_metadata.xml]."The issue is under investigation and scheduled for fix in FortiOS 7.6.9.Workaround:At this time, the only available workaround is to use another administrator authentication method.If no suitable administrator account exists, console access to a physical device can be used to recover access, see Technical Tip: Boot the backup firmware and config via console.If the device is centrally managed by FortiManager or a valid FortiManagement Cloud subscription, an administrator can be added. See Recover access to FortiGate via FortiManagement Cloud.Related article:Technical Tip: Create a 'break glass' admin account on the FortiGate as a backup for remote authentication/MFA (Recommendation) FortiGate Fri, 30 Oct 2026 19:15:45 +0100 https://community.fortinet.com/support-forum-92/websites-not-loading-with-deep-inspection-400-bad-request-230973 Since yesterday morning a lot of websites give a 400 Bad Request ( see screenshot) when DeepInspection is enabled.Disabling DeepInspection fixed the problem.I also saw other issues relating DeepInspection(https://community.fortinet.com/support-forum-92/some-website-not-loading-with-deep-inspection-230891) But this seems to be other. We already have policy in Proxy mode en disabling AV is also not working.We use firmware level 7.4.13. More people have issues with this?  Support Forum Fri, 30 Oct 2026 18:20:05 +0100 https://community.fortinet.com/fortigate-3/unable-to-configure-ip-address-in-vpn-tunnel-interface-in-fortios-7-6-8-231009 DescriptionAfter upgrading to FortiOS 7.6.8, administrators may be unable to configure an IP address for new VPN tunnels via the GUIScopeFortiOS 7.6.8.SolutionIf you try to configure only the IP address, the following behavior is observed: The FortiGate will not display any error message, but the Tunnel interface will remain with the default IP address 0.0.0.0/0.0.0.0.If you try to configure the tunnel IP address and the Remote IP address at the same time, the IP field will revert back to 0.0.0.0 and the GUI will display an error message:Error message:IP must be set if remote IP is defined.Must set ip if remote-ip is defined.Object set operator error, -118 discard the setting.SolutionThe issue is under investigation, and a permanent fix is not available yet.WorkaroundConfigure the IP address and remote address via the CLI with the following commands:config system interface edit <tunnel-interface> set ip <ipaddress> 255.255.255.255 set remote-ip <remoteIP> <subnet mask> end FortiGate Fri, 30 Oct 2026 17:43:47 +0100 https://community.fortinet.com/fortidlp-66/retirement-of-legacy-fortidlp-tenant-domain-231008 DescriptionAn explanation of the retirement of Legacy FortiDLP Tenant Domain.ScopeFortiDLP.OverviewOn November 30th, 2026, two years after Fortinet acquired Next DLP, access to the FortiDLP Console using the legacy reveal.nextdlp.com domain will no longer be supported. The FortiDLP Console will only be accessible via the FortiCloud Services menu or https://fortidlp.forticloud.com.From that date onward, to access the FortiDLP Console, the following is required:A FortiCloud account containing a valid FortiDLP license registration.All FortiDLP operators must be configured in the FortiCloud account as IAM users with access to FortiDLP.FortiCloud accounts can also be integrated with an external IdP for SAML SSO login. For assistance, contact your Fortinet Account Representative.For a smooth transition, complete the following steps before November 30, 2026:Verify that all operators can log in to the FortiDLP Console using their FortiCloud IAM User accounts.Update all references to the legacy domain, such as bookmarks, procedures, internal documentation, and automated processes, to point to https://fortidlp.forticloud.com. To obtain the FortiDLP tenant domain for API scripts and LDAP sync automation, log in to the FortiDLP Console via https://fortidlp.forticloud.com, then navigate to Admin Settings -> About. The region-specific domain is displayed under API Explorer. FortiDLP Fri, 30 Oct 2026 17:23:47 +0100 https://community.fortinet.com/fortinac-f-57/http-403-when-creating-security-actions-in-fortinac-231007 DescriptionCheck the installed license and administrator profile when saving a Security Action returns HTTP 403. The required entitlement depends on whether the action is used for Security Incidents or Endpoint Compliance.ScopeFortiNAC with a PLUS license.SolutionSymptomsWhen you add a Security Action, such as Set Host Role, clicking OK can display the following error even when the administrator profile has all available permissions selected:Add Event Action Error - HTTP Status 403 - Forbidden The requested URL was not found on this server.In the browser developer tools, the failed save request appears as:POST /actions/policy/event-action/ HTTP 403 ForbiddenAdmin permission request and attribute error:License and permission requirementsThe installed license controls the available feature set. The administrator profile controls which licensed operations you can perform. Selecting all available administrator permissions does not enable features outside the installed license. See the FortiNAC Ordering Guide.SolutionVerify the installed licenseGo to System -> Settings -> System Management -> License Management.Record the active license name and FortiNAC build. Confirm whether you are configuring an action under:Logs -> Security Incidents.Policy & Objects -> Endpoint Compliance.Inspect the available administrator permissionsGo to Users & Hosts -> Administrators and open the Profiles tab.Click Add to open an Admin Profile.Select the Permissions tab.Expand Policy and, where available, Security Rules.Identify the views associated with Security Actions and inspect the Access, Add/Modify, and Delete settings.Check both the selected state and whether each control can be changed. A checked, greyed control can indicate an automatically enabled permission; it does not necessarily indicate denied access.Compare these settings with the profile assigned to the affected account. If the required write permission is available but unselected, enable it in the assigned profile and save.VerificationFor Security Incidents / Automated Threat Response actions, the appliance requires PRO licensing and an administrator profile that permits the relevant operation. If that functionality is required, apply the appropriate PRO entitlement through the supported licensing process. See Resolved Issues Version F 7.6.3: issue 1158534.You can click Cancel after inspecting the new profile without saving it.After correcting the applicable license or profile restriction, log out and log back in. Administrator profile changes require a new login.Create an unassigned test action and save it. Verify that:The action appears in the Security Actions list.You can reopen the action and view its saved activities.The save request no longer returns HTTP 403 Forbidden.If the operation still fails, collect the failed request and corresponding server logs for further investigation. FortiNAC-F Fri, 30 Oct 2026 17:08:05 +0100 https://community.fortinet.com/support-forum-92/flow-mode-inspection-drops-the-2nd-tcp-segment-of-a-post-quantum-x25519mlkem768-tls-clienthello-when-the-client-does-not-use-tcp-timestamps-windows-default-230899 Product: FortiGate-80F-POE, S/N FG80FPTK24000713 Firmware: FortiOS v7.6.8 build3744 (GA.M); IPS Engine 7.01200; AV Engine 7.00062 Severity: 3 (business impact, workaround available)SummarySince Windows clients started sending hybrid post-quantum key shares (OpenSSL 3.5+, Chrome/Edge), TLS 1.3 handshakes from Windows hosts through our FortiGate time out. The ClientHello (~1.5–2 KB) is split into two TCP segments. For sessions without the TCP timestamp option (Windows default timestamps=allowed), the FortiGate ACKs the second segment to the client on behalf of the server. It then retransmits that segment on wan1 about 6 times, and the server never acknowledges it. The handshake hangs until the client times out (FIN from server after ~15 s, or RST after ~35 s).macOS clients (TCP timestamps on) are unaffected through the same policy, with the same NAT IP and destination, and even with a byte-identical ClientHello split at the same offsets.This looks related to KB “ERR_SSL_PROTOCOL_ERROR when using flow-based deep inspection due to ML-KEM” (known issue), but our IPS engine (7.01200) is already newer than the fixed build (7.1026). Our profile is certificate-inspection, not deep inspection, and the failure depends on the TCP timestamp option.PolicyPolicy 19 sw-ap-corp_to_WAN: inspection-mode flow, ssl-ssh-profile certificate-inspection, av-profile default, ips-sensor default, auto-asic-offload enable, NAT to wan1 interface IP.ReproductionWindows 11 client (TCP timestamps not sent in SYN). Python 3.14 / OpenSSL 3.5: ssl.create_default_context().wrap_socket(socket.create_connection(('104.18.188.228',443)), server_hostname='api.pipedrive.com')The handshake times out. Destination: Cloudflare (Pipedrive) 104.18.188.228 / 104.18.189.228.EvidenceFortiGate sniffer (diagnose sniffer packet any ... 6), failing Windows session:The client sends seq X (1250 and seq X+1250 (707 B, PSH). Both are forwarded on wan1 with identical payload and a valid checksum.The server ACKs only X+1250.The FortiGate sends the client an ACK for X+1957, which the server never sent.The FortiGate retransmits the 707 B segment on wan1 at +0.25 s, +0.9 s, +2 s, +4 s, +7.7 s and +14.7 s. The server never ACKs it and FINs at ~15 s with ack=X+1250.Client-side pcap (pktmon): the client receives ACK for the full ClientHello 20 ms after sending it. The server’s FIN carries ack=1251 with SACK only for the client’s FIN. Pcap available.Same host, Windows netsh int tcp set global timestamps=enabled: OK (TLS 1.3 in 0.1–0.2 s), even though the ClientHello is still split (1238 + 286 . ECN on/off makes no difference.Same host, temporary policy without UTM (no ssl-ssh-profile / AV / IPS): OK, 2/2.Component isolation (temporary policies above policy 19, same host, 2 attempts each):certificate-inspection + IPS (no AV): FAILcertificate-inspection + AV (no IPS): FAILcertificate-inspection only (no IPS, no AV): FAIL (16 s, 300 B received; same pattern as above)IPS + AV with no-inspection SSL profile: OK (1 s, full handshake)The trigger is the certificate-inspection SSL/SSH profile in flow mode. IPS and AV are not involved.Classic X25519 only (ClientHello ~500 B, one segment): OK.ExpectedThe FortiGate should not ACK client data on the server’s behalf in flow mode, or, if it does, should deliver it reliably. The handshake should complete regardless of the client’s TCP timestamp option. Support Forum Fri, 30 Oct 2026 17:07:50 +0100 https://community.fortinet.com/fortiauthenticator-8/technical-tip-fortiauthenticator-support-tacacs-for-authentication-and-authortization-99549 Description   This article describes the basics of TACACS+ authentication, how this can be used for authorization, and general troubleshooting logs.  Scope   FortiAuthenticator.   Solution   Provides Authentication, Accounting, and Authorization for devices as routers, switches, firewalls, and servers. Uses TCP port 49, and the payload is encrypted, providing security.    Working: User attempts to log in.  Username is checked locally; if present, it is forwarded to the TACACS+ server.  Password is verified successfully, forwarded, and processed to verify the Trusted host list. The required profiles and resources are allowed for the user. Successful authentication returns the Vendor-specific attributes (VSA) as per the specified user group.   Successful snippets of logs for reference. TACACS+ Authentication logs:   2025-12-09T09:42:08.789839+00:00 FAC01 authen_tac_plus[2916]: 10.10.10.2 test1 ssh 10.10.10.1 pap login succeeded2025-12-09T09:42:08.826070+00:00 FAC01 authen_tac_plus[44930]: 10.10.10.2 test1 ssh 10.10.10.1 pap login succeeded   TACACS+ Accounting logs: 2025-12-09T09:42:09.802826+00:00 FAC01 acct_tac_plus[2916]: 10.10.10.2 test1 ssh 10.10.10.1 start start_time=1215575841 task_id=64612 service=test-ssh protocol=ip   TACACS+ Authorization logs:   2025-12-09T09:42:08.523056+00:00 FAC01 author_tac_plus[60848]: 10.10.10.2 new.user/TestRule ssh 10.10.10.1 add  test-ssh group1=global-read-write shell=/usr/bin/cli   Troubleshooting Commands:  For Packet capture on FortiGate, diagnose sniffer packet any ‘hostx.x.x.xand port 49’ 6 0 a. To test the credentials directly from FortiGate, use the command 'diagnose test authserver tacacs+ <servername> <username> <password>'. Packet capture on FortiAuthenticator using the command, execute tcpdump -c2 -v -i port host x.x.x.x and port 49. On FortiAuthenticator, more logs can be viewed by downloading: FortiAuthenticator/Logging/Log Access/Logs -> Downloads drop-down list -> Authentication. FortiAuthenticator/Logging/Log Access/Logs -> Downloads drop-down list -> Accounting. FortiAuthenticator/Logging/Log Access/Logs -> Downloads drop-down list -> Authorization.   Related articles:FortiAuthenticator can be used as a TACACS+ server for Cisco Switch. Refer to Technical Tip: FortiAuthenticator as TACACS+ server for Cisco switch and clear pass for remote user authorization. FortiAuthenticator can be used as a TACACS server, and FortiGate as the TACACS+ client. Refer to Technical Tip: Configure FortiAuthenticator as TACACS+ server, and FortiGate as TACACS+ client for authentication, and authorization  FortiAuthenticator is used as the TACACS+ server with FortiAnalyzer/FortiManager. Refer to Technical Tip: FortiAuthenticator as TACACS+ server for FortiAnalyzer / FortiManager user authorization. FortiAuthenticator is used as the TACACS+ server with steps for user authorization. Refer to Technical Tip: FortiAuthenticator as TACACS+ server for FortiGate user authorization. FortiAuthenticator Fri, 30 Oct 2026 16:44:40 +0100 https://community.fortinet.com/support-forum-92/fortinet-ssl-vpn-virtual-ethernet-adapter-disabled-230882 Running FortiClient 7.4.8.2066 on Windows 11 25H2.What’s happening, Users can connect, everything works.  Next time they open laptop, unable to connect VPN Software.The Fortinet SSL VPN Virtual Ethernet Adapter is disabled.  Simple restart of laptop re-enables card, works again.    100 Users, at any one moment in time, 30 NICs are disabled on average.My best guess, and it is a guess, relates to Power Management on WiFi card.  Windows is disabling WiFi when you put laptop to sleep.  This event disables FortiClient NIC.  Wake laptop up, WiFi enables itself, FortiClient doesn’t.Has anyone seen this before ThanksBryan Support Forum Fri, 30 Oct 2026 16:28:43 +0100 https://community.fortinet.com/support-forum-92/fortiauthenticator-tacacs-server-not-working-with-nvidia-cumulus-switch-231006 Hello team,I am using FortiAuthenticator Tacacs+ server. It is working with Cisco but not with Nvdia Cumulus switch. Because Nvidia cumulus switch uses Linux PAM module for Tacacs and it send authorization request first instead of Authentication. There is no setting in the forti Autheticator like”allow authorization before authentication”. But cisco it works because it uses authetication and then authorization. Any suggestion how to allow authorization first in forti Authenticator? Because other Tecacs servers have this option “authorize before authenticate” Support Forum Fri, 30 Oct 2026 16:28:34 +0100 https://community.fortinet.com/support-forum-92/fortigate-g-series-are-you-seeing-a-notification-for-the-7-4-13-upgrade-230889 Our 700G, running version 7.4.12, is not showing a notification that version 7.4.13 is available (I expect I’ll just update it manually soon). The licenses are valid, and the Fortinet servers are reachable. Do you know why this is happening? Is anyone else experiencing this?  Support Forum Fri, 30 Oct 2026 16:27:41 +0100 https://community.fortinet.com/fortianalyzer-6/masking-fields-in-fortianalyzer-output-profiles-231005 DescriptionThis article explains how to use variables to mask specific field values when configuring FortiAnalyzer Fluentd Output Profiles to send logs via the Azure Monitor Log Ingestion API.ScopeFortiAnalyzer 8.0.SolutionGo to System Settings -> Advanced -> Log Forwarding -> Output Profile -> Create New Type the name, and then select Azure Logs Ingestion as the type.Create the variables under Configuration and Fields, and then click Validate and Save.<match> tenant_id ${TENANT_ID} client_id ${CLIENT_ID} client_secret ${CLIENT_SECRET} dce_url ${DCE_URL} dcr_id ${DCR_ID} table_name ${TABLE_NAME} </match>Once the configuration is complete, go to Log Forwarding -> Settings -> Create New, enter a name, select Remote Server as the server type, choose Forward via Output Plugin, select the profile you created under Output Profile, and select OK.Related document:FortiAnalyzer Fluentd supports the Azure Monitor Log Ingestion API FortiAnalyzer Fri, 30 Oct 2026 16:25:51 +0100 https://community.fortinet.com/fortigate-3/explanation-for-bgp-debug-output-107-transport-endpoint-is-not-connected-231004 DescriptionThis article describes how to manage the condition where the BGP neighborship remains in the Active state, and the BGP debug shows the message '107-Transport endpoint is not connected'.ScopeFortiGate.SolutionAssuming a scenario where a FortiGate is receiving no traffic, the first check to perform is to verify the presence of the necessary routes in the VDOM routing table using the command:get router info routing-table allIf the required route is missing and should be announced by a BGP neighbor, you need to check the neighbor state with the command:get router info bgp neighbors <neighbor-ip>When a BGP neighbor remains in the Active state, and it is not possible to perform checks directly on the neighbor's configuration and status, it is important to first understand what this state indicates. StateMeaningIdleThe local FortiGate has not started the BGP process with the neighbor. For eBGP, this can be because the peer is multiple hops away and multihop is not enabled.ConnectThe BGP process has started but has not initiated a TCP connection, possibly due to improper routing.ActiveA TCP connection was initiated, but there is no response, a delivery, or a remote-peer response problem.Assuming the neighborship remains in the Active state, this indicates that the TCP 3-way handshake has not been completed. If collecting the BGP debug logs, as explained here:Technical Tip: Capture BGP debugs for a specific neighbor, the output contains the message:107-Transport endpoint is not connectedThis confirms that the 3-way handshake was never completed.Another similar error message that might be possible to find in the debug logs:104-Connection reset by peerThis means the handshake was interrupted due to a remote reset.These errors can be caused by several factors, including:Incorrect routing: for the IP address used by the FortiGate to establish the BGP peering.Asymmetric routing: resulting in TCP packets on port 179 never being received.A firewall in the path: dropping TCP port 179 packets sent by the neighbor, or ISP filters.Misconfigured BGP peer IP: for example, a neighbor group configured on the remote side with an IP that falls outside the subnet used by the FortiGate.BGP password mismatch (if configured).QoS misconfigurations.Other routing problems affecting TCP port 179 packets, such as a Layer 3 routing loop.IPsec Phase 2 selector mismatch: In the case of BGP running over an IPsec VPN tunnel.Related article: Technical Tip: FortiOS BGP Resource List FortiGate Fri, 30 Oct 2026 15:09:52 +0100 https://community.fortinet.com/support-forum-92/forticlient-vpn-ipsec-saml-and-microsoft-global-secure-access-client-201018 Hello everyone,I'm not sure if I'll get any help on this topic here, but I'll give it a try anyway.We primarily use FortiClient VPN to establish a VPN connection to our Fortigate via IPsec using SAML.Some employees who do not work in the company, but are mainly in the home office or work on the road, have the Microsoft Global Secure Access Client installed on their Windows devices.With the background of tunneling the Microsoft365 connections and web connections via the EntraID GSA without FortiClient VPN.https://learn.microsoft.com/en-us/entra/global-secure-access/overview-what-is-global-secure-accessIn exceptional cases, however, these employees may still require an IPsec VPN connection in order to access various VLANs behind the Fortigate.The problem is as follows. The employee can connect to the FortiClient VPN, but the connection is terminated after approx. 10 seconds. Nothing can be seen in the FortiClient VPN for incoming traffic.The FortiClient VPN log files there is nothing useful.If the Global Secure Access Client is disabled while connecting to the FortiClientVPN, or web filtering is disabled, the tunnel remains active. If the Global Secure Access Client is then enabled again, both will also work.All internal subnets or the IP of the gateway is already set to Bypass in EntraID, but unfortunately this does not change the behavior.FortiClient VPN 7.4.2.1737FortiGate 7.6Tomorrow, I'll take a look on the fortigate debug.I have already opened a ticket with Microsoft, but have not yet received anything useful in return.Thanks Support Forum Fri, 30 Oct 2026 13:52:57 +0100 https://community.fortinet.com/support-forum-92/standalone-fortiswitch-external-to-fortigate-230870 We have a few switches (124G) which are standalone, but daisy changed together in a loop, one switch per building. This all works. We have 3 ISPs, one in each building. We have two Fortigates, so two of the switches have links to a Fortigate port, one port per ISP. We do this for redundancy. My question is: Should I do any special commands on these standalone switches for hardening purposes? Since at least some of the ports are directly connected to the ISP.Thanks. Support Forum Fri, 30 Oct 2026 13:11:19 +0100 https://community.fortinet.com/support-forum-92/resolved-eappassworderror-with-ikev2-eap-ttls-and-fortiauthenticator-2fa-230861 I recently encountered and resolved the following issue, and I am sharing the troubleshooting process because the FortiClient error did not immediately indicate the actual cause.EnvironmentFortiClient EMS: 7.4.8 FortiClient for Windows: 7.4.8 FortiAuthenticator: 6.6.9 FortiGate VM: FortiOS 7.4.13 VPN type: IKEv2 IPsec Authentication method: EAP-TTLS User source: LDAP/Active Directory Two-factor authentication: FortiToken managed through FortiAuthenticatorIssueWhen I tried to establish the VPN connection using a domain account, FortiClient returned the following error:EAPPasswordErrorThe authentication process failed, and the VPN connection could not be established.Since I was taking over an existing installation, I was not yet fully familiar with every step of the authentication flow between FortiClient, FortiGate, FortiAuthenticator, and the LDAP server.Troubleshooting performedI initially verified the following points: The FortiGate was reachable from the client’s public IP address. A direct LDAP authentication test from the FortiGate was successful for both connectivity and credential validation. EAP-TTLS was selected in the VPN profile distributed through FortiClient EMS. EAP-TTLS was enabled in the FortiAuthenticator RADIUS policy, while EAP-MSCHAPv2 was disabled. The default realm configured in the RADIUS policy was associated with the correct LDAP identity source. During an authentication test from FortiAuthenticator, I received an error indicating that the user could not be found in the imported users database. I also found an Access-Reject event containing the message “User Locked”, but I could not confirm whether it was related to the same VPN authentication attempt. Since the direct LDAP test was successful, I initially suspected that the authentication request was not being processed correctly at some point in the chain between IKEv2, EAP-TTLS, RADIUS, FortiAuthenticator, and LDAP.SolutionI eventually found that the problem was related to the way the second authentication factor had to be entered.When EAP-TTLS/PAP is used with two-factor authentication through FortiAuthenticator, FortiClient does not display a separate prompt for the FortiToken code.The LDAP password and the current OTP must be entered consecutively in the same password field:LDAP password + OTPFor example:MyPassword123456After entering the LDAP password followed immediately by the current OTP, the authentication completed successfully and the IKEv2 IPsec VPN connection was established.The behavior and solution are documented in the following Fortinet Technical Tips:Technical Tip: Multi-Factor Authentication support for Windows FortiClient with LDAP (EAP-TTLS)https://community.fortinet.com/fortigate-3/technical-tip-multi-factor-authentication-support-for-windows-forticlient-with-ldap-eap-ttls-212498Technical Tip: How to resolve the “EAP authentication failed due to missing token” error when using EAP-TTLS/PAP + 2FA Authenticationhttps://community.fortinet.com/fortiauthenticator-8/technical-tip-how-to-resolve-the-eap-authentication-failed-due-to-missing-token-error-when-using-eap-ttls-pap-2fa-authentication-216311?tid=216311&fid=8In my case, the issue was not related to LDAP connectivity or realm selection. It was caused by the way the second authentication factor had to be provided when using EAP-TTLS with FortiAuthenticator.The EAPPasswordError message did not immediately indicate the actual cause, and the successful direct LDAP test initially led me to investigate other parts of the authentication flow.Has anyone else encountered the same behavior or received a different FortiClient error in a similar configuration?I hope this information can help anyone troubleshooting the same issue. Support Forum Fri, 30 Oct 2026 11:06:49 +0100 https://community.fortinet.com/support-forum-92/forticloud-upgrade-to-7-6-8-only-offering-8-x-230871 Hi.We are trying to get all our firewalls upgrading to the latest urgent patches.Forticloud shows our firewalls running 7.6.7 there is a recommended upgrade to 7.6.8, however, when we do the upgrade button, there is only 8.x listed!!!7.2 and 7.4 branches seem fine!Please tell me we don't need to manually patch these 7.6.x boxes? Support Forum Fri, 30 Oct 2026 10:15:12 +0100 https://community.fortinet.com/support-forum-92/fortiauthenticator-vms-dr-explanation-230866 Hi,can someone explain to me what the FortiAuthenticator-VMS-DR license (HA/DR/Load Balancing node license for FortiAuthenticator VM Subscription, with FortiCare Elite Support) is used for?It is not listed in the Ordering guide. If I understand it correctly, does this license allow for the deployment of a cluster (a second unit)?Zhank you Support Forum Fri, 30 Oct 2026 10:14:34 +0100 https://community.fortinet.com/fortimail-26/troubleshooting-whether-the-third-party-phishing-simulation-campaign-is-suspected-of-being-clicked-by-fortimail-231002 DescriptionTroubleshooting whether the third-party phishing simulation campaign is suspected of being clicked by FortiMail.ScopeFortiMail.SolutionAdd the "third party phishing simulation" sending IPs to the FortiMail Safelist.Create a dedicated Recipient Policy matching the "third party phishing simulation" sender address, and ensure no AntiVirus or Content profiles are attached to it.Reasoning for Step 2Merely adding the IP to the Safelist is not enough.FortiMail will still forward URLs/files to FortiSandbox and perform a Content Disarm and Reconstruction scan if a matching AntiVirus/Content profile exists in the policy. FortiMail Fri, 30 Oct 2026 09:53:17 +0100 https://community.fortinet.com/fortigate-3/ips-engine-crash-after-upgrading-to-fortios-7-4-12-231000 DescriptionThe ipsengine daemon crashes frequently on FortiGate devices running FortiOS 7.4.x / 7.6.x when FortiSandBox scanning is enabled in AntiVirus profiles.ScopeFortiGate 7.4.x, 7.6.xipsengine 07.004.604 FortiSandBox FortiSandBox-Cloud.SolutionSymptomAfter upgrading to FortiOS 7.4.x or 7.6.x, the ipsengine daemon has been observed to crash repeatedly.The crash logs indicate a segmentation fault (Signal 11). This behavior results in Intrusion Prevention System scanning failures, which may cause certain traffic sessions or websites to be blocked.The following command below allows you to check the latest ipsengine crashes that occurred:Note:When an AntiVirus profile is configured to use FortiSandBox scanning (either Cloud or On-Premises), this will trigger a crash in the ipsengine.diagnose debug crashlog read | grep ipsengine -A 1 15512: 2026-09-08 07:26:43 <26080> application ipsengine 07.004.604 15513: 2026-09-08 07:26:43 <26080> *** signal 11 (Segmentation fault) received *** ... 15587: 2026-09-08 07:30:26 <26397> application ipsengine 07.004.604 15588: 2026-09-08 07:30:26 <26397> *** signal 11 (Segmentation fault) received ***WorkaroundDisable the FortiSandBox scanning feature within all AntiVirus profiles used in Firewall policies. This allows other security profiles, such as SSL Inspection, Web Filtering, and IPS, to continue functioning without crashing the engine.Log in to the FortiGate GUI.Select Security Fabric -> AntiVirus.Edit the AntiVirus profiles used in the firewall policies.Under the APT Protection Option, set Send files to FortiSandbox for inspection to disabled.Select OK to save the changes.Alternatively, use the Command Line Interface (CLI) to disable the feature:config antivirus profile     edit "<profile_name>"         config http             set fortisandbox disable         end         config ftp             set fortisandbox disable         end         config imap             set fortisandbox disable         end         config pop3             set fortisandbox disable         end         config smtp             set fortisandbox disable         end     next endThe permanent fix for this Known Issue is already included in FortiOS 7.4.13, 7.6.7, and 8.0.0.Resolved issues | FortiGate / FortiOS 7.4.13 | Fortinet Document Library - 1182611Resolved issues | FortiGate / FortiOS 7.6.7 | Fortinet Document Library - 1182611Resolved issues | FortiGate / FortiOS 8.0.0 | Fortinet Document Library - 1182611Related article: FortiGate / FortiOS - Administration Guide - Using FortiSandbox inline scanning with antivirus FortiGate Fri, 30 Oct 2026 09:48:34 +0100 https://community.fortinet.com/fortisase-58/technical-tip-missing-button-to-resize-and-remove-widget-on-the-status-dashboard-230999 DescriptionThis article describes how to recover the Resize and Remove button options of a widget from the FortiSASE status dashboard.ScopeFortiSASE.SolutionThe FortiSASE dashboard has widgets that allow admins to add or remove widgets.There are instances where the button options are missing.To recover the resize and remove button options, zooming in or out of the browser view would resolve the issue.If the issue persists, capture and simulate the issue using the Fortinet Support Tool:Troubleshooting Tip: Collect GUI slowness and errors debugs via Fortinet Support Tool FortiSASE Fri, 30 Oct 2026 09:40:47 +0100 https://community.fortinet.com/forticasb-12/information-on-which-value-to-input-for-the-forticasb-sspm-fortianalyzer-connector-field-230998 DescriptionInformation on which corresponding value from the downloaded credentials from the FortiAnalyzer Cloud to be used in the FortiCASB-SSPM FortiAnalyzer Connector field.ScopeFortiCASB-SSPMSolutionAfter downloaded the credentials from the FortiAnalyzer Cloud (refer to documentation at the end of this article) and upon opening the downloaded file, below information are available.The respective information and the corresponding field.After entering the information, the Check Connection page should show the status as Connected, which confirms the information is correct.Related document:FortiAnalyzer Connector FortiCASB Fri, 30 Oct 2026 09:38:31 +0100 https://community.fortinet.com/fortimanager-27/invalid-image-when-upgrading-fortimanager-230997 DescriptionThis article describes how to troubleshoot when an upgrade to FortiManager fails with an 'Invalid Image' error.ScopeFortiManager.SolutionFortiManager firmware upgrade may fail with the error message 'Invalid Image'. The following is the checklist and steps to troubleshoot and identify the issue.Check the upgrade path and ensure that the image has no intermediate images. Upgrade path tool can be used to check: Upgrade Path Tool.Check the image downloaded. The image is specific to the model and VM instance. To check the VM instance, the following command can be run:diagnose debug klogSnippet of the output:<6>[0.000000] Hypervisor detected: KVMBased on the output, the Hypervisor is KVM, and the image used should match the hypervisor (example):FMG_VM64_KVM-v7.6.8.M-build3788-FORTINET.outThe same command provided in the previous steps can also be used to identify if there are issues in the disks. The following is an example of the error:<0>[702415.444478] EXT4-fs (dm-0): failed to convert unwritten extents to written extents -- potential data loss!  (inode 7864504, error-30)The output indicates there are issues and errors within the disk that should be resolved first. Note that the output may vary depending on the exact issue. Previous command output can be used to compare working and non-working boot-ups to identify the error.System resources need to meet the minimum system requirements, as not meeting the requirements may block the upgrade. The following command can be used to check the system resources:get system performanceThe minimum system requirements are explained in the following document: Minimum system requirements. FortiManager Fri, 30 Oct 2026 09:36:43 +0100 https://community.fortinet.com/fortiadc-7/technical-tip-understand-the-fortiadc-server-load-balance-real-server-pool-member-backup-state-behavior-when-failover-and-failback-triggered-230995 DescriptionThis article describes the FortiADC Server Load Balance Real Server Pool member backup state behavior when failover and failback are triggered.ScopeFortiADC.SolutionPrerequisite: FortiADC Server Load Balance Virtual Server with a Layer-4 application profile. Configurations:FortiADC Server Load Balance Virtual Server with Layer-4 application profile configured with 2 real server members and one of the real servers configured in backup state.Test and behaviors:In the test, an HTTP session is established, and a continuous ping is performed. The session is initially connected to Server01, and a failover is triggered by bringing down Server01.HTTP session is re-established to Server02.After resuming the service on Server01, the real server status changed to UP for Server01. The HTTP session does not stay in Server02 but immediately flows back to Server01.HTTP Session failback to Server01.Explanation:In a normal Real Server Pool with multiple server members configured with load balancing and without backup state, the connection session will stay in a real server member until the session ends or the server health state changes to DOWN.Unlike normal Real Server Pool load balancing, the backup state of a real server pool member always stays inactive if the active real server is healthy.Failover would trigger if all the active real server pool members went DOWN and failback would immediately trigger again if any of the active real server pool members came back online, even if the session is still ongoing at the backup server. Related document:Using Real server pools FortiADC Fri, 30 Oct 2026 09:25:39 +0100 https://community.fortinet.com/fortimail-26/how-to-exclude-specific-sender-for-specific-dlp-rule-230994 DescriptionThis article describes how to exclude a specific sender from specific Data Loss Prevention (DLP) Rule scanning.ScopeFortiMail.SolutionIn IP Policy and Recipient Policy, it is possible to apply a DLP Profile for FortiMail scanning to stop sensitive data from leaking to the outside network.DLP Profile can consist multiple DLP Rule enable and allow to take different action between the DLP Rule.To exclude a specific sender from DLP checks on a specific DLP Rule, edit the DLP Rule and add the condition as per below in the Exception tab.The log message will show as below if the sender matches the exception rule.In this example, the sender only bypassed the check for DLP Rule ‘test_dlp_1’ but is still checked by DLP Rule ‘No_password’. FortiMail Fri, 30 Oct 2026 08:51:08 +0100 https://community.fortinet.com/fortisiem-34/fortisiem-upgrade-fails-with-patroni-cluster-error-because-a-non-ha-environment-is-incorrectly-identified-as-an-ha-deployment-230993 DescriptionFortiSIEM upgrade may fail because the upgrade script incorrectly identifies a non-HA environment as an HA deployment. The script attempts to validate Patroni replica health, but no active replicas exist in the standalone environment.ScopeFortiSIEM.SolutionThe upgrade process fails with one of the following error messages.ERROR: Patroni cluster is missing IPs: <Supervisor_IP>. Fix the Patroni cluster configuration and rerun the upgrade.ERROR: Patroni cluster is not in healthy state. Please check the Patroni cluster status and ensure it is healthy before proceeding with the upgrade.This issue may occur in environments where Supervisor HA was previously configured but has since been removed. The Patroni service remains present, but no active replicas are available.The upgrade script checks for the presence of the Patroni service to determine whether the environment uses HA. When the service is detected, the script executes a health check in patroni_sync.py.The health check requires at least one synced replica. Specifically, the condition len(replicas) > 0 must be satisfied.In a standalone environment where HA is no longer configured, no replicas are available. As a result, the health check returns False and prevents the upgrade from proceeding.ResolutionTo bypass the Patroni replica synchronization check, modify the upgrade scripts as described below.Locate the upgrade script filesLocate the following files in the FortiSIEM upgrade directory.patroni_sync.py.Utils.py.Modify patroni_sync.pyOpen patroni_sync.py using a text editor.Locate the following line that evaluates the replica health status.healthy_replicas = (len(replicas) > 0 and all(self.is_replica_synced(replica) for replica in replicas))Comment out the existing line and add the following statement to set healthy_replicas to True.healthy_replicas = (len(replicas) > 0 and all(self.is_replica_synced(replica) for replica in replicas)) healthy_replicas = TrueSave the changes.Rerun the upgradeRun the following command to restart the upgrade process.sh upgrade.shVerify the upgradeMonitor the upgrade process and verify that it completes successfully. FortiSIEM Fri, 30 Oct 2026 08:44:07 +0100 https://community.fortinet.com/support-forum-92/open-source-claude-skill-that-generates-importable-fortisoar-playbooks-230989 Hi all,I've been building FortiSOAR playbooks for SOC work and turned the lessons I learned into a free, open-source skill for Claude AI.You describe the playbook in plain English, and Claude writes a complete FortiSOAR playbook JSON export that you can import directly. A bundled Python validator checks the export first for problems FortiSOAR would reject on import (broken step routes, Jinja syntax and similar).Example prompt:"Build a FortiSOAR playbook that runs on alert create, enriches every IP with FortiGuard and VirusTotal, and closes the alert as false positive if all are clean."What it covers:- Alert triage and incident response- IOC enrichment and phishing analysis- FortiSIEM / FortiAnalyzer queries (uses a reference of 7,000+ FortiSIEM event attributes)- Response actions with client approval (manual input) links- PDF / HTML reports generated inside FortiSOAR- Reviewing, debugging or adapting an existing playbook exportIt doesn't connect to your FortiSOAR instance. You import the JSON yourself, and the scripts make no network calls.Website: https://git-jimit.github.io/fortisoar-playbook-builder-site/GitHub: https://github.com/git-Jimit/fortisoar-playbook-builderI'd really like feedback from other FortiSOAR users, especially playbook patterns that break on import, so I can add rules for them.Note: this is an independent community project, not affiliated with or endorsed by Fortinet. Support Forum Fri, 30 Oct 2026 08:40:32 +0100 https://community.fortinet.com/fortisiem-34/notification-status-shows-sendfail-for-incidents-230992 DescriptionIncident notifications may fail to send and display a SendFail status due to an incorrectly formatted email address configured in the CC field. This article explains how to identify and resolve the issue by correcting the CC email address.ScopeFortiSIEM.SolutionThe notification status for incidents displaysSendFail, even though standard email testing functions work correctly.The issue occurs when the CC field contains an invalid email address format.FortiSIEM expects a complete email address in the CC field. If a username or alias is entered instead of a valid email address, the notification process may fail and generate the following error in the Appsvr.log.Error MessageERROR com.ph.phoenix.service.notify.email.SmtpClientHelper - [PH_APPSERVER_NOTIFIER_ERROR]:[eventSeverity]=PHL_ERROR,[phEventCategory]=3,[procName]=AppServer,[phCustId]=0,[phLogDetail]=AddressException: Local address contains illegal characterResolutionVerify and correct the email address configured in the notification CC field by following these steps:Check Appsvr.log and search for the error message shown above.Identify the CC user configured for the affected incident notification.Verify that the CC field contains a valid email address.Valid format: user@example.com.Invalid format: username.Replace the username or alias with the complete email address.Save the notification configuration.Trigger a test incident notification and verify that the notification status changes from SendFail to a successful status. FortiSIEM Fri, 30 Oct 2026 08:36:19 +0100 https://community.fortinet.com/fortimail-26/email-address-configured-for-fortiguard-spam-sample-submission-does-not-receive-normal-emails-230991 DescriptionHow to troubleshoot a situation where an email address cannot receive normal emails and no corresponding email logs appear in FortiMail because the address is configured for the FortiGuard Spam Sample Submission Service.ScopeFortiMail all versions & FortiMail Cloud.SolutionWhen troubleshooting an issue where a recipient cannot receive emails, administrators may find that FortiMail has no corresponding mail logs for the affected address.One possible cause is that the email address has been configured under the Spam Sample Submission Service in FortiMail. This setting is intended for receiving spam samples for submission to FortiGuard, rather than for normal email delivery.Verify the Spam Sample Submission Service configuration:Log in to the FortiMail administrative GUI.Navigate to System -> FortiGuard -> Antispam.Locate the Spam Sample Submission Service setting.Check whether the affected email address is configured in Email account to receive spam:More details: Configuring spam sample submission serviceUnderstanding the purpose of the configured address:The email address configured for this service is used for the spam sample submission function. Do not treat it as a regular mailbox for receiving normal emails.If a user attempts to send normal emails to this address, those messages should not be expected to arrive as regular email messages through FortiMail. This can explain why no corresponding mail logs are found for the attempted deliveries. FortiMail Fri, 30 Oct 2026 08:30:13 +0100 https://community.fortinet.com/forticlient-4/troubleshooting-tip-forticlient-vpn-before-logon-fails-to-connect-when-using-windows-credentials-230990 DescriptionFortiClient version 7.4 fails to establish a VPN connection before user logon using Windows credentials.ScopeFortiClient version 7.4.SolutionSymptoms.Users cannot connect to the SSL VPN or IPsec VPN using the VPN Before Logon feature after upgrading to FortiClient version 7.4. The connection fails at the Windows logon screen, and no logs are generated on the FortiGate.Root cause.In FortiClient version7.4, a change in behavior causes the client to check for credentials before initiating the connection. If the Prompt for Username setting is disabled, FortiClient may fail to retrieve the necessary credentials from Windows, causing the pre-logon connection to halt. This differs from FortiClient version 7.2, which attempted to start the connection even if credentials were not immediately found.Resolution.Workaround:To resolve this issue in FortiClient version 7.4, enable the prompt for usernames in the endpoint profile:Log in to the FortiClient EMS console.Select Endpoint Profiles -> System Settings.Select the profile applied to the affected endpoints and select Edit.Navigate to the VPN tunnel settings.Enable the prompt for username option.Save the changes and deploy the profile to the endpoints.Settings in SSL VPN tunnel configuration:Settings in IPsec VPN tunnel configuration:Permanent solution.This behavior is not present in FortiClient version 8.0.0 and above. Upgrade the FortiClient installation to FortiClient version 8.0.0 or above to restore the VPN Before Logon behavior without requiring the username prompt. FortiClient Fri, 30 Oct 2026 08:01:36 +0100 https://community.fortinet.com/support-forum-92/fortiap-231k-repeated-cwwtpd-lldpd-restarts-and-capwap-failure-230547 Hello Fortinet Community,We are facing a persistent issue with a FortiAP 231K that fails to come online on our FortiGate 60E. Interestingly, the same behavior has also been observed on the replacement FortiAP received through RMA.We would appreciate guidance from the community or Fortinet engineers who may have encountered similar symptoms.EnvironmentFortiGate: FortiGate 60E FortiOS: 7.4.12 Access Point: FortiAP 231K AP management: FortiGate wireless controller Original testing topology: FortiGate -> PoE switch -> FortiAP 231K Replacement AP testing setup: PoE injector -> FortiAP 231K, with a laptop connected for testing and a serial console connection through PuTTYWe have checked the official FortiAP and FortiOS Compatibility Matrix and are investigating the issue using the supported firmware combination listed for the FortiAP 231K and FortiOS 7.4.12.Issue ObservedThe FortiAP boots successfully but does not come online or establish a stable CAPWAP connection with the FortiGate.The PuTTY console repeatedly displays the following messages:process '/usr/sbin/lldpd' (pid 16561) exited. Scheduling for restart.process '/sbin/cwWtpd' (pid 16563) exited. Scheduling for restart.ERROR!!! Send debug config info to capwap failedThese messages continue appearing repeatedly while the AP remains powered on.Troubleshooting PerformedWe have performed the following checks:Performed multiple factory resets. Verified that the AP boots successfully and that serial console access is available. Confirmed that the FortiGate wireless controller is enabled. Tested the original AP through different PoE switch ports. Left the AP running for 10–15 minutes to check whether it would come online. Tried Deauthorize/Authorize and Reject/Authorize actions from the FortiGate. Collected PuTTY console logs and video recordings showing the repeated process restarts. Verified that another FortiAP operates normally under the same FortiGate wireless controller. Tested the replacement AP separately using a PoE injector, laptop, and serial console connection rather than connecting it directly to the FortiGate for this test.Despite these tests, the replacement AP exhibits the same repeated process restarts.Important ObservationThe original FortiAP 231K exhibited these symptoms and was approved for RMA due to the repeated daemon restart issue. However, the replacement FortiAP 231K has now exhibited the same behavior during separate testing using a PoE injector, laptop, and console connection.Since the same symptoms have appeared on both units, we would like to determine whether this could be related to firmware/software, AP initialization, or another underlying issue rather than two independent hardware failures.Questions for the Community Has anyone encountered repeated cwWtpd and lldpd restarts on a FortiAP 231K? Could ERROR!!! Send debug config info to capwap failed indicate a known firmware or CAPWAP issue? Are there specific CLI commands or debug outputs we should collect to identify why these processes keep restarting? Could the same symptoms occur when the AP is powered through a PoE injector and tested separately from the FortiGate's direct physical connection? Are there known certificate-related or controller compatibility issues that could cause this behavior on a FortiGate 60E? Has anyone successfully resolved this issue while remaining on the FortiOS 7.4.x branch? We would appreciate any troubleshooting suggestions, known bug references, or recommended fixes. Upgrading the production FortiGate to a different major firmware branch is not currently feasible, so guidance applicable to our existing environment would be especially helpful.Thank you for your time and assistance. Support Forum Fri, 30 Oct 2026 07:45:09 +0100 https://community.fortinet.com/fortiweb-40/technical-tip-randomly-the-chart-within-the-reports-is-not-generated-for-some-sections-230988 DescriptionThis article describes how to deal with the issue of a report chart not being generated in some sections of the report.ScopeFortiWeb version 8.0.x  SolutionAdmin creates a report in Log&Report -> Log Access -> Report -> Report Config and downloads it in Report Browse.   After reported is created, Admin review within the report and in some sections randomly the chart associated to the table is not generated.  This is a known issue that is resolved in version 8.0.8. FortiWeb Fri, 30 Oct 2026 07:35:00 +0100 https://community.fortinet.com/support-forum-92/dial-up-ipsec-vpn-pki-user-group-not-working-after-upgrade-to-7-4-13-230987 We have been using IPsec VPN with a peer group and peers.The peers have the CA cert of the EMS server and the subject as part of the peer identifier. This has always worked fine until the upgrade to 7.4.13 where we get an “invalid certificate” error and no connection. If the Peer Option is set to Any Peer ID then the VPN connection works. I’ve looked through the “known issues” of 7.4.13 but nothing applies.Any ideas?Thanks. Support Forum Fri, 30 Oct 2026 06:06:23 +0100 https://community.fortinet.com/fortigate-3/technical-tip-configuring-agentless-fsso-polling-via-ipsec-vpn-tunnel-92757 DescriptionThis article describes how to configure Agentless FSSO Polling via an IPsec VPN tunnel between two FortiGates.ScopeFortiGate.SolutionIn the network diagram above, the AD server is only reachable by FGT-A by IPsec VPN tunnel to FGT-B. By using FSSO Agent, specify the source IP to reach FGT-B. However, there is no such option in Agentless FSSO polling.LDAP is configured to specify the source IP, but performing a sniffer on FGT-A on port 445 reveals it was being sent out using another source IP:config user ldap     edit "AD"         set server "10.125.1.11"         set source-ip 10.149.1.21         set cnid "sAMAccountName"         set dn "dc=ces,dc=com"         set type regular         set username "cn=Administrator,cn=Users,dc=ces,dc=com"     next end FGT-A # diagnose sniffer packet any 'port 445' 4 interfaces=nany] filters=oport 445] 0.624513 VPN-AtoB out 2.2.2.2.11209 -> 10.125.1.11.445: syn 2524384594 4.636167 VPN-AtoB out 2.2.2.2.11209 -> 10.125.1.11.445: syn 2524384594 25.233656 VPN-AtoB out 2.2.2.2.11211 -> 10.125.1.11.445: syn 2949233177 26.224879 VPN-AtoB out 2.2.2.2.11211 -> 10.125.1.11.445: syn 29492331772.2.2.2 is the public IP of FGT-A and it is not supposed to be traversing through the IPsec VPN tunnel VPN-AtoB; thus traffic will be dropped by the remote FortiGate.Resolution:By configuring IP address on the IPsec VPN tunnel, force the FSSO traffic to use the VPN tunnel IP address instead of the lowest-index IP address as the source IP.By default, FortiGate will use the lowest-index interface IP address as the source IP to initiate the traffic; the index list can be found in the command output below.diagnose ip address list IP=10.56.241.136->10.56.241.136/255.255.252.0 index=3 devname=port1 IP=10.56.1.136->10.56.1.136/255.255.252.0 index=4 devname=port2 IP=10.68.1.136->10.68.1.136/255.255.240.0 index=5 devname=port3 IP=10.69.1.136->10.69.1.136/255.255.240.0 index=6 devname=port4 IP=127.0.0.1->127.0.0.1/255.0.0.0 index=14 devname=root IP=10.255.1.1->10.255.1.1/255.255.255.0 index=18 devname=fortilink IP=127.0.0.1->127.0.0.1/255.0.0.0 index=23 devname=vsys_ha IP=127.0.0.1->127.0.0.1/255.0.0.0 index=25 devname=vsys_fgfmFGT-A # diagnose sniffer packet any 'port 445' 4 interfaces=nany] filters=oport 445] 7.309059 VPN-AtoB out 172.16.1.2.21873 -> 10.125.1.11.445: syn 751818537 7.310877 VPN-AtoB in 10.125.1.11.445 -> 172.16.1.2.21873: syn 1602721448 ack 751818538 7.310938 VPN-AtoB out 172.16.1.2.21873 -> 10.125.1.11.445: ack 1602721449 7.327293 VPN-AtoB out 172.16.1.2.21873 -> 10.125.1.11.445: psh 751818538 ack 1602721449 7.328787 VPN-AtoB in 10.125.1.11.445 -> 172.16.1.2.21873: psh 1602721449 ack 751818732 7.328816 VPN-AtoB out 172.16.1.2.21873 -> 10.125.1.11.445: ack 1602721658 7.329148 VPN-AtoB out 172.16.1.2.21873 -> 10.125.1.11.445: psh 751818732 ack 1602721658 7.330492 VPN-AtoB in 10.125.1.11.445 -> 172.16.1.2.21873: psh 1602721658 ack 751818902 7.330673 VPN-AtoB out 172.16.1.2.21873 -> 10.125.1.11.445: psh 751818902 ack 1602722080FGT-A is now using the VPN interface IP 172.16.1.2 to send the FSSO packet. On the remote FGT-B, the route 172.16.1.2 is now a directly connected route via IPsec VPN tunnel VPN-BtoA, therefore, it knows how to route the traffic back to FGT-A. FGTB # get router info routing-table all Routing table for VRF=0 Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP        O - OSPF, IA - OSPF inter area        N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2        E1 - OSPF external type 1, E2 - OSPF external type 2        i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area        * - candidate default S*      0.0.0.0/0 10/0] via 2.2.2.254, port1 C       10.47.0.0/22 is directly connected, port1 S       10.125.0.0/23 r10/0] via 172.16.1.1, VPN-BtoA C       10.149.0.0/23 is directly connected, port2 C       172.16.1.0/30 is directly connected, VPN-BtoA C       172.16.1.2/32 is directly connected, VPN-BtoAHence, the agentless FSSO polling is now working as expected:FGT-A # diagnose debug fsso-polling detail 1 AD Server Status(connected): ID=1, name(10.125.1.11),ip=10.125.1.11,source(security),users(0) port=auto username=Administrator read log eof=1, latest logon timestamp: Sun May 27 16:41:54 2018 polling frequency: every 10 second(s) success(508), fail(0) LDAP query: success(0), fail(0) LDAP max group query period(seconds): 0 LDAP status: connectedRelated articles:Technical Tip: Self-originating traffic over IPSec VPN (for example, ping)Technical Tip: tracert/traceroute behavior over IPsec VPN tunnel FortiGate Fri, 30 Oct 2026 03:07:42 +0100 https://community.fortinet.com/support-forum-92/updated-certificate-not-being-applied-to-virtual-servers-on-fortigate-7-2-14-230975 Hello, We are having this issue on FGT-80F and FGT-80E, both version 7.2.14. When renewing certificates, we edit the existing certificate object and replace the certificate chain with the new one, so we can keep the same certificate name. The updated certificate is reflected everywhere except on virtual servers. When checking the certificate presented by a virtual server, it appears that the old certificate is still being used.If we switch the virtual server to a different certificate, the change takes effect immediately and the new certificate is presented correctly, but when we switch back to the new certificate, the virtual server continues to present the old one.  Has anyone encouter this issue? Is there a way to force virtual servers to reload the updated certificate without rebooting the FortiGate or manually changing certificate references?  Thanks! Support Forum Fri, 30 Oct 2026 00:50:16 +0100 https://community.fortinet.com/support-forum-92/why-does-fortigate-send-self-signed-root-ca-certificate-in-ikev2-cert-payload-114507 Irrespective whether the FortiGate server certificate is directly issued by a Root CA or by an Intermediate CA, the Root CA is always sent to the IPsec VPN client in the CERT payload of the IKE_AUTH response. This doesn't make any sense since no peer is going to trust a self-signed certificate received via an untrusted channel. Omitting the unnecessary Root CA certificate would help to reduce the number of IKEv2 fragments needed to transmit the huge IKE_AUTH response. Support Forum Fri, 30 Oct 2026 00:44:32 +0100 https://community.fortinet.com/support-forum-92/vpn-disconnects-by-screensaver-or-screen-lock-206251 Hi, does anyone found a solution, to hold the VPN up and running when the screen is locked? OS: MacOS Sequoia 15.4 and MacOS Sequoia 15.5FortiClient: VPN 7.4.3.1761I had to install the newest FortiClient VPN version after a firewall upgrade as the older versions running in some connection problems.The older versions were stable and connected when the screen was locked. With the new version, the VPN disconnect each time the screen locks. In fortitray.log it is good to see, a message is send to forticlient and immediately after the message, the ssl-vpn is disconnecting. 20250508 14:55:24.613 TZ=+0200 [FortiTray:DEBG] AppDelegate.swift:390 System is locked/sleep20250508 14:55:24.620 TZ=+0200 [FortiTray:DEBG] AppDelegate.swift:404 System is going to sleep20250508 14:55:24.646 TZ=+0200 [FortiTray:INFO] VpnManager.swift:2163 Check VPN Connect without Reauth20250508 14:55:24.657 TZ=+0200 [FortiTray:DEBG] VpnManager.swift:2174 VPN Connection without reauthentication enabled, timeout: 6020250508 14:55:24.676 TZ=+0200 [FortiTray:DEBG] VpnManager.swift:2189 VPN Information saved.20250508 14:55:24.690 TZ=+0200 [FortiTray:DEBG] VpnManager.swift:1808 Stop current VPN The network connection is still open and stable. During the screen is locked, I sent a ping without any lost.Any ideas are welcome.Jörg Support Forum Thu, 29 Oct 2026 22:49:10 +0100 https://community.fortinet.com/fortigate-3/technical-tip-fortiauthenticator-ztna-tunnel-failing-due-to-traffic-denied-because-cert-auth-failed-error-on-fortigate-206013 Description This article describes how to troubleshoot a FortiAuthenticator ZTNA certificate error on FortiGate. Scope FortiAuthenticator, FortiGate. Solution FortiAuthenticator v6.4.4 introduced a Zero Trust Tunnel Feature, which is used to securely connect with an on-prem Active Directory Server(LDAP).   Zero trust tunnels FortiAuthenticator v6.4.4 This article assumes that the initial setup for this feature has been completed: Setting up a zero trust tunnel If the ZTNA tunnel is failing on the FortiGate, check the ZTNA traffic logs on FortiGate: Log & Report -> ZTNA Traffic. In the screenshot above, the error 'Traffic denied because cert auth failed' shows up. To resolve this issue, ensure the ZTNA CA certificate has already been uploaded onto the FortiGate: If the CA certificate does not exist, import it and make sure to take note of the name after importing the CA certificate. In the screenshot above, the name is 'CA_Cert_2'. The FortiGate will need to use the CA certificate in order to trust the FortiAuthenticator certificate for the ZTNA tunnel. After confirming the CA certificate, configure the following option through the FortiGate CLI:   config authentication setting     set user-cert-ca <name of CA certificate> end Note:  The authentication rule and scheme settings should also be configured as described in the documentation below: Configuring certificate authentication for FortiAuthenticator After confirming the CA certificate has been selected, re-attempt the ZTNA connection and check the ZTNA traffic logs again to verify it is successful: Related Articles: Configuring certificate authentication for FortiAuthenticator Setting up a zero trust tunnel What's new FortiAuthenticator v6.4.4 FortiGate Thu, 29 Oct 2026 20:16:10 +0100 https://community.fortinet.com/fortigate-3/technical-tip-enable-security-event-logging-on-policy-with-security-fabric-enabled-112730 DescriptionThis article describes how to enable Security Event logging when Security Fabric is enabled.It applies to both Fabric root and subordinate FortiGates.ScopeFortiGate.SolutionBy design and by default, all firewall policies (except for the implicit deny policy) log all sessions after Security Fabric has been enabled.Users cannot directly change the logging configuration on downstream (i.e. non-root) FortiGates as the option is greyed out as shown below: When the info indication highlighted above is hovered over, it shows: 'Security fabric is enabled so logging will exempt traffic from downstream FortiGates'.Although it is possible to change the logtraffic option manually in FortiGate CLI, this change will not be reflected in the GUI, and the session will continue to log all traffic.For example, the following configuration change would cause only security events to be logged if the FortiGate was not part of a security fabric, but is ignored for fabric FortiGates:config firewall policy edit <index> set logtraffic utm next endThis behavior is by design to avoid unnecessary changes to firewall policy configuration when enabling or disabling Security Fabric.In FortiOS version 8.0.1 and above, the following warning shows when changing the 'logtraffic' setting:FortiGate-60F(Primary) # config firewall policy FortiGate-60F(Primary) (policy) #    edit 10 FortiGate-60F(Primary) (10) #        set logtraffic disable WARNING: Security Fabric is enabled. Traffic from downstream devices will still be logged.Customizing Downstream FortiGate logging behavior.This is done on the downstream FortiGate using the Security Fabric 'configuration-sync' setting. Set configuration-sync to 'local' instead of 'default' in the downstream FortiGate CLI Security Fabric settings as shown below:config system csf set configuration-sync local endAfter making the change, the logging level can be changed on the firewall policy in CLI or GUI:Note: In some cases, even after applying 'set configuration-sync local' in CLI, the logging option will still be greyed out and will not permit change; this is generally a browser issue. To resolve it, either refresh the GUI browser page or log out of the admin account and log back in again. The GUI should now allow to update the Logging Options.Note: There are 2 options that configuration-sync can be set to, which are:Default: Synchronize configuration for FortiAnalyzer, FortiSandbox, and Central Management to the root node.Local: Do not synchronize configuration with the root node. As mentioned, setting it to local will prevent the device from synchronizing the configuration with the root node.Note: The 'set configuration-sync local' command is effective only on a downstream FortiGate; in a root FortiGate, it is not used, and therefore the command has been removed for FortiGates serving as a fabric root in FortiOS 7.6.1 and onwards.Customizing fabric root FortiGate logging behavior.This is done using the 'log-unification' setting on the root FortiGate.The fabric root FortiGate will log all sessions matching all configured firewall policies by default, even if the 'logtraffic' setting is changed.For example, the following firewall policy will still generate traffic logs:config firewall policy     edit 10         set name "Explicit LAN block outbound"         set srcintf "lan"         set dstintf "any"         set srcaddr "lan_net"         set dstaddr "grp_LAN_explicit_block"         set schedule "always"         set service "ALL"         set logtraffic disable     next endMatching traffic log:eventtime=2110839462597492736 tz="+0600" logid="0000000013" type="traffic" subtype="forward" level="notice" vd="root" srcip=172.16.10.10 srcport=53467 srcintf="lan" srcintfrole="undefined" dstip=198.51.100.10 dstport=443 dstintf="wan" dstintfrole="undefined" srccountry="United States" dstcountry="United States" sessionid=12345678 proto=6 action="deny" policyid=10 policytype="policy" poluuid="6af9be38-cdf4-51ef-f217-317f2d7e77a3" policyname="Explicit LAN block outbound" service="HTTPS" trandisp="noop" appcat="unscanned" duration=0 sentbyte=0 rcvdbyte=0 sentpkt=0 rcvdpkt=0 crscore=30 craction=131072 crlevel="high"If needed, log-unification can be disabled for the fabric in the root FortiGate's configuration as follows:config system csf set status enable     set log-unification disable endThis disables multiple security fabric features, including the 'log all sessions' behavior and fabric device MAC discovery broadcasts.An alternative option is to configure an explicit granular logging filter matching a specific policyid and traffic subtype; see Technical Tip: Configuring advanced syslog free-style filters.Related documents:Optimizations for physical FortiGate devices with 2 GB RAMTechnical Tip: The impact of 'set configuration-sync local' on the Security Fabric FortiGate Thu, 29 Oct 2026 19:26:39 +0100 https://community.fortinet.com/support-forum-92/forticlient-vpn-only-230964 I have not gotten email yet when I tried to register to download FortiClient VPN only. That email is needed to use FortiToken app. Support Forum Thu, 29 Oct 2026 19:15:47 +0100 https://community.fortinet.com/support-forum-92/adding-fortigate-vm-eval-to-fortimanager-vm-eval-198178 Hi everyone, I am trying to add a Fortigate VM eval, generated via the FortiCloud account to the FortiManager VM eval, also generated via the FortiCloud account. So, both units are "self-generated" evals. I am not talking about evals obtained through the local supplier. It is not working!!! From the debug output on FGM, it seems like the FG is not sending any certificate to the FGM while trying to setup communication via FGFM. This is a debug output from the FGM:2025-02-11 06:44:29 Use cert idx=0 by peer_ca = 1 2025-02-11 06:44:29 __info_callback,993: role=svr,state=23, TLSv1.3 SSLv3/TLS write certificate 2025-02-11 06:44:29 __info_callback,993: role=svr,state=40, TLSv1.3 TLSv1.3 write server certificate verify 2025-02-11 06:44:29 __info_callback,993: role=svr,state=36, TLSv1.3 SSLv3/TLS write finished 2025-02-11 06:44:29 __info_callback,993: role=svr,state=46, TLSv1.3 TLSv1.3 early data 2025-02-11 06:44:29 __info_callback,993: role=svr,state=46, TLSv1.3 TLSv1.3 early data 2025-02-11 06:44:29 TLSv1.3 write fatal alert: unknown 2025-02-11 06:44:29 fw_proto_ssl.c,1026: TLSv1.3 error 2025-02-11 06:44:29 fw_proto_ssl.c,__get_error,1615, err=167772359, error:0A0000C7:SSL routines::peer did not return a certificate. 2025-02-11 06:44:29 fw_proto_ssl.c,__get_error,1629, ret=-4, error=1, errno=0,Success. 2025-02-11 06:44:29 proxy_session.c,__proxy_session_cleanup, 118:cnt=0, session=0x558f996106bc.  On FG unit I can see the FGM is resetting the connection:FGFMs: setting session 0x5578e5f67440 exclusive=0 FGFMs: Connect to 10.100.100.20:541, local 10.100.100.21:10514. FGFMs: set_fgfm_sni SNI<fortinet-ca2.fortinet.com> FGFMs: Load Cipher [ALL:!RC4:!EXPORT:@STRENGTH] FGFMs: Load TLS 1.3 Cipher [TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256] FGFMs: Set self_initiated = 1 FGFMs: before SSL initialization FGFMs: CA to broadcast: subject fortinet-subca2001, issuer fortinet-ca2 FGFMs: Broadcast 1 CA subject names to FMG FGFMs: SSLv3/TLS write client hello FGFMs: SSLv3/TLS write client hello FGFMs: SSLv3/TLS read server hello FGFMs: SSLv3/TLS write change cipher spec FGFMs: SSLv3/TLS write client hello FGFMs: SSLv3/TLS write client hello FGFMs: SSLv3/TLS read server hello FGFMs: TLSv1.3 read encrypted extensions FGFMs: SSLv3/TLS read server certificate request FGFMs: Verified CA certificate 1: (subject: fortinet-subca2001, issuer: fortinet-ca2) FGFMs: Verified peer certificate 0: (subject: *****, issuer: fortinet-subca2001) FGFMs: SSLv3/TLS read server certificate FGFMs: TLSv1.3 read server certificate verify FGFMs: SSLv3/TLS read finished FGFMs: SSLv3/TLS write client certificate FGFMs: SSLv3/TLS write finished FGFMs: SSL negotiation finished successfully FGFMs: client:send: get auth serialno=***** mgmtid=00000000-0000-0000-0000-000000000000 platform=FortiGate-VM64-KVM fos_ver=700 minor=6 patch=2 build=3462 branch=3462 maxvdom=2 fg_ip=10.100.100.21 hostname=***** harddisk=yes biover=04000002 harddisk_size=32768 logdisk_size=32124 mgmt_mode=normal enc_flags=0 mgmtip=10.100.100.21 mgmtport=443 FGFMs: [__get_error:1169] error=5, errno=104,Connection reset by peer. FGFMs: [__get_error:1169] error=5, errno=32,Broken pipe. FGFMs: SSL Alert read: fatal unknown FGFMs: Cleanup session 0x5578e5f67440, 10.100.100.20. FGFMs: Destroy session 0x5578e5f67440, 10.100.100.20. Both units are running FortiOS v7.6.2. I have tried also with versions 7.4.5 and FG version 7.2.10. No success!I have gone through all the documentation and know everything about changes from the >= 7.4.6 and peer certificate SN validation, low encryption algorithms, etc. Nothing worked!!! I have to mention that adding a production or PAYG FG in Azure works like a charm (even with the custom certificates generated via local PKI). So, my guess is that alongside other limitations of FG VM eval (e.g., maximum of 3 routes, 1 CPU and 2 GB of RAM), you cannot mange this FG VM with FGM. Apparently, this had worked before (at least to other folks on the Internet), but it seems like it does not work anymore.Anyone have had any luck with this setup? Thank you! Support Forum Thu, 29 Oct 2026 18:33:37 +0100 https://community.fortinet.com/support-forum-92/how-to-block-all-file-uploads-using-dlp-on-fortigate-7-4-13-230951 Hello Fortinet Community,I am using FortiGate with FortiOS 7.4.13 and want to prevent employees from uploading any file type (PDF, TXT, Microsoft Office, EXE, ZIP, RAR, etc.) to any external website or service.However, I need to ensure that Windows Update and Kaspersky updates and cloud services continue to work normally, without being affected by this policy.What is the recommended configuration to achieve this? Should I use DLP File Patterns with Flow-based or Proxy-based inspection? Is SSL Deep Inspection required?I would appreciate a step-by-step guide or an official Fortinet reference.Thank you. Support Forum Thu, 29 Oct 2026 18:28:06 +0100 https://community.fortinet.com/support-forum-92/fortios-can-two-vips-share-the-same-external-ip-230982 Hello everyone, Does FortiGate accept two VIP objects with the same external IP ? If so which FortiOS and how is it configured ? Thanks in advance.BR, Support Forum Thu, 29 Oct 2026 18:19:20 +0100 https://community.fortinet.com/fortigate-3/troubleshooting-tips-admin-is-logged-out-of-the-gui-immediately-after-login-login-must-be-entered-twice-on-fortigate-version-7-6-7-230402 DescriptionThis article describes an issue on FortiOS version 7.6.7: some administrators are kicked back to the login page right after a successful GUI login; it is necessary to enter credentials a second time before the dashboard loads. In other cases, the first attempt shows a blank/white page, and a later attempt loads normally. The login may be recorded in the event log together with an HTTPS connection error, even though authentication itself succeeds.ScopeFortiOS version 7.6.7.SolutionSymptoms:After entering the username and password, the login page reappears instead of the dashboard. Entering the credentials a second time succeeds and the GUI loads.The issue affects GUI (HTTPS) logins only, SSH sessions are not affected. It may be seen across Chrome, Edge, and Firefox, and sometimes in /private mode as well.An 'HTTPS connection error' may be logged in the event log.Root cause:When signing in through a web browser, the page loads a large number of small resources all at once (far more than in earlier releases). The web interface's activity monitor mistakes this normal burst of activity for a brief attack and interrupts the login, dropping back to the login page, even though the username and password were already accepted.This is why the login can appear in the event log as successful while the page still sends back: authentication succeeds, but the session is cut before the dashboard finishes loading.Related known issues in the 7.6.7 release notes:Bug ID 1300025 – Admin session termination (especially Chrome/Edge). Workaround: clear browser cache/cookies.Bug ID 1306049 – Blank page after upgrade to 7.6.7. Workaround involves disabling HTTP rate-limiter settings.Resolution:Fixed in FortiOS version 7.6.8 (and above version 8.0.1). The fix scopes the unauthenticated request-body monitor to body-carrying methods only, raises the unauthenticated request timeout from 1 s to 10 s, and reworks the rate-limiter token pricing and refund logic so a normal GUI bootstrap is not mistaken for an attack and killed.Upgrade to FortiOS version 7.6.8 or above to resolve the issue.Workaround (until upgrade):Until the upgrade can be performed, one of the following avoids the problem:Clear the browser cache and cookies associated with the FortiGate, then log in again.Access the GUI in the browser's Incognito/InPrivate mode.Simply log in a second time; the second attempt loads the dashboard normally.Diagnostic Commands:Useful while reproducing the issue:diagnose debug resetdiagnose debug console timestamp enablediagnose debug application httpsd -1diagnose debug application node -1diagnose debug application http_authd -1 # or http_authdiagnose debug enableStop with:diagnose debug disable diagnose debug reset FortiGate Thu, 29 Oct 2026 18:10:42 +0100 https://community.fortinet.com/fortigate-3/bgp-vpnv4-routes-received-but-not-installed-in-the-vrf-routing-table-230986 DescriptionWhen a BGP VPNv4 route(s) are received, the route(s) fail to be installed in the VRF routing-table when an extended community value is missing.ScopeFortiOS.SolutionIn an MPLS L3VPN environment integrating FortiGate firewalls, MP-BGP VPNv4 routes and VRF route-tagging mechanisms help maintain routing separation between customer networks while controlling route exchange across the provider backbone. By combining FortiGate routing policies and VRF-based segmentation with appropriate BGP route-target import/export policies and route-tag controls, service providers can reduce unintended route propagation and strengthen customer traffic isolation.This article focuses on the route installation issue. The configuration part is assumed to be working, and BGP neighborship between FW-01 and FW-02 is established.In this scenario, FW-01 receives the route 10.115.1.0/24 from Customer-A on VRF 115. FW-01 advertises this route to FW-02. The same route must be installed to FW-02 VRF 115 routing table.10.100.223.9 - FW-01 BGP router ID10.100.223.10 - FW-02 BGP router ID10.100.228.5 & 10.100.228.6 - Customer A BGP router IDFW-01 is advertising the route to neighbor 10.100.223.9 (FW-02).FW-01 # get router info bgp neighbors 10.100.223.10 advertised-routes vpnv4 | grep 10.115.1.0 *> 10.115.1.0/24 10.100.223.9 0 0 64902 64902 64902 64902 64901 64900 ? <-/->On FW-02, the route is received from FW-01. However, the route is not installed in the routing-table.FW-02 # get router info bgp neighbors 10.100.223.9 received-routes vpnv4 | grep 10.115.1.0 *> 10.115.1.0/24 10.100.223.9 0 0 64902 64902 64902 64902 64902 64901 64900 ? <-/->The required Extended Community (RT) Route Target for VRF 115 is 64600:115.First, look at the BGP route information for 10.115.1.0/24 on FW-01 VRF 115. This route is received from Customer-A via two BGP neighborship, 10.100.228.5 and 10.100.228.6. Notice that Extended Community field is empty.FW-01 # get router info bgp network 10.115.2.0/24 VRF 115 BGP routing table entry for 10.115.2.0/24 Paths: (2 available, best #2, table Default-IP-Routing-Table) Advertised to non peer-group peers: 10.100.228.5 10.100.228.6 Original VRF 115 local 64901 64900 10.100.228.6 from 10.100.228.6 (10.100.228.6) Origin incomplete distance 20 metric 0, localpref 100, valid, external, best Extended Community: Advertised Path ID: 2 Last update: Mon Aug 10 23:37:14 2026 Original VRF 115 local 64901 64900 10.100.228.5 from 10.100.228.5 (10.100.228.5) Origin incomplete distance 20 metric 0, localpref 100, valid, external, best Extended Community: Advertised Path ID: 1 Last update: Mon Aug 10 23:37:14 2026When FW-01 advertises this route to FW-02, the extended community value is empty.Take a look at a working subnet 10.107.1.0/24, which is advertised with the extended community value 64600:115. This attribute is requirement for VRF 115 route installation. As a result, this route is successfully installed in the FW-02 VRF 115 route table.Despite adding a route-map out to include the extended community route target, FW-01 still advertises 10.115.1.0/24 without any route target attribute. For more information about extended community route targets, refer to Matching BGP extended community route targets in route maps.ResolutionTo mitigate this, the required route target attribute must be added before the route is installed on FW-01 VRF 115 route table. To achieve this, a route-map-in must be configured under the BGP neighbor configuration between FW-01 and Customer-A.Configure the route-map rule.FW-01# config router route-map edit "VRF115-RT-Inbound" config rule edit 1 set set-extcommunity-rt 64600:115 next end next endThen apply the route-map inbound under BGP neighbor configuration on FW-01.FW-01# config router bgp config neighbor edit "10.100.228.5" set route-map-in ""VRF115-RT-Inbound" next end endOnce this is applied, the route installed on FW-01 VRF 115 will now show the required extended community route target attribute of 64600:115.FW-01 # get router info bgp network 10.115.2.0/24 VRF 115 BGP routing table entry for 10.115.2.0/24 Paths: (2 available, best #2, table Default-IP-Routing-Table) Advertised to non peer-group peers: 10.100.228.5 10.100.228.6 Original VRF 115 local 64901 64900 10.100.228.6 from 10.100.228.6 (10.100.228.6) Origin incomplete distance 20 metric 0, localpref 100, valid, external, best Extended Community: RT:64600:115 Advertised Path ID: 2 Last update: Thu Oct 15 22:46:36 2026 Original VRF 115 local 64901 64900 10.100.228.5 from 10.100.228.5 (10.100.228.5) Origin incomplete distance 20 metric 0, localpref 100, valid, external, best Extended Community: RT:64600:115 Advertised Path ID: 1 Last update: Thu Oct 15 22:46:42 2026On FW-02, the route is now installed in VRF 115 with the required extended community route tag attribute.FW-02 # get router info bgp network 10.115.2.0/24 VRF 115 BGP routing table entry for 10.115.2.0/24 Paths: (1 available, best #1, table Default-IP-Routing-Table) Advertised to non peer-group peers: 10.200.228.5 10.200.228.6 Original VRF 10 external duplicated 64902 64902 64902 64902 64902 64901 64900 0.0.0.0 from 10.100.223.9 (192.168.250.54) Origin incomplete distance 20 metric 0, localpref 100, valid, external, best Extended Community: RT:64600:115 Advertised Path ID: 1 Last update: Thu Oct 15 22:48:01 2026 FortiGate Thu, 29 Oct 2026 17:42:34 +0100 https://community.fortinet.com/fortigate-3/dial-up-ipsec-vpn-clients-assigned-duplicate-ip-addresses-230985 DescriptionHow to prevent remote users connecting via dial-up IPsec VPN from being assigned IP addresses already in use by other active sessions, leading to connectivity drops and authentication failures.ScopeFortiGate, FortiClient/EMS.SolutionSymptomsUsers connecting to a dial-up IPsec VPN configured with "net-device disable" experience connection drops immediately after completing Multi-Factor Authentication (MFA). Logs indicate that the IP address assigned to a new user is already linked to another active VPN session.The issue occurs when the system reassigns IP addresses too quickly after a session ends or when the tunnel configuration does not properly manage the IP pool reuse interval. This can lead to IP address conflicts where multiple users are assigned the same address from the configured range.ResolutionTo resolve IP address duplication and improve connection stability, perform the following steps:Configure IP address reuse delay:Increase the time the FortiGate waits before reusing an IP address from the pool. This prevents a new user from receiving an IP that is still associated with a recently disconnected session.config vpn ipsec phase1-interface edit <Tunnel_Name> set ip-delay-interval 240 next endOptimize tunnel configuration:Follow these best practices to ensure tunnel stability and performance:Upon experiencing this issue, limit the number of characters in the IPsec VPN phase 1 name to avoid potential processing issues (must be below 13 characters), even when net device is disabled. See Technical Tip: IPsec VPN phase1 interface name characters limitation best practice.Disable reauthentication on the tunnel to prevent unexpected drops during active sessions.Enable the net-device setting if the environment requires specific network device handling for the tunnel.To enable the net-device setting, run the following commands:config vpn ipsec phase1-interface edit <Tunnel_Name> set net-device enable next endVerify and troubleshoot:If the issue persists, use the following commands to monitor IP assignments and tunnel status:diagnose vpn ike gateway list diagnose vpn tunnel list diagnose vpn ipsec status get vpn ike gateway get vpn ipsec tunnel details get vpn ipsec state tunnelTo capture detailed debug logs for the IKE process and authentication, use these commands:diagnose debug reset diagnose debug disable diagnose vpn ike log filter name <Tunnel_Name> diagnose vpn ike log filter rem-addr4 <Remote_IP> diagnose debug application ike -1 diagnose debug application eap_proxy -1 diagnose debug console timestamp enable diagnose debug enable diagnose debug application fnbamd -1After, open a TAC support case with this evidence: Customer Service Tip: How to create a ticket for Fortinet TAC. FortiGate Thu, 29 Oct 2026 17:34:38 +0100 https://community.fortinet.com/fortigate-3/fortigate-30-31g-platform-unable-to-upgrade-to-fortios-7-6-8-this-firmware-didn-t-pass-the-signature-verification-230865 DescriptionInstructions to resolve the "This Firmware didn't pass the signature verification." error when upgrading to FortiOS 7.6.8.ScopeFortiOS.SolutionWhen upgrading from FortiOS 7.6.7 to 7.6.8, you may face an error stating "This Firmware didn't pass the signature verification." when the image has finished downloading (or uploading, if you are using the file upload function):This is a known issue with the 30/31G platform, and the solution is to upgrade to FortiOS 7.6.7 STS build 8767 before proceeding. To get this build, open a TAC ticket. After upgrading to this build, it will be possible to upgrade to FortiOS 7.6.8 GA: FortiOS 7.6.7 GA -> 7.6.7 STS build8767 -> 7.6.8 GA.Useful:In the ticket, you will find attached the special build you should need for the upgrade :The upgrade path should be: Current FOS 7.6.7 GA -> Special build8767 -> 7.6.8 GAAlternatively, you can upgrade the device via FortiManager.Note: If during the upgrade procedure you get an error on the GUI stating: "Image upgrade fail device could not be rebooted" and via console cable:inflate() error: -3This is because the device does not have enough free RAM to proceed with the upgrade. As a workaround, change the number of IPS workers to 1:config ips global set engine-count 1 endReboot the unit and try again. If it still fails with the same error, disable UTM temporarily in the Firewall Policies to free more memory and perform another reboot. FortiGate Thu, 29 Oct 2026 17:15:30 +0100 https://community.fortinet.com/fortigate-3/traffic-logs-generated-on-fortigate-proxy-policies-despite-logging-being-disabled-230984 DescriptionFortiGate generates excessive traffic logs for proxy policies even when the logtraffic setting is disabled, leading to increased log volume on FortiAnalyzer.ScopeFortiGate, FortiAnalyzer.SolutionAfter upgrading to FortiOS 7.6.6 or 7.6.7, the volume of daily logs sent to FortiAnalyzer increases significantly. Traffic logs with Log ID 13 continue to be generated for policies where logging is explicitly disabled using the set logtraffic disable command.A bug in the logging logic of FortiOS 7.6.x causes traffic logs to be generated for proxy policies regardless of the logtraffic configuration. This issue affects both explicit proxy policies and standard firewall policies configured with inspection-mode proxy.Resolution:Upgrade the FortiGate device to FortiOS 7.6.8 or a later version. This release contains the fix for the logging logic that prevents the unauthorized generation of traffic logs when logging is disabled.Verification steps:To confirm if the issue is present, check the logs on FortiAnalyzer for the following characteristics:Filter logs by logid 13.Verify if the logs are associated with a policy where set logtraffic disable is configured.Check if the affected policies use inspection-mode proxy or are defined as proxy-policy.Example of a policy configuration affected by this behavior:config firewall policy edit xxxx set inspection-mode proxy set logtraffic disable next end FortiGate Thu, 29 Oct 2026 17:08:32 +0100 https://community.fortinet.com/support-forum-92/help-with-third-party-sflow-collector-that-works-well-with-fortigate-133077 I all. I would like to obtain information about my network, mainly related to bandwitch usage. I go to install to obtain this information a netflow collector.I have read about some problems with some third party Netflow collectors and I would like to answer about your experience to install a good Collector to work with Fortigate Firewall.  Please, could you recommend me a netflow network analyzer, free if its possible and it works well with fortigate, to can monitorice the bandwitch of my network in a way that I can get more information  than the information that a widget or fortiview gives me?Thanks ¡¡¡ Support Forum Thu, 29 Oct 2026 16:29:56 +0100 https://community.fortinet.com/support-forum-92/missing-ztna-bookmark-options-for-rdp-230823 HelloWe want to replace Ivanti Connect Secure with Fortigate Agentless ZTNA for RDP connections.So far everything works fine but our customer has a special configuration on Ivanti Gateway:In the Ivanti bookmark configuration, an application (mstsc) is set to start automatically.This means that after the first RDP connect, an mstsc window opens, allowing you to switch to the next RDP server.We are using a Fortigate 101F / OS: 7.6.7For ZTNA Bookmark on Fortigate I found these RDP options:# set *apptype                  Application type.verify-cert              Enable/disable certificate verification of the real server.*host                     Host name/IP parameter.description              Description.keyboard-layout          Keyboard layout.security                 Security mode for RDP connection (default = any).send-preconnection-id    Enable/disable sending of preconnection ID.load-balancing-info      The load balancing information or cookie which should be provided to the connection broker.restricted-admin         Enable/disable restricted admin mode for RDP.port                     Remote port.color-depth              Color depth per pixel.sso                      Single sign-on.width                    Screen width (range from 0 - 65535, default = 0).height                   Screen height (range from 0 - 65535, default = 0). Is there no option like on Ivanti Gateway, where I can start an application? Thank you for helpRegardsSteffen Support Forum Thu, 29 Oct 2026 16:19:09 +0100 https://community.fortinet.com/support-forum-92/forticlient-vpn-for-ipados-fails-with-aes256-gcm-and-prf-sha384-sha512-in-ikev2-phase-1-230730 FortiClient VPN 7.4.11.0198 on iPadOS 26.7.1 fails to establish an IKEv2 IPsec tunnel to FortiGate running FortiOS 7.4.12 build 2902 when Phase 1 uses AES256-GCM with PRF-SHA384 or PRF-SHA512.FortiGate accepts the Phase 1 proposal:ENCR: AES_GCM_16, 256 bitINTEGR: NONEPRF: PRF_HMAC_SHA2_384 or PRF_HMAC_SHA2_512DH: MODP2048 or MODP3072However, FortiClient does not send the subsequent IKE_AUTH request. FortiGate eventually reports:negotiation timeout, deletingconnection expiring due to phase1 downThese combinations were tested:AES256-GCM / PRF-SHA256 / DH15: worksAES256-GCM / PRF-SHA384 / DH14 or DH15: fails after IKE_SA_INITAES256-GCM / PRF-SHA512 / DH14 or DH15: fails after IKE_SA_INITAES256-CBC / SHA384 / DH15: worksPhase 2 with AES256-GCM works correctly when Phase 1 uses either AES256-GCM/PRF-SHA256 or AES256-CBC/SHA384. The problem occurs with both SAML SSO and local username/password authentication, although authentication is never reached in the failing cases.I reproduced the issue on both an iPad and an iPhone running iPadOS/iOS 26.7.1. Has anyone else confirmed this behavior with FortiClient VPN 7.4.11, and is there a known solution, workaround, or bug ID?Thanks in advance.Best regards, Stepan Cirkl Support Forum Thu, 29 Oct 2026 16:06:26 +0100 https://community.fortinet.com/fortigate-3/troubleshooting-tip-resolving-stale-fsso-ts-gent-sessions-retained-by-collector-agent-230981 DescriptionIn environments utilizing Fortinet Single Sign-On (FSSO) Terminal Server Agent (TS Agent), if a host running the TS Agent service is decommissioned, shut down, or has the TS Agent software uninstalled, its assigned port-range logon sessions (type fsso_citrix) may persist indefinitely on the Collector Agent and continue to be advertised to FortiGate firewalls.Symptoms:Stale TS-Agent sessions persist indefinitely in the Collector Agent (show logon users) after the TS Agent service is stopped or uninstalled.Stale TS-Agent sessions coexist with fresh standard logons (such as EventLog polling or DC Agent) for the same IP address.User traffic using outbound source ports outside the assigned range fails identity-based firewall policies.Cause:Aging timer exclusions: Standard Collector Agent aging timers (Dead Entry Timeout, Workstation Verification, and DNS verification) are architected for single-user endpoints and deliberately exempt multi-user TS-Agent sessions.Silent service shutdown: When the TS Agent service stops or is uninstalled, it terminates without transmitting a logoff or disconnect notification to the Collector Agent.Session coexistence: TS-Agent sessions are indexed by server session ID rather than workstation name, allowing them to coexist alongside standard logons (EventLog or DC Agent) on the same IP address.Keepalive validation disabled by default: The Collector Agent background keepalive health check (tsagent_alive_check) is disabled by default (0).Security consideration: DHCP IP reuse:If a machine with an active TS Agent session releases its IP address back to a DHCP pool without a clean logoff, and a new client device subsequently leases that same IP address, any outbound traffic generated by the new device using source ports within the stale port range will inherit the previous user's FSSO identity and group permissions on the FortiGate. Enabling keepalive checking mitigates this identity-spoofing exposure.ScopeFSSO Collector Agent: All supported versions.FSSO Terminal Server Agent (TS Agent): All supported versions.Operating System: Microsoft Windows Server.SolutionTo enable automatic detection and cleanup of abandoned TS-Agent sessions, configure the tsagent_alive_check registry values on all Collector Agents.Step 1: Open Registry Editor.Launch regedit.exe on each Collector Agent server with administrative privileges.Step 2: Navigate to the correct registry key.The Collector Agent service queries the registry using the KEY_WOW64_32KEY flag. On 64-bit Windows installations, the values must reside under the 32-bit registry hive (WOW6432Node).64-bit Windows: HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Fortinet\FSAE\CollectorAgent32-bit Windows:HKEY_LOCAL_MACHINE\SOFTWARE\Fortinet\FSAE\CollectorAgentStep 3: Create or update DWORD values.Create or modify the following DWORD (32-bit) Value entries:NameTypeRecommended ValueDescriptiontsagent_alive_checkREG_DWORD1Enables Timer 6 to monitor TS Agent keepalives. (Default is 0 - Disabled).tsagent_alive_check_periodREG_DWORD7200 (Decimal)Timeout period in seconds. Once a TS Agent host stops sending keepalives for longer than this period, all sessions for that host IP are purged.Recommended timeout guidelines:Production Environments with regular maintenance: 7200 seconds (2 hours) is recommended to prevent premature session purges during routine Windows patching or server reboots.Fast cleanup / Lab environments: 300 seconds (5 minutes) can be used for rapid session cleanup.Step 4: Restart the service.A service restart is mandatory because the timer 6 evaluation thread is only initialized during service startup:Open Windows Services (services.msc).Restart the Fortinet Single Sign On Agent service (Fortinet_FSAE):Verification.In the Collector Agent GUI, navigate to the log level settings and set the log level to debug.Open CollectorAgent.log located under C:\Program Files (x86)\Fortinet\FSAE\.Verify that Timer 6 starts:Periodic keepalive checks log as TSAgentAliveCheck.When an abandoned host exceeds the timeout period, the log records:[UPDATE_LOGON_LIST] action:remove_entry ...In the Collector Agent GUI under Show Logon Users, confirm that the stale TS-Agent entry has been removed and only the active user session remains. FortiGate Thu, 29 Oct 2026 15:30:09 +0100 https://community.fortinet.com/fortinac-f-57/fortinac-disconnect-request-fails-with-ruckus-wireless-230980 DescriptionUsers connected to Ruckus wireless do not move to a new VLAN after a role change unless they manually disconnect and reconnect to the Wi-Fi.ScopeFortiNAC-F v7.6.5.SolutionSymptoms.When a user role is changed in FortiNAC, the user remains in the current VLAN. The user must manually disconnect and reconnect to the wireless network to be moved to the new VLAN. A packet capture shows that FortiNAC sends a Disconnect-Request, but the Ruckus controller responds with a Disconnect-NAK.Root cause.The Ruckus controller requires specific attributes in the RADIUS Disconnect-Request message to identify the session. If these attributes are missing, the controller rejects the request with a Disconnect-NAK.Resolution.To resolve this issue, configure a custom attribute group and apply it to the device model configuration using RFC5176 mode.Step 1: Create a custom attribute group.Create a new custom attribute group.Add the following attributes to the group with the specified values:NAS-IP-Address = %AUTH%Calling-Station-ID = %AUTH%User-Name = %AUTH%Step 2: Configure the device model.Go to the device model configuration for the Ruckus controller.Select 'Custom RFC5176' mode.Select the custom attribute group created in Step 1.Step 3: Verify the configuration.Run a packet capture to confirm that the Ruckus controller now responds with a Disconnect-ACK. Use the following command to capture RADIUS traffic:execute tcpdump -vi port1 port 1812 or port 1813 or port 3799 and host <Ruckus_IP>The successful exchange should look similar to the following:Disconnect-Request (40) NAS-IP-Address Attribute (4), Value: <Ruckus_IP> User-Name Attribute (1), Value: <User_MAC> Calling-Station-Id Attribute (31), Value: <User_MAC> Disconnect-ACK (41) FortiNAC-F Thu, 29 Oct 2026 15:23:58 +0100 https://community.fortinet.com/support-forum-92/fortimail-ha-group-vip-dkim-key-synchronization-and-action-on-failure-behavior-230979 Hello everyone, I have a few questions about how synchronization works at the HA group level.Virtual IPs (VIPs): Are VIPs synchronized across all the clusters/units that belong to the HA group, or must they be configured separately on each cluster? DKIM keys: Are DKIM keys synchronized across all the units/clusters in the HA group? Or do we need to generate or import them manually on each one? “Action on failure” in the HA group: When this option is set to “Wait for recovery and switch to configured role”, what happens when Site A comes back after being down while Site B was acting in its place? Does Site A resynchronize and apply the configuration changes made on Site B during the outage before switching back to its configured role? Or does it come back with its old configuration, potentially overwriting or ignoring the changes made on Site B? Thanks in advance,BR, Support Forum Thu, 29 Oct 2026 15:12:08 +0100 https://community.fortinet.com/fortinac-f-57/isolation-network-failure-in-fortinac-v7-6-7-operating-in-layer-2-mode-230978 DescriptionUpgrading FortiNAC from version 7.6.6 to 7.6.7 may cause Layer 2 isolation and remediation interfaces to lose their IP addresses, resulting in DHCP and captive portal failures.ScopeFortiNAC-F v7.6.7.SolutionSymptoms.After upgrading FortiNAC from version 7.6.6 to 7.6.7, the following issues occur in Layer 2 isolation mode:The Configuration Wizard Summary displays the message "No isolation networks configured" even when isolation is correctly configured.Isolation and remediation interfaces lose their assigned IP addresses.DHCP services and the captive portal on these networks stop responding.The DHCP service may become inactive.Verify the DHCP service status using the following command:execute service status kea-dhcp6The output shows the service as Active: inactive (dead).Applying the config wizard displays the following result:Results 2026/10/13 15:04:56 Successful Configuration, scroll down for details. You will need to reboot your FortiNAC-CA. Results are written to the following file: /bsc/campusMgr/config/results.html File /bsc/campusMgr/bin/.cm_config written successfully Configuring DHCP Server... No isolation networks configured <====== (EVEN THOUGH ISOLATION IS CONFIGURED AND NO CHANGES HAVE BEEN MADE) DHCP Server configuration updated successfully Successful write to file /etc/hosts using /bsc/campusMgr/config/templates/hosts_Server.template Root cause.A problem in the configuration script in FortiNAC version 7.6.7 causes Layer 2 isolation and remediation VLAN interfaces to be omitted. As a result, these networks are silently discarded.Resolution.This issue is resolved in the upcoming FortiNAC version 7.6.8. To resolve the problem, perform the following steps:Take a virtual machine snapshot and perform a full system and database backup of the current environment.Upgrade FortiNAC to version 7.6.8 during a scheduled maintenance window.Verify that the isolation and remediation interfaces have the correct IP addresses assigned.Run the Configuration Wizard to ensure the summary no longer displays 'No isolation networks configured'. FortiNAC-F Thu, 29 Oct 2026 14:39:29 +0100 https://community.fortinet.com/fortigate-3/bypassing-forticare-registration-when-cli-configuration-or-off-network-license-uploading-fails-230977 DescriptionInstructions to bypass FortiCare registration through BIOS.ScopeFortiGate.SolutionOn newer FortiGate models, FortiCare registration is required before accessing the GUI. After the first login, you will be automatically redirected to the registration page. Once the device is registered, you can proceed with the configuration.However, there are situations where internet connectivity cannot be established through the CLI, preventing FortiCare registration, or where the air-gapped deployment option does not function as expected. Please try this methods first before changing BIOS settings: Enforce FortiCare registration.Example 1: It is not possible to select the reseller because the device does not have an Internet connection configured and there is no other option to bypass registration:Example 2: Before FortiCare registration is completed, the FortiOS CLI is restricted to read-only access, with only a subset of network configuration commands permitted. In theory, these commands should allow customers to configure an Internet connection. However, some customers have reported that they are unable to use them as expected or not recognizing the commands at all.SolutionThe solution is to access the BIOS menu and manually set the FortiCare registration level to 1 as shown in the Registering FortiGate section of the documentation. FortiGate Thu, 29 Oct 2026 14:23:05 +0100 https://community.fortinet.com/fortirecorder-31/how-to-configure-ldap-user-query-for-ldap-authentication-on-fortirecorder-to-restrict-access-to-users-within-a-specific-group-on-active-directory-ad-230976 DescriptionThis article discusses how to configure an LDAP user query for LDAP authentication on FortiRecorder to restrict access to users within a specific group in Active Directory(AD).ScopeFortiRecorder.SolutionSet 'User Authentication Options' to 'Search user and try bind DN', and change the user query as below, replacing the text in bold with appropriate config relevant to the network: '(&(|(objectClass=user)(objectClass=group)(objectClass=publicFolder))(|(proxyAddresses=smtp:$m)(mail=$m)(sAMAccountName=$u))(memberOf=CN=<group name>,OU=<OU or CN>,DC=<domain>,DC=<com>))'. Example:FK-SVM0000000000 # show profile ldap config profile ldap edit AD set server 10.1.1.3 set base-dn dc=test,dc=com set bind-dn "test\\Administrator" set bind-password ENC xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx set query "(&(|(objectClass=user)(objectClass=group)(objectClass=publicFolder))(|(proxyAddresses=smtp:$m)(mail=$m)(sAMAccountName=$u))(memberOf=CN=GG_testAccess,ou=Managed Groups,ou=Groups,ou=testing,DC=test,DC=com))" next endRelated article:Technical Guide: Configuring LDAP authentication FortiRecorder Thu, 29 Oct 2026 14:20:08 +0100 https://community.fortinet.com/support-forum-92/fortinac-7-6-x-how-to-assign-vlans-based-on-certificate-authentication-eap-tls-230919 Hi all,I am deploying FortiNAC-F v7.6.x using Local RADIUS with EAP-TLS authentication and Microsoft CA.The environment uses Active Directory (AD), where client devices are required to authenticate to the network exclusively using digital certificates, without requiring a username or password.When a client successfully authenticates using a valid certificate, how does FortiNAC identify the client and determine which Role or Network Access Policy to apply for VLAN assignment?What is the recommended configuration for this scenario? Support Forum Thu, 29 Oct 2026 14:00:02 +0100 https://community.fortinet.com/fortigate-3/technical-tip-multiple-dashboard-alerts-on-fortigate-after-upgrading-to-fortios-v7-6-7-230096 DescriptionThis article describes the issue of multiple alerts appearing on the FortiGate GUI after upgrading to FortiOS v7.6.7. The user may experience this issue when logging in to the FortiGate GUI in read-only mode, even without making any changes to the dashboard.ScopeFortiGate.SolutionFor FortiGate FortiOS V7.6.7 managed by FortiManager, when logging in to the GUI using a read-only account, multiple alert messages will appear: Dashboard changes will not be saved due to the device being managed by FortiManager.The alerts are cosmetic as FortiOS v7.6.7 restricts read-only accounts to make changes to the FortiGate GUI dashboard.The alerts only appear when logging into the GUI using a read-only account. Read-write accounts do not show the alerts.As a workaround, a dummy GUI dashboard configuration can be added to the read-only account.config system admin edit <read-only-account-name> config gui-dashboard edit 1 set name "Status" set vdom "root" set layout-type standalone set permanent enable set csf enable config widget edit 1 set type sysinfo set x-pos 0 set y-pos 0 set width 1 set height 1 set source '' set csf-device '' set overlay-autoplay-speed 5 next end next endAfter adding the dummy dashboard configuration to the read-only account, the alert no longer appears. FortiGate Thu, 29 Oct 2026 13:41:21 +0100 https://community.fortinet.com/fortigate-3/rest-api-super-admin-profiled-admin-access-using-pki-group-fails-230974 DescriptionAn error during the authentication of a REST API super-admin profile admin account and available workarounds.ScopeFortiOS 7.4, 7.6.SolutionThere is a KB article, Technical Tip: FortiGate REST API access using PKI group, describing an option to use PKI user settings on FortiOS for REST API admin authentication with a token and certificate.REST API super-admin profiled admin access using a PKI group fails with errors “No matched peer found for given certificate”, “Peer certificate invalid or missing,” and “Failed api-key login attempt”.These debugs should be enabled to see authentication attempts:diagnose debug reset diagnose debug application httpsd -1 diagnose debug application fnbamd -1 diagnose debug console timestamp enable diagnose debug enableDebug snippets while a super-admin-profiled REST API admin sends a request to any interface with enabled HTTPS service. Some debug outputs are skipped intentionally:2026-10-09 12:46:19 0httpsd 1042 - 1791542779 info] fweb_debug_initw626] -- New GET request for "/api/v2/monitor/system/status" from "192.168.178.20:63854" <<<--- REQUEST 2026-10-09 22:46:19 02416] handle_req-Rcvd auth_cert req id=4475563298818, len=1894, opt=0 2026-10-09 22:46:19 0705] fnbamd_cert_check_group_list-checking group with name 'api-group' 2026-10-09 22:46:19 0518] __check_add_peer-check 'api-group' 2026-10-09 22:46:19 0520] __check_add_peer-'api-group' is not a peer user. <<<--- ERROR #1 .. .. 2026-10-09 22:46:19 01256] fnbamd_cert_auth_copy_cert_status-req_id=4475563298818 2026-10-09 22:46:19 0884] fnbamd_cert_check_matched_groups-checking group with name 'api-group' 2026-10-09 22:46:19 0954] fnbamd_cert_check_matched_groups-not matched <<<--- ERROR #2 2026-10-09 22:46:19 01295] fnbamd_cert_auth_copy_cert_status-Leaf cert status is unchecked. 2026-10-09 22:46:19 01383] fnbamd_cert_auth_copy_cert_status-Cert st 2c0, req_id=4475563298818 2026-10-09 22:46:19 0239] fnbamd_comm_send_result-Sending result 0 (nid 672) for req 4475563298818, len=2592 2026-10-09 22:46:19 2026-10-09 12:46:19 01390] destroy_auth_cert_session-id=4475563298818 3httpsd 1042 - 1791542779 warning] _peer_auth_certificate_validt182] -- No matched peer found for given certificate. <<<--- ERROR #3 2026-10-09 22:46:19 2026-10-09 12:46:19 01228] fnbamd_cert_auth_uninit-req_id=4475563298818 3httpsd 1042 - 1791542779 info] api_access_check_for_api_keyc664] -- Peer certificate invalid or missing. <<<--- ERROR #4 2026-10-09 22:46:19 2026-10-09 12:46:19 01874] fnbamd_ldaps_destroy- ehttpsd 1042 - 1791542779 warning] _lock_out_check_and_lock_outk418] -- Failed api-key login attempt from 192.168.178.20. (4/10 attempts within 60s). <<<--- ERROR #6 2026-10-09 22:46:19 01447] fnbamd_rads_destroy-There is a known issue, which is resolved in 7.6.7 and 8.0.0. The problem is with restricted PKI-user authentication, which can not retrieve other VDOM settings.Unfortunately, there is no fix yet for the 7.4 major version; however, there are available workarounds:Use a connection to the root.VDOM interface.Create and apply pki-user settings and group to api-admin account in the VDOM which interface request is reached.The following snippet is a configuration for workaround #2:API-user settings in global VDOM:FR02FW02 (global) # show system api-user config system api-user edit "apiadm01" set comments "" set api-key ENC KEY set accprofile "super_admin" set peer-auth enable set peer-group "pkigr-ext-vd" next endUser-peer and user-group settings in the VDOM where the request is reached:FR02FW02 # config vdom FR02FW02 (vdom) # edit external current vf=external:1 FR02FW02 (external) # show user peer config user peer edit "peer-ext" set ca "CA_Cert_1" next end FR02FW02 (external) # show user group config user group edit "SSO_Guest_Users" next edit "pkigr-ext-vd" set member "peer-ext" next endSettings of the interface that the request has reached:FR02FW02 # config vdom FR02FW02 (vdom) # edit external FR02FW02 (external) # show system interface port2 config system interface edit "port2" set vdom "external" set ip 10.5.208.220 255.255.192.0 set allowaccess ping https ssh http telnet fgfm set type physical set snmp-index 4 next endHTTPS debug outputs:2026-10-14 11:44:08 0httpsd 1789 - 1791971048 info] _peer_auth_certificate_validt189] -- Api-key + certificate login successful for apiadm01 via pki peer peer-ext 2026-10-14 11:44:08 0httpsd 1789 - 1791971048 info] api_access_check_for_api_keyc691] -- API Key request authorized for apiadm01 from 10.5.255.254.Related article:REST API administrator FortiGate Thu, 29 Oct 2026 13:34:44 +0100 https://community.fortinet.com/support-forum-92/suspected-false-positive-eurotool-xlam-flagged-as-fsa-risk-high-2000002166-230972 Hello everyone,Since this morning, multiple clients across our network have simultaneously started receiving virus warnings from FortiClient. The legitimate Office component EUROTOOL.XLAM is being flagged as high risk.I have reviewed the hash (2C4AFE4AFEDE252158A732EDB0C3754B9CB984A7CC2EB6EEFAC47C1EF38C9753)  , file location and metadata on a number of devices and all comes back clear.Since the file is cryptographically clean and unmodified I strongly suspect this is a false positiveHas anyone else seen similar in their orgs? Thanks in advancePASMC Support Forum Thu, 29 Oct 2026 13:23:19 +0100 https://community.fortinet.com/fortiguard-23/technical-tip-fortinet-fortiguard-connectivity-requirements-for-update-services-230971 DescriptionThis article describes the requirement for Fully Qualified Domain Names (FQDNs) and provides guidance on configuring outbound access controls to ensure Fortinet products like FortiGate and FortiWeb can connect to FortiGuard update services.ScopeFortiGate, FortiWeb, FortiGuard.SolutionSymptoms.Fortinet products like FortiGate and FortiWeb appliances may experience intermittent failures when downloading security signature updates if outbound security controls restrict traffic to specific IP addresses. This occurs because the IP addresses associated with FortiGuard update services change dynamically.Root Cause.FortiGuard services use dynamic IP addressing. If a network environment uses a strict allow-list based on individual IP addresses rather than FQDNs, connectivity is lost when the service resolves to a new IP address not present in the allow-list.Resolution.Recommended Configuration.Reference FortiGuard services by FQDN to avoid connectivity issues caused by IP address changes. Configure outbound security controls to permit the following endpoints:service.fortiguard.net — UDP port 53, 8888securewf.fortiguard.net — HTTPS over ports 443, 53, 8888update.fortiguard.net — TCP port 443usupdate.fortinet.net — TCP port 443usservice.fortiguard.net — UDPussecurewf.fortiguard.net — HTTPSeuservice.fortiguard.net — UDPeusecurewf.fortiguard.net — HTTPSAdditional subscription service domains include:globalupdate.fortinet.net — Object download serverglobalguardservice.fortinet.net — Querying service servergloballogctrl.fortinet.net — FortiGate Cloud loggingglobalmgrctrl.fortinet.net — FortiGate Cloud managementglobalmsgctrl.fortinet.net — FortiGate Cloud messagingglobalaptctrl.fortinet.net — FortiGate Cloud sandboxglobalproductapi.fortinet.net — Product API serverAlternative configuration for strict IP allow-listing:If the environment requires explicit IP or CIDR ranges, use the following methods to identify legitimate FortiGuard IP ranges:FortiGate: Use the built-in Internet Service Database (ISDB) object on a FortiGate device to verify IP ranges and associated ports.Technical Tip: How to search ISDB using IP addressFortiGate: Refer to the following technical resources for methods to fetch updated lists of FortiGuard server IP addresses via the Command Line Interface (CLI):Technical Tip: How to get an updated list of IP addresses of all FortiGuard servers via CLIFortiGate: How to get an updated list of IP addresses of all FortiGuard servers via CLI:Technical Tip: The FortiGuard IP address rangeAlternatively, find the FortiGuard IP address ranges and respective protocols and ports for Fortinet products in general, including FortiWeb.IP ranges listening on TCP ports 25, 53, 80, 443, 465, 514, 541-542, 853, 2195-2196, 5223, 8000, 8686, 8888, 8890, 9582IP range3.33.191.177-3.33.191.17712.34.97.0-12.34.97.25513.248.131.62-13.248.131.6213.248.136.8-13.248.136.813.248.137.30-13.248.137.3013.248.211.0-13.248.211.013.248.219.43-13.248.219.4315.220.85.25-15.220.85.2515.220.85.206-15.220.85.20615.220.85.223-15.220.85.22334.205.201.225-34.205.201.22538.21.200.58-38.21.200.5838.21.200.120-38.21.200.12045.75.200.64-45.75.200.9554.252.14.246-54.252.14.24659.108.28.228-59.108.28.22859.108.28.239-59.108.28.23959.108.28.244-59.108.28.24461.204.170.252-61.204.170.25263.137.229.12-63.137.229.1264.26.135.64-64.26.135.9564.26.151.32-64.26.151.6364.114.199.234-64.114.199.23465.210.95.224-65.210.95.25566.117.56.32-66.117.56.6369.167.109.72-69.167.109.7269.167.109.241-69.167.109.24169.167.109.247-69.167.109.24869.195.205.64-69.195.205.11172.1.78.32-72.1.78.3272.1.79.4-72.1.79.472.1.79.6-72.1.79.675.2.56.5-75.2.56.576.223.2.16-76.223.2.1676.223.10.41-76.223.10.4176.223.64.5-76.223.64.576.223.68.60-76.223.68.6080.85.69.32-80.85.69.6383.231.212.0-83.231.212.25596.45.32.0-96.45.33.25596.45.34.47-96.45.34.4796.45.36.95-96.45.36.9596.45.45.45-96.45.45.4596.45.46.46-96.45.46.4699.83.210.24-99.83.210.24104.204.181.15-104.204.181.15104.204.181.59-104.204.181.59104.204.181.194-104.204.181.194111.108.191.64-111.108.191.95121.111.236.179-121.111.236.180130.61.107.7-130.61.107.7139.138.105.0-139.138.105.255140.174.22.0-140.174.22.255141.109.161.71-141.109.161.71141.109.166.0-141.109.166.255148.116.71.219-148.116.71.219148.230.32.0-148.230.32.255148.230.33.0-148.230.33.255148.230.34.0-148.230.34.255148.230.36.0-148.230.36.255148.230.40.71-148.230.40.71148.230.40.76-148.230.40.76148.230.41.79-148.230.41.79148.230.41.122-148.230.41.122149.5.232.0-149.5.232.255154.52.1.42-154.52.1.42154.52.1.107-154.52.1.107154.52.1.125-154.52.1.125154.52.1.208-154.52.1.208154.52.1.232-154.52.1.232154.52.1.250-154.52.1.250154.52.2.50-154.52.2.50154.52.10.102-154.52.10.106154.52.11.0-154.52.11.255154.52.24.0-154.52.24.110154.52.24.113-154.52.24.255154.52.30.0-154.52.30.255160.223.166.39-160.223.166.39173.140.138.16-173.140.138.31173.243.129.6-173.243.129.6173.243.129.16-173.243.129.16173.243.129.18-173.243.129.18173.243.132.23-173.243.132.26173.243.132.185-173.243.132.185173.243.137.143-173.243.137.143173.243.138.0-173.243.138.255173.243.140.0-173.243.140.255173.243.141.6-173.243.141.6173.243.141.16-173.243.141.16173.243.141.18-173.243.141.18173.243.141.26-173.243.141.26173.243.141.36-173.243.141.36173.243.141.64-173.243.141.255173.243.142.0-173.243.142.255173.243.143.0-173.243.143.255184.94.113.225-184.94.113.235192.35.158.0-192.35.158.255194.69.172.21-194.69.172.59194.69.174.0-194.69.174.255208.91.112.0-208.91.112.255208.91.113.114-208.91.113.114208.91.113.249-208.91.113.249208.91.114.32-208.91.114.32208.91.114.151-208.91.114.151208.91.114.190-208.91.114.190208.184.237.46-208.184.237.119209.40.99.3-209.40.99.3209.40.100.3-209.40.100.3209.40.106.0-209.40.106.255209.40.117.130-209.40.117.130209.222.136.0-209.222.136.31209.222.147.32-209.222.147.63IP ranges listening on UDP ports 53, 5246, 8888:IP range3.33.191.177-3.33.191.17712.34.97.0-12.34.97.25513.248.131.62-13.248.131.6213.248.136.8-13.248.136.813.248.137.30-13.248.137.3013.248.211.0-13.248.211.013.248.219.43-13.248.219.4315.220.85.25-15.220.85.2515.220.85.206-15.220.85.20615.220.85.223-15.220.85.22334.205.201.225-34.205.201.22538.21.200.58-38.21.200.5838.21.200.120-38.21.200.12045.75.200.64-45.75.200.9554.252.14.246-54.252.14.24659.108.28.228-59.108.28.22859.108.28.239-59.108.28.23959.108.28.244-59.108.28.24461.204.170.252-61.204.170.25263.137.229.12-63.137.229.1264.26.135.64-64.26.135.9564.26.151.32-64.26.151.6364.114.199.234-64.114.199.23465.210.95.224-65.210.95.25566.117.56.32-66.117.56.6369.167.109.72-69.167.109.7269.167.109.241-69.167.109.24169.167.109.247-69.167.109.24869.195.205.64-69.195.205.11172.1.78.32-72.1.78.3272.1.79.4-72.1.79.472.1.79.6-72.1.79.675.2.56.5-75.2.56.576.223.2.16-76.223.2.1676.223.10.41-76.223.10.4176.223.64.5-76.223.64.576.223.68.60-76.223.68.6080.85.69.32-80.85.69.6383.231.212.0-83.231.212.25596.45.32.0-96.45.33.25596.45.34.47-96.45.34.4796.45.36.95-96.45.36.9596.45.45.45-96.45.45.4596.45.46.46-96.45.46.4699.83.210.24-99.83.210.24104.204.181.15-104.204.181.15104.204.181.59-104.204.181.59104.204.181.194-104.204.181.194111.108.191.64-111.108.191.95121.111.236.179-121.111.236.180130.61.107.7-130.61.107.7139.138.105.0-139.138.105.255140.174.22.0-140.174.22.255141.109.161.71-141.109.161.71141.109.166.0-141.109.166.255148.116.71.219-148.116.71.219148.230.32.0-148.230.32.255148.230.33.0-148.230.33.255148.230.34.0-148.230.34.255148.230.36.0-148.230.36.255148.230.40.71-148.230.40.71148.230.40.76-148.230.40.76148.230.41.79-148.230.41.79148.230.41.122-148.230.41.122149.5.232.0-149.5.232.255154.52.1.42-154.52.1.42154.52.1.107-154.52.1.107154.52.1.125-154.52.1.125154.52.1.208-154.52.1.208154.52.1.232-154.52.1.232154.52.1.250-154.52.1.250154.52.2.50-154.52.2.50154.52.10.102-154.52.10.106154.52.11.0-154.52.11.255154.52.24.0-154.52.24.110154.52.24.113-154.52.24.255154.52.30.0-154.52.30.255160.223.166.39-160.223.166.39173.140.138.16-173.140.138.31173.243.129.6-173.243.129.6173.243.129.16-173.243.129.16173.243.129.18-173.243.129.18173.243.132.23-173.243.132.26173.243.132.185-173.243.132.185173.243.137.143-173.243.137.143173.243.138.0-173.243.138.255173.243.140.0-173.243.140.255173.243.141.6-173.243.141.6173.243.141.16-173.243.141.16173.243.141.18-173.243.141.18173.243.141.26-173.243.141.26173.243.141.36-173.243.141.36173.243.141.64-173.243.141.255173.243.142.0-173.243.142.255173.243.143.0-173.243.143.255184.94.113.225-184.94.113.235192.35.158.0-192.35.158.255194.69.172.21-194.69.172.59194.69.174.0-194.69.174.255208.91.112.0-208.91.112.255208.91.113.114-208.91.113.114208.91.113.249-208.91.113.249208.91.114.32-208.91.114.32208.91.114.151-208.91.114.151208.91.114.190-208.91.114.190208.184.237.46-208.184.237.119209.40.99.3-209.40.99.3209.40.100.3-209.40.100.3209.40.106.0-209.40.106.255209.40.117.130-209.40.117.130209.222.136.0-209.222.136.31209.222.147.32-209.222.147.63 FortiGuard Thu, 29 Oct 2026 13:14:08 +0100 https://community.fortinet.com/support-forum-92/free-fortinet-exams-167033  friends a question:As you know, the NSX no longer exists. Before, the NSE1 NS2 were free. My question is, now with the changes made by Fortinet, are there still free exams? which are? Support Forum Thu, 29 Oct 2026 13:00:40 +0100 https://community.fortinet.com/fortimanager-27/how-to-configure-ems-connector-for-a-specific-vdom-using-fortimanager-230970 DescriptionFortiManager allows administrators to configure an EMS connector at the ADOM level. By default, the configured EMS connector is pushed to all FortiGate devices within the ADOM. For FortiGate devices operating in multi-VDOM mode, this configuration is applied at the Global level.However, in a multi-VDOM environment, individual VDOMs can override the Global EMS configuration to connect to their own EMS servers. VDOMs that do not enable the override continue to inherit the Global EMS configuration.ScopeFortiManager 7.4, 7.6, 8.0.SolutionBackgroundThe EMS connector can be configured in FortiManager under Fabric View -> Fabric connector -> Enable EMS.When configured at the ADOM database level, the EMS connector is intended to be distributed to the FortiGate devices managed by that ADOM. In multi-VDOM mode, the configuration is applied at the Global level.FortiGate also supports configuring an EMS connector override at the VDOM level. When the override is enabled, the VDOM can use its own EMS configuration instead of inheriting the Global configuration.The VDOM-level EMS configuration is stored in the FMG Device Database. Therefore, configuring an EMS connector in the ADOM database does not override an existing VDOM-level EMS configuration.Configuring the EMS connector in the FortiManager ADOM database remains necessary when FortiManager needs to import tags from the EMS server.SetupFollow the steps below to configure an EMS connector override for a specific VDOM on a FortiGate operating in multi-VDOM mode.Step 1: Enable endpoint-control settings for the VDOMNavigate to Device Manager -> Device & Groups.Select the required FortiGate VDOM.Navigate to CLI Configuration -> endpoint-control settings -> Enable it.Step 2: Install the VDOM device settings.Step 3: Retrieve the configuration: Technical Tip: Retrieve configuration file using GUI or CLI from a FortiManager.Step 4: Configure the VDOM-level EMS connector.Navigate to Device Manager -> Device & Groups.Select the required FortiGate VDOM.Navigate to CLI Configuration -> fctems-override -> Configure the EMS connector required per-VDOM and enable it.Install the configuration to the FortiGate.SummaryAfter the configuration is installed successfully:The specified VDOM uses its own EMS configuration.VDOMs without the override enabled continue to inherit the Global EMS configuration.The EMS connector configured in the ADOM database remains available for FortiManager's EMS tag-import functionality. FortiManager Thu, 29 Oct 2026 12:44:19 +0100 https://community.fortinet.com/fortigate-3/fortigate-ipoe-setup-guide-ntt-docomo-business-corporation-fixedip-230969 DescriptionThis article is written based on the FortiGate-60F. The WAN configuration with multiple VNE interfaces requires FortiOS 7.6.1 or later. If required to use multiple VNE interface features, make sure to upgrade FortiGate in advance. For information on the firmware upgrade path and how to upgrade, please refer to the release notes or manuals.ScopeFortiGate 7.6.1 and later.SolutionWAN 1 Interface IPv6config system interface edit "wan1" set vdom "root" set mode dhcp set allowaccess ping set type physical set role wan set snmp-index 1 config ipv6 set dhcp6-information-request enable set autoconf enable set unique-autoconf-addr enable end next end VNE configurationconfig system vne-interface edit "vne.wan1" set interface "wan1" next end IPv4 Default Routeconfig router static edit 1 set device "vne.wan1" next end IPv4 firewall policyconfig firewall policy edit 1 set name "internal-vne.wan1" set srcintf "internal" set dstintf "vne.wan1" set action accept set srcaddr "all" set dstaddr "all" set schedule "always" set service "ALL" set logtraffic all set nat enable set tcp-mss-sender 1420 set tcp-mss-receiver 1420 next end DHCPv4 server settingsconfig system dhcp server edit 1 set dns-service default set default-gateway 192.168.101.254 set netmask 255.255.255.0 set interface "internal" config ip-range edit 1 set start-ip 192.168.101.101 set end-ip 192.168.101.200 next end next endChecking the IPv6 addressWAN1 and the IPv6 address for the IPv4 over IPv6 tunnel generated by the obtained MAP rules are both configured. These IPv6 addresses are automatically generated based on the settings so far. If these IPv6 addresses are not set, it could be a misconfiguration or an environmental factor. In that case, verify the settings and investigate the environment.FortiGate-60F # diagnose ipv6 address list dev=5 devname=wan1 flag=P scope=0 prefix=128 addr=XXXX:XXXX:XXXX:XXXX:<auto-generated>:0 preferred=4294967295 valid=4294967295 cstamp=72883 tstamp=72883 dev=5 devname=wan1 flag= scope=0 prefix=64 addr=XXXX:XXXX:XXXXX:XXXX:<auto-generated> preferred=14281 valid=2591881 cstamp=71960 tstamp=672570 (omitted)Checking the IPv4 over IPv6 tunnelMake sure that the IPv4 over IPv6 tunnel with the IPv6 tunnel endpoint is properly established. The IPv6 addresses for the IPv4 over IPv6 tunnel created by the MAP rule are shown in the blue box, and the IPv6 address of the IPv6 tunnel endpoint is shown in the orange box.FortiGate-60F # diagnose ipv6 ipv6-tunnel list devname=vne.wan1 devindex=5 ifindex=27 vfid=0000 rpdb=0 ref=0 laddr=XXXX:XXXX:XXXX:XXXX:<Auto-generated> raddr=XXXX:XXXX:XXXX::X <-- IPv6 tunnel endpoint device RX bytes:0 (0.0 b) TX bytes:232 (232.0 b); RX packets:0, TX packets:2, TX carrier_err:0 collisions:0 npu-info: asic_offload=1, enc4/dec4=0/0, enc6/dec6=0/0, enc4_bk=0/0/0/0, dec4_bk=0/0/0/0, enc6_bk=0/0/0/0, dec6_bk=0/0/0/0 rpdb-ver: ffffffff rpdb-gwy: :: rpdb-oif: 0 total tunnel = 1Check the IPv4 address of the VNE interface. Make sure that the VNE interface has an IPv4 address (the fixed IPv4 address provided by the VNE provider) set in FG-60F.FG-60F (Interim)# diagnose ip address list IP=192.0.2.1->192.0.2.1/255.255.255.255 index=27 devname=vne.wan1Once the above items are verified, make sure that user can access the internet via IPv4 from the LAN-side device.Related Articles:config system vne-tunnel (FortiOS 7.4.X and earlier) NP6 session fast path requirements FortiGate Thu, 29 Oct 2026 12:42:52 +0100 https://community.fortinet.com/support-forum-92/vpn-ipsec-saml-230949 I configured an IPsec Remote Access VPN. When I use local authentication, the VPN works fine. However, when I switch to SAML authentication, the SAML login completes successfully, but FortiClient returns to the main screen instead of establishing the VPN connection.Has anyone experienced this issue before or knows what could be causing it?  Support Forum Thu, 29 Oct 2026 11:39:14 +0100 https://community.fortinet.com/fortigate-3/ha-cluster-firmware-upgrade-stuck-after-the-secondary-unit-is-upgraded-successfully-230968 DescriptionA firmware upgrade behavior issue observed in a High Availability (HA) cluster. In an HA cluster, when the FGCP Multi-Version Cluster (MVC) upgrade mode is enabled using set uninterruptible-upgrade enable, the upgrade behavior will upgrade the Secondary unit first followed by the Primary unit.However, there are cases where the firmware upgrade may not proceed to the Primary unit even after the Secondary unit has been successfully upgraded.For example:The Secondary unit has been successfully upgraded to firmware version 7.6.7.However, the Primary unit remains on firmware version 7.4.11.ScopeFortiGate.SolutionRecommended action:Do not reboot the Primary unit or initiate a failover.Re-run the firmware upgrade from the Primary unit to trigger the upgrade process again.This approach will usually resolve the issue and allow the firmware upgrade to proceed as expected. FortiGate Thu, 29 Oct 2026 11:08:14 +0100 https://community.fortinet.com/support-forum-92/fortiaps-are-offline-but-can-be-pinged-from-firewall-and-pass-capwap-traffic-230830 Need help troubleshooting. Already did factory reset of APs, deauthorize and re-authorize as well as the following.Killed CAPWAP process  - diagnose sys kill 11 <PID_of_cw_acd>Ran command - diagnose wireless-controller wlac -d wtp SN] reset] to reset cached AP information and state Changed wireless-controller timersconfig wireless-controller timersset echo-interval 100set discovery-interval 15end Set set max-retransmit from 3 to 15config wireless-controller globalset max-retransmit 15nextend  Support Forum Thu, 29 Oct 2026 10:37:04 +0100 https://community.fortinet.com/support-forum-92/forticlient-vpn-deployment-via-soti-mdm-on-android-devices-230828 Hello Fortinet Support,We are looking for guidance on deploying and configuring the FortiClient VPN application on Android devices managed through SOTI MobiControl.Our goal is to deploy FortiClient with a predefined VPN configuration, including authentication settings, so that users do not need to configure the VPN manually.Specifically, we would appreciate your guidance on the following:Can FortiClient VPN be deployed and configured automatically on Android devices through SOTI MobiControl? Can VPN profiles and authentication settings be preconfigured using Managed App Configuration or another officially supported method? Does FortiClient support receiving VPN configurations from FortiClient EMS on Android devices, and can this be used in conjunction with SOTI MobiControl? Is there any official Fortinet documentation or recommended best practice for deploying and configuring FortiClient VPN on Android using SOTI MobiControl?Our environment:MDM: SOTI MobiControl Devices: Zebra MC9400 running Android VPN client: FortiClient for Android Objective: Centrally deploy the application and preconfigure VPN connectivity and authentication settings.We would appreciate any relevant documentation, configuration examples, or recommendations for achieving this deployment. Support Forum Thu, 29 Oct 2026 10:35:41 +0100 https://community.fortinet.com/support-forum-92/fortiextender-wan-extension-in-nat-mode-230738 Hello,we currently use several FortiExtenders as WAN extensions in combination with 5G, SIM cards an IP passthrough. While this seems like the optimal solution we randomly encounter issues because the ISP assigns random CGNAT subnets through DHCP within 10.0.0.0/8. This seems completely random and may or may not conflict with our internal networks.I have thought about using the FEX in standalone NAT mode so I am able to use deterministic transit networks on the FortiGate. However in that case we lose the nice FortiGate integration & management.Has anyone an idea how this can be solved more elegant? Can NAT mode used while the extender is managed by FortiGate? Support Forum Thu, 29 Oct 2026 10:33:55 +0100 https://community.fortinet.com/support-forum-92/multiple-plc-devices-on-individual-vlan-s-with-overlapping-ip-s-subnet-need-to-setup-2-way-traffic-230734 I have a FortiGate firewall with FortiGate switches all connected via Fortilink in the firewall.  I have a requirement to now connect 20 PLC devices that share the same ip addresses to our network.  I am not able to re-ip the PLC devices so need to figure out the correct NAT setup for this.  I have setup each PLC in its own vlan (Vlan 3001-3020). Each vlan its own unique subnet as the primary subnet (10.0.2.0/29…..10.0.2.210/29).  I then added the overlapping subnet (192.168.1.0/24) as a secondary subnet to each vlan.  Dnat and Snat ip pools have been setup for each device and firewall rules have been setup to allow the communication. The snat is working I am able to ping from each PLC device to the corp network.  The problem I have is the Dnat ping from the Corp network to each PLC device.  Because of the overlapping subnets the VIP is converting the traffic back to the 192.168.1.1 address and the firewall is routing all traffice back to one vlan not the correct vlan. I have searched the Fortigate KB’s and it looks like i need to put each vlan in a different VRF and then setup route leaking.  I have tried to follow the instructions from the KB’s but I have not been able to get this working. Can anyone help with the correct steps to get this setup.  Here is an Example of the current configuration:Corp netowrk 10.0.1.0/24 Overlapping subnet on each of the 20 PLC devices  192.168.1.0/24. I am giving a /29 subnet as the primary subnet on each of the PLC vlans.  Subnets start at 10.0.2.0/29 and end at 10.0.2.152/29 each plc vlan also has a secondary IP of 192.168.1.254/24. VIP setup for each PLC example PLC1 VIP is 10.0.2.2  mapped to 192.168.1.1  Vip for PLC2 is 10.0.2.11 mapped to 192.168.1.1. I also have IP Pools setup.  PLC1 Ip Pool  Ext range 10.0.2.2-10.0.2.2  one to one  and PLC2 10.0.2.11-10.0.2.11 one to one.   I then setup firewall rules to allow the traffic to the VIP and from each vlan from the 192.168.1.1 address nat to the IP pool for that vlan. Everything is on VRF 0 at the moment and I am running fortios 7.4.11.   It looks like version 8.x allows this routing but we are not able to upgrade to version 8.x at this time.Thanks Support Forum Thu, 29 Oct 2026 10:32:10 +0100 https://community.fortinet.com/fortianalyzer-6/no-allowed-logs-in-fortianalyzer-230967 DescriptionTroubleshooting steps to take when there are no allowed web-filter logs in the FortiAnalyzer.ScopeFortiAnalyzer, FortiGate.SolutionWhen checking the FortiAnalyzer Analytics logs, it is possible to see there are no Allow web-filter logs:First thing needs to do is to verify if there are any Allowed traffic log in the Archived logs. Navigate to FortiView -> Log Browse -> Traffic logs of the selected device.If there are no allowed logs, it means the FortiGate itself does not generate the logs. Note that FortiAnalyzer can only process what is being received from the logging devices and does not generate the logs.To address this, FortiGate needs to generate the logs. The following article can be referred to on how to configure for all logs for traffic:Technical Tip: How to see all visited website URLs under web filter security logIf there are necessary archive logs, but no analytics logs, capture the following debug output:diagnose debug reset diagnose debug app fazsvcd 255 diagnose debug enableAfter debugging is enabled, start querying analytics logs to generate output.If the CLI shows there are Allowed traffic logs, it means the issue is on the GUI rather than the database. Further debug and troubleshooting steps can refer to the following documents:Technical Tip: How to debug GUI issues in FortiManager/FortiAnalyzer.If the output from the previous steps shows no Allowed logs, the issue may be on the database itself. At this stage, a database rebuild can be considered:execute sql-local rebuild-dbIf the issue still observes after all 3 steps have been verified. There could be a hardware/hypervisor issue or underlying issue within the system.Reach out to the Technical Support team to assist and verify if there are issues within the system/hardware. Make sure to provide required documents from the steps provided above along with the TAC report: Technical Tip: Required information for TAC tickets. FortiAnalyzer Thu, 29 Oct 2026 10:24:20 +0100 https://community.fortinet.com/fortiweb-40/how-to-block-the-brotli-vulnerability-cve-2026-111497-on-fortiweb-230966 DescriptionThe signatures that can help block block Brotli Vulnerability (CVE-2026-111497) on FortiWeb.ScopeFortiWeb.SolutionCVE-2026-111497 is a Brotli Request Body http traffic.FortiWeb can help to block the header since it is encoded in protocol level.To do this, create a customer signature. Navigate to the CLI of FortiWeb and run the following commands sequentially:config waf custom-protection-rule edit "CVE-2026-111497" set action alert_deny config meet-condition edit 1 set request-target REQUEST_HEADERS_NAMES set expression Transfer-Encoding next edit 2 set request-target REQUEST_RAW_BODY set expression "\\x50\\x67\\x81\\x00\\x00\\x00\\x00\\x00\\xF8\\x97\\xFB" next end next end config waf custom-protection-group edit "node" config type-list edit 5 set custom-protection-rule CVE-2026-111497Since it is a custom signature, false positive blocks may occur. In that case, create an exception to allow legitimate traffic. For that, follow this article: Technical Tip: How to add an exception in a signature. FortiWeb Thu, 29 Oct 2026 10:20:39 +0100 https://community.fortinet.com/fortimail-26/fortimail-transparent-mode-does-not-generate-mail-event-or-history-logs-for-proxy-bypass-traffic-230965 DescriptionThe reason FortiMail in Transparent mode does not generate Mail Event or History logs for SMTP sessions that match an IP-based policy configured with the Proxy Bypass action, whereas FortiMail will generate the Mail Event or History logs for SMTP sessions when the IP policy action is set to "scan," and how to troubleshoot. ScopeFortiMail (Transparent Mode). SolutionIn FortiMail Transparent Mode, when a session matches an IP Policy with the Proxy Bypass action, FortiMail forwards the traffic at the network layer without engaging the SMTP proxy engine. As a result, the session bypasses processing by smtpproxy and mailfilterd entirely, which means there will be no Mail Event or History logs generated. For the administrator to generate logs for troubleshooting purposes, the admin can either move that specific Source IP from the current policy to a new policy with the action set to "Scan" or change the action of the existing policy to "Scan" instead of "Proxy Bypass" Proxy Bypass action is only available when FortiMail is operating in Transparent mode. If the logs are still not appearing in FortiMail after changing the policy by moving the specific source/client IP from the existing IP policy to a new IP policy, you may run the following command, as sometimes the policy change may not take effect immediately execute reload netd  If the user still sees further issues, the user may enable SMTP proxy debugs on the transparent FortiMail unit to trace the proxy session handling:diagnose debug application smtpproxy 255 diagnose debug application smtpproxy-children 255 diagnose debug enable  Related Article:Controlling email based on IP addresses FortiMail Thu, 29 Oct 2026 10:18:47 +0100 https://community.fortinet.com/fortisiem-34/performance-monitoring-object-not-displaying-metrics-after-custom-object-creation-230963 DescriptionIn FortiSIEM, a custom Performance Monitoring object may not start monitoring an already discovered device after the custom monitor is added. The monitoring job may not display the green OK status in the Monitor Performance page, and the expected performance metrics may not be collected.ScopeFortiSIEM.SolutionUse the following steps to troubleshoot the issue.Log in to the FortiSIEM GUI.Navigate to Admin -> Setup -> Monitor Performance.Locate and select the affected device.Disable monitoring for the selected device.Wait a few minutes, then enable monitoring again.Refresh the Monitor Performance page and verify whether the monitoring job displays the green OK status.Confirm that the expected performance metrics are being collected.If the FortiSIEM 7.x issue persists, the alternative workaround documented in the Release Notes is to delete the affected device from the CMDB and rediscover it. Before proceeding, assess the impact of removing the device and ensure that rediscovery is appropriate for the environment.For additional troubleshooting, verify that the custom Performance Monitoring object is configured correctly, the required attributes are mapped, the device type is associated with the performance object, and the monitoring credentials and protocol connectivity are valid. FortiSIEM Thu, 29 Oct 2026 10:13:51 +0100 https://community.fortinet.com/support-forum-92/fortiaigate-8-0-2-traffic-log-details-show-request-refused-the-gateway-refused-this-request-404-http-404-230961 FortiAIGate 8.0.2 can see traffic logs that my UI and postman API request were caught but traffic log details show Request Refused 'The gateway refused this request (404, HTTP 404)'ChatUI & Postman API calling to FortiAIGate 8.0.2 following FortiAIGate Administration Guide [Send a normal request]:https://docs.fortinet.com/document/fortiaigate/8.0.2/fortiaigate-administration-guide/531206/appendix-a-api-endpoints-and-request-examples#select-an-api-dialectAny idea? Support Forum Thu, 29 Oct 2026 10:07:00 +0100 https://community.fortinet.com/fortigate-3/one-arm-sniffer-option-visible-on-interface-with-wan-role-230962 DescriptionThe one-arm sniffer addressing mode remains visible in the GUI when an interface role is set to WAN.ScopeFortiOS.SolutionThe one-arm sniffer addressing mode should not be visible in the GUI when the interface role is set to WAN as mentioned in the document: One-arm sniffer.This only means that the one-arm sniffer mode is hidden on the GUI level: not on the functionality level. When the one-arm sniffer mode is selected before the role of an interface is set to "WAN", or when the one-arm sniffer is enabled via CLI, the option will remain visible in the interface GUI. The firmware does not restrict the users to set the addressing mode to one-arm sniffer in the interfaces with a role WAN. It only attempts to hide the option from the GUI.Two methods to enable the one-arm sniffer on a WAN interface:Using the Command Line Interface (CLI) below on an interface with the "WAN" role:config system interface edit <interface_name> set ips-sniffer-mode enable next end2. Using the Graphical User Interface (GUI):Select Network -> Interfaces -> Edit an interface(port1 for this example image).Select the interface and change the role from "WAN" to "LAN" or "Undefined". (Example image is port1.)Select "One-Arm Sniffer" as the addressing mode.Select OK to save the changes.Edit the Same InterfaceChange the interface role back to "WAN". On this part, the one-arm sniffer mode will not disappear in the GUI.Select OK to save the changes.To hide the One-arm sniffer option from the GUI while the role is set to "WAN":Edit the interface with "WAN" role.Change the Addressing mode to a different option like" Manual" or "DHCP".Select OK to save the changes. FortiGate Thu, 29 Oct 2026 10:06:27 +0100 https://community.fortinet.com/support-forum-92/forticlient-ipsec-vpn-timeout-230886  HI all,I’ve run into a tricky issue on an IPsec Remote Access VPN connection with Forticlient.my FG version: ’FortiGate-50G v7.4.8,build2795,250523 (GA.M)’, FG can see internet, and here is the configuration of IPsec Phase1:FortiGate-50G # config vpn ipsec phase1-interfaceFortiGate-50G (phase1-interface) # edit IPsec\ RA\ vpn0 FortiGate-50G (IPsec RA vpn0) # show config vpn ipsec phase1-interface edit "IPsec RA vpn0" set type dynamic set interface "lan2" //yes my wan interface name is lan2 set ike-version 2 //also tried ikev1(agressive and main) set local-gw <my public ip> set peertype any set net-device disable set mode-cfg enable set proposal aes128-sha256 aes256-sha256 set dpd on-idle set dhgrp 5 set eap enable //also tried with no eap set eap-identity send-request set authusrgrp "POC_grp" set nattraversal forced //also tried enable set network-overlay enable set network-id 0 set transport udp-fallback-tcp //also tried tcp only, udp only set ipv4-start-ip 9.5.6.7 set ipv4-end-ip 9.5.6.70 set dns-mode auto set ipv4-split-include "all" set psksecret ENC a...A set dpd-retryinterval 60 next endIPsec phase2:FortiGate-50G # config vpn ipsec phase2-interface FortiGate-50G (phase2-interface) # edit IPsec\ RA\ vpn0 FortiGate-50G (IPsec RA vpn0) # showconfig vpn ipsec phase2-interface edit "IPsec RA vpn0" set phase1name "IPsec RA vpn0" set proposal 3des-md5 aes128-sha256 set dhgrp 5 nextendnote that i tried to change the following configuration with same result(Forticlient timeout):Disabled local gateway, but it’s not useful since my interface only has one public IP. Changed phase 1 and phase 2 proposals to lower authentication and hashing algorithms, such as NULL, DES, or 3DES, and MD5 or SHA1, as well as to higher values such as AES128/256 and SHA256. changed DH group to 1, 2, 3, 4, 5, or 20, or used multiple values, and even disabled PFS by setting no DH group in phase 2. change nat-t to forced , enable or disable Used IKEv1 with both of its modes, as well as IKEv2. Disabled and enabled network-overlay. Enabled and disabled split tunnel. Enabled XAUTH with “inherit from policy,” specified the POC_grp group matching the firewall policy, and also disabled it. changed DPD values set peer id to authenticate with and accept any peer id change tcp port to custom ports like 5500,11500 to traverse restrictive firewalls at ISPs that only permit TCP-based traffic, and use default one 4500 via:config system settings set ike-tcp-port 5500endAs well as creating user tst0 and adding it to POC_grp, and creating a firewall policy with srcintf set to the IPsec virtual interface and dstintf set to the local LAN, with srcaddr set to all + POC_grp and dstaddr set to all (also tried the local LAN subnet), NAT enabled (also tried disabling it), all services allowed, and no inspection (for testing purposes). I then matched all of those settings (authentication, encryption, and all other settings and parameters that must be matched — I am 100% sure of this) on FortiClient (version 7.4.3.4726), and also tested on other versions, such as 7.4.2 and 7.4.1. and same thing debugging of fortigate while FC connecting:FortiGate-50G # diagnose debug application ike -1Debug messages will be on for 30 minutes.FortiGate-50G # diagnose debug enableFortiGate-50G # diagnose vpn ike log filter rem-addr4 <remote access user public ip>FortiGate-50G # diagnose sniffer packet any "port 500 or port 4500" 4 0 ainterfaces=4any]filters=tport 500 or port 4500]ike :shrank heap by 159744 bytesike V=root:0: comes <RA user public ip>:64916-> <FG public ip>:11500,ifindex=5,vrf=0,len=469....ike V=root:0: IKEv2 exchange=SA_INIT id=ad2fddfdbc283436/0000000000000000 len=465ike 0: in AD2FDDFDBC28343600000000000000002120220800000000000001D12200005C0200002C010100040300000C0100000C800E00800300000802000005030000080300000C00000008040000050000002C020100040300000C0100000C800E01000300000802000005030000080300000C0000000804000005280000C800050000555EA143039A3A8A68C5E13E2B09A20ADD8C67A437B1235CAA9EBCCD16C5D62EAB552AF0EF860904F55496CAFF55BE987CF403BF17D31FAEF4AF64BEFF66584F84E41F004DE09838B7D82BE9AA97A8FCF8E67943B0B9C7CB1BEA3417A59EA8CA6842D5A925B3E22C7A1CCF23F13979CBD431FB0376D910754796F580446758E5C653D0327A5EF669CE37E7E667F504092E4C7BE8F28167E6DFC9A42620D70AF5588702A314DDC5C6E56CC4F09315F95E8EEF33837BE405500656D19B7AF7A3A02B0000149B92E804589812B90F81E4B606E298402B0000144C53427B6D465D1B337BB755A37A7FEF2B000014B4F01CA951E9DA8D0BAFBBD34AD3044E29000014C1DC4350476B98A429B91781914CA43E2900001C00004004E890098CEB32076F9B0AF782D851E11499D0BD382900001C000040057D6B6E7E68DC62F087C33DFE47B38AEC661E09AD000000090000F05000ike V=root:0:ad2fddfdbc283436/0000000000000000:267: responder received SA_INIT msgike V=root:0:ad2fddfdbc283436/0000000000000000:267: VID forticlient connect license 4..Fike V=root:0:ad2fddfdbc283436/0000000000000000:267: VID Fortinet Endpoint Control B..Eike V=root:0:ad2fddfdbc283436/0000000000000000:267: VID Forticlient EAP Extension C1DC4350476B98A429B91781914CA43Eike V=root:0:ad2fddfdbc283436/0000000000000000:267: received notify type NAT_DETECTION_SOURCE_IPike V=root:0:ad2fddfdbc283436/0000000000000000:267: received notify type NAT_DETECTION_DESTINATION_IPike V=root:0:ad2fddfdbc283436/0000000000000000:267: received notify type VPN_NETWORK_IDike V=root:0:ad2fddfdbc283436/0000000000000000:267: NETWORK ID : 0ike V=root:0:ad2fddfdbc283436/0000000000000000:267: incoming proposal:ike V=root:0:ad2fddfdbc283436/0000000000000000:267: proposal id = 1:ike V=root:0:ad2fddfdbc283436/0000000000000000:267: protocol = IKEv2:ike V=root:0:ad2fddfdbc283436/0000000000000000:267: encapsulation = IKEv2/noneike V=root:0:ad2fddfdbc283436/0000000000000000:267: type=ENCR, val=AES_CBC (key_len = 128)ike V=root:0:ad2fddfdbc283436/0000000000000000:267: type=INTEGR, val=AUTH_HMAC_SHA2_256_128ike V=root:0:ad2fddfdbc283436/0000000000000000:267: type=PRF, val=PRF_HMAC_SHA2_256ike V=root:0:ad2fddfdbc283436/0000000000000000:267: type=DH_GROUP, val=MODP1536.ike V=root:0:ad2fddfdbc283436/0000000000000000:267: proposal id = 2:ike V=root:0:ad2fddfdbc283436/0000000000000000:267: protocol = IKEv2:ike V=root:0:ad2fddfdbc283436/0000000000000000:267: encapsulation = IKEv2/noneike V=root:0:ad2fddfdbc283436/0000000000000000:267: type=ENCR, val=AES_CBC (key_len = 256)ike V=root:0:ad2fddfdbc283436/0000000000000000:267: type=INTEGR, val=AUTH_HMAC_SHA2_256_128ike V=root:0:ad2fddfdbc283436/0000000000000000:267: type=PRF, val=PRF_HMAC_SHA2_256ike V=root:0:ad2fddfdbc283436/0000000000000000:267: type=DH_GROUP, val=MODP1536.ike V=root:0:ad2fddfdbc283436/0000000000000000:267: matched proposal id 1ike V=root:0:ad2fddfdbc283436/0000000000000000:267: proposal id = 1:ike V=root:0:ad2fddfdbc283436/0000000000000000:267: protocol = IKEv2:ike V=root:0:ad2fddfdbc283436/0000000000000000:267: encapsulation = IKEv2/noneike V=root:0:ad2fddfdbc283436/0000000000000000:267: type=ENCR, val=AES_CBC (key_len = 128)ike V=root:0:ad2fddfdbc283436/0000000000000000:267: type=INTEGR, val=AUTH_HMAC_SHA2_256_128ike V=root:0:ad2fddfdbc283436/0000000000000000:267: type=PRF, val=PRF_HMAC_SHA2_256ike V=root:0:ad2fddfdbc283436/0000000000000000:267: type=DH_GROUP, val=MODP1536.ike V=root:0:ad2fddfdbc283436/0000000000000000:267: lifetime=86400ike V=root:0:ad2fddfdbc283436/0000000000000000:267: SA proposal chosen, matched gateway IPsec RA vpn0ike V=root:0:IPsec RA vpn0:IPsec RA vpn0: created connection: 0x3f463ef0 5 <FG public ip>-> <RA user public ip>:64916.ike V=root:0:IPsec RA vpn0:267: processing notify type NAT_DETECTION_SOURCE_IPike V=root:0:IPsec RA vpn0:267: processing NAT-D payloadike V=root:0:IPsec RA vpn0:267: NAT detected: PEERike V=root:0:IPsec RA vpn0:267: process NAT-Dike V=root:0:IPsec RA vpn0:267: processing notify type NAT_DETECTION_DESTINATION_IPike V=root:0:IPsec RA vpn0:267: processing NAT-D payloadike V=root:0:IPsec RA vpn0:267: NAT detected: PEERike V=root:0:IPsec RA vpn0:267: process NAT-Dike V=root:0:IPsec RA vpn0:267: FEC vendor ID received FEC but IP not setike 0:IPsec RA vpn0:267: FCT EAP 2FA extension vendor ID receivedike V=root:0:IPsec RA vpn0:267: responder preparing SA_INIT msgike V=root:0:IPsec RA vpn0:267: generate DH public value request queuedike V=root:0:IPsec RA vpn0:267: responder preparing SA_INIT msgike V=root:0:IPsec RA vpn0:267: compute DH shared secret request queuedike V=root:0:IPsec RA vpn0:267: responder preparing SA_INIT msgike V=root:0:IPsec RA vpn0:267: create NAT-D hash local <FG public ip>/11500 remote <RA user public ip>/0ike 0:IPsec RA vpn0:267: out AD2FDDFDBC2834361662274BE4C53324212022200000000000000160220000300000002C010100040300000C0100000C800E00800300000802000005030000080300000C0000000804000005280000C800050000D509DD5FD97EE8266DD3100A96CF9B7D850E783E4FC1C344F631B927220F38ED009400BD04FA5DC6BC7987F98309D13EF28FBA5F3DFFD2C9F2C8B558883B4FAE19088B70501F10DC144C859F431DCA0C5F234176C86D7FB009DAF7E964918A7899B5C304A4FA033C59E41BCD685CDDFF43261DADD6CE280055E57DCF2927167B550DFB52E22905FF75F898AEA42F4D7BBD35B7ABB1A093B930B6D8A72A7BCDA6D5749912ECAEB005CC4D74A983069E343CD6714BC0BAB57C0E2F76F2725D343E290000145C9F5573E047E944E085B043E4A1E4042900001C00004004EEB92DFFCE8DBF5F069BA8B829F82E7A1F8B0DAF0000001C00004005A9D7AEA50C9FB43680B5576C326EB07D54AEE927ike V=root:0:IPsec RA vpn0:267: sent IKE msg (SA_INIT_RESPONSE): <FG public ip>:11500-><RA user public ip>:64916, len=352, vrf=0, id=ad2fddfdbc283436/1662274be4c53324, oif=5ike 0:IPsec RA vpn0:267: IKE SA ad2fddfdbc283436/1662274be4c53324 SK_ei 16:33A917D26B5F7EB020F930176A36E662ike 0:IPsec RA vpn0:267: IKE SA ad2fddfdbc283436/1662274be4c53324 SK_er 16:01C84469384504823EE39677E15A5BC3ike 0:IPsec RA vpn0:267: IKE SA ad2fddfdbc283436/1662274be4c53324 SK_ai 32:E74339B5953FD6A4FE265572F95CE00068DB08F1C70F469204F2C6ADA918C56Fike 0:IPsec RA vpn0:267: IKE SA ad2fddfdbc283436/1662274be4c53324 SK_ar 32:60162FBC4B62030A9B0E868654336703FB3708FB58FF3B4C1D0F6BAD5E6B4F53ike V=root:0:IPsec RA vpn0:267: negotiation timeout, deletingike V=root:0:IPsec RA vpn0: connection expiring due to phase1 downike V=root:0:IPsec RA vpn0: going to be deletednote that on forticlient i tested all encaps settings like udp port , ipsec over tcp, auto(udp fallback tcp ) and set matched ports as uploaded screenshot But it times out when connecting from FortiClient.Note that I contacted the ISP, and they confirmed that IPsec VPN traffic (IKE and NAT-T) is allowed, with no filtering in place. I also ensured that the time is synced on both the FortiGate and the end-user device.Also note that when connecting from FortiClient, most of the time I get a timeout message, followed by IPsec is down, and it rarely connects — which confuses me, because when it does connect, and I intentionally disconnect and reconnect with the same parameters, I get a timeout message again.vpn logs when successfully connected:success log install IPsec SA log:note that FG accepted IPsec tunnel for 5500 in certain timesfailure logs:delete phase1 sa log:Thanks in advance for taking the time to read through this and for any insight you can offer. I’m happy to provide additional logs, configs, or debug output if that would help narrow this down further. Support Forum Thu, 29 Oct 2026 09:53:06 +0100 https://community.fortinet.com/forticlient-4/forticlient-web-filter-browser-extension-fails-to-uninstall-during-an-on-fabric-to-off-fabric-transition-230960 DescriptionWhen the Web Filter extension is not uninstalled when the endpoint moves from on-fabric to off-fabric while 'Keep Extension When Endpoint is Off-Fabric' is disabled and 'Web Browser Plugin for HTTPS Web Filtering' is enabled.ScopeFortiClient Endpoint version 8.0.0, FortiClient Windows.SolutionIssue scenario: FortiClient v8.0.0.0103 GA.Enable the Web Filter profile.Disable 'Keep Extension When Endpoint is Off-Fabric'.Enable 'Web Browser Plugin for HTTPS Web Filtering'.Verify the extension is installed while on-fabric.Move the endpoint to off-fabric and observe that the extension is not uninstalled. Issue resolved In: FortiClient version 8.0.1. Solution description:Fixed a bug where the policy watchdog unconditionally re-added the browser extension force-install policy. The fix ensures that when 'Keep Extension When Endpoint is Off-Fabric' is disabled, the policy is removed during the transition to an inactive filtering state (including on-fabric to off-fabric). Both the periodic policy-check and extended-keepalive-absence paths now respect the policy gate to prevent the extension from being resurrected. Additionally, SafeSearch hosts-file enforcement was updated to align with actual extension presence. FortiClient Thu, 29 Oct 2026 09:36:10 +0100 https://community.fortinet.com/fortigate-3/fortigate-single-sign-on-users-logged-off-when-enforce-kerberos-is-enabled-230959 DescriptionUsers are automatically logged off from FortiGate Single Sign-On after enabling the Enforce Kerberos setting in the Collector Agent.ScopeFortiGate, FSSO Collector AgentSolutionA known issue exists where the workstation check fails when "Enforce Kerberos" is enabled. Users are de-authenticated when the workstation check fails after the dead entry timeout.Upgrade the FortiGate Single Sign-On Collector Agent to version 5.0.0335 or later. This version addresses WMI workstation check failures when "Enforce Kerberos" is enabled by adding reverse DNS lookup to resolve workstation IP addresses to hostnames.Download the FortiGate Single Sign-On Collector Agent version 5.0.0335 from the Fortinet Support Portal.Install the updated Collector Agent on the server.Enable the "Enforce Kerberos" setting in the Collector Agent configuration.Monitor the user sessions to verify that they are no longer automatically logged off after one hour.Related article:Technical Tip: FortiGate FSSO Collector Agent v5.0.0323 and earlier do not support Windows Server 2025 with default polling mode FortiGate Thu, 29 Oct 2026 09:32:03 +0100 https://community.fortinet.com/forticlient-4/forticlient-endpoints-fail-to-match-assigned-entra-id-group-policies-and-fall-into-the-default-policy-due-to-a-synchronization-issue-between-the-user-identity-and-the-device-object-230958 DescriptionFortiClient Endpoints that are members of a specific Entra ID group do not match the corresponding group policy in FortiClient EMS. These endpoints are assigned to the default policy.ScopeFortiClient EMS and FortiClient Endpoint.SolutionFortiClient EMS cannot correctly retrieve the Azure device object ID for certain users. This occurs when a mismatch or failure happens in the lookup process between the reported user identity and the Entra ID device object, resulting in a 404 Not Found error during the API call to Microsoft Graph.Error example:ERROR update/sysinfo.go:344 [TID:KiK5dhcVVQ][site:default][uid:A11E1B23714F48A4910032061E4E7122]: Could not get azure device object id: search for device object id: http.GET(https://graph.microsoft.com/v1.0/devices(deviceId='0e427e3a-5d65-40bb-bfa5-b1b72f940d1b')?%24select=id) return status: 404 Not FoundPermanent solution: Update FortiClient EMS to version 7.4.8 or above. This version includes the fix for the identity matching bug.If updating to version 7.4.8 is not immediately possible, use the following workaround:Create a new group in Entra ID.Add the computer accounts directly to this new group instead of adding user accounts.Assign the desired FortiClient EMS policy to this new computer-based group. FortiClient Thu, 29 Oct 2026 09:31:14 +0100 https://community.fortinet.com/support-forum-92/fortigate-gui-inaccessible-after-upgrade-to-fortios-7-6-8-due-to-tls-handshake-failure-230760 After upgrading a FortiGate HA cluster to FortiOS 7.6.8, the HTTPS GUI was no longer accessible. Browsers returned ERR_SSL_PROTOCOL_ERROR, while curl reported SEC_E_DECRYPT_FAILURE.The GUI worked when TLS 1.2 was explicitly enforced. The issue was resolved with:config system global    set admin-https-ssl-versions tlsv1-2    set tls-session-cache disableendA reboot was required for the TLS session cache change to take effect. After the reboot, the GUI was accessible again.Is this a known issue in FortiOS 7.6.8? Support Forum Thu, 29 Oct 2026 09:21:54 +0100 https://community.fortinet.com/support-forum-92/fortiaigate-8-0-2-only-seeing-governance-detectors-and-the-rest-is-not-there-230957 FortiAIGate on 8.0.2 without GPU on the node.Helm install method with values.yaml applied latest image tags. All pods are up. License applied in GUI. Workspace & model setup done but detectors for DLP, Regex & NL are missing, is GPU-enabled node a must to see/enable all the detectors? Support Forum Thu, 29 Oct 2026 09:16:34 +0100 https://community.fortinet.com/support-forum-92/some-devices-unable-to-connect-to-wi-fi-after-upgrading-to-7-4-13-230816 We are experiencing an issue where some client devices cannot connect to Wi-Fi after upgrading our FortiGate 101F and FortiAP 231F environment to FortiOS 7.4.13, what can I follow up Support Forum Thu, 29 Oct 2026 09:14:55 +0100 https://community.fortinet.com/support-forum-92/site-to-site-ipsec-tunnel-problem-between-different-os-firewall-230860 We created site to site ipsec vpn Between two fortigate firewall... One firewall OS 7.6.6 & another firewall OS 7.4.2..we entry the data exact the same to both firewall like Ike v number ,  DH,  Encryption protocol etc but tunnel not working. Please help is there any solution for it  Support Forum Thu, 29 Oct 2026 09:08:02 +0100 https://community.fortinet.com/support-forum-92/fortimanager-upgrade-vs-new-adom-230956 I'm looking to go from 7.4.x to 7.6,.xI already upgraded Fortimanager. We normally make a new ADOM and migrate.However I see people just update the existing one since 7.6 ADOMs can manage 7.4 devices.Any opinions on which is a better practice? Support Forum Thu, 29 Oct 2026 08:49:52 +0100 https://community.fortinet.com/fortigate-3/rxqid-default-value-was-changed-after-upgrade-230955 DescriptionAfter an upgrade from versions 7.0.14, 7.2.8, and 7.4.4 to versions 7.0.15, 7.2.9, and 7.4.5, the rxqid value was changed and may cause RX drops on the interface.ScopeFortiOS.SolutionSymptomsUnder system 'affinity-packet-redistribution ' is the rxqid setting. It is the ID of the receive queue on an interface used to perform packet redistribution across multiple CPU cores. The value is from <0> to <255>.In 7.0.14, 7.2.8, and 7.4.4, the default value is 0. After upgrading FortiOS to 7.0.15, 7.2.9, 7.4.5, and above, the default value is changed to 255. In some cases, it can cause an increase in interface RX drops.7.0.14 7.2.8 7.4.4:FGT # get system status | grep Version: Version: FortiGate-VM64-KVM v7.4.4,build2662,240514 (GA.F) FGT # show system affinity-packet-redistribution config system affinity-packet-redistribution edit 1 set interface "port2" set affinity-cpumask "0xff" next end FGT # show full system affinity-packet-redistribution config system affinity-packet-redistribution edit 1 set interface "port2" set rxqid 0 set round-robin disable set affinity-cpumask "0xff" next end7.0.15 7.2.9 7.4.5 and above:FGT # get system status | grep Version: Version: FortiGate-VM64-KVM v7.4.5,build2702,240916 (GA.M) FGT # show system affinity-packet-redistribution config system affinity-packet-redistribution edit 1 set interface "port2" set affinity-cpumask "0xff" next end FGT # show full system affinity-packet-redistribution config system affinity-packet-redistribution edit 1 set interface "port2" set rxqid 255 set round-robin disable set affinity-cpumask "0xff" next end Root cause.The rxqid default value was changed from 7.0.15 7.2.9 7.4.5, as it is the default setting, customer will not know the value was changed from configuraiton file.Resolution.Change it from 255 back to 0.FGT # config system affinity-packet-redistribution FGT (affinity-packet-~ion) # edit 1 FGT (1) # set rxqid 0 FGT (1) # end FGT # FortiGate Thu, 29 Oct 2026 08:38:36 +0100 https://community.fortinet.com/forticloud-products-44/fortiidentity-cloud-s-north-america-region-has-new-public-ip-addresses-230954 DescriptionFortiIdentity Cloud's North America public IP address migration, which began on October 10, 2026, is complete. Both the primary and disaster recovery addresses were changed successfully. This article explains the impact of the change and the recommended actions.ScopeFortiIdentity Cloud (formerly FortiTokenCloud)SolutionNo action is required for normal access when service endpoints are reached by FQDN and resolved through DNS. With the change now complete, DNS automatically returns the new IP addresses, so applications, integrations, and end-user access continue working without modification.If you use a ZTNA tunnel to connect to an on-prem LDAP, make sure 154.52.17.20 and 141.109.161.3 are allowed.Action may be required for environments using IP-based access controls. If any firewall policy, allowlist, ACL, or network rule explicitly permits traffic to or from the retired IP addresses listed below, those rules need to be updated to replace the retired addresses with the current ones.Where possible, reference the service by FQDN instead of a hard-coded IP address, so future changes require no action.If you have third-party integrations, monitoring checks, or scripts that reference the retired IPs directly, update those as well.PrimaryFQDNRETIRED ADDRESSCURRENT ADDRESSfic.fortinet.com69.167.109.248189.25.109.168auth.fortinet.com69.167.109.247189.25.109.169id.fortinet.com69.167.109.241189.25.109.170Disaster RecoveryFQDNRETIRED ADDRESSCURRENT ADDRESSfic.fortinet.com206.47.184.22176.23.146.242auth.fortinet.com206.47.184.25176.23.146.243id.fortinet.com206.47.184.28176.23.146.244 FortiCloud Products Thu, 29 Oct 2026 08:29:46 +0100 https://community.fortinet.com/support-forum-92/forticlient-causes-macbook-air-m5-wi-fi-and-bluetooth-error-and-force-reboots-230300 Hello, our organization recently obtained a few MacBook Neos and Airs to test, running on macOS 27 Golden Gate. However, after installing FortiClient and connected to the office network, at random times, the Wi-Fi and Bluetooth would switch off and cannot be turned back on manually. After 2-3 minutes of this, the MacBook will then freeze then immediately restart on it’s own. Following a restart, everything seems normal, but this issue can repeat multiple times in a day, but as the day goes on, it becomes stable. This happens the moment I disconnect and reconnect back to the office network. Especially after bringing home and returning to the office with the MacBook. This issue does not happen with a private home network or hotspot. Resetting the MacBook does not resolve the issue either. When FortiClient is not installed, the MacBook behaves normally. 2 older MacBooks obtained last year does not experience this issue. We have disabled / blocked Apple Account login, Mail, Calendar, iCloud. Support Forum Thu, 29 Oct 2026 08:29:42 +0100 https://community.fortinet.com/fortimanager-27/technical-tip-recovering-a-policy-block-rule-that-was-changed-directly-on-the-fortigate-230952 DescriptionThis article explains how to restore a policy block rule that was edited, disabled or deleted directly on a FortiGate. It also explains the two warnings that the Import Configuration wizard shows for a policy package that uses a policy block, and what not to do.ScopeIt applies to firewall rules that FortiManager installs from a policy block and that were then changed directly on the FortiGate. It does not cover changes made to the block in FortiManager itself.SolutionWhich way to go: if the change made on the FortiGate is unwanted, install the policy package to that device (section 3). If the change is wanted, make it in the policy block in FortiManager (section 4). Do not use Import Configuration for either case (section 5).How a policy block rule appears on the FortiGate.A policy package stores only a reference to the policy block. At install, FortiManager expands the block into normal firewall policies. The FortiGate has no policy block concept and shows the rules as ordinary policies.The expanded rules have large, block-derived policy IDs.These IDs come from a range that FortiManager reserves. A FortiGate accepts policy IDs from 0 to 4294967294, but FortiManager supports policy IDs only up to 1071741824 for policies it imports or creates, and it reserves IDs from 1071741825 upward for internal use. The range 1071741825-1072741824 is reserved for policy blocks. See Appendix B - Policy ID support in the Administration Guide.What FortiManager shows after a change on the FortiGate.When a block rule is edited, disabled or deleted directly on the FortiGate, FortiManager pulls the change into the Device DB of that device (auto-update). The same pattern appeared in the lab for all three changes:In Device Manager, Config Status of the device and of the VDOM shows Auto-update, and the policy package of that VDOM shows the red Out-of-Sync icon. Other VDOMs and other devices stay green.The device Revision History gets a new revision named AutoUpdate with the comment 'Auto update from device'.The policy block and the policy package are unchanged and still list the block. Other devices that use the block are not affected.Restore the original rule.The policy package defines the block rules, so installing the package to the affected device restores them. A Device Revert is not needed.In Device Manager, open Install Preview for the device. To see which rule differs, right-click the VDOM and choose Policy Package Diff.Install the policy package to that device only. Use Install Wizard (Install Policy Package & Device Settings), or right-click the VDOM and choose Re-install Policy. Re-install Policy opens a two-step wizard with the device and the package already selected and an Install Preview button on page 1. In that wizard, Next starts the install, so review the preview first.Open the install log. It lists only the commands from the preview.On the FortiGate, run show firewall policy with the rule ID to confirm the rule. In Device Manager, Config Status returns to Synchronized and the package to Installed.Before installing: The install sends every difference between the package and the device, not only the rule changed. If the preview shows anything else, find out why before continuing.Other devices that use the block are not touched by this install.Keeping the change instead.If the change made on the FortiGate must stay, make it in the policy block in FortiManager. Do not import it.Open the policy block and use Where Used to list every policy package that references it.Edit the rule in the block. If you edit it from inside a device package, FortiManager shows Confirm Policy Block Edit and changes the shared block, not only that package.Run Install Preview for each device and install the devices that should receive the change.A change in the policy block reaches every package that references it. Until a device is installed, it keeps the old value, so check each device.The two Import warnings, and what not to do.Import Configuration reads the configuration of the device into FortiManager. It is not the way to accept or undo a change to a block rule, because the wizard does not bring the block rules back as a policy block. On page 2 (Interface Mapping & Policy) it shows one of two red warnings, depending on the package name:Package name in the wizardWarning shown in the labWhat it meansAn existing package nameThe policy package will be overwritten and 1 policy block will be removed from the existing policy package.Continuing would replace the package and remove the policy block from it.A new package namePolicy Block policies installed from FortiManager will not be imported. Please add back Policy Block after import.The new package would not contain the block rules. The block would have to be added back by hand.Both warnings appeared for a device that was in sync and for a device that was never edited on the FortiGate, so they do not mean that the block link is already broken. In both cases, select Cancel and use section 3 or 4.What not to do:Do not use Import Configuration to accept or undo a change to a block rule.Do not use Device Revert as the fix. It changes only the record that FortiManager keeps for the device.Do not edit a block rule from inside one device package to change one device. It edits the shared block (section 4).Do not remove the block from a package to make a rule editable. That device then no longer receives later edits of the block.Tools and notes.ToolWhat it showsInstall PreviewThe exact commands FortiManager would send to the device. No preview result means that the device and the package match.Policy Package Diff (right-click the VDOM)The rules that differ between the policy package and the device, without the commands.Where Used (policy block)Every policy package that references the block.Device Revision History > Revision DiffWhat changed in the Device DB of one device. For a deleted rule it lists the lines of the rule that were removed.Note: Install Preview lists every difference between the package and the device, not only the rule changed. Read all of it before installing.Related documents:Using Policy BlocksAppending a Policy Block to a Policy PackageImporting policies and objectsAppendix B - Policy ID support FortiManager Thu, 29 Oct 2026 07:40:06 +0100 https://community.fortinet.com/support-forum-92/ipsec-auth-payload-not-received-230676 fortigate FG201f running 7.4.12 b2902forticlient 7.4.8, managed by forticloudintune pki (CloudPKI)the payload (via sniff) appears to be sent, but fortigate ignores as the tunnel has been ignored.wanting to set up a device cert based TCP IPSEC tunnel.  end goal is for the device to connect without user involvement.from the ike debug logs:session started on tcp 8443proposal acceptedcert requestedcert sent (in 6 piecescert received and reassembledclient details sent, mostly correct except the OSVER.  this is a Win 11 devicepeer is matched“AUTH payload not received”tunnel is closed How do I diagnose why the tunnel was closed?  Why is the OSVER wrong? debug log:ike V=root:accepts ike tcp-transport(vd=0, vrf=0, intf=0:27, 162.252.yyy.yy:8443->142.167.xx.xx:58204 sock=42 refcnt=2 ph1=(nil)) (1).ike V=root:0: comes 142.167.xx.xx:58204->162.252.yyy.yy:8443,ifindex=27,vrf=0,len=606....ike V=root:0: IKEv2 exchange=SA_INIT id=225ee7034892962d/0000000000000000 len=606ike 0: in 225EE7034892962D000000000000000021202208000000000000025E2200008C0200004401010007030000080300000C0300000C0100000C800E0100030000080400000E03000008020000050300000802000006030000080200000700000008020000020000004402010007030000080300000C0300000C0100000C800E0100030000080400000E030000080200000503000008020000060300000802000007000000080200000228000108000E0000A582DCB45E209F142CB0259EC98071861DF0B794A07F2EFD1D0B8298B4892C05069953F5EFEBA1A60D4B473B48886EEF7DFFDB8A44FD3A8D2EABD31F47D9C142798E198FFDF9BD3E0A9E9B909F44A750A2E0EC19BA3FC427D65DE7FCEEEA1040CD0F77681896600C810127DB3D21E51FCDAA13216624990089DF34B425F24C1F73F5CF0571DB4CF5B83946EBF9D2CC9A1541E4DF21FC37D52B70679DCA8AC2F794631C5DB773FD27D19761A68BC29CBFC7CFFD55400DE745BE6D16F3B6201ED09B6E89BB7141C0506BE973F540DE09B84C9E7D570B4F442B14B7FCC9D907C89212A3AF8AB8823149472D598A1B0A7C55C5E007B3244851B97B73A05BEB4697302B00002463B045E621AB9261434271EBF823BB2E1C502DA5854C47050003FFB280F586052B0000144C53427B6D465D1B337BB755A37A7FEF2B000014B4F01CA951E9DA8D0BAFBBD34AD3044E29000014C1DC4350476B98A429B91781914CA43E290000080000402E2900001C0000400423F12D9C61AA2D0DE627144FB81CCBEE33948E732900001C000040053AC3683EE55D61B4EBD891A5F7B391BF8A67FF730000000E0000402F000200030004ike V=root:0:225ee7034892962d/0000000000000000:411:sa bind new tcp-transport(vd=0, vrf=0, intf=0:27, 162.252.yyy.yy:8443->142.167.xx.xx:58204 sock=42 refcnt=2 ph1=(nil))ike V=root:0:225ee7034892962d/0000000000000000:411: responder received SA_INIT msgike V=root:0:225ee7034892962d/0000000000000000:411: VID forticlient connect license 4C53427B6D465D1B337BB755A37A7FEFike V=root:0:225ee7034892962d/0000000000000000:411: VID Fortinet Endpoint Control B4F01CA951E9DA8D0BAFBBD34AD3044Eike V=root:0:225ee7034892962d/0000000000000000:411: VID Forticlient EAP Extension C1DC4350476B98A429B91781914CA43Eike V=root:0:225ee7034892962d/0000000000000000:411: received notify type FRAGMENTATION_SUPPORTEDike V=root:0:225ee7034892962d/0000000000000000:411: received notify type NAT_DETECTION_SOURCE_IPike V=root:0:225ee7034892962d/0000000000000000:411: received notify type NAT_DETECTION_DESTINATION_IPike V=root:0:225ee7034892962d/0000000000000000:411: received notify type SIGNATURE_HASH_ALGORITHMSike V=root:0:225ee7034892962d/0000000000000000:411: incoming proposal:ike V=root:0:225ee7034892962d/0000000000000000:411: proposal id = 1:ike V=root:0:225ee7034892962d/0000000000000000:411:   protocol = IKEv2:ike V=root:0:225ee7034892962d/0000000000000000:411:      encapsulation = IKEv2/noneike V=root:0:225ee7034892962d/0000000000000000:411:         type=ENCR, val=AES_CBC (key_len = 256)ike V=root:0:225ee7034892962d/0000000000000000:411:         type=INTEGR, val=AUTH_HMAC_SHA2_256_128ike V=root:0:225ee7034892962d/0000000000000000:411:         type=PRF, val=PRF_HMAC_SHAike V=root:0:225ee7034892962d/0000000000000000:411:         type=PRF, val=PRF_HMAC_SHA2_512ike V=root:0:225ee7034892962d/0000000000000000:411:         type=PRF, val=PRF_HMAC_SHA2_384ike V=root:0:225ee7034892962d/0000000000000000:411:         type=PRF, val=PRF_HMAC_SHA2_256ike V=root:0:225ee7034892962d/0000000000000000:411:         type=DH_GROUP, val=MODP2048.ike V=root:0:225ee7034892962d/0000000000000000:411: proposal id = 2:ike V=root:0:225ee7034892962d/0000000000000000:411:   protocol = IKEv2:ike V=root:0:225ee7034892962d/0000000000000000:411:      encapsulation = IKEv2/noneike V=root:0:225ee7034892962d/0000000000000000:411:         type=ENCR, val=AES_CBC (key_len = 256)ike V=root:0:225ee7034892962d/0000000000000000:411:         type=INTEGR, val=AUTH_HMAC_SHA2_256_128ike V=root:0:225ee7034892962d/0000000000000000:411:         type=PRF, val=PRF_HMAC_SHAike V=root:0:225ee7034892962d/0000000000000000:411:         type=PRF, val=PRF_HMAC_SHA2_512ike V=root:0:225ee7034892962d/0000000000000000:411:         type=PRF, val=PRF_HMAC_SHA2_384ike V=root:0:225ee7034892962d/0000000000000000:411:         type=PRF, val=PRF_HMAC_SHA2_256ike V=root:0:225ee7034892962d/0000000000000000:411:         type=DH_GROUP, val=MODP2048.ike V=root:0:225ee7034892962d/0000000000000000:411: matched proposal id 1ike V=root:0:225ee7034892962d/0000000000000000:411: proposal id = 1:ike V=root:0:225ee7034892962d/0000000000000000:411:   protocol = IKEv2:ike V=root:0:225ee7034892962d/0000000000000000:411:      encapsulation = IKEv2/noneike V=root:0:225ee7034892962d/0000000000000000:411:         type=ENCR, val=AES_CBC (key_len = 256)ike V=root:0:225ee7034892962d/0000000000000000:411:         type=INTEGR, val=AUTH_HMAC_SHA2_256_128ike V=root:0:225ee7034892962d/0000000000000000:411:         type=PRF, val=PRF_HMAC_SHA2_256ike V=root:0:225ee7034892962d/0000000000000000:411:         type=DH_GROUP, val=MODP2048.ike V=root:0:225ee7034892962d/0000000000000000:411: lifetime=86400ike V=root:0:225ee7034892962d/0000000000000000:411: SA proposal chosen, matched gateway EMS-TCP-VPNike V=root:0:EMS-TCP-VPN:EMS-TCP-VPN: created connection: 0x7f8c3e97bd40 27 162.252.yyy.yy->142.167.xx.xx:58204.ike V=root:0:EMS-TCP-VPN: HA start as masterike V=root:0:EMS-TCP-VPN:411: processing notify type NAT_DETECTION_SOURCE_IPike V=root:0:EMS-TCP-VPN:411: processing NAT-D payloadike V=root:0:EMS-TCP-VPN:411: NAT detected: PEERike V=root:0:EMS-TCP-VPN:411: process NAT-Dike V=root:0:EMS-TCP-VPN:411: processing notify type NAT_DETECTION_DESTINATION_IPike V=root:0:EMS-TCP-VPN:411: processing NAT-D payloadike V=root:0:EMS-TCP-VPN:411: NAT detected: ME PEERike V=root:0:EMS-TCP-VPN:411: process NAT-Dike V=root:0:EMS-TCP-VPN:411: processing notify type FRAGMENTATION_SUPPORTEDike V=root:0:EMS-TCP-VPN:411: processing notify type SIGNATURE_HASH_ALGORITHMSike V=root:0:EMS-TCP-VPN:411: FEC vendor ID received FEC but IP not setike 0:EMS-TCP-VPN:411: FCT EAP 2FA extension vendor ID receivedike V=root:0:EMS-TCP-VPN:411: responder preparing SA_INIT msgike V=root:0:EMS-TCP-VPN:411: generate DH public value request queuedike V=root:0:EMS-TCP-VPN:411: responder preparing SA_INIT msgike V=root:0:EMS-TCP-VPN:411: compute DH shared secret request queuedike V=root:0:EMS-TCP-VPN:411: responder preparing SA_INIT msgike V=root:0:EMS-TCP-VPN:411: create NAT-D hash local 162.252.yyy.yy/8443 remote 142.167.xx.xx/58204ike V=root:0:EMS-TCP-VPN:411: sending CERTREQ payload (len=21)ike V=root:0:EMS-TCP-VPN:411: certreqr0]: '0FF54B48F2DA02B3B3A3CBCD046A0BDB1B6F3329'ike 0:EMS-TCP-VPN:411: IKE SA 225ee7034892962d/a26b0a97d3da22a3 SK_ei 32:351286F3A4D04E2E485244E25C3526CCC7A894A340ED515B70B05E2C1C269AE3ike 0:EMS-TCP-VPN:411: IKE SA 225ee7034892962d/a26b0a97d3da22a3 SK_er 32:C7B5ACBF11ABC4A99FA07A9B7759909DD03C1A34B9A2710FDCF99DF1900FCF7Eike 0:EMS-TCP-VPN:411: IKE SA 225ee7034892962d/a26b0a97d3da22a3 SK_ai 32:76139396AAD4F511E5C6FB1B14181C3EA9238F3DBCDF256A3D7C82928EE3C912ike 0:EMS-TCP-VPN:411: IKE SA 225ee7034892962d/a26b0a97d3da22a3 SK_ar 32:61E5666940E5AE1EFC44AF56F2ACC492F01B6833216704B5C274084F30262564ike V=root:0: comes 142.167.xx.xx:58204->162.252.yyy.yy:8443,ifindex=27,vrf=0,len=548....ike V=root:0: IKEv2 exchange=AUTH id=225ee7034892962d/a26b0a97d3da22a3:00000001 len=548ike 0: in 225EE7034892962DA26B0A97D3DA22A3352023080000000100000224230002080001000685688B19E8096516AB287E630EDBEC51B0A5847AA1C9CBFCC11ABE52D86F0ED10FA51519878DB22DC26031082351339AE861CB257ECD1DF10A81C05D42C501433A42F141D4E277FB7846DFA99C34F0A52EC7D597F8B80D1A9891FB13BE7FEC375DFB400C1CA04FE7C3CDD607F2273F79120400B549434C710D5389256977C324E89802E5F54B57C24B2205EA8CC395002018266748A664D621D1F6F6640B67E8B4B09AA47858406D6761CE7AC80F9C51B0C1EECAB8766F872E6D8EC1EB6BEE316120BDC84734581A5BBF945672936576C6F5B22962D31B8F4796B5AB6E9FABB62AA726BACA53C1AA96B637AD0E815D087DCB448E26052F805AB69B0D4E6322215613DD8DF65560B6FB1C9B9F8B49D4751726DBF729E4ED8757660DA799D2B72B6D3C6462C0DCC77D2C9B86D67C6C5F19193C7654A1EFA0934C412AA188F7C462642D9C54EB5C14ACFF38F086D26D2353F84226C180A6B507D58C3DA76D8D5A435A97548E02AF7D7F314CA43D1C158C3F5408393BAC43E52E9253108B1508F2D802CC0DF960BB85B4858A3291A05B38A402D3AF2B8645C527ECC111AC4EE4F4FBFBA46DE573E541FE27F97E410D0C5B6DF7F45AA92AF620B6A73445B7A3BE342965FEA6296885041142497D7127FDA9A6AC00AA0EC8E8CAFA3E28CC60AA7597D33495D8DE8C6C843B7758EE4BC39A802CF3B6E187589193807D2207DBA7C1972Cike V=root:0:EMS-TCP-VPN: HA state master(2)ike V=root:0:EMS-TCP-VPN:411: encrypted fragment 1 of 6 queuedike V=root:0: comes 142.167.xx.xx:58204->162.252.yyy.yy:8443,ifindex=27,vrf=0,len=548....ike V=root:0: IKEv2 exchange=AUTH id=225ee7034892962d/a26b0a97d3da22a3:00000001 len=548ike 0: in 225EE7034892962DA26B0A97D3DA22A33520230800000001000002240000020800020006F5E36CEE3526EFA4612A0734D7F4382A25C0C26C9B0BC76A17CA40C49745BDC25DF42E6FEB012F0AEA203ABAF15A30B62C62F8BBA672B75E09237A50DB265B66423BD13798AB4091BEAE76D77439DFEAEAA84D926E338D473146154E6BE4EC668B6B70CC8013446D7E8ADE12ED5033E4F0EC4D975A097048BC0724A2F8F97A013FE204577976ED8380A0FCDEF45ECB6CB5A9B77D9FA858C879E337C1EE6B742B57A66DE0AC058E8E22A3E5A625BAA5BF9527EEC0DA75090DBC8F764256F4C1E6EB6968DF99BF18BD173FDFD9C6439458E2CABF9E829FF51029DBFCDE1A0F1687558FBB2725E9AE842016A6D71EC31EBBE448A087B44F4551FF08D2A7D56BAD7EB8E27B97F6BCE48DE03320185E4328B35D4420ABC424E904732CE92B32A5F49A1EC4D74047875C4EAD229F14AB6674ADC44D5C0756EB9E3A08431D0804890B4F5D8F495E927DF15853767CE539FD21B5E426D13338AB09B63492C658F6907CD93027D887EA8973D4EBA1613A9B7435BB88FC35F4853F71F2F776D2F4D6985E8446C91F33D791CA60AB5D100890DBDD92313F9E568A7AC9A89D894496E58CFAAB03439E7D0B565B0C09F095F88C161244BF528BD70407FA4BDC81C1504071A80C4E7201E339676CE7073859446C2C50CA5C53839B1F60843B9536293E9280300D753CA8265E4A403AE69227149A3BB25D9BAA13BA840FD29C0F8A4C5E6762069Aike V=root:0:EMS-TCP-VPN: HA state master(2)ike V=root:0:EMS-TCP-VPN:411: encrypted fragment 2 of 6 queuedike V=root:0: comes 142.167.xx.xx:58204->162.252.yyy.yy:8443,ifindex=27,vrf=0,len=548....ike V=root:0: IKEv2 exchange=AUTH id=225ee7034892962d/a26b0a97d3da22a3:00000001 len=548ike 0: in 225EE7034892962DA26B0A97D3DA22A33520230800000001000002240000020800030006BD639FFBA5230B455EBB8BFD3E956834768F7AC26AEA5EC7D5404E8357627B5231BA2826818D218E375F6F34F5B59B0F69C0A3384A4FB1A479D04D121328F7BF035E37C34637578BBB56960E8F935C7B0619F605CB9881FF832E3464B3F858BCA18F8EBEC7683E8CA32BFD44EEDA43582545E1A3F47266D960128CAAC47B4606F49E7D9973FF0FF24AE1AC5F6C910CB32D0010CE0054249B04EEE2E81F62C8C0587CD3CF98554922338974B7326B5430D13CA7AEDB9E33A43CAF277FD7FE33FD1946DCD683F52EB0B249309F6AA61B0703D6C974024BF1783882ED11C9A6BC1C718F8DC790A90D3957075C07588C882EBB244B2FA15D98DB69E777460984DAAF804C5D7E9922490C2A01D67E758C796EA8BE42AC8CBA6F04FC70E12999C8CFA3E59CB9269166F3861454511AB9872130C0EAC96EE26E91DC7F2319A430DB5BA8DD1071731C9331130C64704DEC9703940C57023F12D15A126C6DFC93496F7C36C74AFA13449AAA0649B33241742E357252DA92FA4BAA596FB019A89723311836C5A5D9F773CE99149AB48242A7D4CE98436F15C640B99E5EEC9432E86CC7E5A573D74FEAC3092E66A4419F2C03F49BF1152BB3074109D8F2A927EF5981510D8D425EB1C64F669BCB6E9B0A7D7817356AAFE5737CB7347DD6630A747C679E39B4887A81ECF1ECA0C6EEE0BE4A433D1014995315D9324316AA90B680FD69B43B1Dike V=root:0:EMS-TCP-VPN: HA state master(2)ike V=root:0:EMS-TCP-VPN:411: encrypted fragment 3 of 6 queuedike V=root:0: comes 142.167.xx.xx:58204->162.252.yyy.yy:8443,ifindex=27,vrf=0,len=548....ike V=root:0: IKEv2 exchange=AUTH id=225ee7034892962d/a26b0a97d3da22a3:00000001 len=548ike 0: in 225EE7034892962DA26B0A97D3DA22A3352023080000000100000224000002080004000690CC6CF2E0E71FBA4C99A10EE5B4061D3803771F31EADD844702FDA4261272C8C1D42CEA245AD642F0F51A4E6AEB8768A9C679DD63914684A83277BFBC6540FBEEED18DAFF43E8266F66BAF253F4C5BDFAB8BD10EC2227AA5062EB022868861BA5EA71D389B9895D4EF092A287DECF3CEE559654BBF7AE6966722AA771BB4697C2B2E967E52BA359D6188CA51477AE3D1595CC7FF9C437A10A4C99D8F46B3FEF067976BCFC9B27A2110FA2955377F5E1F651506EA2829BA96E12905DC72EE6F84340FE1D91D79C9175064661095D2A5C823C9A11293FCC8F4A2BDEBF52B01CB081D083666CE56890A94A87BBC8152C0EEFCC41B7AC29E1CABC9A7D6275BFC9BDA2CD7B63F671C19D9300C0922F7CC94EC9286859B57AF82073A4B8392D46C08BFEA9595AE24138746B6CBD8C7B9E876F21C47C7089BF975E9B812961343FFAC10A0F9A5CD237E261DFFE1D9F8E7C215AA5B1173E2B5EE18D37E756725C59D6724F9FD47C9ADEFD990391538D85E7ECF060688A071CEC6E1C4CD2050A819FA0A2877E0BF852569CABF119511251393403E7F6DA810DC2FE5D72476347C081D6ECC78E203432F863F67B334B98CF5DFBE7A4C6DDEDF1F1E6C094BD51BEBDEBD9C8FFEC7A9222D8E33F5127DE0E56C44763C4F1B32458E5636E9945FEEDDA951B8906810A7BE23AE8A71BC1D7C4485C2555575D62FE1878A3C379DAD6FD6BF24F59ike V=root:0:EMS-TCP-VPN: HA state master(2)ike V=root:0:EMS-TCP-VPN:411: encrypted fragment 4 of 6 queuedike V=root:0: comes 142.167.xx.xx:58204->162.252.yyy.yy:8443,ifindex=27,vrf=0,len=548....ike V=root:0: IKEv2 exchange=AUTH id=225ee7034892962d/a26b0a97d3da22a3:00000001 len=548ike 0: in 225EE7034892962DA26B0A97D3DA22A335202308000000010000022400000208000500060778A62741876C9F505A2E0314C6B3105664078121E64C796E747DAC4E8D94D790D0C1576A25BB7A6621027E0EAB65D5C3A4298456C1A57D5223042E2F7FDD8C6B4385D68DE80D4ACFFA4B57F6AE43F0F698BB584582D1BC2A26C183F6F92B520BC9ECF73A874DCF1FD908FBED0FCB4C90A4E4806B8A8187D132DE8063A494E75F202C234976A618CA490231C6C0E060938E1FEEDA35B97B99855D6DB86E87F491426AD4D580EA506BB33792AF1FEF17FE59E8EB27D7D5B2B11022A362EC149452D54CE8BF7A1EE725190CF5E35D31BBBA909C4DB2EA9094178F4E5BC1CBD07E49D32A1863C15036468B2D5BD57EA8498D485B2D289CDA9487B54098BF5D1E1685B749D24E5F9D42790CC331202B993198BC86B9491492D3E2E9C6B9E72824A04632FE67CCF944F10AA9AB8F624818611AB9643806DE8EE9186395643951A033D48D53F8B8BA93E21631391D8576B8CE22F8AD09D8329BBFAC8F206E6F76A8A83B20D3140327A6FF66574242665BF1AF9A7BCAA10DC0112E95790B8923EBEF96DFE8887E3470B49A84B701D8649017F58883F98AE511C78EA0A1179EE36406CD719228ECB5ECA55B442FAF431FDF6764C244C632F4985D1E34FBE273607EAE99A0EFA081A51CFA8DC48D9F11AE6EE559A9FD2BE5EA73613715E3B6C5B99A2D323B5E7DB5E1DE013082D244D287DB2B0596742BD3C79EF02FC0027E3D199E5438ike V=root:0:EMS-TCP-VPN: HA state master(2)ike V=root:0:EMS-TCP-VPN:411: encrypted fragment 5 of 6 queuedike V=root:0: comes 142.167.xx.xx:58204->162.252.yyy.yy:8443,ifindex=27,vrf=0,len=100....ike V=root:0: IKEv2 exchange=AUTH id=225ee7034892962d/a26b0a97d3da22a3:00000001 len=100ike 0: in 225EE7034892962DA26B0A97D3DA22A33520230800000001000000640000004800060006638B4FC8F407F8F6F3D262F7482C2766C036A2FD282AD8979D7472538C1FDDE5D3E97143F9BB6859C346B28FAEBC8E2ADA291BAB3DA760AF750832940258BC13ike V=root:0:EMS-TCP-VPN: HA state master(2)ike V=root:0:EMS-TCP-VPN:411: encrypted fragment 6 of 6 queuedike 0:EMS-TCP-VPN:411: dec 225EE7034892962DA26B0A97D3DA22A33520230800000001000001FC230000080001000625000020090000003016311430120603550403130B46434E422D303030303030290006EF04308206E63082054EA00302010202106065FE042D5C34C6E331DFB5E74E2D6C300D06092A864886F70D01010C05003043310B3009060355040613024341310B300906035504080C024E42310D300B060355040A0C0446434E423118301606035504030C0F46434E425F55736572446576696365301E170D3236313031363132303530385A170D3237313031363132313530385A3016311430120603550403130B46434E422D30303030303030820122300D06092A864886F70D01010105000382010F003082010A0282010100B580DD9DF5A38B63DB0CA40B19A0E01C5A014BF49DD49FBA7AA9770759CB08D1BE2386BED1762CA153E1E8122D852CF18AA8421AF7E6A6465913466AEC5E3AC239B3AA1D2A02E95AAB71149454420111440A0E83CD30EE3039A19E148D8334441F574D6078064DCB3FEF5BA35FD3E683FD90DD32DE676FA1DC4430AAE3065978CDD80A8A65339785F4BDF157AD98992341DB5395D7E2CBA35307DCFBF8D9C70F4BC93B1E757B1E67CA50CB1122CF7274FFB20F7388AD4831ED45D7117ECBFAC5400B0EC1CA8AB9EB2121F0D59FEAFCA4BB8E532DBB71B962B26178ACF6E699FAF1121BDFAB4008ike 0:EMS-TCP-VPN:411: dec 225EE7034892962DA26B0A97D3DA22A33520230800000001000001FC0000000800020006C4581FDCF2E89AD4669F3DCF692CCCF427196C2320B3000AB10203010001A38203813082037D30160603551D11040F300D820B46434E422D303030303030300C0603551D130101FF0402300030130603551D25040C300A06082B06010505070302300E0603551D0F0101FF0404030205A0301D0603551D0E04160414243437CCE39ED1CA531DA63D1BC8978976944098301F0603551D230418301680141B9002434F8E734D1E01E42F5F6B80251F4B10DA3082012F0603551D1F048201263082012230818BA08188A08185868182687474703A2F2F7072696D6172792D63646E2E706B692E617A7572652E6E65742F656173747573322F63726C732F30663632373238386461666134396434613333313136373338613361383463382F64313564373130302D333935302D343637332D626566352D3636626433383830623735335F76312F63757272656E742E63726C308191A0818EA0818B868188687474703A2F2F30663632373238386461666134396434613333313136373338613361383463382E656173747573322E706B692E617A7572652E6E65742F6365727469666963617465417574686F7269746965732F64313564373130302D333935302D343637332D626566352D3636626433383830623735335F7631ike 0:EMS-TCP-VPN:411: dec 225EE7034892962DA26B0A97D3DA22A33520230800000001000001FC00000008000300062F63757272656E742E63726C308201BB06082B06010505070101048201AD308201A930818906082B06010505073002867D68747470733A2F2F30663632373238386461666134396434613333313136373338613361383463382E656173747573322E706B692E617A7572652E6E65742F6365727469666963617465417574686F7269746965732F64313564373130302D333935302D343637332D626566352D3636626433383830623735335F763130818F06082B06010505073002868182687474703A2F2F7072696D6172792D63646E2E706B692E617A7572652E6E65742F656173747573322F636163657274732F30663632373238386461666134396434613333313136373338613361383463382F64313564373130302D333935302D343637332D626566352D3636626433383830623735335F76312F636572742E63657230818806082B06010505073002867C687474703A2F2F30663632373238386461666134396434613333313136373338613361383463382E656173747573322E706B692E617A7572652E6E65742F6365727469666963617465417574686F7269746965732F64313564373130302D333935302D343637332D626566352D3636626433383830623735335F7631300D06092A864886F70D01010Cike 0:EMS-TCP-VPN:411: dec 225EE7034892962DA26B0A97D3DA22A33520230800000001000001FC000000080004000605000382018100666BC089F711EE1B83482F082AD3C4D9E65F8235AF42122BAE134099316EC210ADD09FC2D0DC9B8834042717C06CA42E6A4D5A586EB704FDE5E50676A5D2943635B972E1D219DC007F9935194C0AC4500F73EC74D51321C353A23AC473C5C9D99F9C952B35E43D52AEC480841278EC7E61DDE1BCF4AB89F7AB1C3E0E99DB481AC5AF5A6884804CDD89B5A2474BDED133B72F1DD3A756838C74903D07554386E7E203B3D7741B97A77F77F9CCD32A9BC00383AEDC6FF42FE5EC712144F1A948B4438316094096C3AFBA8F46663438C9E2C47EBD0F9312FF205D73F5F22DD599233933FFB7B8739EFA89EEE9444B8CE75D4338F723E4FC00BFF04EF79E0D46CB18C5A3875858CBDFCEC0425D7027F0F244448A4B1712610AF96B43041166E210A8FD995438D5E0DE416A79625E078534BEA6E2691FC3E67924E08F30055FE85A81F381D9844E2CB97AE1A51D0DE47B778AE1CD5AF021AE460C8157352BBDAEA08A70FC33FC8517B80029EF5756731F1DDF4070B7434ECD37A65F9625A927639CCB29000008000040002F0001670000F1005645523D310A4643545645523D372E342E382E323036360A5549443D36364645453542314241444234304137393946454141443944383336454646340A49503D31ike 0:EMS-TCP-VPN:411: dec 225EE7034892962DA26B0A97D3DA22A33520230800000001000001FC000000080005000639322E3136382E312E34380A4D41433D39302D32652D31362D64632D34342D32323B31342D35612D66632D33362D64622D66613B31342D35612D66632D33362D64622D66393B31362D35612D66632D33362D64622D66393B39362D35612D66632D33362D64622D66393B0A484F53543D46434E422D3030303030300A555345523D706F637573657231746573740A4F535645523D4D6963726F736F66742057696E646F777320382E3020456E74657270726973652045646974696F6E2C2036342D62697420286275696C642039323030290A5245475F5354415455533D300A454D53534E3D464354454D53383832353030323236380A454D5349443D30303030303030303030303030303030303030303030303030303030303030300A0021000048010000000001000000020000000300000003000000040000000D000000080000000A0000000B0000000F000000190000540C000070060000540A0000540B0000700100002C00005402000028010304031E1E00B8030000080300000C0300000C0100000C800E0100000000080500000000000028020304031E1E00B8030000080300000C0300000C0100000C800E010000000008050000002D00001801000000070000100000FFFF00000000FFFFFFFF000000180100ike 0:EMS-TCP-VPN:411: dec 225EE7034892962DA26B0A97D3DA22A335202308000000010000003600000008000600060000070000100000FFFF00000000FFFFFFFFike V=root:0:EMS-TCP-VPN:411: reassembled fragmented messageike V=root:0:EMS-TCP-VPN:411: responder received AUTH msgike V=root:0:EMS-TCP-VPN:411: processing notify type INITIAL_CONTACTike V=root:0:EMS-TCP-VPN:411: processing notify type FORTICLIENT_CONNECTike V=root:0:EMS-TCP-VPN:411: received FCT data len = 351, data = 'VER=1FCTVER=7.4.8.2066UID=66FEE5B1BADB40A799FEAAD9D836EFF4IP=192.168.1.48MAC=90-2e-16-dc-44-22;14-5a-fc-36-db-fa;14-5a-fc-36-db-f9;16-5a-fc-36-db-f9;96-5a-fc-36-db-f9;HOST=AAAA-000000USER=pocuser1testOSVER=Microsoft Windows 8.0 Enterprise Edition, 64-bit (build 9200)REG_STATUS=0EMSSN=FCTEMS8825002268EMSID=00000000000000000000000000000000'ike V=root:0:EMS-TCP-VPN:411: received FCT-UID : 66FEE5B1BADB40A799FEAAD9D836EFF4ike V=root:0:EMS-TCP-VPN:411: received EMS SN : FCTEMS8825002268ike V=root:0:EMS-TCP-VPN:411: received EMS tenant ID : 00000000000000000000000000000000ike V=root:0:EMS-TCP-VPN:411: received peer identifier DER_ASN1_DN 'CN = AAAA-000000'ike V=root:0:EMS-TCP-VPN:411: match gw peer ID by FNBAMike V=root:0:EMS-TCP-VPN:411: AUTH payload not receivedike V=root:0:EMS-TCP-VPN:411: schedule delete of IKE SA 225ee7034892962d/a26b0a97d3da22a3ike V=root:0:EMS-TCP-VPN:411: scheduled delete of IKE SA 225ee7034892962d/a26b0a97d3da22a3ike V=root:destorys tcp-transport(vd=0, vrf=0, intf=27:27, 162.252.yyy.yy:8443->142.167.xx.xx:58204 sock=42 refcnt=0 ph1=(nil)) (0).ike V=root:0:EMS-TCP-VPN: connection expiring due to phase1 downike V=root:0:EMS-TCP-VPN: going to be deletedike V=root:0:EMS-TCP-VPN: reset TCP ports    Support Forum Thu, 29 Oct 2026 07:21:04 +0100 https://community.fortinet.com/support-forum-92/ipsec-vpn-with-device-certificates-230668 Trying to create IPSEC Dialup using device certificates.  The authentication is not succeeding.This is the ike debug log:ike V=root:0:EMS-TCP-VPN:179: received FCT-UID : 66FEE5B1BADB40A799FEAAD9D836EFF4ike V=root:0:EMS-TCP-VPN:179: received EMS SN : FCTEMS8825002268ike V=root:0:EMS-TCP-VPN:179: received EMS tenant ID : 00000000000000000000000000000000ike V=root:0:EMS-TCP-VPN:179: received peer identifier DER_ASN1_DN 'CN = xxxx-000000'ike V=root:0:EMS-TCP-VPN:179: match gw peer ID by FNBAMike V=root:0:EMS-TCP-VPN:179: AUTH payload not receivedike V=root:0:EMS-TCP-VPN:179: schedule delete of IKE SA 7bd8a3c30b6c6d6f/7234bdc65e60b4a4ike V=root:0:EMS-TCP-VPN:179: scheduled delete of IKE SA 7bd8a3c30b6c6d6f/7234bdc65e60b4a4ike V=root:destorys tcp-transport(vd=0, vrf=0, intf=27:27, 162.252.xxx.xx:8443->142.167.xx.xx:53461 sock=42 refcnt=0 ph1=(nil)) (0).ike V=root:0:EMS-TCP-VPN: connection expiring due to phase1 downike V=root:0:EMS-TCP-VPN: going to be deletedike V=root:0:EMS-TCP-VPN: reset TCP ports Fortigate 7.4.12Forticlient 7.4.8 (FortiCloud managed)how to resolve or how do i track down why the payload is not being recieved/sent?thanks  Support Forum Thu, 29 Oct 2026 07:20:04 +0100 https://community.fortinet.com/support-forum-92/ipsec-saml-server-230950 If we refer to the Fortinet article below:Technical Tip: Implementing IPsec VPN SAML-based authentication using loopback Interface | Community it states that:IKE with SAML authentication does not support multiple SAML servers on the same interface, as the SAML server is directly bound to the interface and allows only one instance to be configured.What is the recommended design if I have two Internet connections for VPN redundancy?Since the SAML server is bound to an interface, does that mean we cannot enable the same SAML server on the secondary Internet interface?Has anyone implemented IPsec VPN with SAML authentication in a dual-ISP redundant setup? Support Forum Thu, 29 Oct 2026 03:35:46 +0100 https://community.fortinet.com/support-forum-92/fortimanager-upgrade-vs-new-adom-230948 I'm looking to go from 7.4.x to 7.6,.xI already upgraded Fortimanager. We normally make a new ADOM and migrate.However I see people just update the existing one since 7.6 ADOMs can manage 7.4 devices.Any opinions on which is a better practice?  Support Forum Thu, 29 Oct 2026 00:41:40 +0100 https://community.fortinet.com/support-forum-92/restore-fortianalyzer-logs-from-old-to-new-via-execute-restore-logs-only-all-sftp-ip-of-server-user-id-and-password-or-home-logs-i-get-error-230937 Restore Fortianalyzer logs from old to new via "execute restore logs-only all sftp ip of server user id and password / (or /home/logs" I get error diagnose log restore cancel Support Forum Thu, 29 Oct 2026 00:08:39 +0100 https://community.fortinet.com/support-forum-92/since-7-4-13-build2933-emails-not-sent-if-username-exceeds-36-characters-230909  Since the update to version 7.4.13 build2933, emails are no longer sent to users whose username exceeds 36 characters.I am referring to the emails containing the QR code for FortiToken Mobile. Version: FortiGate-901G v7.4.13,build2933,260929 (GA.M)  Support Forum Wed, 28 Oct 2026 22:15:15 +0100 https://community.fortinet.com/support-forum-92/new-available-fortios-v7-4-13-mature-release-230947  Hello community,I would like to know whether the newly available FortiOS v7.4.13 (Mature) release addresses and fixes the multiple CVEs (Common Vulnerabilities and Exposures) identified in previous versions.  Regards,Lengai  Support Forum Wed, 28 Oct 2026 19:45:41 +0100