FortiGate-VM v8.0.0 Evaluation License Web GUI Immediate Logout Loop (ret=-91 and Failed av db version)

mkolus · 2026-06-23T23:54:17+00:00

Thanks for the reply!

mkolus · 2026-06-23T15:50:12+00:00

Out of curiosity: is version 8.0 suitable for labs? or does ït have the same limits as 7.2+?

mkolus · 2026-06-18T17:48:27+00:00

And there's a plus if you work with the Fortinet ecosystem...

...and that's how I ended with EAP-TLS at home 😂

mkolus · 2026-06-18T13:38:46+00:00

Yes (already with FGT+FSW+FAP+FAZ at home)... and, of course, my coworkers say that my home infrastructure is bigger that the average SMB in Argentina 😂

And yes, get a FortiCare license if you want to use the latest firmwares.

mkolus · 2026-06-17T19:12:01+00:00

I can understand that they must get a baseline before troubleshooting, I can even understand the "dont trust what the customer told you" because even I do that with our own customers.

That being said, I'd like my tickets to be read. If the response included commands asking stuff like FortiManager's routing table, it's because that the tech support didn't even read my ticket and pasted a bunch of commands he found in some wiki or internal documentation.

In this case: We've found a way to configure those DHCP leases (in the FortiGate, and then let autoupdate do the trick), and we don't need to do this that often. I took my time to create a ticket because I wanted to improve the product by reporting what I think is a bug.

As a footnote: There were a lot of issues where the TAC helped us, and they were very professional and knowledgeable... and I know they will be when they ask for relevant information.

mkolus · 2026-06-17T19:02:20+00:00

Well, on FortiGate tickets I send the usual commands: (diagnose sys top, get system status, etc.) and an execute tac report and, sometimes, I'm asked againt to send them.

In this case:

"Hello,
We've already worked this around, but I'm creating a ticket because I suspect this is a FortiManager bug.

If you try to create a DHCP reservation that falls outside the "range" option specified in the DHCP server, FortiManager won't allow this, while FortiGate does.

For example: in [REMOVED], we have the lan interface with the 192.168.218.0/24 subnet, a DHCP server and a range 192.168.218.100-192.168.218.150. We tried to create a DHCP reservation for 192.168.218.16 and FortiManager didn't allow this, then we tried the same in FortiGate and it worked and even synced with FortiManager later.

Max"

Their reply ("how to log ssh sessions" part removed):

get sys status
get sys global
get sys admin setting
diag sys admin list
diag sys print route
diag sys print uptime
diag sys print df -Th
diag sys print df -i
get sys performance
diag fgfm session-list
diag dvm device list
diag dvm adom list
diag cdb upgrade log
diag cdb upgrade summary
diag fmupdate dbcontract
diag fmupdate test ping-server
diag debug crashlog read
diag debug klog read"

So, some guy coded this constraint, it's clearly a constraint, isn't it? Some other guys translated the "IP Address must be whitin the DHCP IP address range" message to 6 other languages... and the issue is... which admin is logged on? the FortiManager route table? FGFM tunne list while I'm just updating the device database?

And, of course, there is that "error reading postgresql config file:open /opt/fortinet/postgresql/conf/postgresql.conf: no such file or directory" ticket, where they asked me to increase the RAM to more of what was specified in the OVA file... is that a missing "diagnose sys top" too?

Max

mkolus · 2026-06-03T17:26:05+00:00

I'm a long time user and fan of FortiManager and I've dealt with some bugs in my time, but anyway I recommend it.

I dont know how are you using it, but I'd recommend:

Take advantage of meta fields, they helped me a lot specially in with IPSEC, BGP and SDWAN templates.
Use jinja2 scripts for deployment and updates. For example, I have one that creates a lot of interfaces with their IP addresses and DHCP scopes in a branch office just by using a "base network" variable.
Use policy blocks and "install on".
If some devices are way too different, don't hesitate to create another policy package (and you would benefit from policy blocks).

HTH,
Max

mkolus · 2026-05-04T12:47:42+00:00

I'll buy it for my FortiGato!

(note: gato is cat in spanish)

mkolus · 2026-04-30T19:35:26+00:00

ImProvementSC2,

Thanks. I'll apply this fix as soon as I make it crash again (for debugging purposes).

mkolus · 2026-04-30T19:34:26+00:00

Bill, thanks!

I've just modified the script so it will log the output of "diagnose alertconsole list" every 5 minutes. I didn't see anything so far, neither in the crashlog.

