Recently active topics

Anyone seen a problem using FMG from Safari on MacOS where you occasionally (every few minutes) get a message saying connection to FMG was lost, usually counts down for a few seconds then reconnects. It's likely related to a tcp keep alive because it doesn't happen when I'm interacting, only when I'm idle for a few minutes. I'm just not sure if I should adjust Mac or FMG side. I only see this in FMG but it never happens on Windows machines, even using Safari.

DescriptionThis article describes an authentication issue that affects Windows hosts authenticated through 802.1X PEAP-MS-CHAPv2 to FortiNAC using Winbind, or any other Active-Directory integrated RADIUS server.ScopeWindows hosts performing 802.1X PEAP-MS-CHAPv2 authentication with FortiNAC or other RADIUS servers.SolutionFollowing the installation of Windows update KB5127648 (released on 13 October 2026), authentication attempts using cached credentials are failing. The affected endpoints report Event ID 12014: OneX Held State Timeout.This issue is not specific to FortiNAC; it also impacts configurations using other RADIUS servers, and it is triggered by the update on the Windows endpoints. This will impact any 802.1X authentication using a cached username/password. This includes many WiFi deployments using WPA2-Enterprise or WPA3-Enterprise, as well as VPN connections using NTLMv1-derived credentials and PEAP-MS-CHAPv2. Deployments using client certificate authentication rather than

DescriptionThis article explains the steps to configure FortiSwitch to automatically trigger VRRP failover based on the status of the monitored destination IP.ScopeFortiSwitch version 7.6 and above.SolutionThe Virtual Router Redundancy Protocol (VRRP) provides redundancy without user intervention. A VRRP group consists of a master router and one or more backup routers that share a virtual IP address. In this article, the example includes the configuration involving two FortiSwitches forming VRRP. FortiSwitch-1:VRRP interface configuration:config system interface edit "CORE" set ip 10.10.1.2 255.255.255.0 set allowaccess ping set vrrp-virtual-mac enable config vrrp edit 110 set priority 200 set vrgrp 10 set vrip 10.10.1.1 next end set vlanid 11 set interface "internal" next end VRRP Status:get router info vrrp Interface: CORE, primary IP address: 10.1

I got problem.. I Deployment Web filter profile on Fortigate, my system already allowed & all runs well..But someday the license expired...then the Web Filter profile not running because license expired…and now i already renew, update & payment the license fortigate... Then Re-Deployment Web filter profile in rules firewall, but my system is blocking by Web filter profile without any changes on web filter profile.. i just replace / re-use Web filter after renew the license.Can you help explain what happen with this?FYI, Fortigate 101F with OS version :  v7.0.18 build0695 (Mature)This alert / alarm show in URL my system must be allowed, but blocking by Security Policies → Web Filter Profile : 

Description This article describes how to encapsulate VLAN tag inside VXLAN using same VNI over an IPsec deployment using different methods. Scope FortiGate v7.4 and v7.6. Solution The following infrastructure diagram consists of 3 VLANs (10, 20 and 30) in the WEST side and 2x VLANs (10 and 20) in the EAST side. The objective is to enable Layer 2 traffic between both sites using a single VNI. For this purpose, the VLAN tag will be encapsulated inside the VXLAN. This scenario is applicable when Layer 2 traffic from multiple customer VLANs must be supported, with a dedicated VNI for each customer.     Note: connection between switches and FortiGate are in trunk mode.   There are two ways of doing this:     Encapsulate each VLAN interface tag in the VXLAN.   FGT_WEST FGT_EAST config system interface    edit "wan"        set vdom "root"        set ip 11.11.11.11 255.255.255.0   

