FortiGate Hardware Offload Problems: NPU/ASIC Fixes and Workarounds

Remote-access IPsec from behind the same FortiGate

Symptom: FortiClient connects and split-tunnel Internet access works, but VPN destinations do not. Protected traffic may reach the destination and receive a reply, yet usable return traffic never reaches the VPN client with NPU offload active.

1. Why it fails

The client’s outer physical address is directly reachable behind the same FortiGate that terminates the VPN. This fictional topology uses ordinary Layer-2/VLAN forwarding, not FortiAP tunnel mode.

FortiClient endpoint: 192.168.250.50
        │ IPsec over OFFICE-LAN
        ▼
same FortiGate → decrypt → REMOTE-ACCESS-VPN
                              ├─ INTERNAL-LAN
                              └─ SITE-TO-SITE-VPN

Reply → IPsec encrypt → OFFICE-LAN → same client

The encrypted return packet must leave toward that directly connected VPN peer. The failure was isolated to the NPU-offloaded IPsec datapath in this same-FortiGate topology: the CPU path, routes, policies and selectors worked. The exact internal ASIC defect is unknown.

2. How to fix it

config vpn ipsec phase1-interface
    edit "<remote-access-phase1>"
        set npu-offload disable
    next
end

Reconnect FortiClient to establish fresh SAs after the tunnel interruption.

3. Why the fix works

FortiOS handles decrypt/encrypt processing and return forwarding without handing this datapath to the problematic NPU fast path. The route stays the same; the processor changes: NPU fast path → FortiOS CPU path.

Status: Field-observed workaround; experimentally isolated to NPU offload, with no established bug ID or affected-version range.

Source: Phase1 control; separate SSID case; August 2026 field report: 401F local Guest Wi-Fi needed offload disabled; other WANs worked. Related evidence does not establish an identical defect.

QinQ 802.1Q-over-802.1Q traffic stops after offload

Symptom: Traffic through nested 802.1Q interfaces passes its first packets, then stops. The initial capture can make routing, ARP, NAT or policy look intermittently broken.

1. Why it fails

FortiOS creates the session in software, then programs the NPU. Fortinet identifies a hardware design limitation for this nested-interface format on pre-NP8 processors, including NP6, NP6XLite, NP7 and NP7Lite: the CPU handles it, but the offloaded flow fails.

802.1Q inside 802.1Q differs from 802.1Q inside 802.1ad. Fortinet documents offload support for the latter. NP7 virtual-wire-pair DVLAN modes are a separate configuration, not proof that nested routed VLAN interfaces support the same offload.

2. How to fix it

For ordinary forwarding, including a policy that performs NAT:

config firewall policy
    edit <policy-id>
        set auto-asic-offload disable
    next
end

For an IPsec tunnel using that QinQ interface as its underlay:

config vpn ipsec phase1-interface
    edit "<phase1-name>"
        set npu-offload disable
    next
end

Retest a fresh session or SA. NAT itself is not the cause.

3. Why the fix works

The working initial packets demonstrate software forwarding for this flow. Keeping it on the CPU avoids transferring the double-tagged traffic into unsupported NPU processing.

Status: Hardware limitation on the stated pre-NP8 processors. The current tip excludes NP8 from that statement; it does not establish model-specific NP8 support. Do not assume NP8 compatibility without its platform documentation.

Source: Fortinet Technical Tip: 802.1Q-over-802.1Q offload limitation

NP6 IPsec / ESP hardware-path drops

Symptom: The tunnel stays up but traffic becomes one-way or encrypt/decrypt counters diverge. ESP arrives without the expected forwarded traffic.

1. Why it fails

Fortinet documents an NP6 IPsec-engine/PBA resource condition in which excessive Layer-2 padding on cleartext or ESP packets can block the session in hardware. Asymmetric counters alone do not prove a PBA leak.

2. How to fix it

config vpn ipsec phase1-interface
    edit "<phase1-name>"
        set npu-offload disable
    next
end

The tip’s broader isolation test also disables ASIC offload on the affected VPN policies at both peers, where applicable:

config firewall policy
    edit <policy-id>
        set auto-asic-offload disable
    next
end

Expect a tunnel interruption. If this restores traffic, arrange TAC investigation and a controlled reproduction. For confirmed padding-related PBA cases, the source also documents padding-stripping settings requiring a reboot; have TAC validate their applicability.

