Recently active topics

DescriptionAn explanation of how setting WAD affinity works in FortiGate. By default, FortiGate spreads the WAD processes across all CPU cores. With the usage of the set wad-affinity these processes can be restricted to run on specific CPU cores.ScopeFortiGate.SolutionThis setting is available under config system global and required a hex number to select all the wanted CPU cores. So for example a hex number of 0x3 would correspond to the first two CPU cores. All other cores would therefore be ineligible to be used by the WAD process.This configuration change also requires a reboot of the device.config system global set wad-affinity <HEX_BITMASK> endWhat is important to understand is that this restriction will be placed on all wad sub-processes and not only wad workers. This may cause high CPU usage since all work will be done by fewer CPU cores. For a detailed description of wad-sub processes refer to this article Overview of wad process structure.Example: With diagnose test

DescriptionOn FortiGate models with a built-in 3G/4G LTE modem, the WWAN physical interface on a FortiGate 40F 4G does not receive an IP address from the provider, resulting in a loss of connectivity.This article explains how to restore the LTE connection by forcing modem to use IPv4 as the Packet Data Protocol (PDP) type.ScopeFortiGate 3G/4G models.SolutionFortiGate 3G/4G devices may experience an unexpected loss of LTE connectivity. During the issue, the LTE connection becomes unavailable, and the 3G/4G indicator LEDs turn off while the service (SVC) indicator remains on. The WWAN interface may continue to appear in the configuration with DHCP enabled, but its IP address and netmask are displayed as 0.0.0.0. The issue may persist even when the SIM card is functional and provides mobile connectivity when tested in another device.Run the following command to query "api.ipify.org" over HTTPS and retrieve the firewall's public WAN IP address.diagnose sys waninfo ipifyIf no WAN IP resolve

DescriptionFortiGate-50G-5G units equipped with an integrated cellular modem can experience severe intermittent packet loss over the WWAN interface despite reporting excellent LTE signal strength and maintaining an active connected state. When this occurs, user traffic and ICMP pings sourced from the WWAN interface suffer high packet loss, even though interface error counters show zero discards and the modem remains connected.This behavior occurs when the modem network type is configured for simultaneous 4G and 5G operation in an area where the mobile operator does not provide active 5G Standalone (SA) or 5G Non-Standalone (NSA) E-UTRA-NR Dual Connectivity (EN-DC). As a result, the modem repeatedly initiates radio renegotiation attempts for secondary carrier aggregation, causing momentary data transmission pauses. You can resolve this issue by locking the modem network mode to 4G and enabling automatic carrier profile negotiation (auto-gcf).ScopeFortiGate-50G-5G, WWAN.SolutionOn a Fort

DescriptionOn FortiGate ZTNA Access Proxies configured with TCP forwarding and SAML authentication, client authentication attempts can fail with Error 021: Application not found (HTTP 403 Forbidden). This error occurs when the client browser reaches the FortiGate Assertion Consumer Service (ACS) endpoint (/remote/saml/login/), but the Web Access Daemon (WAD) proxy engine fails to route the request to the internal SAML service provider gateway.This behavior occurs because FortiOS dynamically registers the implicit SAML Service Provider virtual host only when the SAML Service Provider endpoints are configured with a Fully Qualified Domain Name (FQDN). When a literal IP address is used in the SAML single-sign-on-url, or when the SAML hostname collides with an existing reverse-proxy virtual host, WAD drops the request with a "No matched gwy" condition. You can resolve this issue by assigning a dedicated public FQDN to the SAML Service Provider configuration.ScopeFortiGate, ZTNA, SAML.Solut

What is the latest recommended and stable FortiOS version for our FortiGate 60F?What is the recommended upgrade path, and could you please provide the step-by-step procedure for upgrading the FortiGate firewall from its current version to the recommended stable version?

DescriptionAn issue where users experience loss of DHCP reservation configuration after revoking a leased IP.ScopeFortiGate.SolutionAfter a DHCP reservation using MAC address, the configuration is added to the configuration.On the GUI menu at the left side of the page, navigate to Dashboard -> DHCP Monitor (if it is not present, it means you need to add a monitor).You can see the leased IP and the reserved status under the "Reserved" column. The value can be "Reserved" or "Not Reserved".If you revoke a "Not reserved" leased IP, there is no change on the configuration.However, if you select and revoke a reserved leased IP, you will get a popup warning stating that the reservation DHCP lease will be deleted.You can validate on the interface that the reservation was deleted.

I need to know how to configure the policy to provide email access with an attachment filter in FortiMail.