DescriptionWhy FortiWeb may buffer and drop Server-Sent Events (SSE) responses when HTTP Header Security (HHS) is enabled without any rules configured.ScopeFortiWeb deployments using SSE over HTTP or HTTPS.SolutionSymptoms:SSE responses with the Content-Type header set to text/event-stream are received from the backend server but are not forwarded to the client. The issue may occur when the HTTP Header Security module is enabled, even when no rules are configured.Debug output:The following debug messages were observed in the affected environment.<11:45:04> [Header Security][Debug]: (./waf_module/http_header_security.c:1027): hhs caching for CSP <11:45:04> [Header Security][Mod_Dbg]: Module name:http_header_security, Execution:3, Process error:0, Action:CACHE <11:45:06> [Header Security][Debug]: (./waf_module/http_header_security.c:1027): hhs caching for CSP <11:45:06> [Header Security][Mod_Dbg]: Module name:http_header_security, Execution:3, Process error:0, Act

FortiClient IKEv2 IPsec VPN – Negotiation Timeout After 30 Seconds During RADIUS/EAP OTP AuthenticationHello everyone,I'm experiencing an issue with an IKEv2 IPsec remote-access VPN using RADIUS/EAP authentication with MFA/OTP, and I would appreciate your feedback or any similar experiences.Environment FortiGate: FortiOS 7.6.6 FortiAuthenticator: 6.6.8 FortiClient: 7.4.8 (ZTNA) VPN: IPsec IKEv2 Remote Access Authentication: RADIUS/EAP with MFA/OTP RADIUS server: FortiAuthenticator Issue descriptionThe issue occurs regardless of the OTP delivery method. We have reproduced it with: FortiToken Mobile SMS OTP Email OTP When the user enters the OTP within approximately 30 seconds, authentication succeeds and the VPN tunnel is established normally.However, if OTP entry takes longer than approximately 30 seconds, FortiClient remains in the "Connecting" state. The connection eventually fails with an IKE negotiation timeout, and the tunnel is not established.Important observation:

We need to block Microsoft Copilot for our users, but the M365 admin controls don’t give us a clean off switch. So I’m looking at doing it at the FortiGate level instead. I am specifically talking about the co-pilot that is embedded in all Office 365 apps, not the direct web interface.The catch is that Office 365 must keep working without any impact. Copilot is now embedded across the Office apps and shares a lot of Microsoft infrastructure, so I’m wary of blocking too broadly.Has anyone had success with this? Specifically interested in:Application Control signatures for Copilot and how reliable they areWeb Filter or FQDN based blocking, and which domains you targetedWhether deep inspection was needed to make it workAny side effects you hit with Teams, Outlook, or the desktop appsSuccess stories, gotchas, or configs that worked would be really appreciated.

DescriptionThis article describes how to troubleshoot WBC_ERR_WINBIND_NOT_AVAILABLE when DNS resolution problems prevent FortiNAC from locating an Active Directory domain controller and completing the domain join.ScopeFortiNAC CentOS and FortiNAC-F.SolutionThe Winbind configuration may show Not Joined, Stopped, or Disabled. A user authentication test may return:plaintext password authentication failed could not obtain winbind interface details: WBC_ERR_WINBIND_NOT_AVAILABLE Failed to get domain from winbinddCheck the Winbind service and domain status.Navigate to Network -> Configuration -> RADIUS, then select the Winbind tab.Under Service Info, review:Status: Check whether the Winbind service is Running.Domain Status: Check whether FortiNAC is Joined to a domain.Toggle Service Status: This control enables or disables the service. A button labeled Disable is an available action, not an indication that the service is currently disabled.Details & Logs: Select View Logs to inspec

Hi, I'm trying to improve FortiGate security profiles.What are the best threat feeds for Web Filtering and Antivirus?

DescriptionThis article describes how to troubleshoot certificate-based IPsec VPN tunnels that fail after migrating from a physical FortiGate to a FortiGate VM when the configured peer CA object references a different CA certificate on the destination device.ScopeFortiGate.SolutionAfter migration, two certificate-based IPsec tunnels failed to establish. The local certificate was valid, and its private key matched. However, the destination FortiGate rejected the remote peer certificate during IKE authentication.Review the IPsec Phase 1 configuration.Verify the local certificate and private key.get vpn certificate local details <Certificate_Name> execute vpn certificate local verify <Certificate_Name>Collect IKE debug during a failed negotiation.diagnose debug reset diagnose vpn ike log filter name <Tunnel_Name> diagnose debug console timestamp enable diagnose debug application ike -1 diagnose debug enableTrigger tunnel negotiation, then stop debugging:diagnose debug d

