FortiGate Hardware Offload Problems: NPU/ASIC Fixes and Workarounds

First packets work, then traffic stops? The CPU path may work while the NPU/ASIC path fails. Start with the matching case below; test only the affected policy, tunnel or feature.

Quick reference

Problem	Symptom	Fix	Why
Same-FortiGate local-LAN IPsec	VPN up; internal traffic fails	Disable Phase1 NPU offload	NPU return path fails
Nested 802.1Q over 802.1Q	First packets work, then stop	Disable policy ASIC offload¹	Pre-NP8 nested-tag limit
NP6 IPsec / ESP	One-way traffic	Disable tunnel NPU offload	NP6 / PBA resource condition
Redundant-interface failback	Existing sessions lose packets	Policy offload off; selective clear	Stale NPU egress
SoC5 ingress shaping	Forwarded traffic drops	Fixed release or policy offload off	Bug 1256278
FortiAP tunnel-mode SSID + VPN	VPN up; internal traffic fails	Disable Phase1 NPU offload	CAPWAP / IPsec interaction

¹ For an IPsec QinQ underlay, disable the affected Phase1’s NPU offload instead. See the case for scope and commands.

The common first-packets-work pattern

Packet 1:            CPU → policy/routing → works
Session established: CPU programs NPU
Packet 2+:           NPU fast path → specific failure
Offload disabled:    CPU → policy/routing → keeps working

Illustrative sequence, not an exact packet count. Failback and resource exhaustion may fail later.

What npu-offload and auto-asic-offload control

npu-offload controls IPsec Phase1 NPU acceleration.

Change only the affected IPsec Phase1

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

auto-asic-offload controls firewall-policy session acceleration.

Change only the affected firewall policy

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

Choose the affected scope; do not disable both automatically. Work in the owning VDOM, replace placeholders and record the previous setting. Changing Phase1 offload interrupts the tunnel: reconnect for fresh security associations (SAs). Policy tests need a fresh session too.

“CPU path” means FortiOS handles the datapath. IPsec cryptography may still use a content processor (CP); npu-offload disable does not disable every hardware accelerator.

Offload failures and their fixes

Remote-access IPsec from behind the same FortiGate

Symptom: FortiClient connects from a LAN behind the same FortiGate that terminates the VPN. Split-tunnel Internet works, but VPN destinations do not.

1. Why it fails

The client’s physical outer IP is directly reachable through a local interface on the same FortiGate. The reply takes this path:

Internal destination → FortiGate → IPsec encrypt → local LAN → same VPN client

In this topology, the NPU-offloaded IPsec return path failed while FortiOS software forwarding worked. Traffic could reach the destination and receive a reply, but not return to the VPN client. No exact ASIC defect or bug ID is established. This ordinary LAN/VLAN path is separate from FortiAP tunnel mode.

2. How to fix it

Change only the affected IPsec Phase1

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

The route stays the same. The processor changes. FortiGate stops handing the IPsec datapath to the NPU fast path and uses the working FortiOS software path.

Status: Field-observed workaround — no established bug ID or affected-version range.

Source: Phase1 control; separate SSID case; August 2026 field report: 401F Guest Wi-Fi affected; 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. Routing, ARP, NAT or policy may appear intermittent.

1. Why it fails

The CPU handles the initial packets, then the NPU takes over and fails on the nested tags. Fortinet documents this hardware limitation on pre-NP8 processors, including NP6, NP6XLite, NP7 and NP7Lite.

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:

Change only the affected firewall policy

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

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

Change only the affected IPsec Phase1

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 session stays on the working CPU path, avoiding unsupported nested-tag processing in the NPU.

Status: Hardware limitation — pre-NP8 processors. The tip excludes NP8 but does not establish model-specific NP8 compatibility.

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

Change only the affected IPsec Phase1

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:

Change only the affected firewall policy

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. Software forwarding increases CPU work and may reduce VPN throughput.

Status: Vendor-documented workaround — no universal affected-version range or fixed release published.

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

Change only the affected firewall policy

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

