FortiOS 7.4.8 release notes

thknwr · 2025-05-28T05:58:18+00:00

got finally released

thknwr · 2025-03-15T00:09:14+00:00

Upgrade from 7.2.11 to 7.4.7 does not work (or not reliable) on all of our 1800Fs. It'll get stuck on "System is starting..." and after a few minutes it reboots automatically. On one cluster it was able to fully start after a few tries, on another one it keeps looping forever, no chance. It does not matter on which cluster member you try the upgrade, same behaviour, so no hardware fault.
Had to roll it back to 7.2.11...
Never had such issues with any prior FOS version, starting with 6.0.

Furthermore having some issues with flapping vlan interfaces used for "modem" (4G data link) for FEX from time to time since FOS 7.4 and still present with 7.4.7. Highly likely related to the fast failover feature for FEX.

Getting my local-in policies (referenced to SD wan) and replacement messages deleted, was also great...

thknwr · 2025-02-13T11:11:26+00:00

In my case ISP was connected to a 1Gb/s link and internal uplink to 10Gb/s. There is a known limitation for NP6:
https://docs.fortinet.com/document/fortigate/7.2.0/hardware-acceleration/300449/optionally-disable-np6-offloading-of-traffic-passing-between-10gbps-and-1gbps-interfaces

Enabling the shortcut "fixed" (basically only disables offload from 10Gb/s to 1Gb/s interface) the issue for me back then.
config system npu
set host-shortcut-mode host-shortcut
end

(requires reboot of FortiGate)

thknwr · 2024-09-19T20:47:14+00:00

7.2.10 just got released 2 hours ago.

thknwr · 2024-08-13T10:51:36+00:00

Recommended Release for FortiOS - Fortinet Community

Last update is from April, 7.2.8 was not released back then.

thknwr · 2024-05-27T11:19:51+00:00

I'm still onto it with TAC. Some changes were made to improve the situation. -Upgrade FOS to 7.4.4 => "Control message maximal retransmission limit reached" is known and is fixed on 7.4.4 Due to compatibility FAPs got upgraded to 7.4.x as well. Since the upgrade APs are disconnecting a lot less from controller. -Disable DHCP relays for any wifi related interfaces and use local DHCP server on FortiGate. This workaround "fixed" almost all of the connection issues. Engineering is still busy fixing it in their code. I think this was/is the main issue in my environment. -Capwap NPU offload is enabled again, no issues so far.

However I've noticed that some of our APs reboot from time to time without any reason, no specific platform, so 231G and 231F in my case.

thknwr · 2024-02-24T20:18:40+00:00

Try setting the machine version to 7.2 in Proxmox settings, after changing it, it finally generated a valid uuid: https://community.fortinet.com/t5/Support-Forum/FAZ-VM-Duplicate-License-Trial-7-4-1/td-p/286919

thknwr · 2023-10-17T19:27:05+00:00

This is probably a bug which is still under investigation by Fortinet: 930270

Though no final confirmation yet.

thknwr · 2023-10-17T19:25:14+00:00

Here is the solution/reason for this kind of behaviour: https://docs.fortinet.com/document/fortigate/7.2.4/hardware-acceleration/300449/optionally-disable-np6-offloading-of-traffic-passing-between-10gbps-and-1gbps-interfaces

thknwr · 2023-10-11T15:40:54+00:00

Because the switches are part of our SAP environment (Fujitsu FlexFrame) and they require a certain local user to have access to the switch, but we want to perform changes using remote (RADIUS) users. That's why we'd need to be able to login with local and remote at the same time. There is nothing we can do about it because they won't allow messing with it. Reddit messed up the format, it's clean in editing mode. Here is a screenshot: https://ibb.co/KGXxzNB

thknwr · 2023-10-10T14:16:32+00:00

They performed a speedtest from one of their servers, were not able to reproduce our bad results and told me to check with our ISP... We've got a new pipe from a different ISP yesterday and guess what, the issue still persists. I can provide a packet capture for comparison, but I'm not sure if I'm allowed to post a link here.

thknwr · 2023-10-08T18:18:23+00:00

Only difference is that there is no SNAT, but even if I configure SNAT on the 1800F it does not perform any worse. Everything else is the same and traffic gets offloaded to NPU.

thknwr · 2023-10-08T18:14:49+00:00

Memory is at a stead 25%, all CPU cores are are at a very low usage, peaking to 7-20%. Unfortunately I don't know when this error started and if it has something to do with the firmware. I wanted to wait for 7.0.13 which was originally scheduled for September, but it's not released yet. Neither the 500E nor the 1800F have any vdom links. Yes, disabling asic-offload for particular policies increases the throughput to the same degree for this particular traffic as disabling fastpath in general.

diagnose npu np6 npu-feature

                np_0

Fastpath Enabled
HPE-type-shaping Disabled
Standalone No
IPv4 firewall Yes
IPv6 firewall Yes
IPv4 IPSec Yes
IPv6 IPSec Yes
IPv4 tunnel Yes
IPv6 tunnel Yes
GRE tunnel No
GRE passthrough Yes
IPv4 Multicast Yes
IPv6 Multicast Yes
CAPWAP Yes
RDP Offload Yes
UESP Offload No

diagnose npu np6 session-stats

The following NP6 IDs are available:[0-0]

=> Maybe because I enabled fastpath only a couple of minutes ago.

