Recently active topics

DescriptionThis article describes why an IPsec tunnel using DDNS may fail to re-establish in certain scenarios.ScopeFortiGate.SolutionNote: The issue described in this article is not common.The following illustrates the scenario in a site-to-site IPsec VPN:Local firewall: the Hub FortiGate has a static public IP address.Remote firewall: the Spoke FortiGate is behind CGNAT (such as on a 4G/5G mobile network).DDNS is configured on the Spoke FortiGate so that the Hub FortiGate can resolve the Spoke FortiGate's public IP address for IKE negotiation.Since the Spoke FortiGate is behind CGNAT, it can act only as the IKE initiator.The Hub FortiGate, on the other hand, is configured to act as the IKE responder only by enabling passive mode with the following configuration:config vpn ipsec phase1-interface edit "TO_SPOKE" set type ddns set remotegw-ddns "SOPKE_FQDN" set passive-mode enable next endSymptoms.The IPsec tunnel is initially established successfully.Su

DescriptionManaged FortiSwitch devices may show a MAC-SYNC status of 'Wait' on the FortiGate after an upgrade, preventing synchronization of MAC addresses.ScopeFortiGate, FortiSwitch.SolutionSymptoms.After upgrading FortiGate from versions 7.2.13 to 7.4.12 or above, managed FortiSwitch devices display a status of 'Wait' in the MAC-SYNC column when running the following command:execute switch-controller get-sync-status all Managed-devices in current vdom root: FortiLink interface : fortilink SWITCH-ID (SERIAL) STATUS CONFIG MAC-SYNC HTTP-UPGRADE Server-SW01 (S224EPTF25000849) Up - Wait - Server-SW02 (S224EPTF25004126) Up - Wait -The configuration sync remains functional, and traffic continues to flow, but the MAC-SYNC status does not transition to a synced state.Resolution.Rename the affected FortiSwitch devices to their default names (serial numbers) to trigger a fresh synchronization.Log in to the FortiGate console.Rename the affected FortiSwitch devices.Verify that the MAC-SYNC sta

DescriptionThis article describes how to configure inbound BGP route maps on a branch FortiGate to prefer a disaster recovery (DR) site over a production site for a specific application network.ScopeAll FortiGatesSolutionBoth sites advertise the same prefix. During a planned switchover, the branch assigns a higher BGP local preference to the route received from DR. Production remains available as a backup path.Prerequisites:Both BGP sessions are established and advertise 172.16.100.0/24 to the branch.Both paths have reachable next hops and equal BGP weight.The application can operate at DR using the same destination addresses. Routing does not perform application or data replication.Firewall policies, IPsec selectors and return routes permit branch-to-application traffic through either site.No more-specific route, preferred non-BGP route, policy route or SD-WAN decision overrides the intended forwarding path.Configure a prefix list:config router prefix-list     edit "APP-NETWORK"      

DescriptionHow to disable unwanted FortiToken activation emails for FortiClient Standalone users provisioned in FortiIdentity Cloud that use an external Identity Provider for MFA.ScopeFortiIdentity Cloud (formerly FortiTokenCloud), FortiClient Standalone.SolutionTo prevent FortiToken activation emails from being sent, configure FortiIdentity Cloud to use the remote Identity Provider for all authentication by enabling passthrough mode:Log in to the FortiIdentity Cloud console.Go to Applications -> SSO.Edit the SSO application or create a new SSO application.Set the authentication setting to Passthrough.This configuration ensures that FortiIdentity Cloud does not attempt to manage passwords or MFA tokens locally, which suppresses the automatic sending of FortiToken activation emails.

Hi everyone,we using a Fortigate G900 with v7.6.7 as explicit proxy.Since a couple of weeks, we have the problem that, when using Firefox, we can’t use the Google Search.After we type anything in the search bar, we get the following error:502 unknown content-encodingThe webserver reported that an error occurred while trying to access the website. Please return to the previous page.URL     https://www.google.com/search?client=firefox-b-d&q=fortigate Other Websites / Search-Engines with Firefox are working fine. With Edge or Chrome Browser Google works as well.Have somebody an idea? Regards, Michel