DescriptionLearn the limitations of restricting SHA1 as a signature algorithm during a TLS 1.2 handshake.ScopeFortiGate.SolutionThe FortiGate terminates TLS on an HTTPS server-load-balance Virtual Server using SSL full mode.Despite restricting the cipher suites, the FortiGate still accepts SHA1 as a signature algorithm during a TLS 1.2 handshake.This is specifically related to the TLS 1.2 ServerKeyExchange signature algorithm.To restrict the cipher suites, see Remove cipher suites which are shown as weak.ServerKeyExchange -- The server sends the client a server key exchange message if the public key information from the Certificate is not sufficient for key exchange.SolutionCurrently there is no way to disable rsa_pkcs1_sha1 or SHA1 as a TLS 1.2 signature algorithm for a HTTPS Virtual Server while keeping TLS 1.2 enabled.A New Feature Request (NFR) must be raised.Related articleUnderstanding the cipher suite 1.2 supported by Fortinet devices

Hello Team,Our FortiClient EMS uses a manually uploaded Let’s Encrypt server certificate containing two DNS SANs.Certificate renewal is already automated through our Salt master. After each renewal, we currently download the certificate and manually upload and apply it in EMS.We want to automate only the certificate deployment and activation steps while keeping certificate renewal managed by Salt. Or happy explore option auto renwal in EMS with two DNS SANs.Please provide the supported API or CLI procedure for importing the renewed certificate, matching private key, and intermediate chain, and assigning it to the applicable Web server and Endpoint control services.Please also confirm the required authentication and permissions, any service restart requirements, and whether this operation can run unattended on our EMS version. Thanks,

DescriptionThis article describes why changes to the FortiGuard Anycast settings may appear in the FortiGate system event logs under the FortiManagement Cloud user and explains why this is expected behavior.ScopeFortiGate.SolutionAs seen in the event logs below, it is observed that the FortiGuard anycast setting is disabled and then re-enabled.date=2026-10-08 time=00:16:50 eventtime=1791342952XXXX89120 tz="-0300" logid="010XXXXXX6" type="event" subtype="system" level="information" vd="root" logdesc="Attribute configured" user="FortiGateCloud" ui="fgfm_tunnel" action="Edit" cfgtid=25XXXXX7 cfgpath="system.fortiguard" cfgattr="fortiguard-anycast[disable->enable]" msg="Edit system.fortiguard " date=2026-10-08 time=00:16:48 eventtime=17913429509XXXX60 tz="-0300" logid="010XXXXXX6" type="event" subtype="system" level="information" vd="root" logdesc="Attribute configured" user="FortiGateCloud" ui="fgfm_tunnel" action="Edit" cfgtid=25XXXXX6 cfgpath="system.fortiguard" cfgattr="fortiguard-

DescriptionA fix for the installation issue with multiple "firewall service custom" objects that may occur after an ADOM upgrade.Post vdom failed: error firewall service custom protocol- TCP_UDP_20101 TCP/UDP/SCTP:-999 - invalid value - prop[protocol]: option(TCP/UDP/SCTP) Copy objects for vdom Main_VDOM "firewall ssl-ssh-profile", "certificate-inspection", id=18459, SKIP - (null) "firewall ssl-ssh-profile", "deep-inspection", id=18474, SKIP - (null)ScopeFortiManager.SolutionWhen upgrading from FortiOS 7.4 to 7.6, the default protocol changes from TCP/UDP/SCTP to TCP/UDP/UDP-Lite/SCTP. To match this logic, a 7.6 ADOM should be used in FortiManager.However, it might appear that after upgrading the ADOM, "firewall service custom" objects fail to be installed.When drilling down to the object, it can be observed that the UUID of the object is set to ZERO, which is causing the issue during the installation:To resolve this problem and generate a correct UUID, it is possible to add the commen

DescriptionA method to block Google AI Mode outright using the "udm=50" web filter method described in Technical Tip: Blocking Google Search AI mode via Web Filter or Application Control profile. The method is all-or-nothing. To keep AI Mode available and block only uploads, create a Static URL filter as below.ScopeFortiGate.SolutionStep 1: Create Firewall Policy:Navigate to Policy & Objects and select "Create New".Make sure inspection Mode is set to proxy-based and SSL inspection is set to deep-inspection.Note: Refer to this article to install a certificate into end-user system: Technical Tip: How to enable deep inspection and import a certificate in the browser.Step 2: Applying the Static URL filter Inside Web Filter to the Firewall Policy:Navigate to Security Profiles -> Web Filter and select "Create New".Inside the Web Filter Profile, Enable the "URL Filter option" under "Static URL Filter" and configure the below:Note: The URL "lensfrontend-pa.clients6.google.com" was obtai

