Recently active topics

Hello, good evening! I've been having VPN connection problems for a few days now. I've already tried reinstalling and configuring it, but without success. Currently, my connection is timing out and I can't access it. Could someone tell me what might be causing this? Thank you in advance. 

DescriptionFortiGate incorrectly removes the static route from the active routing table when a Prefer Passive Performance SLA goes down, even though other Performance SLAs associated with the same WAN interface remain up. As a result, traffic is no longer forwarded through that interface.ScopeFortiGate.SolutionThis behavior occurs when a Prefer Passive Performance SLA transitions to a dead state. Although other Performance SLAs linked to the same WAN interface remain operational, the route associated with the affected member is withdrawn from the active routing table.diagnose sys sdwan health-check status Health Check(Microsoft Teams): Seq(4 port1): state(alive), packet-loss(0.000%), latency(25.108), jitter(0.168), mos(4.391), custom_profile(0.000), bandwidth-up(999977), bandwidth-dw(999988), bandwidth-bi(1999965), sla_map=0x1 Seq(5 port2): state(dead), packet-loss(100.000%), sla_map=0x0 Health Check(Google): Seq(4 port1): state(alive), packet-loss(8.000%), latency(6.036), jitter(0.055

I updated the FortiGate from FortiOS 7.6.6 to 7.6.7 and am experiencing issues with SSL inspection certificates.After the update, the firewall started dropping all traffic. Even traffic matching firewall policies without SSL inspection enabled is being dropped.As a temporary workaround, you can disable SSL inspection globally to restore connectivity.Has anyone else encountered this issue after upgrading to version 7.6.7? Is there a known bug or a recommended fix?Update:Not logging dropped packetsFirewall memory usage reaching 90%Thousands of active sessions (compared to normal levels)

DescriptionThis article describes how to configure and verify the Bootstrap Router (BSR) mechanism in PIM Sparse Mode across FortiGate firewalls. It provides step-by-step guidance to elect a Candidate BSR, register a Candidate Rendezvous Point (C-RP), and dynamically distribute RP information across the network.ScopeFortiGate.SolutionTopology:Step 1: Ensure Multicast Routing and Base PIM Configuration:Enable multicast routing globally on all FortiGate units (FG1, FG2, and FG3) and activate PIM-SM on the transit and local interfaces.On FG1:config router multicast set multicast-routing enable config interface edit "port2" set pim-mode sparse-mode config igmp set version 2 end next edit "port3" set pim-mode sparse-mode config igmp set version 2 end next

DescriptionThis article describes a behaviour where FortiNAC-F stops adding entries to Users & Hosts -> Network Sessions after an upgrade to 7.6.7, in deployments that use NetFlow as a device profiling source.The appliance continues to receive and queue NetFlow packets normally, and existing session records remain visible, but no new records are created. Device Profiling rules that rely on the Network Traffic method therefore stop matching, and no error, warning or exception is written to output.master.The behavior is independent of FortiGate firewall session polling, and affects setups where NetFlow is the only configured session source as well as setups where both are enabled.ScopeFortiNAC-F 7.6.7, using NetFlow as a device profiling source (Network Traffic profiling method).Any NetFlow exporter supported by FortiNAC, including FortiGate.SolutionThe steps below confirm the behavior and separate it from the configuration faults that produce the same empty Network Sessions view.

DescriptionAn explanation of why the Microsoft Entra ID service connector fails with "Unauthorized" once the Authentication Type is set to Certificate, and how to fix it. The GUI hides Entra's actual error code; it is logged in output.master only when the connector searches Entra groups.ScopeFortiNAC-F 7.6.x with a Microsoft Entra ID service connector (Network -> Service Connectors -> Authentication Sources) set to Authentication Type = Certificate.SolutionSymptoms after switching the connector from Application Secret to CertificateToasts in the GUI: "Unauthorized Service Connection", "UNAUTHORIZED" or "There was an error processing this request".Test and Poll Now return HTTP 400. Select Groups to Import returns HTTP 500 and the group list stays empty.The same connector works with Application Secret.Two causes have been confirmed from logs:The certificate is not installed in the Remote API [remote_api] target, so Entra ID holds a different certificate from the key FortiNAC signs

I am French, I bought a MacBook in July from an individual. He told me he won it thanks to his company that gives gifts, so with an Apple care guarantee. Nothing alarming, everything seemed normal, up to a few days. It is written that the MacBook belongs to this company. With attached a proof and a code requested. I can't get anyone from the company who can contact me, to learn more and get more information.It says it belongs to Fortinet France, but I only find sites in English and no French interlocutor can anyone help?  

DescriptionA known issue where the FortiGate sends SYN/ACK packet using wrong source IP when a single SYN packet is sent to a real server without an acknowledgment or reset.ScopeFortiOS.SolutionIn this scenario, a Virtual Server is configured as follows:config firewall vip edit "http_virtual_server" set type server-load-balance set server-type tcp set extip 198.51.100.169 set extintf "any" set arp-reply disable set extport 80 config realservers edit 1 set ip 192.0.2.20 set port 80 next end next end config firewall policy edit 1 set srcintf "port1" set dstintf "any" set action accept set srcaddr "all" set dstaddr "http_virtual_server" set schedule "always" set service "HTTP" set inspection-mode proxy set logtraffic all set nat enable next endNote that the source traffic is

DescriptionAn issue where traffic is blocked because the content is flagged as malicious.ScopeFortiGate.SolutionUsers cannot load the content from Internet websites. In the FortiGate Logs, the traffic is flagged as a certificate anomaly.Error while accessing the website:To verify if a certificate is being blocked by the Malicious Certificate Database, perform the following steps:To confirm that traffic is blocked by a malicious certificate, check Security Profiles -> SSL/SSH Inspection -> Malicious Certificates -> View.Select Blocked certificates -> View Blocked Certificates to check if the certificate for the affected domain is listed.To check SSL security events via the CLI:execute log filter reset execute log filter category utm-ssl execute log displayUse the following command to view the current update version that the malicious certificate DB is running.diagnose autoupdate versions | grep -A 7 'Malicious Certificate' Malicious Certificate DB --------- Version: 1.00609

I have problem with my NAC where sometime the endpoint is loss connectivity both for wired and wifi. Previously i post error from client side here and now after i enable authentication log from FNAC then we can see for same endpoint the authentication can be success and sometime is fail.The fail message is ‘No EAP session macthing state’ View from authentication step then i got message ‘outer-method failed to authenticate Switch_IP → FNAC IP’The issue is from FNAC?

DescriptionThis article describes how to trigger a FortiGate automation stitch, such as an IP ban, from a FortiAnalyzer alert based on FortiWeb logs.ScopeFortiAnalyzer version 8.0, FortiOS version 7.6, FortiWeb version 8.0.SolutionWhen Automation Stitch is enabled on a FortiAnalyzer alert handler, FortiAnalyzer sends the notification only to the FortiGate that sent the logs that triggered the handler. For handlers based on FortiWeb logs, the alert is generated on FortiAnalyzer, but the FortiGate stitch is not triggered, and its trigger count stays at 0. The same applies to handlers based on FortiMail logs.This is expected behavior, as described in the FortiAnalyzer Administration Guide: Using the Automation Stitch for alert handlers.For alerts generated from FortiWeb or FortiMail logs, the supported method for triggering an action on a FortiGate is to use a FortiAnalyzer playbook with the FortiOS connector and a FortiGate automation stitch with an Incoming Webhook trigger.Prerequisites

DescriptionThis article describes an issue where disk logging is unavailable on a downstream FortiGate after configuring Security Fabric setup.ScopeFortiGate.SolutionBefore Security Fabric was configured, disk logging was enabled, and logs stored on the disk could be viewed under Log & Report -> Forward Traffic. From CLI:jiyong-fgvm-dmz-esxi3 (setting) # show config log disk setting set status enable end From Log & Report -> Forward Traffic: However, after Security Fabric is enabled, disk logging is no longer available on the downstream FortiGate, and the option is no longer displayed in the GUI.  After Security Fabric is enabled, the disk logging setting in the CLI is automatically changed to disabled, and the Local Logs tab related to disk logging no longer appears in the GUI. From CLI:jiyong-fgvm-dmz-esxi3 (setting) # show config log disk setting set status disable end From Log & Report -> Forward Traffic:This is expected behavior. When Security Fabric i

firewall Remote-IPsecVPN not able to get ping WAN ip,rest of the all services is okay including router IP.which is same series. 

DescriptionThis article describes how to connect the Fabric Root and downstream FortiGate devices through Security Fabric Setup.ScopeFortiGate.SolutionThe initial Security Fabric setup consists of the following steps. On the FortiGate that will serve as the Fabric Root, navigate to GUI -> Fabric Connectors -> Security Fabric Setup. Select Serve as Fabric Root, then choose a listening interface that is reachable by the downstream FortiGate.   On the downstream FortiGate that will connect to the Root FortiGate, navigate to the same menu as in Step 1. Select Join Existing Fabric, then configure the interface and IP address/FQDN used to communicate with the upstream FortiGate.  After completing the configuration, the Security Fabric will not be established immediately. The Root FortiGate must authorize the downstream FortiGate before the connection is established. On the Root FortiGate, navigate to GUI -> System -> Firmware & Registration. The downstream FortiGate that has

Hi , i have Question about Using Multiple IKEV2 Dial-up VPN with PeerID is that possible ? i note in the FortiGate_7.6_Administrator_Study_Guide-Online page 363 saying:“When you configure multiple dial-up IPsec VPNs, IKEv2 makes it simpler to match the intended gateway bypeer ID. With IKEv2, you can either use the standard peer ID attribute or the Fortinet proprietary network IDattribute to indicate the phase 1 gateway to match on the dial-up server, regardless of the authentication modein use.”while the technical tips i saw saying you can only use network id   

Hello,We're currently migrating users from EMS to FortiSASE and have run into an issue with pre-logon VPN connectivity.The customer requires a pre-logon tunnel using machine certificate authentication (PKI), allowing the endpoint to connect before the user signs in.What we observe:The endpoint initiates the pre-logon connection. FortiSASE indicates that the connection is successfully established. Shortly afterwards, the session is terminated. The FortiClient on the endpoint never shows the pre-logon tunnel as connected.We have tested multiple certificate configurations, including certificate chains with and without an intermediate CA, but the results are identical.A Fortinet PS engineer is involved and a support case has already been opened, but so far we have not found the root cause.Has anyone experienced this before or successfully deployed pre-logon PKI-based tunnels with FortiSASE?

​Description When querying processor-related SNMP OIDs on hardware FortiGate units, the returned results may show more processor entries than the number of CPU cores available on the device. This behavior can be observed on platforms where a network processor is also represented as an entry in the processor-related SNMP information. Scope This article uses the FortiGate 1801F as an example. The device has 16 CPU cores, but querying certain processor-related SNMP OIDs returns 17 entries. Example Querying fgProcessorPktTxDroppedCount.OID: 1.3.6.1.4.1.12356.101.4.4.2.1.11.Command: snmpwalk -v2c -c test <fgt_ip_address> 1.3.6.1.4.1.12356.101.4.4.2.1.11.The output contains 17 entries, indexed from .1 to .17.:iso.3.6.1.4.1.12356.101.4.4.2.1.11.1 = Counter64: 0 iso.3.6.1.4.1.12356.101.4.4.2.1.11.2 = Counter64: 0 iso.3.6.1.4.1.12356.101.4.4.2.1.11.3 = Counter64: 0 ... iso.3.6.1.4.1.12356.101.4.4.2.1.11.16 = Counter64: 0 iso.3.6.1.4.1.12356.101.4.4.2.1.11.17 = Counter64: 0 Querying fgProc

DescriptionUsers synchronized from Microsoft Entra ID are incorrectly listed as members of the local All Management Group in FortiNAC, causing them to receive administrative alarm notifications.ScopeFortiNAC 7.6.6.6083 (STS).SolutionSymptomsUsers synchronized via the Microsoft Entra ID Service Connector appear as members of the local administrative group All Management Group when using the "Show Members" option in the GUI. This occurs even if:No Admin Profile Mappings are configured.The User Group Membership for the affected user does not show membership to the ALL_MANAGEMENT Group.The users are assigned the "NAC-Default" role.As a result, these synchronized users receive alarm notifications intended for the All Management Group.Root CauseThe issue is caused by database inconsistency where synchronized users are listed under the ALL_MANAGEMENT group in the backend database despite not having an associated administrator profile. This can lead to the system treating these users as part o

DescriptionThis article describes the steps to configure Server Load Balancing Layer-7 HTTP to restrict a URL from public access.ScopeFortiADC.SolutionPrerequisite:Server Load Balance Virtual Server is using Layer-7 HTTP application profile. Steps:In the FortiADC GUI, navigate to the Content Rewriting page and create a new Content Rewriting rule:In the Content Rewriting rule page, select the Action as 'Send 403 Forbidden':Create the condition match for the Content Rewriting rule. In the example, the URL path '/restricted' will be used as the sample to be blocked from public access. Use the regular expression match for the URL path match.Regular Expression:^/restricted(/.*)?$Add another condition to allow a specific IP address to access the restricted URL. To do so, add a condition of object with Source IP Address condition with the 'Negative' option enabled, which means to invert the matching condition. The source IP that does not match the defined source IP will be returned with the 4

DescriptionThis article describes an issue where, in some FortiOS versions, the explicit proxy PAC file configured under the root VDOM may become empty after deleting another VDOM with a similar name, such as 'ro' or 'roo'.This issue has been observed on FortiOS 7.4.11 and may also affect other FortiOS versions.ScopeFortiOS v7.4, FortiOS v7.6, FortiOS v8.0.SolutionThe issue may occur after creating and deleting VDOM names similar to root.config vdom edit roo end config vdom delete roo endWhen this issue occurs:Explicit proxy clients may lose internet connectivity.PAC file download from the GUI may fail with HTTP 404.The configured PAC file data under the root VDOM is removed.The following command may show an empty PAC file configuration:config web-proxy explicit showExample output:set pac-file-data ""PAC file download from the GUI under 'Network -> Explicit Proxy' may also fail with the following error:{ "status":"error", "http_status":404 }The following httpsd debug ma

DescriptionThis article describes the issue when HA is out of sync due to Fortinet_Sub_CA_Backup.ScopeFortiGate 700G.SolutionWhen adding VDOMs in an HA cluster, HA goes out of sync due to vpn.certificate.ca.Fortinet_Sub_CA_Backup certificate is present only in the root VDOM in the secondary FortiGate. It is missing on any other VDOM.diagnose system ha checksum cluster ================== FG7H1GT000000011 ================== is_manage_primary()=1, is_root_primary()=1 checksum global: f9 26 81 5c cf 3d 91 09 a3 28 1c 24 4a 62 94 95 vdom_a: 0b a8 29 30 c2 d4 59 87 41 35 a8 40 ef 57 5f b6 vdom_b: ce 42 f0 49 e9 4d 4a c8 15 18 f4 bb e0 fd 04 c1 vdom_c: 5f 24 95 16 0e 6e cb e2 29 e6 80 77 24 56 38 d0----->> root: 23 86 b9 57 ee 71 8f 5c c7 b5 7b 87 6e 22 30 ed internet: e5 a6 a9 e9 c9 39 ad 0f e0 ae e0 d7 3a 85 46 7f all: 9a 1a f5 97 76 1d 11 15 91 d8 40 a4 68 50 e2 ce ================== FG7H1GT00000022 ================== is_manage_primary()=0, is_root_primary()=0 checksum

DescriptionThis article describes how to adjust the retention and time range of the WinRDPLogin lookup table to reduce false positive alerts for users who log in periodically.ScopeFortiSIEM v7.x+.SolutionSymptoms.The default rule 'Uncommon Windows Server Login' (PH_Rule_LT_8) uses the WinRDPLogin lookup table, which typically captures baseline logins over a rolling 24-hour window. If legitimate users log into servers occasionally (e.g., weekly or bi-weekly), this short window causes frequent false positive alerts.Root cause.The default report time range for the lookup table is too short to capture the login patterns of users who do not authenticate daily.Resolution.To extend the baseline window to 30 days, modify the lookup table import schedule.Select Resources -> Lookup Tables.Select WinRDPLogin.Select Actions -> View -> Import -> Enable the checkbox -> Schedule.In the first tab, set the Report Time Range to relative last 30 days. This ensures each execution queries lo

DescriptionTroubleshoot and resolve an issue where the FortiSIEM Linux Agent process terminates unexpectedly with a segmentation fault (SIGSEGV), causing the agent to disconnect from the manager.ScopeFortiSIEM v7.x+.SolutionSymptomsThe FortiSIEM Linux Agent disconnects randomly. System logs show the process terminating with a SIGSEGV (signal 11) error. Example log entries include:phLinuxAgent[33907]: segfault at 0 ip 00007fb2566182d0 sp 00007fb24574bb18 error 4 in libc.so.6 fortisiem-linux-agent.service: main process exited, code=killed, status=11/SEGVRoot CauseThe Linux Agent process crashes due to a segmentation fault. While the root cause of the crash may vary, the systemd service configuration may prevent the process from restarting automatically if RemainAfterExit is set to yes, leading to a persistent disconnected state.ResolutionTo ensure the FortiSIEM Linux Agent automatically restarts after a crash, modify the systemd service configuration.Open the FortiSIEM Linux Agent servic

DescriptionThis article explains why the FortiManager Cisco pxGrid connector can complete every pxGrid request successfully (HTTP 200) and still import no users, and how to fix it. It is useful when FortiManager shows no user or session information from Cisco ISE, although the connector status, certificates, and pxGrid account all look correct.ScopeFortiManager.SolutionOn the FortiManager CLI, enable the connector debug:diagnose debug reset diagnose debug application connector 255 diagnose debug enable Trigger the import by running Apply & Refresh on the pxGrid connector in the GUI, and leave the debug running for at least one minute. The connector repeats the full exchange about every 5 seconds, alternating between the configured servers.The connector debug shows a complete and successful pxGrid exchange, but the session query returns an empty list:POST /pxgrid/control/AccountActivate -> {“accountState”:”ENABLED”,”version”:”2.0"} POST /pxgrid/control/ServiceLookup {“name”:”com.

Fortigate firewall didn’t connect by remote users when using remote ipsec vpn 7.6.6 OS. But client getting all other services after created policy remote user interface to wan. Please help me if any other solution for it. I follow the below link remote access vpn for AD users through LDAP server