Replace only the affected sessions after disabling policy offload. Clearing sessions interrupts matching connections. Inspect the filtered list first; stop if any filter command errors.

Selective session-clear example

Replace the fictional addresses and policy ID; run in the owning VDOM.

Read-only • inspect the filtered sessions

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

Disruptive • clear only the selected policy and address pair

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 — fix in development, no release or bug ID published. NP7 flushes sessions for this transition and is excluded.

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

Bug 1256278 affects the QTM/NPU path when ingress shaping is enabled. Examples include 50G, 70G, 90G and 120G. During loss, look for increasing DCE_QTM_ENQ_DROP:

Read-only • SoC5/NP7Lite drop counters

diagnose npu np7lite dce-drop-all 0

2. How to fix it

Change only the affected firewall policy

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; forwarded traffic only, not traffic addressed to the FortiGate.

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

Fortinet documents decrypted traffic failing the reverse-path check on this CAPWAP/tunnel-mode wireless path in FortiOS 7.4.x/7.6.x. The internal defect is unspecified; this does not explain failures on an ordinary LAN.

2. How to fix it

Change only the affected IPsec Phase1

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

Software processing bypasses the documented NPU interaction with tunneled wireless traffic. Routes and reverse-path checking remain unchanged.

Status: Vendor-documented workaround — no bug ID or fixed release published.

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

How to confirm hardware offload is involved

In the owning VDOM, filter to the affected flow. Replace these fictional addresses; for decrypted VPN traffic, use inner tunnel addresses:

Read-only • inspect one address pair; then remove diagnostic filters

diagnose sys session filter clear
diagnose sys session filter src 192.168.250.50
diagnose sys session filter dst 10.77.20.10
diagnose sys session list
diagnose sys session filter clear

Read npu info and offload= for original/reply directions. offload=8/8 means both directions in Fortinet’s NP6 example; npu, npu_state and flags vary by processor. Use the matching hardware reference, not a universal bitmask. no_ofld_reason, when present, explains why offload was not used.

For IPsec:

Read-only • inspect the affected IPsec tunnel

diagnose vpn tunnel list name <phase1-name>

Compare encryption/decryption counters while generating traffic. A directional mismatch narrows the investigation; it does not identify a particular defect.

CPU debug may show session creation and then go quiet because later packets are offloaded. This affects diagnose debug flow and diagnose sniffer packet. Fortinet documents this visibility limit. Silence is not proof that packets vanished. Retest with the relevant scoped offload setting disabled and a fresh session; compare actual endpoint connectivity as well as captures.

If connectivity still fails, check routes, policies and IPsec selectors. For failures tied to large packets, use the IPsec overhead calculator to investigate MTU separately. See intermittent IPsec troubleshooting for SA/rekey checks and another specifically scoped firmware defect.

Performance cost and when to restore offload

Hardware acceleration is normally desirable. Disabling it increases CPU work and can reduce throughput, VPN capacity and session scalability.

Disable only the smallest affected policy or tunnel scope; avoid global changes.
Retest fresh sessions and monitor CPU under representative load.
Prefer a fixed FortiOS release; restore offload and retest after the fix.
Use TAC for unexplained production cases.

FortiGate Hardware Offload Problems: NPU/ASIC Fixes and Workarounds

Quick reference

The common first-packets-work pattern

What npu-offload and auto-asic-offload control

Offload failures and their fixes

Remote-access IPsec from behind the same FortiGate

1. Why it fails

2. How to fix it

3. Why the fix works

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

1. Why it fails

2. How to fix it

3. Why the fix works

NP6 IPsec / ESP hardware-path drops

1. Why it fails

2. How to fix it

3. Why the fix works

Redundant interface failback leaves stale NPU sessions

1. Why it fails

2. How to fix it

3. Why the fix works

SoC5 ingress shaping causes packet loss

1. Why it fails

2. How to fix it

3. Why the fix works

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

1. Why it fails

2. How to fix it

3. Why the fix works

How to confirm hardware offload is involved

Performance cost and when to restore offload

References