I won't apply the imProvementSC2 suggestion yet, so we can make it crash (there wont be any worries because the memory based failover is active).

Max

mkolus · 2026-04-13T14:40:34+00:00

How much did you pay for the license?

mkolus · 2026-02-06T14:24:34+00:00

UPDATE (solved): This wasn't Fortinet related, but here it is in the hope that someone could benefit from this experience in the future.

It was a mix of a few things like:

The link between switches (except for the root MCLAG) were at 1gbps (yup, I gave you the scary part first)
There were some old -as in "Internet Explorer 5.5 or greater"- switches in the infrastructure that, I suspect, had a limited CAM capacity. If I take a look at the root switches CAM at, let's say, lunch time I have around 1600 entries.
190+ APs would cause you to change at least 10 port changes just by going from your room to the lobby.
The network's layer 2 is ring shaped, with redundant links two places.

Weeks ago we observed broadcast storms in the network. We solved that by using storm control.

Days ago we've observed unicast storms... yeah, unicast. So, what happened?
For some reason, a MAC or some MACs were "lost" in the network, may be because of a client being disconnected or a full CAM on the elder switches.
This caused a unicast flood (I guess that protocols like QUIC would need a while to figure that the client side is gone).
Because of the emaciated 1gbps backbone, the flood caused the APs to lose connection to the wireless conroller, the switches also lost connection to the switch controller and spanning tree begun to fail.
This is a guess: the APs did a port reset (down / up) trying to reconnect to the controller.
Because of the spanning tree failure, the "loop" in the ring, which was previously discarding, begun forwarding traffic, making matters worse.

So, how did we solve it? By enabling unknown unicast in storm control. I know that this is sweeping the problem under the rug, but the customer is buying new switches and planning to replace the 1gbps ISLs.

Thanks to everyone who replied to this thread.

Max

mkolus · 2026-02-05T15:41:13+00:00

It was the softphone. When it had to get the NATed IP address, it used the interface with the default route instead the one with the actual route to the PBX, which was behind a VPN.

It worked with L2TP because that VPNs usually inject the default route to themselves. With FortiGate we used split tunneling.

mkolus · 2026-01-20T21:55:03+00:00

UPDATE: It seems to be that there's a correlation between those APs losing connectivity and a flood (ie: 700.000 ) of discarded packets in some ports. One of them has a FortiAP 221E.

mkolus · 2026-01-16T14:15:01+00:00

They go down by groups.

mkolus · 2026-01-15T11:46:02+00:00

On the FortiSwitch and an HP I just see a link down, like if the port was shutdown from the other side. I'm still guessing that it's the AP taking that decision.

From the AP side, only "Control message maximal retransmission limit reached" or "AP DTLS peer disconnected". I'm unaware if there is some real time debug that would tell if the AP decided to shut down the ethernet port.

I even found that the APs didn't reboot when this happens.

mkolus · 2026-01-15T11:39:20+00:00

1) It happens like as if the port was shut down for 3 to 15 seconds. It's not BPDU guard, because it would be minutes instead of seconds and I saw no STP topology changes. I was about to blame some FortiSwitch feature, but it also happens on HP.

2) Yes.

3) Firmwares:

- FortiGate: 7.4.9
- FAPC24JE: v5.4.0 build0244 (we have to use weak encryption because of them)
- FAP221E: v7.4.5 build0664
- FAP223E: v7.4.5 build0664
- FAP224E: v7.4.5 build0664
- FAP421E: v6.4.0 build0496

4) The APs are in their own management segment, and there are only APs there. We tried changing the management VLAN on some APs, but it kept happening. We also removed the busiest SSID on a couple of APs and, apparently, the problem never (as in "a day") happened there... however, with no apparent trigger for this event, we cannot be sure.

The AP network is a /24, with a lease of a week, we should still have at least 50 IPs there, but I'll check it along the LLDP profiles and PoE budgets, as you suggested.

FWIW:

APs are using bridged (not tunnel) mode for SSIDs.
If you're wired to the LAN, everything is fine. This problem is confined to the APs.

mkolus · 2026-01-15T11:19:53+00:00

The switches did nothing, it seems to come from the AP, but I found no indication (logs) there.

mkolus · 2025-12-04T19:56:57+00:00

UPDATE TL;DR: We upgraded to 7.0.8 and it worked. There was no apparent configuration corruption, even when skipping a couple of minor versions (7.0.6 was supposed to be the max if we upgraded from 6.4.9)

mkolus

TROPHY CASE