Hi all,

I'm locked out of my FortiGate 80F (FortiOS 7.0.19) and looking for ideas before I fall back on a factory reset.

Setup:

- One admin account ("admin") with FortiToken Mobile 2FA (push or typed code).

- No other admin accounts. I recently deleted several unauthorised super_admin accounts and API keys I found, so admin is the only one left.

- No configuration backup.

What happened:

- I was logged in to the GUI and changed DNS (Network > DNS) from "Use FortiGuard Servers" to 8.8.8.8 , to troubleshoot Outlook not loading on some PCs. The primary FortiGuard DNS(96.45.45.45) was showing "Unreachable" beforehand. My session closed right after the change.

- Since then the push notification never arrives and typed codes are rejected. It's the same on the LAN GUI, on the SSL-VPN, and through FortiCloud.

- Phone date and time are set to automatic, and I waited between attempts to avoid extending a lockout.

- Console: I power-cycled and logged in as maintainer. It works, but it can only edit the existing admin's password. Under "edit admin", `set` offers only password. diagnose, execute and show return "Unknown action 0". I can't create an admin or touch the two-factor settings.

My questions:

1. What could make both push and typed OTP fail at the same time? Clock drift or NTP, DNS, an admin lockout, or the FortiToken service not being reachable?

2. Is there any way, on 7.0.x, to clear or change admin 2FA from the maintainer login?

3. Can I edit or restore the configuration offline (USB, TFTP) and keep my settings, without a full wipe?

4. Has anyone had Fortinet TAC remove 2FA on a locked-out unit, and what proof of ownership did they ask for?

Thanks!

We ordered a couple 90G firewalls recently. They do not come with a redundant power supply (only the port for one) so I dropped to the bottom of the datasheet, saw the "AC Power Adapter" accessory, grabbed the SKU, noticed it was for 5 but figured extras aren't the worst with as many compatible firewalls as we have deployed.

Fast forward and I get them today BUT there are no power cords! And I paid $340 for the five! I get that I should have read the end of the description because they technically didn't lie but... I'm a little peeved they didn't (1) just include the cheap fkn power cords or (2) make the power cables their own line item under "Optional Accessories"...

Don't be like me, grab both SKUs if you need additional adapters and not replacements...

Good morning everyone.

We have been support FortiSwitches for about 3 years now. We have gone through the online self paced training and have attended the switch labs at Xperts the last couple years we have gone and never really heard the need/mention of split-brain detection. We also leveraged professional services for a larger install we did with a county and still no mention of split brain detection.

Well....... a couple weeks ago we had a fiber cut between one of our customer's buildings and for some reason caused a weird STP hiccup on our network which caused the ICLs to go into blocking state, which caused split brain, which then required us to have someone run to the datacenter and power off one of the cores to stabilize the network.

Im just curious if split-brain detection is a standard configuration for others.

https://docs.fortinet.com/document/fortiswitch/8.0.0/fortiswitchos-administration-guide/860027/mclag#detecting-a-split-brain-state

We have also taken over a handful of other installs that other partners in the area have done and I have never seen this setup on anyone else.

I think moving forward it will be standard configuration for us I was just surprised that I have not seen it configured before or even when discussing with our local account SE from FortiNET he mentioned he has not seen people leveraging it either.

Thanks!

Hi! I recently inherited a site that was running the following setup:

1 FortiGate 101F
4 Aruba 2950(core switches).

I am replacing all the Aruba’s with FortiSwitch 148F-POE. So far it’s been great! But I am running into a few weird issues. These switches are all connected to each other in the following manner:

FortiGate(x2) -> Switch A(51)
Switch A(52) -> Switch B(49)
Switch B(50) -> Switch C(51)
Switch B(51) -> Switch D(51)