FortiRecon Digital Risk Protection (DRP), a SaaS-based service, includes External Attack Surface Management, Brand Protection, and Adversary Centric Intelligence.Adversary Centric Intelligence (ACI): leverages FortiGuard Threat Analysis to provide comprehensive coverage of dark web, open-source, and technical threat intelligence, including threat actor insights to enable organizations to respond proactively assess risks, respond faster to incidents, better understand their attackers, and guard assets.The Vulnerability Intelligence Module under Adversary Centric Intelligence (ACI) provides a realistic view of the impact of the vulnerability based upon chatter and discussion of the same across various external sources such as Darkweb, social media, News / Blogs etc.CVE IDCVE-2026-21589CVE TitleAtlassian Multiple Products Files or Directories Accessible to External Parties VulnerabilityNVD SeverityCRITICALFortiRecon SeverityCRITICALFortiRecon Score95/100Epss Score0.12711ExploitedYesExploi

I integrated my Cisco C1300 to NAC and all is working fine except for CoA. When i manually execute send CoA then in the switch i got message ‘13-Oct-2026 13:37:21 %RADIUS-I-CoAREJECT: CoA Request from 10.10.10.9 rejected. Reason: Missing NAS identification attribute’I try add NAS-Identifier in Radius Attribut with value %AUTH%, %ACCESS_VALUE”, %SYSTEM% and %ACCT% with no success. Anyone know why?Same radius attribute is working fine for Cisco Catalyst switch even in the radius attribute no NAS-Identifier. 

itle: FortiGate 100F – EMAC-VLAN across multiple VDOMs with a routed /28 subnet over /30Hello Fortinet Community, We are testing a FortiGate 100F running FortiOS 7.6.6 with two VDOMs (root and Production), using EMAC-VLAN interfaces. Our configuration: - Physical "wan1" interface belongs to the root VDOM.- "wan1" has an IP address in the ISP's "/30" transit network.- Two EMAC-VLAN interfaces ("outside_Root" and "outside_Prod") share "wan1" as their parent interface.- Each EMAC-VLAN belongs to a separate VDOM and has its own public IP address from the same "/28" subnet.- Both VDOMs have independent IPsec VPN tunnels. What works: We have successfully tested EMAC-VLAN when the upstream router or Layer 3 switch has an IP address in the same public subnet as the EMAC-VLAN interfaces. In this setup, the router can resolve each EMAC-VLAN interface's unique MAC address using ARP, and traffic reaches the correct VDOM. Our problem: Our ISP provides two separate IPv4 networks: - A "/30" transit n

Currently we have a Microsoft Server 2016 server as our radius server.We intent to upgrade to Server 2025.is there anything for us to take note when we upgrade to Server 2025 ?

Am final year in college I already have CCNA.My next goal is Security fundamental for Network Security, What about NSE4 and Sec+?, What i should focus on and worth for Entry level in Network security ? 

I’m on a FortiGate 61F version 7.4.11 and FortiClient Windows version 7.4.3.I am trying to set up IPSec VPN for my remote users so that I can upgrade the FortiGate (knowing that SSL is no longer supported).  I’m running into trouble with Authentication when it comes to PSK vs Peer ID from dialup group.  What I want is for the tunnel to accept users from a specific local user group on the FortiGate.  My problem is that if I change the Peer Options to Peer ID from dialup group, the Pre-shared Key box goes away.  That’s then a problem on FortiClient since I can't leave the PSK box blank.  Any help on how to solve this?  Thank you! Side Note: I have an IPSec VPN for remote users set up on a different box running 7.6.6 doing exactly what I want.  There are more options for Authentication on that version and I can have a PSK and the tell it to use user group I want.

Hello, the content on the fortigate management interface doesn't load because fortinet's cdn certificate seems to have expired.For example the browser doesn't load the content at https://fos-cdn.fortinet.com/artifacts/fos/7.2.10/b1706/3655.js, if I try to open the url directly in the browser I see  that the domain SSL expired one Oct 30thAnd the cert Is indeed expired

DescriptionTroubleshooting steps for situations where the Events Per Second (EPS) value is displayed as N/A for a Collector under the FortiSIEM Collector Health page.The Collector may appear in the GUI, but the EPS value may be unavailable, making it difficult to determine whether the Collector is actively processing or forwarding events.ScopeFortiSIEM.SolutionStep 1: Verify collector health in the GUILog in to the FortiSIEM Supervisor.Navigate to Admin -> Health -> Collector Health.Locate the affected Collector and review the following information:Collector health status.Collector IP address and name.Last Status Updated.Last File Received, if available.EPS value and other displayed health metrics.Hover over the Collector status to review any available health details.Determine whether the issue affects a single Collector or multiple Collectors.If the status information is outdated, investigate whether the Collector is communicating with the Supervisor before proceeding.Step 2: Ve