DescriptionThe revised security workflow and operational mechanics for handling managed device credentials and reclaiming FGFM communication tunnels, starting with versions 7.6.7 and 8.0.0. ScopeFortiManager.SolutionHistorically, administrator credentials supplied during the initial onboarding phase stayed permanently stored within the FortiManager. These FortiGate credentials are only required during the initial connection, and as a security enhancement, it was decided to remove them from the internal FortiManager DB.Beginning with FortiManager 7.6.7, the platform implements an automated pruning mechanism.As soon as the FGFM channel is successfully established and the central management system's serial number is successfully registered on the managed firewall, the platform purges the administrator password from its internal storage repository.This behavior eliminates the continuous retention of node-level credentials on the central management server, significantly narrowing the securi

Hi Team,We plan to deploy a FortiPortal Scalable Cluster with two nodes in one DC and one node in the other. If the DC with the two nodes goes down, the single node can operate independently per the configuration:config system ha set min_nodes 1endWhat will happen when the two-node DC is brought up? Will it be enough to change the single configuration to a scalable cluster? Will the changes made on the single node during the outage be replicated to the other nodes?

Good morning teams 😊;For FortiClient EMS Trial, I created an IPsec VPN tunnel.However, I cannot export the XML configuration file with the VPN password included.Is there a way to export the VPN XML configuration with a password?What I would like is that when the user imports the XML configuration file (with forticlient) , they are required to enter a password before they can access the VPN.thanks for you support 😊

DescriptionThis article describes the behavior when adding a second health check server while the first server is dead to one of the SD-WAN interfaces.ScopeFortiGate.SolutionIn the scenario of SD-WAN health check with two servers and two members, one of the configured servers is unreachable through one member and the expectation is that SLA should be shown as up. Two SD-WAN interfaces configured as below:config members edit 1 set interface "port1" set gateway 10.47.15.254 next edit 2 set interface "port2" set gateway 10.200.4.79 next endSet up the health check server that is not accessible from port1:config health-check edit "test" set server "10.200.4.79" set members 1 2 next endFrom the output below, port1 is marked as dead:diagnose sys sdwan health-check Health Check(test): Seq(1 port1): state(dead), packet-loss(100.000%) sla_map=0x0 Seq(2 port2): state(alive), packet-loss(0.000%) latency(0.248), jitter(0.029), mos(4.404), bandwidth-up(9999999), bandwidth-dw(9999999), bandwidth-bi

DescriptionDNS filtering fails to inspect DNS over TLS (DoT)and DNS over HTTPS version 2 (DoH2) queries in certain FortiOS versions like 7.6.4 and 7.6.7, leading to bypassed filtering or connection errors in flow mode.ScopeFortiGate.SolutionThe issue occurs because the IPS engine does not recognize port 853 for decoding, causing it to skip the DNS dissector.Workaround:Run the following commands to add port 853 to the IPS decoder port list:config ips decoder "dns_decoder" config parameter "port_list" set value "53,853" end endRestart the IPS engine to apply the changes:diagnose test application ipsmonitor 99Sample result that shows it working, as the default block IP address of 208.91.112.55 is returned over TLS:dig @p2.freedns.controld.com +tls +all http://www.nab.com.au ; <<>> DiG 9.17.12 <<>> @p2.freedns.controld.com +tls +all http://www.nab.com.au ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QU

DescriptionThis article describes an issue where the FortiVoice license is not updated due to an invalid FCPR object.Scope FortiVoice 50E version 7.4.x.SolutionThe admin will observe that the license is not being updated in FortiVoice after a manual update.Collecting the update debug shows:diagnose debug application updated -1 diagnose debug enableThe updated daemon connects to the FDS server 12.34.97.16:443 successfully (SSL certificate verification passes), but receives an 'invalid setup rsp' and 'Error unpacking FCPR object' during both Setup and Update phases. The license does not update.08.31-16:51:07 updated(207): upd_comm.c:__upd_peer_vfy[348]-Server certificate OK. 08.31-16:51:07 updated(207): upd_pkg.c:pack_obj[211]-Packing obj=Protocol=3.0|Command=Setup|Firmware=FO-50E-FW-7.4-691|SerialNumber=FO50E65G111129|Connection=Internet|Address=172.16.3.30:9443|Language=en|TimeZone=-6|UpdateMethod=0|Features=Gateway 08.31-16:51:08 updated(207): upd_pkg.c:get_fcpr_response[302]-Error