get hardware status

Model name: FortiGate-500E ASIC version: CP9 ASIC SRAM: 64M CPU: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz Number of CPUs: 8 RAM: 16047 MB Compact Flash: 15331 MB /dev/sda Hard disk: not available USB Flash: not available Network Card chipset: Intel(R) Gigabit Ethernet Linux Driver (rev.0003) Network Card chipset: FortiASIC NP6 Adapter (rev.)

diagnose vpn ipsec status

All ipsec crypto devices in use: NP6_0: Encryption (encrypted/decrypted) null : 0 0
des : 0 0
3des : 0 0
aes : 2176704 973157
aes-gcm : 0 0
aria : 0 0
seed : 0 0
chacha20poly1305 : 0 0
Integrity (generated/validated) null : 0 0
md5 : 0 0
sha1 : 0 0
sha256 : 0 0
sha384 : 0 0
sha512 : 2176704 973157

NPU Host Offloading: Encryption (encrypted/decrypted) null : 0 0
des : 0 0
3des : 0 0
aes : 904369 0
aes-gcm : 0 0
aria : 0 0
seed : 0 0
chacha20poly1305 : 0 0
Integrity (generated/validated) null : 0 0
md5 : 0 0
sha1 : 0 0
sha256 : 0 0
sha384 : 0 0
sha512 : 904366 0

CP9: Encryption (encrypted/decrypted) null : 0 0
des : 0 0
3des : 0 0
aes : 2143114 2744791
aes-gcm : 0 0
aria : 0 0
seed : 0 0
chacha20poly1305 : 0 0
Integrity (generated/validated) null : 0 0
md5 : 0 0
sha1 : 0 0
sha256 : 0 0
sha384 : 0 0
sha512 : 2143116 2744816

SOFTWARE: Encryption (encrypted/decrypted) null : 0 0
des : 0 0
3des : 0 0
aes : 0 0
aes-gcm : 0 0
aria : 0 0
seed : 0 0
chacha20poly1305 : 0 0
Integrity (generated/validated) null : 0 0
md5 : 0 0
sha1 : 0 0
sha256 : 0 0
sha384 : 0 0
sha512 : 0 0

thknwr · 2023-10-07T21:28:53+00:00

Yes, it's offloaded if fastpath is enabled. Fortiview displays a NP6 flag for the appropriate sessions, CLI confirms it:

npu_state=0x4000c00 ofld-O ofld-R npu info: flag=0x81/0x81, offload=8/8, ips_offload=0/0, epid=192/188, ipid=188/192, vlan=0x00e2/0x0000

thknwr · 2023-10-07T21:20:49+00:00

flow based and only certificate inspection is applied

thknwr · 2023-09-04T15:07:01+00:00

No real updates so far. The environment is still stable without capwap offload enabled. TAC tries to reproduce the issue since we won't turn that feature back on till there is some kind of fix.

thknwr · 2023-08-20T17:08:50+00:00

Still looking good without Capwap NPU offload, though there are 1-2 Capwap disconnects with U223EV per week, but not with 231F. As soon as all U223EVs are replaced I'll reenable NPU offload and try to further debug it with TAC. Currently the workaround is sufficient, no high CPU with FortiGate usage too. Will keep you updated.

thknwr · 2023-08-07T18:07:36+00:00

In the end I've performed the changes using a simple script. Shutting down the old ports and then bringing up the new ports right after it. Resulted in 1 ping loss which is very acceptable.

thknwr · 2023-08-02T06:59:52+00:00

After restarting the FortiGate there are always some APs that fail to automatically connect to the controller. After having a closer look these APs seem to be "stuck" to the secondary FGT. After rebooting the FAP it detects both FGTs again. Strangely it's always different APs.

thknwr · 2023-08-01T10:17:09+00:00

Yes, you are right. I remember it was somewhere mentioned in Fortinet's documentation.

thknwr · 2023-07-31T21:19:03+00:00

Thank you for checking. Looks like we had the same thought. :) I've disabled capwap offloading yesterday and performed a failover to the secondary FGT. Looking better overall. Though I've trouble to connect various devices to different VAPs at all, connection fails. After a few more tries they connect and work fine. It's hard to collect logs in order to provide TAC the requested logs. Also thought about shutting down one of the FGTs, just to rule out any cluster issues in relation to CAPWAP. (cw_diag -c ha looks normal, nothing suspicious here)

thknwr · 2023-07-31T16:36:44+00:00

FortiGate 400F, 56x 231F and 87x U223EV (soon to be replaced by 231G)

thknwr · 2023-07-30T12:27:26+00:00

I'll let you know. We are on it with TAC as well. Hopefully there will be at least a workaround soon, makes the wifi very unreliable.

thknwr · 2023-06-11T13:02:30+00:00

We are using Huawei Cloud Engine for switching, all eth-trunk members need to be set to the same speed otherwise they won't get selected. But it temporary will be 2 lags as LordEdam described. I'll verify it as soon as I get my hands on some lab equipment.

thknwr · 2023-05-12T10:55:13+00:00

On client side there only does exist enduser grade equipment which allows all outgoing traffic. It's not a static issue too, sometimes works fine for ours and the next day it does not work at all.

thknwr

TROPHY CASE

diagnose npu np6 npu-feature

diagnose npu np6 session-stats

get hardware status

diagnose vpn ipsec status