3. Why the fix works

The tunnel bypasses the affected NP6 IPsec engine. FortiOS manages packet processing and forwarding through the software path, with higher CPU load and potentially lower VPN throughput.

Status: Vendor-documented workaround for the NP6 condition; the tip gives no universal affected-version range or software-fix release.

Source: Fortinet Technical Tip: ESP drops and NP6 PBA leak

Redundant interface failback leaves stale NPU sessions

Symptom: After redundant-interface failover/failback, existing sessions lose packets although the active member and routing are correct.

1. Why it fails

On the documented NP6/NP6XLite platforms, FortiOS returns to the recovered primary member, but an offloaded session can retain the standby egress member. Software says “primary”; the stale hardware entry still sends to “standby”.

2. How to fix it

config firewall policy
    edit <policy-id>
        set auto-asic-offload disable
    next
end

Then select only the affected sessions. Replace these fictional addresses and policy ID; run in the owning VDOM:

diagnose sys session filter clear
diagnose sys session filter policy <policy-id>
diagnose sys session filter src 192.168.250.50
diagnose sys session filter dst 10.77.20.10
diagnose sys session list

Proceed only if the list matches the intended traffic. Reapply the same filters below before clearing; matching connections are interrupted. If a filter command errors, stop.

diagnose sys session filter clear
diagnose sys session filter policy <policy-id>
diagnose sys session filter src 192.168.250.50
diagnose sys session filter dst 10.77.20.10
diagnose sys session clear
diagnose sys session filter clear

3. Why the fix works

Replacement sessions stay on the CPU path and use the current interface decision, bypassing the stale NPU egress entry.

Status: Vendor-documented workaround. The current tip says a permanent software fix is being developed, without a release or bug ID. NP7 flushes sessions for this transition and is not included in this specific issue.

Source: Fortinet Troubleshooting Tip: redundant-interface failback on NP6/NP6XLite; session filter syntax

SoC5 ingress shaping causes packet loss

Symptom: Forwarded data traffic loses packets on affected SoC5 models when ingress shaping and ASIC offload are enabled together.

1. Why it fails

Issue 1256278 affects the hardware/QTM path with an ingress shaping profile. On affected SoC5 platforms, such as 50G, 70G, 90G and 120G, repeat this during loss and look for increasing DCE_QTM_ENQ_DROP:

diagnose npu np7lite dce-drop-all 0

2. How to fix it

config firewall policy
    edit <policy-id>
        set auto-asic-offload disable
    next
end

Alternatively, remove the affected interface ingress shaping profile if its bandwidth policy can be changed.

Permanent fix: FortiOS 7.4.12 lists 1256278 as resolved. Fortinet also documents resolution in 7.6.4 and 8.0.0. Choose a supported fixed release for the model and follow its upgrade path.

3. Why the fix works

Disabling offload avoids the affected QTM/NPU path. A fixed release allows hardware acceleration to remain enabled with the corrected implementation.

Status: Resolved Fortinet bug, 1256278. This condition concerns forwarded traffic, not traffic addressed to the FortiGate itself.

Source: Fortinet Troubleshooting Tip: SoC5 ingress shaping, issue 1256278; FortiOS 7.4.12 resolved issues: 1256278

FortiAP tunnel-mode SSID clients cannot use the local IPsec VPN

Symptom: A client on a FortiGate tunnel-mode SSID establishes remote-access IPsec on that same FortiGate but cannot reach internal resources.

1. Why it fails

This is a separate CAPWAP/tunnel-mode wireless path. Fortinet documents decrypted traffic failing the reverse-path check in this topology on FortiOS 7.4.x/7.6.x. The tip does not identify the internal defect; it does not establish that ordinary LAN clients fail for this reason.

2. How to fix it

config vpn ipsec phase1-interface
    edit "<remote-access-phase1>"
        set npu-offload disable
    next
end

Reconnect the client after the tunnel resets. Use this tunnel-scoped workaround; changing global CAPWAP acceleration is broader.

3. Why the fix works

The affected IPsec datapath stays under FortiOS software processing, bypassing the documented NPU interaction with tunneled wireless traffic. This does not change routes or disable reverse-path checking.

Status: Vendor-documented workaround; the cited tip provides no bug ID or fixed release.

Source: Fortinet Technical Tip: tunnel-mode SSID clients using remote-access VPN