I am writing to submit a critical product architectural improvement request regarding how FortiClient EMS 8.0.0 on Linux establishes secure directory integrations.During our recent deployment of FortiClient EMS 8.0.0 on Ubuntu 24, we encountered persistent authentication failures when connecting EMS to our Windows Server Domain Controllers via secure LDAPS (Port 636). Real-time debugging via the adconnector.log file revealed that the authentication loop continuously failed with the following explicit Windows SChannel error wrapper:LDAP Result Code 49 "Invalid Credentials": 80090302: LdapErr: DSID-0C09089D, comment: AcceptSecurityContext error, data 1In the Windows security subsystem, Windows Error Code 80090302 translates directly to SEC_E_UNSUPPORTED_FUNCTION. This protocol violation occurs because the FortiClient EMS backend engine is compiled to automatically encapsulate its Active Directory GUI bind traffic using an NTLM/SPNEGO negotiated token handshake.The Troubleshooting Barrier

DescriptionWhy the administrator SAML SSO login option may be missing on the secondary unit in a FortiWeb HA deployment.ScopeFortiWeb.SolutionThe IdP certificate synchronizes from the HA primary to the secondary, but the SAML configuration does not synchronize between HA members.To enable SAML SSO login on the secondary unit, configure the SAML settings independently.Access the secondary unit and open the SAML SSO settings.Select the synchronized IdP certificate.Configure the secondary unit's own server address or FQDN.Ensure that the corresponding Entity ID and ACS URL are configured on the IdP.Save the configuration and verify that administrator SSO login works on the secondary unit.Configure and test both HA members independently to ensure administrator SSO access remains available after failover.Related document:SAML SSO Login issuesTechnical Tip: How to configure SAML SSO login for FortiWeb Administrators with Microsoft Entra ID

Hi there, I have few expectation with Ipsec version 2 which might support. If user is setting idle it means neither sending traffic nor receiving  user must be disconnected as per the set timeout , what is the default time out and how I set as per my need. Same user cannot be login in multiple device. how can I achieve it only single user can login in one device. I have two ISPs, I want if one ISP goes down users must not be experiencing any issue and users must be shifted to another link automatically. (do we need to create two separate tunnel and policy and all configuration must be same - like policy,routing,access) or any other way I can achive. I have observed in remote IPsec version 2  if MFA is configured for users until user enter OTP till then internet gets disconnected, however tunnel is configured in split mode. Anyone has faced this issue, please share your experience can I achieve in Foritgate Remote Ipsec version 2

DescriptionThis article indicates the options that must be enabled while configuring IPsec VPN SAML-based authentication using loopback Interface.ScopeFortiGate v7.2.4 and later.SolutionThe configuration of IPsec VPN SAML-based authentication is based on the document IPsec VPN SAML-based authentication.When using a loopback interface for IPsec SAML authentication, 'set ike-saml-server' must be configured on both the loopback interface and the actual ingress interface; otherwise, the TLS handshake may fail before SAML processing begins.The following tunnel has been configured with a lookback interface:config vpn ipsec phase1-interface     edit "v4-PSK-IKEv2"         set type dynamic         set interface "Loopback"         set ike-version 2         set peertype any         set net-device disable         set mode-cfg enable         set ipv4-dns-server1 172.17.60.6         set ipv4-dns-server2 8.8.8.8         set proposal aes128-sha1 aes256-sha256         set dpd on-idle         set dhgrp

