Issue with ASIC offloading and UTM on 100F Series?

[sw2090]

After having done a load of testing I've come to the conlusion that there actually is an issue with ASIC offlading and UTM on the 100F Series.

This issue does not occur on 100E Series or a 300E or a 60F but it does on all of our 100F.

All FGT here are at 7.0.12.

Issue is:

When your internet policy is in flow mode (default) then per default ASIC offloading is on. If you then also applied some UTM Profiles or a security profile group to the policy you will notice that at least website that use http v2 protocol will no longer work. They will load endless or/and timout.

If you disable ASIC offloading the sites work immediately. 

They also work if the policy is in proxy mode because in proxy mode the FGT does no ASIC offloading.

TAC are still investigating this with us. Up to now their suggested workaround is to disable ASIC offloading. However Fortinet themselves do not recommend that because this will generate a higher CPU load on the FGT. 

Just wanted to post that in here for if anyone else runs into this.

[code0]

I don't have a reference at the moment, but we saw something matching this with traffic coming across an IPSec tunnel to a "core" firewall, then having flow mode UTM applied there before going out to the Internet. Issue was relatively inconsistent. IIRC, it was a bug in ipsengine that was being looked into.

Workaround was to set up MSS clamping to a reasonable value.

[sw2090]

thanks for your reply.

We have no IPSec in effect here. Just Client either in a vlan or in older shops even without vlan wired to the FGT through some switches and then going to internet through sdwan.

[Fortiuser2]

You wrote, the issue does not occur on a 60F. I made a different experience:

Since a few days, we test to deploy settings and automated software installations via Microsoft Autopilot and Intune. Our testclients are connected via WiFi, which is managed by a 60F. From 10 clients, a minimum of 8 faild at the software-installation-task during the Autopilot process. When we used a wired connection between the client and a Fortigate 300E cluster, all clients installed all packets without any issue.

After I saw a hint regarding to ASIC, we decided to deactivate ASIC on the 60F. This was the solution. After this change, 20 of 20 notebooks did a perfect installation so far...

[Toshi_Esumi]

I'd imagine there are a few more ASIC (SOC4) related bugs still exist that need to be patched by the software. @sw2090 Didn't TAC recommend upgrading it to 7.2.6 or 7.4.1 to see if it would fix it?

Toshi

[cassac]

My team has had similar issues on our 101Fs running 7.0.12.  In some cases it was only specific traffic allowed in a rule and we were able to create a new rule isolating the affected traffic with asic disabled.  

Packet captures show a normal TCP session and then a reply with an incorrect sequence number causing everything to restart.  

Did TAC ever find a permanent resolution?   We showed them the packet captures and it got to the point where TAC wanted to see captures not taken from the Fortigate thinking our routing equipment was introducing the error.   

[BillH_FTNT]

Hi @sw2090 @cassac 

Can you share some more detail configuration or Ticket Number. We can try to reproduce your case in lab to find the cause. Thanks

[cassac]

8273751

With and without IPSEC tunnels.  We even create any any permit rules for testing but then one port/session/etc would stop working.  If we isolate that session into its own rule, it would start working again.   

[BillH_FTNT]

Hi @cassac 

I think your case can check 2 more things. To have a more clear view
1. If you can make a change to test. Let's decrease MTU on the Server site to 1340. Or MTU in the incoming firewall to 1340. Or MTU of the IPsec SA to 1340.
2. Does the system affect all URLs, or is it Just an issue with some unique URLs? What are the okay URLs and Non okay URLs?

HTH

Bill

[sw2090]

No TAC did not yet provide any solution for this. All I can say is it didn't happen on the same Fortinet Hardware in 6.4.x but does happen in 7.0.x. 

As a workaround we created a policy that uses an address group containing affected sites which has asic offloading disabled.