DescriptionThis article describes how to deal with error daemon does not response in a non-root vdom when command diagnose sys link-monitor is executed.ScopeFortiProxy version 7.6.x.SolutionAdmin has a link-monitor configured in a non-root vdom.FortiProxy(vdp-pro) # show system link-monitor config system link-monitor edit "gw_test" set server "10.5.191.254" set update-cascade-interface disable set update-static-route disable set update-policy-route disable next endThe monitored IP answers to a ping test.FortiProxy(vdp-pro) # execute ping 10.5.191.254 PING 10.5.191.254 (10.5.191.254): 56 data bytes 64 bytes from 10.5.191.254: icmp_seq=0 ttl=255 time=0.1 ms 64 bytes from 10.5.191.254: icmp_seq=1 ttl=255 time=0.0 ms However when the admin runs a command to verify the link-monitor, the error daemon does not response is received.FortiProxy(vdp-pro) # diagnose sys link-monitor status daemon does not response, please try later. errno: 11To solve the issue, the FortiProxy needs to

im having an issue with our FortiClient IPsec VPN randomly disconnecting users. we are running a FortiGate 60F, using IKEv1 with xAuth.The VPN connects and works fine, but sometimes it disconnects after just 4-6 minutes, while other times it stays connected for hours. I've tested this on different Windows laptops with FortiClient VPN-only 7.0.8 and 7.2.14, and both versions have experienced the issue.I've spent quite a bit of time checking the logs and running IKE debug on the FortiGate, during one of the disconnects, I noticed these messagesrecv IPsec SA delete, spi count 1recv ISAKMP SA deleteFrom what I understand, this means the client itself is requesting the disconnect, but I cant figure out why. There was no DPD failure, and Windows didnt report any Wi-Fi disconnection at that timeHas anyone experienced something similar? Is there anything else worth checking or changing in the current IKEv1 setup? I'm also considering switching to IKEv2, but Id rather understand whats causing t

Hello, I would like to use my 300D as some kind of ipsec concentrator.It will be used for a lot of dialup connections. Every connection is authorised by configured radius server. Till now everything is ok and configurated (phase 2 is established). Next thing is to assign ip taken from radius, which is connected to customer's mac address in radius database.Unfortunatelly i have no idea how to configure it. If i change anything phase 2 is falling down. May i ask you to give me advice how to move it forward please? It is my first post here, i couldn't find such problem using search mode :)

FortiGate-VM64-HV Trial Issue on Hyper-VPlatform:- Hyper-V (Server 2019) Gen 1 virtual machine- FortiGate-VM64-HV v8.0.1 build0245 (GA.F)- Trial LicenseIssue:The trial license activation completed successfully and the CLI shows "License Status: Valid". However, after logging into the web GUI, I logged out immediately.CLI access works normally.Network Connectivity:- Can ping 8.8.8.8 successfully- Default route configured via 192.168.1.254 on port1Relevant Output:FGT-VM64-HV-NZVQOU # get system statusVersion: FortiGate-VM64-HV v8.0.1 build0245 (GA.F)First GA patch build date: 260421Current Security Level: HighFirmware Signature: certifiedLicense Status: ValidVM Resources: 1 CPU/1 allowed, 1694 MB RAM/2048 MB allowedHostname: FGT-VM64-HV-NZVQOUOperation Mode: NATCurrent virtual domain: rootMax number of virtual domains: 10Virtual domains status: 1 in NAT mode, 0 in TP modeCurrent HA mode: standaloneBranch point: 0245Release Version Information: GAFortiOS x86-64: YesRouting Table:S* 0.0.0.

Is there any way I can create a rule to detect missing logs for an application/event type? Since I have two different applications running on the same server and both use CEF format to send logs to FortiSIEM, in this way, the "PH_DEV_MON_LOG_DEVICE_DELAY_HIGH" can't be used since it detects the log source device missing logs. How should I create the rule to detect such a scenario?

Hi everyone,I manage like 30 fortigate devices and I updated them to 7.2.13 when it was released.Since I got users complaining about slow SMB traffic inside IPSEC tunnel s2s. The users are all behind this 101E model and they are thé only ones to complain.Bandwidth is like 300KB/s during transfer in 7.2.13I tried to check ipsec config (encrypt. algo.) Changed and adjust MTU but the traffic is still slow...Since the users told me it started since last update I tried to rollback to 7.2.12. same issue. I remember that I updated 7.2.12 and 7.2.13 a week after. So I checked to rollback to 7.2.11 and now speed is back to normal like it was before 8MB/s.I'll open a ticket but it seems linked to this model. Anyone has the same behaviour ?

we are using forticlient v7.4.7, today our users brought down their latest updates. Our VPN users are coming back down the VPN tunnel to download their updates, this maxed out our 1GB line. We have Windows updates set in the forticlient to go direct instead of using the tunnel. We also have the .exe and microsoft domain set to got direct. We are still seeing all this traffic coming down the VPN tunnel and then using our web filtering policies on the Fortigate to go out. Can anyone help with this?