DescriptionA FortiWeb high availability (HA) synchronization issue in which CLI MD5 values differ between cluster members and the secondary unit may become unresponsive.ScopeFortiWeb.SolutionSymptomsThe following symptoms are observed in an affected environment.The primary unit remains operational while the secondary unit intermittently becomes unresponsive to ping and its console stops responding.The output of the execute ha md5sum command shows matching SYS MD5 values but different CLI MD5 values between the primary and secondary units.HA event logs show repeated CLI configuration synchronization attempts, including failed synchronization operations followed by retries.Crash logs contain repeated segmentation faults (SIGSEGV) in ha_send_ctrl, with the stack trace terminating in haget_detail_md5sum.High CPU utilization may also be observed on the affected secondary unit. This symptom alone does not confirm the MD5 calculation defect.WorkaroundThe following procedure clears the predefi

DescriptionThis article describes how to troubleshoot an issue where traffic received through a dial-up IPsec VPN tunnel does not match the configured firewall policy and is denied by the implicit deny policy (policy 0).ScopeFortiGate.SolutionIn this example, traffic received through the dial-up IPsec interface 'Dialup-IPsec-VPN' is denied by policy 0, despite an existing firewall policy allowing traffic from the VPN to the internal network.The following firewall policy is configured:config firewall policy     edit 101         set name "IPsec-to-Internal"         set srcintf "Dialup-IPsec-VPN"         set dstintf "Internal-Network"         set action accept         set srcaddr "VPN-Subnet"         set dstaddr "Internal-Subnet"         set schedule "always"         set service "HTTPS"         set logtraffic all     next endThe traffic being tested has the following information:ParameterValueSource IP192.0.2.10Destination IP198.51.100.20ProtocolTCP (6)Source port50120Destination port443V

Description This article describes how to change passwords for Windows domain users through FortiPAM. Scope FortiPAM. Solution FortiPAM allows manual password changes in secrets using various templates, such as Windows Domain Account, Windows Machine, Unix Account, or Windows Domain Account (Samba). Additionally, automatic password changing is also allowed based on parameters specified in the secret settings.   Go to Secrets -> Targets -> Create. Specify Name, Classification Tag,  Default Template select 'Windows Domain Account', Domain- Controller specify Domain IP, Domain section specify 'Domain FQDN'. Advanced Domain Settings ensure that the Common Name is 'sAMAccountName' and the LDAPs Port used is 636.   Note: Password change will work only when FortiPAM is connected through the LDAP server using port 636.   Figure 1.Creating Target   Note: Domain name should be the FQDN of the domain, not the NETBIOS name. Run the below command on CMD to g

DescriptionThis article describes how to automatically configure and license a FortiGate-VM when it is first deployed in a cloud or virtualized environment, without having to connect manually to the VM and perform the initial setup.ScopeFortiGate VM.SolutionFortiGate-VM supports the Cloud-init NoCloud datasource with a YAML user-data filestarting with:FortiOS 7.4.5 in the 7.4 branchFortiOS 7.6.0 in the 7.6 branchUsing this method, the user-data file can contain FortiGate-specific attributes, including the initial FortiOS configuration and the FortiGate-VM license.The user-data file must use the following structure:Note that the cloud-config is for FortiGate init configuration only.cloud-config fortigate: | config system global ... end license: | -----BEGIN FGT VM LICENSE----- QA...... -----END FGT VM LICENSE-----The FortiGate attribute contains the FortiOS CLI configuration that must be applied during the initial provisioning of the FortiGate-VM.Only FortiOS configuration comma

Hello, I am currently using a laptop that runs FortiClient to connect via REMOTE IPSEC VPN to the primary and backup firewalls.On this laptop, I am using version 7.07 345, which is obsolete. I have a new PC on which I just installed the latest version, 7.4.34726. I created a backup of the configuration on my old PC that I'm trying to import onto my new PC. Unfortunately, when I try to restore this backup on the new PC, FortiClient doesn't even ask me for the password.I asked ChatGPT+ for help, and we switched to the Command Prompt (cmd—run as administrator) and ran the following commands:    - FCConfig.exe -m all -f cheminfichierSave.conf -o import -p MOT_DE_PASSE   - FCConfig.exe -m all -f cheminfichierSave.conf -o import i -1 -p MOT_DE_PASSENeither of these two orders is going through. Could you please let me know what steps to take?Thank you, and have a great day.GwénaëlleNote: This post was machine translated in accordance with our Fortinet Community Guidelines.

