pjhtech Tools
FortiGate

FortiGate IPsec Tunnel Up but Traffic Stops Intermittently

Diagnose intermittent IPsec data loss using Child SA rekey, tunnel counters, routing and narrowly scoped hardware-offload issues.

On FortiGate 4xF/6xF models running FortiOS 7.6.4, issue 1206506 can stop IPsec traffic while the tunnel remains up. The documented temporary fix is to disable npu-offload on the affected tunnel; fixed releases are listed below. Use this workaround only for that model/build case.

4xF/6xF on 7.6.4: apply the scoped offload workaround

Fortinet documents issue 1206506 on 4xF/6xF running FortiOS 7.6.4: IPsec may stop carrying both user and local-out traffic. The exact issue is listed resolved in 7.4.10 and 7.6.5.

Before applying the workaround, read the affected existing tunnel in its owning VDOM. On a multi-VDOM unit, a global administrator first enters config vdom and edit "<owning-vdom>"; stay in that context for both the read and change below.

Read-only • owning VDOM; retain output privately
show full-configuration vpn ipsec phase1-interface "<affected-existing-tunnel>"

Record the effective npu-offload value before changing it. If it is already disable, skip the change: this workaround is already applied, so continue the data-path investigation. If it is enable and the documented issue matches, the temporary workaround below disables NPU offload. It flushes the tunnel, interrupts traffic and increases CPU processing:

Configuration change • scoped known-issue workaround; tunnel interruption
config vpn ipsec phase1-interface
    edit "<affected-existing-tunnel>"
        set npu-offload disable
    next
end

After the VDOM-local change block, a global administrator uses next and end to leave the VDOM context. Restoring the recorded offload value also requires a coordinated interruption. Do not apply the workaround to every tunnel as a generic diagnostic.

Scope: FortiGate route-based IPsec data-path failures. The hardware-offload exception above applies only to its named models/build.

Other models or failures tied to rekey

Run tunnel diagnostics in the VDOM that owns the tunnel. On a multi-VDOM unit, a global administrator enters config vdom and edit "<owning-vdom>" before the command below; use next and end afterward to return to the top-level prompt. A VDOM administrator is already in the assigned context.

Read-only • replace the tunnel name; output can contain key material
diagnose vpn tunnel list name <existing-tunnel>

If the model/build does not match, compare the relevant proxyid, sa count and expire through the failure. A missing Child SA or failure at rekey belongs in the proposal/PFS correction; a subnet-only failure belongs in the selector, route and policy fixes. Keep SA output private.

Identify the model and current load

Read-only • affected FortiGate
get system status
get system performance status

Record the model and exact version/build from get system status, plus CPU, memory and session load from get system performance status. Compare the same fields before and after any offload workaround; CPU pressure can replace the original fault with a different bottleneck.

Verify through the original failure interval

Repeat the application workload and any affected BGP/SD-WAN probes. For rekey failures, observe the next relevant rekey; for load-related failures, compare the same load and CPU behavior.

References