DescriptionTroubleshooting steps for situations where the FortiSIEM GUI fails to display or run Machine Learning (ML) jobs after a report has been deleted.ScopeFortiSIEM.SolutionStep 1: Confirm the errorLog in to the FortiSIEM GUI.Navigate to the Resources or Analytics menu and open ML jobs.Record the complete error message and the report ID.Confirm whether the issue started immediately after deleting one or more reports.Step 2: Review the Application LogsOn the Supervisor, inspect the GlassFish application server log:tail -n 300 /opt/glassfish/domains/domain1/logs/server.logSearch for the report ID and related errors:grep -n -C 5 'Report@<report_id>' \/opt/glassfish/domains/domain1/logs/server.logReplace <report_id>  with the report ID from the error message.Review the surrounding entries for exceptions, missing report references, or failures while loading ML jobs. Preserve the relevant timestamps and stack traces.Step 3: Determine whether the reference is orphanedConfirm

DescriptionInstructions on how to register a FortiGate hardware appliance with FortiCare when the FortiGate does not have Internet access. An air-gapped environment is a network intentionally isolated from the Internet, preventing the FortiGate from directly reaching FortiCare and FortiGuard services.ScopeFortiGate hardware appliances.SolutionRecent FortiGate models with the latest BIOS version require FortiCare registration during the initial setup process. When the FortiGate is deployed in an air-gapped environment and cannot reach FortiCare directly, an offline license file can be uploaded through the FortiGate setup wizard.Note: This registration workflow applies to recent FortiGate hardware models with the latest BIOS version. Older FortiGate models without the latest BIOS do not use the same mandatory registration workflow.Note: FortiGate-VM licensing still requires connectivity to a licensing FortiManager or FortiGuard server. Therefore, this procedure is intended for FortiGate

Where we can find supported device by FortiNAC?

DescriptionIn active-active FortiGate Session Life Support Protocol (FGSP) clusters, asymmetric traffic routing can cause connection drops for traffic that uses session helpers or Flow-based UTM inspection. Common examples include DCE-RPC on TCP port 135, SIP, and FTP.When asymmetric routing or ECMP paths are present, the client SYN arrives on one FortiGate and the return SYN-ACK arrives on a peer FortiGate. The peer FortiGate cannot inspect return packets independently. It must redirect them to the session owner so the session helper and IPS engine can evaluate the complete TCP handshake.In the factory default configuration, FortiOS sets set layer2-connection unavailable under config system standalone-cluster. This default configuration uses Layer 3 UDP encapsulation to redirect traffic between peers across routed boundaries.However, administrators often explicitly change this setting to set layer2-connection available in an attempt to optimize performance or because data centers link

Description This article describes how to configure a Lua script on FortiADC to achieve an HTTP redirect with a 301 return code. The user requires assistance with editing the Lua script to redirect HTTP requests to a specific URL with a 301 return code. Scope FortiADC. Solution To configure an HTTP redirect with a 301 return code on FortiADC, follow these steps: Go to Server Load Balance -> Scripting, make sure the tab is under 'HTTP', select 'Create New'.  In the script, add the following Lua code:   when HTTP_REQUEST{ host = HTTP:header_get_value("host") path = HTTP:path_get() t={} t["code"] = 301; t["url"] = string.format("https://%s%s", host, path); HTTP:redirect_t(t); } Make sure to configure one virtual server (VS) for the HTTP service, where the redirection script is specified, and another VS with HTTPS for application access. Note: It is essential to split up the HTTP/HTTPS services into two separate instances to avoid excessive redirects.   Verify th

DescriptionA list of the minimum information to gather before opening a Fortinet technical support (TAC) case for a wireless client roaming or disconnection issue.ScopeFortiGate, FortiAP, FortiWiFi.SolutionCollect the environment details first, then the debug output and logs from the FortiGate/FortiWiFi, the FortiAP, and the Windows client.Before you collect any logsGather the following information before you collect any logs.Details of the affected client: the operating system, the MAC address of the Wi-Fi network interface card, and the Wi-Fi driver vendor and version.The approximate local time when the issue occurred.A detailed description of the issue as reported by the customer. For example, the client disconnects for a few seconds and reconnects automatically while it is stationary, or the client disconnects when it moves and does not reconnect automatically.If the client was moving, the approximate access points it moved between: the access point it moved away from, and the acce

