Recently active topics

Hello,I am trying to activate the FortiGate-VM permanent trial (FortiOS 7.2.1+ model) on a lab VM, and the license request always fails.EnvironmentFortiGate-VM64-KVM v7.4.13 (build 2933) and v7.6.8 (build 3744), both downloaded from Support > Download > VM Images (FortiGate, KVM; FGT_ image, not FFW_). Running under QEMU/KVM inside a container (Containerlab/vrnetlab) in WSL2, with 1 vCPU and 2 GB RAM, so inside the trial limits. get system status shows "License Status: Invalid", "VM Resources: 1 CPU/1 allowed".What I doexecute vm-license-options account-id <my FortiCloud e-mail>execute vm-license-options account-password <password>execute vm-licenseResult"Requesting FortiCare Trial license, proxy:(null)" followed by "Failed to download VM license." No error code is displayed. The web GUI trial activation also fails ("Error downloading license: Invalid serial number" on one attempt).What I have verifiedDNS works (public resolvers 8.8.8.8 / 1.1.1.1; earlier "dns resolve

We are currently in the process of switching over to the FortiClient VPN (v7.0.0.0029) from the DrayTek Smart VPN Client and I notice that all of my traffic is now being piped through the VPN, instead of just the traffic that requires it. Our FortiClient is set up to use IPsec VPN. The DrayTek VPN has a setting named Use default gateway on remote network and I always have this switched off.  I'm trying to find a similar setting in the FortiClient VPN. Sorry.  I'm not overly familiar with all the network jargon, so please forgive me for that.  I see a bunch of settings under Advance Settings, but nothing that appears equivalent to the DrayTek setting. Thank you in advance for any assistance provided.

On the fortigate log result there is data transfer, example the 1st row have 598.2 MB / 85.64 MB and 2nd row 598.18 MB  / 85.63 MB.How we can read that? Is my under standing below is correct?598.2M B is data transfer from 12:41:07 - 12:43:10? and598.18 MB is data transfer from 12:38:57 - 12:41:07?  

Hello Everyone, I would like to test my knowledge in NSE 4 - 7 via the use of past exam papers. Is there a repository I can connect to? 

DescriptionAn issue where existing users do not receive updated role assignments after changes are made to the SAML Team and Role Mapping configuration.ScopeFortiSOAR.SolutionAfter modifying the role mapping in the SAML configuration, users who have previously logged into FortiSOAR continue to be assigned their old roles instead of the new roles defined in the mapping.This behavior occurs when IdP User Attribute Sync is disabled. Updated role mappings are not applied to existing users during subsequent SAML logins.To resolve this issue:Navigate to Administration -> System -> SSO Configuration.Locate and enable IdP User Attribute Sync.Select the appropriate synchronization option:Sync All Attributes: Synchronize all supported user attributes, including roles.Sync SAML Roles Only: Synchronize only SAML role assignments.Select Save.Sign out of the affected account and sign back in through SAML using a private browser session.Verify that the user's assigned roles match the updated SA

Hi All,I'm looking for guidance and best practices for implementing a resilient Layer 2 access network using a ring topology.Hardware Under ConsiderationFortiGate 121G (Firewall) FortiSwitch FS-1024E (Core/Distribution) FortiSwitch FS-224E (Access) FortiSwitch Rugged FSR-112F-POE (Rugged Access)Design ConsiderationsThe current access-layer design consists of up to five rings, with each ring supporting 15 hops in a dual-ring architecture (up to 30 switches per dual ring).End devices (1 NIC 2 IP ports) will be connecting to two separate access switches for redundancy. The expectation is that RSTP will provide both:Ring redundancy within the access network Redundancy for dual-homed endpoint connectionsThe attached diagram provides a high-level representation of the proposed architecture.Challenges RSTP convergence time RSTP convergence may be too slow for the application. The target recovery/convergence time is less than 1 second following a link or switch failure. MRP/PRP limitations

DescriptionManagement access services such as HTTPS, SSH, and Ping are randomly removed from port1 on FortiNAC version 7.6.7 in High Availability deployments, resulting in a loss of remote administrative access.ScopeFortiNAC-F 7.6.7SolutionSymptomsRemote management access to the FortiNAC appliance is lost. The following services become unavailable on port1:HTTPS Admin UISSHPingAdministrative access is only possible through the VM console. Logs indicate that the allow access configuration on port1 was updated and the management services were removed.Root causeThis is a known issue (Bug ID 1321265) affecting FortiNAC version 7.6.7 in 1+1 High Availability (HA) deployments. The issue causes the allowaccess settings on port1 to be randomly modified, removing critical management services.ResolutionWorkaroundDisable the Layer 4 health check on both nodes of the HA cluster to prevent the removal of management access services. Run the following command on both appliances:diagnose system health

DescriptionConfiguring a domain check custom scan for a child domain may cause the parent domain scan to fail or incorrectly change its domain settings.ScopeFortiNAC, FortiNAC-FSolutionSymptomsWhen a separate User Health Profile (UHP) and Endpoint Compliance check are created for a child domain, modifying the custom scan for the child domain causes the parent domain custom scan to fail. Additionally, the parent domain name may automatically change to the child domain name within the configuration settings after saving.Root causeThe issue occurs when the custom scan is configured to use "Match Value". This can lead to conflicts or incorrect resolution when multiple domain levels (parent and child) are monitored using the same scan logic.ResolutionTo resolve this issue and ensure both parent and child domains are scanned correctly, follow these steps:Go to the custom scan configuration for the child domain.Change the scan setting from Match Value to Search keys and values.Select Save.Cre

Hey everyone,We currently have a couple of FortiGate VM appliances running FortiOS 7.2.13 and are using FortiClient SSL VPN tunnel mode for client remote access.I understand Fortinet is sunsetting SSL VPN tunnel mode in FortiOS 7.6.3. the business is not ready to pivot off SSL VPN so in the meantime, they want to know whether upgrading to FortiOS 7.4.x is a reasonable short-term bridge (Fortinet’s lifecycl page says says it’ll be supported until March 31, 2028/November 11, 2028). Questions:1. For those who have upgraded, has FortiOS 7.4.x been stable for production SSL VPN tunnel mode?2. Is SSL VPN tunnel mode supported throughout the 7.4.x branch, including later releases such as 7.4.8 or newer, or is there a specific 7.4.x version we should target/avoid?3. Since SSL VPN is hidden from the GUI by default in 7.4, is it still considered fully supported in 7.4.x, or is it more of a transitional feature?4. Can I upgrade directly from 7.2.13 to a 7.4.x release, or should I follow a specifi

DescriptionTroubleshooting steps for an issue where LDAPS configurations are erased after a FortiManager upgrade when a 'ca-cert' is not configured.ScopeFortiManager.DescriptionFortiManager currently permits omitting the 'ca-cert' field when configuring LDAPS.These LDAPS configurations, where LDAPS is configured but the 'ca-cert' field is not set, will be automatically deleted during the upgrade to FortiManager versions 7.4.12 GA and 7.6.8 GA.config system admin ldap edit "LDAP" set server "x.x.x.x" set cnid "sAMAccountName" set port 636 set dn "dc=fortinet,dc=lab" set type regular set username "fortinet" set password ENC XXX set secure ldaps set ca-cert "Fortinet_CA" nextWorkaround: Assign a temporary ca-cert before upgrading FortiManager to keep the configurations during the upgrade. Disable it if necessary once the FortiManager has been upgraded. Note: This behavior applies to RADIUS over TLS and TACACS+

DescriptionA guide to finding a stable software release for FortiSIEM. The information in this document is not meant to be exhaustive and is intended to serve as general guidance to users, especially in cases of mass deployments/upgrades.ScopeThis document is a general recommendation of FortiSIEM software releases for general user deployments for general stability. It covers FortiSIEM hardware appliances, virtual appliances (Supervisor, Worker and Collector), FortiSIEM Manager, and FortiSIEM Agents.SolutionProduct DetailsRecommended ReleaseEnd of Engineering Support Passed (Y/N)Hardware AppliancesFortiSIEM-500F (Collector)7.6.1NFortiSIEM-500G (Collector)7.6.1NFortiSIEM-2000F7.6.1NFortiSIEM-2000G7.6.1NFortiSIEM-2200G7.6.1NFortiSIEM-3500F7.6.1NFortiSIEM-3500G7.6.1NFortiSIEM-3600G7.6.1NVirtual Appliances (Supervisor / Worker / Collector)FortiSIEM-VM - all supported hypervisor and cloud platforms7.6.1NManagement and AgentsFortiSIEM Manager7.6.1NFortiSIEM Windows Agent7.6.xNFortiSIEM Linux

Hello Fortinet Team, Could you please change my community nickname to Gohan? If it is already used, you can change to GohanC or GohanFC. Thanks in advanced.

DescriptionA guide to handling the status=233/RUNTIME_DIRECTORY error in ClickHouse.ScopeFortiSIEM.SolutionThe following error will appear in either the ClickHouse logs or the status of the service.Logs:/opt/clickhouse/log/clickhouse-server.logService status:systemctl status clickhouse-serverThe error:status=233/RUNTIME_DIRECTORYThis issue relates to the ownership of the directory under which the ClickHouse Database is located.namei -l /data-clickhouse-hot-1/ f: /data-clickhouse-hot-1/ dr-xr-xr-x root root / drwxr-xr-x root admin data-clickhouse-hot-1To correct the ownership:chown -R clickhouse:clickhouse /data-clickhouse-hot-1The correct ownership is demonstrated below:namei -l /data-clickhouse-hot-1/ f: /data-clickhouse-hot-1/ dr-xr-xr-x root root / drwxr-xr-x clickhouse clickhouse data-clickhouse-hot-1

Description This article describes how to verify if old events in ClickHouse still exist after the event retention period is over. Scope FortiSIEM. Solution It has been observed that some of the older events from previous months still exist while checking from Admin -> Settings -> Database -> Online data for Clickhouse deployment.This behavior is mainly observed when older events are not covered by the Retention policy.The commands below provide details about the number of retention days for the events. This information can be useful for comparing the number of retention days defined in the retention policy.Run both of the following commands on the ClickHouse Data node:   clickhouse-client -q "select distinct(toIntervalDay(retentionDays)) from fsiem.events_replicated;"   The command below provides details about the oldest and newest event dates covered by retentionDays:   clickhouse-client -q "SELECT    retentionDays,    m

DescriptionThis article describes troubleshooting steps for IPsec IKEv2 VPN connections that use SAML single sign-on with FortiGate as the service provider and FortiAuthenticator as the identity provider. It covers troubleshooting listener connectivity, HTTP 403 responses, SAML attributes, and EAP authentication failures. Optional Fortinet Single Sign-On checks are included for deployments that also collect Active Directory logon events.ScopeFortiGate running FortiOS 7.4.11, FortiAuthenticator 6.6.9, and FortiClient 7.4.7 on Windows. The reference lab also used Windows Server 2019 Active Directory and a Windows 10 domain client. Commands and menu paths refer to these versions. Hostnames, usernames, addresses, and object names below are examples.There is an available community article explaining how to setup IPsec dialup tunnel with a SAML-based authentication between FortiGate and FortiAuthenticator.SolutionSymptomsThe lab troubleshooting included the following observations:IKE_SA_INIT

I stepped away from Fortinet for a while and am coming back to find that there still seems to be no real solution to connecting the internal switch ports and external (FortiSwitch) switch ports on the same VLAN.  You'd think that once you setup FortiLink, attach a FortiSwitch, and start making FortiSwitch VLANs that those VLAN interfaces would be available to add to either a software switch or hardware (vlan) switch. It doesn't seem that is the case though... Instead, it seems the only way to share traffic between internal ports and external ports is to PHYSICALLY connect between them? Is this really the best (only?) solution:Create virtual VLAN switch with VLAN ID of zero on Fortigate.Add all the ports you are going to use as membersCreate sub-interfaces for each VLAN ID that you are using on the networkDesignate a physical port on the firewall as the trunkCreate a trunk port on the switch controller for the FortiSwitchesPhysically connect the internal (fw) switch trunk

DescriptionThe Rx Discards counter increases on the uplink ports of an access FortiSwitch when the FortiGate FortiLink interface uses fortilink-neighbor-detect fortilink. Also, how to stop the increase by changing the setting to LLDP.ScopeFortiGate and FortiSwitch units managed over FortiLink, with fortilink-neighbor-detect set to FortiLink.SolutionSymptoms:The Rx Discards counter increases steadily on the uplink ports of the access FortiSwitch. These are the ports that connect to the distribution or core FortiSwitch.The Rx Discards counter does not increase on the access (downlink) ports.The uplink ports show no CRC, input, or output errors.The Rx Discards counter stops increasing after setting fortilink-neighbor-detect to LLDP on the FortiGate.Cause:When setting fortilink-neighbor-detect to FortiLink, the FortiGate and FortiSwitch units exchange proprietary FortiLink protocol frames over the FortiLink and ISL trunks. The access FortiSwitch receives these frames on its uplink ports, h

DescriptionAfter upgrading to FortiOS 7.4.13, you may observe frequent event logs on a FortiGate High Availability (HA) cluster with log ID 0108035018.A sample log message appears as follows:date=2026-10-23 time=10:33:00 logid="0108035018" type="event" subtype="ha" level="information" vd="root" logdesc="HA secondary received CLI commands" user="FGT_ha_admin" ui="ha_daemon" msg="Received CMD from ip:169.254.0.1 vdom:vsys_ha type:1, msg_type:66"In FortiOS 7.4.13, security audit logging was added to record commands exchanged between HA cluster members across the internal heartbeat channel.Before FortiOS 7.4.13, these internal exchanges occurred silently. In FortiOS 7.4.13, each received command generates an informational event log.ScopeFortiOS 7.4.13.SolutionThese logs are purely informational. They do not cause packet loss, do not trigger failovers, and do not indicate a configuration defect.You can confirm that your cluster is healthy, or configure a log filter to exclude this message i

Description How metadata variables works in a CLI script. Scope FortiManager. Solution Metadata variables referenced inside CLI scripts in FortiManager do not resolve to a device‑specific mapped value when the script is executed on the Device Database. The script applies the value defined for the global context, or the default value if no global value is set — not the value mapped for a specific device or VDOM.   Scenario A metadata variable is created with a default value and a per‑device mapped value (e.g. mapped for a root or named VDOM). If used inside a firewall object (e.g. an Address), the variable correctly resolves to the device's mapped value. The same variable used inside a CLI script run on the Device Database resolves to the global value — or the default value when no global value exists — instead of the per‑device/VDOM mapped value. This is an expected behavior. Metadata variables used in CL

Hi,  Please, can you change my Fortinet Community Username to "FortiEng_345"?Bests,

DescriptionThe reasons why Managed FortiSwitch ports configured with the default-auto-isl LLDP profile may forward unnecessary FortiLink protocol frames (EtherType 0x88FF) to connected end devices. Devices that do not support or process these frames may discard them, resulting in rapidly increasing packet discard counters and unnecessary network traffic.ScopeFortiSwitch.SolutionFortiSwitch ports configured with the default-auto-isl LLDP profile by default.This profile supports automatic Inter-Switch Link (ISL) formation, allowing FortiSwitches to discover each other and establish inter-switch trunks.When this profile is applied to ports connected to end devices that do not require automatic ISL formation, FortiLink protocol frames with EtherType 0x88FF may reach those devices.The receiving devices may discard these frames because the EtherType is unsupported, causing unnecessary increases in packet discard counters.SolutionChange the LLDP profile on affected edge ports from default-aut

DescriptionHow to upgrade FortiNAC-F CAs in an N+1 Failover Group when the FortiNAC Manager cannot push the upgrade to the primaries.ScopeFortiNAC-F v7.6.x, FortiNAC Manager, N+1 Failover Group with more than one Primary CA. Validated on an upgrade from F 7.6.6 to F 7.6.7.SolutionSymptoms:In the Manager UI, System -> CA Management lists the N+1 Failover Group correctly: several Primary CAs with status Running and one Secondary CA with status Standby, all on the same version.In the Manager UI, System -> Settings > Updates > System > Server List shows only a Failover Group containing the Secondary CA. None of the Primary CAs appear, so they cannot be selected for Distribute or Upgrade (Upgrade Using Manager, Option 1).Logging in to the Secondary CA GUI shows only a limited set of menus.Example: 4 Primary CAs (Running) and 1 Secondary CA (Standby) on 7.6.6.0900. The Server List showed "Failover Group (1)" with only the Secondary.CauseKnown issue 1072240: the primary FortiNA

We have Fortigate FW running on FortiOS 7.4.12M and FortiAnalyzer on 7.4.11.Are these affected by the PHP2Shell remote code execution vulnerabilities ??

DescriptionA FortiWeb standby unit repeatedly leaves and rejoins the High Availability (HA) cluster due to configuration synchronization failures in the predefined bot public key list.ScopeFortiWeb.SolutionSymptomsThe standby unit in a FortiWeb HA cluster repeatedly leaves and rejoins the cluster. Event logs on the standby unit show "Config restore: successful" without administrator intervention. This behaviour causes management access, including the web GUI and serial console, to freeze or disconnect periodically.Root CauseThe issue is caused by a synchronization mismatch in the bot-public-keys predefined section. Because these entries are predefined, they cannot be manually edited, added, or deleted by the administrator. When the primary unit fails to synchronize this section with the standby unit, it initiates a forced synchronization. This forced sync triggers a configuration reload on the standby unit, which restarts all processes and modules, causing the unit to temporarily leave

DescriptionEnabling the Set HttpOnly Cookie feature in FortiWeb Cloud may cause applications to return HTTP 403 Forbidden errors if the application relies on JavaScript to read CSRF tokens from cookies.ScopeFortiAppSec Cloud.SolutionSymptomsUsers encounter HTTP 403 Forbidden (Authentication Error) responses on various application pages after a successful login. These errors occur specifically when Cookie Security features are enabled in FortiWeb Cloud. No corresponding security violations or blocks appear in the Web Application Firewall (WAF) event logs, even when the policy is set to Alert mode.Root CauseThe issue is caused by the Set HttpOnly Cookie setting. When this feature is enabled, FortiWeb Cloud adds the HttpOnly flag to cookies passed to the browser. This flag prevents client-side JavaScript from accessing the cookie.If the application is designed to read a Cross-Site Request Forgery (CSRF) token from a cookie using JavaScript, the browser cannot access the token. Consequentl