DescriptionThis article explains how to troubleshoot FortiClient deployment issues when FortiClient EMS shows the status as Endpoint Notified, but the endpoint does not display an upgrade notification.ScopeFortiClient EMS, FortiClient deployment and upgrade troubleshooting.SolutionIssue:During a FortiClient upgrade deployment, the deployment status in FortiClient EMS may show Endpoint Notified, while the endpoint does not display an upgrade notification or proceed with the upgrade.In this situation, review the FortiClient diagnostic logs to determine whether the endpoint received the upgrade command and whether the installer download was successful.Troubleshooting Steps:Collect the FortiClient diagnostic logs from the affected endpoint.Navigate to the following log file within the diagnostic results:Diagnostic_Result\FCDiagData\general\logs\trace\FortiESNAC.logSearch for keywords such as Install, upgrade, or Received upgrade command to identify the upgrade process and any related error

Hi, I upgraded my Forticlient EMS to the 7.4.5 version and now i can't access to the web portal. When i try to run the command "service restart --all" in the linux console i have the next error:get services status: start apache2 service: exit status 1exit error: [exit status 1], exitStatus: 1Can someone help me with this issue please?

When I attempt to Telnet into a Cisco switch located downstream of a FortiGate 50G (FG-50G), the Telnet connection fails.However, through cross-testing, I discovered an odd workaround: Whenever I modify any Firewall Policy on the FG-50G (even an irrelevant change, such as removing a service from a disabled policy), the previously failed Telnet connection to the downstream switch suddenly starts working normally.Unfortunately, if the system is left idle for a while, the Telnet connection issue returns.Network Architecture & Environment Setup Upstream & Downstream Switches: Cisco switches, connected via LACP configured to allow all VLANs. Plaintext   interface Port-channel1 switchport mode trunkend FortiGate 50G: Configured in Transparent Mode. Aggregate Interface Configuration:   edit "downlink" set vdom "root" set allowaccess ping https ssh snmp radius-acct set broadcast-forward enable set l2forward enable set stpforward enable set type aggregate set me

DescriptionThis Article describes how the config sync list works for the existing config, and if some of the config is deleted from the target device.ScopeFortiADC and FortiADC VM.SolutionConfig Sync list works in 2 directions. This can be used either to PUSH config or PULL config from the Target FortiADC device. The Target device can be referred as the device from where the config is Pulled or to the device where config is being Pushed.To perform config sync via CLI, follow config sync-listTo config via GUI, Technical Tip: Config Sync without enabling HAConfig Sync can work for the new configuration, however if configuration is deleted on one device and that device PUSH the config to the target device, then the deleted config will not be removed from the Target device.Example: There are 2 FortiADC device: FADC-A and FADC-B:FortiADC-A has deleted the config for the Global DNS policy. This config was then pushed to the target device (FADC-B).The status shows success, however, the config

DescriptionThis article describes an issue where VXLAN traffic does not properly follow SD-WAN rules when traversing IPsec VPN tunnels, causing traffic to be forwarded through multiple tunnel interfaces instead of exclusively using the interface selected by the SD-WAN rule.This behavior occurs when an SD-WAN rule uses a manual strategy to prioritize IPsec VPN tunnels for VXLAN traffic.ScopeFortiGate, NP7 and NP7Lite platforms, FortiOS 7.6, VXLAN, SD-WAN, IPsec VPNSolutionThis issue occurs because VXLAN traffic does not properly update its forwarding path when the preferred route or SD-WAN member changes.In the affected scenario, VXLAN connectivity is established between two data centers using four IPsec VPN tunnels.The tunnel interfaces are identified as follows.L1-D1L1-D2L2-D1L2-D2An SD-WAN rule is configured with a manual strategy to forward VXLAN traffic through one tunnel at a time, according to the configured interface priority.Expected behaviorWhen the preferred SD-WAN member cha