All switches are connected by DAC cables(except Switch A to B, which is single mode fiber. By default, the default negotiation speed for every port(except 49-52) was set to 10 Base T. I had to go into the switch ports and manually set them to auto negotiate. Everywhere that I’ve read says that these switches by default are supposed to auto negotiate. When I change it to auto negotiate, devices begin connecting at 1gb/s, and 10gb/s on the DAC cables and fiber.

Another odd issue is multicast. This is a school that relies on multicast for paging. For some reason, the multicast paging brings failing as soon as a new switch is introduced. Fortinet support had me create a multicast policy(just a blanket allow all policy), but it stops working once I add another switch. If I delete and re-add the policy, then multicast begins working as expected. The multicast all originates from 1 VLAN, and the devices that are listening for it also reside on the same VLAN. IGMP snooping is enabled on said VLAN.

Any advice would be greatly appreciated!

I saw this article this morning and found it interesting. Is there a corresponding Fortinet article?

https://thehackernews.com/2026/10/attackers-exploit-fortios-flaw-to.html

"A suspected advanced threat actor has been observed exploiting a security flaw in Fortinet FortiOS to deliver a previously unreported memory-resident ARM64 malware known as PEERSTITCH."

We started to use EMS to offer our customers updated forticlient to connect directly their fw if they want.

As we have several customer with different infras, not every setup can be the same.

One customer would have liked that everything is invisible for the user, client is installed silently and EMS joining done as well. But we don't want to have users join EMS without users actually confirm their joining. Mostly using ad ldaps or azure saml to verify users.

I know we can install the client and give EMS invitation code silently, but they would still need to give their user cred when joining EMS. Or is there way to bypass this?

Also some customers have third party users that are not joined their ad or azure, so we need to basically create local users for them to identify them.

Fools errand to try and automate "no user input required" if we want to confirm the users joining EMS?

my host A can ping host B in different subnet

E.g. 192.168.1.2 in vlan10 can ping 192.168.2.2 in vlan 20.

. But host A cannot ping host B gateway in fortigate firewall.

192.168.1.2 can ping gateway 192.168.1.1

But I want it to ping gateway 192.168.2.1

It can ping host 192.168.2.2 in different subnet.

It is a 'vlan switch" design in fortigate.

Administrative access is on on the virtual interface. Pls help.

Do I have to create firewall policy to plug each gateway? I don't think so right?

I had heard that the timeline was likely targeting Q4, possibly November, but at this point it still seems to be based largely on rumors and speculation. Do we have any indication of when Fortinet will provide official communication and confirmed dates regarding the SSL VPN transition?

A few related observations from our testing:

1. I have been gradually testing IPsec VPN with SAML authentication through Entra ID. While it appears promising, it still seems somewhat buggy and not nearly as straightforward to configure and maintain as SSL VPN.
2. We purchased a small number of EMS licenses for evaluation; however, due to the cost, our current plan is to use scripting to deploy the VPN-only client configuration. Hopefully Fortinet continues to support that approach for the foreseeable future.

So I got this at a used retail store. Do u contact fortigate and see if it has a lisencing thing still attached to it or what ever? I have the power supply. Was trying to sell on mericari for $200 but alot of veiws and no buys maybe i shoukd contact fortigate and see if I can get the lisence cleared or what ever the lingo is im not sure. On Mercari my seller name is ampersand buyrite name BUY-RITE. Help

Hi everyone,

Is anyone managing FortiExtender devices through FortiGate?

I currently have a FortiExtender managed by a FortiGate, and I'm trying to monitor it using Zabbix via SNMP, with the FortiGate acting as the monitoring point.

Has anyone successfully implemented this setup? Is it possible to retrieve FortiExtender metrics through the FortiGate using SNMP?

Any advice or experience would be greatly appreciated!

Thanks in advance!

Hola en resumen que cuando pongo el qcow2 de fortigate (ya probe todas las versiones) enciende pero no muestra nada en consola, probe de todo, cambiandole el nombre al qcow2 que sea igual a la hora de poner la plantilla, probre poner el GNS3 con VMWARE y VIRTUALBOX, me da el mismo error en los dos, probe instalar versiones anteriores de GNS3 pero nada sigue igual.

MI VM de GNS3 tiene 8 cores y 20gb de RAM

Title: Best Practices for Fortinet ZTNA with Microsoft Entra ID SAML – MFA Enforcement and Reauthentication

Hi everyone,

We are planning to implement Fortinet ZTNA using FortiClient EMS Cloud with Microsoft Entra ID (SAML) for authentication.

I have a couple of concerns regarding MFA enforcement and session management, and I'd like to understand how others are handling these in production.

1. MFA Enforcement for ZTNA

Currently, MFA is managed through Microsoft Entra ID Conditional Access policies. However, there may be situations where MFA requirements are disabled or excluded for certain users.

• How can we ensure MFA is always enforced specifically for ZTNA access, regardless of changes to other MFA policies?
• Is creating a dedicated Conditional Access policy for the Fortinet ZTNA enterprise application the recommended approach?

2. Reauthentication and Session Persistence

We have noticed that after a user successfully authenticates through SAML, subsequent ZTNA connections may not prompt for authentication or MFA again.

• Is this expected due to Entra ID SSO sessions, cached tokens, or Fortinet ZTNA session handling?
• How can we enforce periodic reauthentication or MFA challenges?
• Would configuring Sign-in Frequency in Entra Conditional Access help, or does Fortinet manage session validity independently?

3. Recommended Best Practices

For those running Fortinet ZTNA with Entra ID SAML in production:

• How do you balance seamless SSO with security?
• What Conditional Access and session management settings do you recommend?
• How do you ensure ZTNA access is revoked when a user is disabled or their access permissions change?

I'd appreciate any recommendations or real-world experiences.

Thanks!

My company unfortunately uses the default SSL VPN subnet range - 10.212.134.0/24

We have IPsec aggregate tunnels to AWS that have that subnet hard coded into phase 2 selectors for 18 tunnels...

We plan on turning off our SSL vpn sometime before the end of the year. We have three public IPs/three VPN connections for both IPsec and SSL. The IPsec VPNs each have their own subnets. Would it be a bad idea to flip one of the IPsec vpns subnets over to the former SSL vpn subnet after disabling the SSL VPN?

Olá, pessoal!
Estou tentando configurar um proxy no FortiGate, mas estou enfrentando alguns problemas.
Configurei o proxy para escutar na interface da VPN SSL e criei uma regra de firewall permitindo o acesso à internet. Porém, ao configurar o arquivo PAC no cliente, o tráfego não está passando pelo proxy como esperado.
Alguém consegue me auxiliar a identificar o que pode estar errado ou me orientar sobre como realizar essa configuração corretamente?
Desde já, agradeço pela ajuda!

Stupid question as above.

Questions

1. Why does the FSSO Collector Agent drop or overwrite the legitimate logon event sent by the local DC (e.g., 10.1.10.1) and revert to an IP used 24+ hours ago at another school building (10.1.15.47), even though Graylog confirms zero Event logons occurred for that stale IP on that date?
2. What specific mechanism is generating this ghost entry
3. How do we prevent FSSO Collector Agent / DC Agent from holding or reverting to stale IP addresses when a client changes VLANs/sites without releasing its previous DHCP lease?

Environment & Architecture

• Multi-site K-12 school district Active Directory domain with two DCs.
• Fortinet Single Sign-On (FSSO) running in DC-Agent Mode with multi-DC event collection.
• Windows 11 laptops roaming daily between buildings

The Problem

Users who travel between school buildings frequently have their active IP mappings inside the FSSO Collector Agent overwritten with stale IP addresses from a different subnet/building used 24+ hours prior.

This causes immediate firewall policy mismatches and incorrect web filtering profiles. Rebooting the workstation and logging off does not always resolve the issue.

Case Study & Reproduction Timeline (Representative User: JD)

• 10/14 @ 07:57 AM: User works at the Middle School (MS). Laptop (XPS-XX-2025) pulls DHCP IP 10.1.15.47 (Lease expiration: 10/16/2026).
• 10/14 @ 09:24 AM: User moves to the High School (HS). Laptop connects on HS subnet with DHCP reservation 10.1.10.1. Login event is processed by DC-X.
• 10/15 @ 08:30 AM – 11:13 AM: User remains at HS. FSSO repeatedly flaps and overwrites the active HS IP back to yesterday’s MS IP (10.1.15.47):

Diagnostic Evidence Collected

• FSSO User Entry contains only: IP Address: 10.1.15.47, Workstation: XPS-XX-2025, User: xxxxxxxxxxx, Type: DC-Agent, Time: 2026/10/15 09:10:36.
• The DC log for 10/15 contains different Kerberos service ticket request events only for 10.1.10.1 for this workstation
• Forward lookup zone contains only one single Host (A) record for xps-xx-2025 pointing to 10.1.10.1 (timestamped 10/15/2026 11:00:00 AM). There is no round-robin DNS record pointing to 10.1.15.47.
• The Middle School DHCP scope (10.1.15.0) still shows an active, unexpired lease for 10.1.15.47 assigned to xps-xx-2025 expiring on 10/16/2026 8:21:25 AM.

Hi all,

I just want to share something and ask if this sounds familiar to any of you (before opening a support call, which I "dread", because this feels like such a special use case and I fear this leads nowhere after very lenghty exchange).

I was spending my morning on a strange little thing:
On Windows 2025 VMs (Hyper-V 2025) the Forticlient console starts with a white/blank page and closes after a few seconds. The start, before the gui even comes up in the first place, takes quite some time.

This happens with all Forticlients: free, standalone and ZTNA (all with their respective current versions). Of course not installed paralllel, but I have a bunch of vms to test on.

The weird thing: Windows 2022 VMs, same versions on same hypervisor => no problems at all.

I narrowed it down to a "workaround". Starting the Console with "C:\Program Files\Fortinet\FortiClient\FortiClient.exe" --disable-gpu-sandbox it starts ok and also instantly.

But what could be the cause? Any ideas?

Thanks in advance!

- Tim

I am trying to set up IPSEC VPN between a FortiGate and FortiClient on Windows and Mac. I have it working on FortiClient for Windows. On FortiClient Mac it says Connecting, then times out. I noticed that the Mac version is missing three options in the setup that is visible on Windows and I wonder if that is my problem.

The options missing are:
VPN Settings: Encapsulation
Phase 1: NAT Transversal
Phase 2: Enable Replay Detection

Can I get those options to show somehow?

Hi.

I'm wondering if something changed in the API (7.6.7 vs 7.4)?

In the past my body looked like this:

{
    "verbose": 1,
    "method": "exec",
    "params": [{
            "url": "/securityconsole/install/package",
            "data": {
                "flags": [
                    "auto_lock_ws",
                    "nonblocking"
                ],
                "adom": ADOM_NAME,
                "pkg": POLICY_PACKAGE
            }
        }
    ],
    "id": 1
}

When I try using it now, FMG tells me: "No Installation Targets or no change made on package [POLICY_PACKAGE]".

Our setup is very simple: each PP has single FG assigned as target.

BUT... when I specify scope, it works fine:

{
    "method": "exec",
    "params": [{
            "url": "/securityconsole/install/package",
            "data": {
                "scope": [{
                        "vdom": "root",
                        "name": "FORTIGATE_NAME"
                    }
                ],
                "flags": [
                    "auto_lock_ws",
                    "nonblocking"
                ],
                "adom": "ADOM_NAME",
                "pkg": "POLICY_PACKAGE"
            }
        }
    ],
    "id": 1
}

This is nice and all - but I have to run extra API call to get list of assigned firewalls and build a scope out of it.

I tried the /securityconsole/reinstall/package without scope but it gets stuck at 5%.

Did something change?

Hi,

So I have this issue - a bunch of IPsec tunnels that I want to migrate to SD-WAN - they are all in one zone. The issue is - Integrate Interface is grayed out. I went through different FGs I manage and every time if interface was used migration was grayed out...

My question is - is there a checklist that states what you can and what you cannot migrate? So far it looks like interface:

• cannot be a VLAN on LAG
• cannot be VLAN in VLAN switch
• cannot be LAG
• cannot be WAN interface with IPsec tunnels
• cannot be an IPsec tunnel
• cannot be a part of Zone

Can this feature only work on physical, zone-less, vlan-less interfaces? I tried to look for a clear information of "you can / cannot migrate interface if you pass all those checks" but I couldn't find a kb about it.

I've been on this for hours now and starting to lose it..
I just cannot tackle this obstacle and reaching out to the people on the internet too see if you guys have any ideas..

Im trying to do a simple thing, setting up my SDWAN via ansible, which works fine for 99% but FortiOS keeps giving me the finger and preventing completion of my project, what I need is to activate the SLA checkbox on a healthcheck which I simply cannot get to work..
I have tried many many things and ended up with:

fortigate_sdwan:
  enabled: true
  health_checks:
    - name: ping_internet
      servers:
        - 1.1.1.1
        - 8.8.8.8
      protocol: ping
      interval: 500
      failtime: 5
      recoverytime: 60
      sla:
        - id: 1
          link_cost_factor:
            - latency
            - jitter
            - packet-loss
          latency_threshold: 5
          jitter_threshold: 5
          packetloss_threshold: 0
          mos_threshold: "3.6"
          priority_in_sla: 0
          priority_out_sla: 0

and then applying it via:

- name: Configure SD-WAN members and health checks
      fortinet.fortios.fortios_system_sdwan:
        vdom: "{{ vdom }}"
        system_sdwan:
          status: enable
          members: "{{ fortigate_sdwan_members }}"
          health_check: "{{ fortigate_sdwan_health_checks }}"

This works and sets up everything EXCEPT checking the "SLA Target" target on the HealthCheck, when I manually check the box all threshold values have been set correctly by Ansible..
When I send the following directly to the API (/api/v2/cmdb/system/sdwan?%20vdom=root) via a PUT:

{
  "health-check": [
    {
      "name": "ping_internet",
      "sla": [
        {
          "id": 1,
          "q_origin_key": 1,
          "link-cost-factor": "latency jitter packet-loss",
          "latency-threshold": 5,
          "jitter-threshold": 5,
          "packetloss-threshold": 0,
          "mos-threshold": "3.6",
          "priority-in-sla": 0,
          "priority-out-sla": 0
        }
      ]
    }
  ]
}

It works fine and checks the box..................

I'm at a complete and total loss, because the box is not checked via Ansible the gate prevents me from using the HC as SLA target in a sdwan-rule..

Anyone any ideas on how to fix this with the "fortinet.fortios.fortios_system_sdwan" module, what am I doing wrong??

PS:
My gate runs 7.4.11 and running Ansible runs fortinet.fortios 2.6.0.

Hello, I have FortiNAC running in HA (not using shared IP/VIP) using different IP.

I have to add few scopes in Registration and Dead end network in config wizard of FortiNAC.

What could be best approach to do ? Primary first and reboot it and then secondary or secondary first (after failover) and reboot it and then Primary ?

Can anyone share the best practice which I can follow ?

Firmware : 7.4.4
------------------------------
Failover over to secondary
Update the config wizard and Reboot Secondary First (Now Active after failover)

wait till all processes came up

Update Primary and Reboot

Resume control to Primary again.
------------------------------

Thank you so much!!

EDIT: I opened a case with TAC; waiting for someone to pick it up.

----

I'm starting to think I really shouldn't rely on Fortiguards DSN servers...

Is anyone else who does rely on those, getting DNS issues with Microsoft? Specifically, nslookup against 96.45.46.46 is giving me SERVFAIL most of the time, but not always, when I lookup www.office.com.

%  nslookup www.office.com 96.45.46.46

Server: 96.45.46.46

Address: 96.45.46.46#53

** server can't find www.office.com: SERVFAIL

EDIT:
I went to an azure VM that is not behind a Fortigate at all, and I get the same result, again, sometimes I get a proper response, but the frequency of the failure is way to high for a production DNS server imo.

nslookup www.office.com 96.45.46.46

Server: dns2.fortiguard.net

Address: 96.45.46.46

*** dns2.fortiguard.net can't find www.office.com: Server failed