I have a fortigate 70G (v7.4.12 build2902) setup as the wireless controller of a mesh network. A fortiap 421E (FP421E-v6.4-build0492) is the root, and then the two leaf ap's are another 421E (v6.4.0 build0492) and a 221E (v7.4.4 build0644). When I first configured this several months ago, everything worked great. Then recently my daughter started mentioning that the internet seemed slow.I looked into it and although I hadn't changed anything, the leaf ap's were no longer connected to the mesh network, so all traffic was routing through the root ap.Through some reboots I was able to get the entire mesh up again. However, no clients will connect to either of the leaf ap's.This configuration was previously working with no changes made and then stopped working. What should I do?I don't believe any of the ap's auto updated nor did the FG. None of the devices are registered for support, but that has been true for quite a while, definitely while the mesh was up and working.Any help and advice

DescriptionComputer accounts continue to appear in the User Monitor during Kerberos authentication, even when an LDAP account-key filter is configured to exclude them.ScopeFortiProxy, FortiGate.SolutionDuring Kerberos authentication, FortiProxy can use Windows Security Identifiers (SIDs) extracted from the Privilege Attribute Certificate (PAC) in the Kerberos ticket to match group information.When PAC-data extraction is enabled, group matching uses the SIDs extracted from the Kerberos ticket instead of relying on LDAP account-key filtering. As a result, the LDAP account-key filter may be bypassed, allowing computer accounts to be authenticated and displayed in the User Monitor.To resolve this issue, disable PAC-data extraction in the Kerberos keytab configuration so that LDAP account-key filtering is used for group matching.Disable PAC data in the Kerberos keytab configuration:config user krb-keytab edit "<keytab_name>" set pac-data disable next endConfigure the L

DescriptionThis article describes an issue where FortiGate generates multiple administrator login event logs during a successful HTTPS GUI login when FortiToken push-based multi-factor authentication (MFA) is used.Although the administrator successfully authenticates and gains access to the GUI, FortiGate may generate:Multiple failed administrator login events while waiting for the user to approve the FortiToken push notification.Multiple successful administrator login events for a single login session.These additional log entries can lead to false-positive alerts or inaccurate reporting in SIEM and monitoring platforms.ScopeFortiOS version 7.6.7.SolutionThe issue is related to how the FortiGate GUI authentication process handles and logs pending MFA status checks.During GUI authentication, FortiGate sends an initial authentication request and subsequently polls the MFA status until the user approves the FortiToken push notification.Here, pending MFA status checks can be incorrectly re

DescriptionTroubleshooting steps for a custom protocol error that occurs when performing a policy installation to FortiGate. ScopeFortiManager.SolutionThe following issue may be encountered by users when performing policy installation to FortiGate v7.6 to a v7.4 ADOM in FortiManager.This issue occurs because the protocol types defined in the default firewall service objects differ between ADOM versions.For example, in v7.4, the default protocol for the DNS service is TCP/UDP/SCTP, whereas in v7.6, it has been updated to TCP/UDP/UDP-Lite/SCTP.To resolve this issue, upgrade the ADOM to v7.6 so that the default firewall service object definitions in FortiManager align with those on the FortiGate.

DescriptionFortiGate units in an Active-Passive High Availability cluster running FortiOS 7.6.7 on Oracle Cloud Infrastructure fail to automatically reassign secondary IP addresses to the new primary node during a failover event.ScopeFortiGate VM (OCI) 7.6.7.SolutionThis is a known issue (1303540) in FortiOS 7.6.7 that prevents the OCI process from recognizing the HA event, which stops the automatic movement of secondary IP addresses.The issue is patched under FortiOS 7.6.8 (Pending release) and 8.0.1. See FortiOS 8.0.1 - Resolved issues.In such a scenario, there are three options:Option 1: Upgrade the cluster to FortiOS 8.0.1.Option 2:Roll back the cluster to FortiOS 7.6.6.Option 3:If an immediate upgrade/downgrade is not possible, manually trigger the movement of secondary IP addresses using the following command on the new primary node:diagnose test application ocid 4To verify if the secondary IP addresses moved to the current primary node, run the following command:diagnose test ap

How to fix analytic and archive( actual days)if i set the fortiananlyzer system time after 2 weeks from the time the logs sent to fortianalyzer