← Back to Fortinet Guides

FortiGate Troubleshooting

Operational deep dives for FortiGate engineers — packet flow from the wire to the NP7 ASIC and back out again, NPU offload mechanics, SDWAN service rule selection, the iprope policy chain, central NAT vs policy NAT, flow vs proxy UTM, and the diagnose, get, and show commands that come up under pressure.

A Day in the Life of a Packet on a 50G FortiGate

A five-part deep dive following one packet from the moment it arrives on a 25G/10G port through every decision point in FortiOS — NP7 fast path, stateful inspection, RPF, SDWAN service rules, the FIB, firewall policy, NAT, security profiles, and the egress path. Ends with a single-page command reference covering every diagnose, get, and show in the series, organised by symptom.

  1. A Day in the Life of a Packet on a 50G FortiGate, Part 1: Ingress, NP7, and the Fast Path

    Where the packet is born on a 50G FortiGate. From the wire and DMA, through the NP7 SoC's session cache, IPSA, NTurbo, and the moment a packet either flies through hardware or crosses the bridge into the kernel slow path.

  2. A Day in the Life of a Packet on a 50G FortiGate, Part 2: Stateful Inspection, Session Lookup, and Anti-Spoofing

    The packet has been punted from the NP7 to the kernel. Now FortiOS does the things ASICs cannot: IP integrity, DoS sensors, RPF, session table lookup, helpers, and the state machine that decides whether this is a brand new flow or one we already know.

Proving the Path: A FortiGate SD-WAN Diagnostic Companion

A six-part companion to the packet-flow series above, framed around diagnosis rather than architecture. One fault, threaded through all nine stages of the packet decision chain, plus the false conclusions that make it worth checking evidence at every stage rather than trusting the first plausible explanation.

  1. Proving the Path Part 1: The Chain, and the Fault We're Chasing

    A companion series to Day in the Life of a Packet, framed around diagnosis rather than architecture: one Teams call that stayed choppy long after the dashboards said everything had recovered, and the nine-stage chain I used to prove where the packet actually was.

  2. Proving the Path Part 2: Ingress and Session

    Before touching SD-WAN or routing, the session table tells you whether the flow you're chasing predates the event you're investigating. For the choppy Teams call, that one field settles more than the dashboard did.

  3. Proving the Path Part 3: Policy Route and Routing

    The pinned session predates the fault. Before blaming SD-WAN or routing for what's happening now, I need to know what a brand-new flow to the same destination would actually do today, and that's a different question from what the config says on paper.

  4. Proving the Path Part 4: SD-WAN Member, SLA, and Rule Selection

    The health-check history shows a breach, a failover, and a recovery, all working exactly as designed. Which raises the real question: if SD-WAN did its job correctly, why did the call stay broken?

  5. Proving the Path Part 5: Policy/NAT and IPsec

    The tunnel the pinned session is using never went down. The policy it matched hasn't changed. Both of those facts are true, and neither of them means the session's path was healthy the whole time it mattered.

  6. Proving the Path Part 6: Egress, NPU Offload, and the Verdict

    Every stage checked out clean on its own terms. The fix isn't clearing everything and hoping, it's one targeted action once the evidence points at a single cause. Closing the series with the full false-conclusions list and the discipline behind it.

Other Troubleshooting Posts

Standalone troubleshooting and diagnostics write-ups that don't form part of the packet-flow series.


How to use this section

If you're new to FortiGate packet flow, work through the five-part series in order — each part hands the packet off to the next stage and the diagnostic vocabulary builds up as you go. If you're triaging a live issue, jump straight to Part 5: it ends with a complete command cookbook organised by symptom (sniffer, driver, NPU, sessions, policy, NAT, routing, SDWAN, UTM, VPN, auth, flow trace, CPU/memory, HA), plus a 10-step triage discipline.

For a diagnosis-first read on the same territory, work through Proving the Path: it runs a single fault through all nine stages of the chain and closes with the false conclusions that make each stage worth checking on its own evidence.

Diagnostics and troubleshooting from a certification angle are covered in the NSE4 and NSE5 series.