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."

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.

Stupid question as above.

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...

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?

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 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!

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!

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 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!

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!

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!

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?