Common Fortinet Firewall Errors and How to Fix Them Fast

By Stackvora Team · 2026-09-06 · 8 min read

Five FortiGate errors cause most of the pain in production. Here's what each one actually means and how to kill it fast.

1. "Conserve mode" — memory pressure

Symptom: GUI banner, new sessions dropped, proxy features disabled.

Fix: Find the process eating memory:

diagnose hardware sysinfo memory
diagnose sys top 5 30

Usual suspects: IPS engine after a signature update, or a logging process. Restart one process, not the box: diagnose sys kill 11 <pid>. Long-term: reduce logging verbosity and disable unused security profiles.

2. "Certificate error" on every HTTPS site

Symptom: Browser warnings on all sites behind the FortiGate.

Cause: SSL deep inspection is on, but the FortiGate CA cert isn't installed on endpoints.

Fix: Either deploy Fortinet_CA_SSL via GPO/MDM to all devices, or switch the policy to certificate-inspection only. There is no third option.

3. Sessions drop after exactly one hour

Cause: Session TTL default (3600s) hitting long-lived connections — database links, monitoring tunnels.

Fix: Raise the TTL on that specific policy:

config firewall policy
 edit <id>
  set session-ttl 28800
 next
end

4. "HA out of sync" / split-brain

Fix: Find the divergence first:

diagnose sys ha checksum cluster
execute ha synchronize start

If checksums still differ after a sync, a config object was changed directly on the secondary. Compare show output on both units for the flagged table. Never leave heartbeat interfaces on a switch that also carries production traffic — that's how split-brain starts.

5. Traffic hits the wrong policy

Symptom: Allowed traffic denied, or vice versa.

Fix: Use the policy lookup, not your eyes:

diagnose firewall proute list
diagnose debug flow filter addr <dst-ip>
diagnose debug flow show function-name enable
diagnose debug flow trace start 100

The flow trace tells you exactly which policy ID matched — it's usually not the one you expected. Policy order is top-down, first match wins.

Every FortiGate mystery ends in a flow trace. Learn diagnose debug flow once and you'll never guess at a policy problem again.

Paste your error message into Stackvora AI for a tailored diagnosis, or browse our Fortinet knowledge base.

How to read FortiGate logs efficiently

Most Fortinet errors become obvious once you filter logs correctly. In the GUI, go to Log & Report > Forward Traffic and add a filter on the source or destination IP. Look at the action and policyid fields first: a deny with policy ID 0 means the traffic hit the implicit deny, not a rule you wrote. From the CLI, execute log filter category traffic plus execute log display gives the same picture in seconds.

For VPN and authentication errors, switch to the Event logs. The subtype field (vpn, user, system) tells you which daemon logged the failure, and the message field usually names the exact object — a phase 1 name, an LDAP server, or a certificate — that caused it.

Debug flow: your last resort

When logs are inconclusive, the debug flow shows exactly which policy and NAT rule a packet matches:

diagnose debug flow filter addr 10.0.0.50
diagnose debug flow show function-name enable
diagnose debug flow trace start 50
diagnose debug enable
# reproduce the problem, then:
diagnose debug disable
diagnose debug flow trace stop

Always stop the trace afterward — a forgotten debug flow can spike CPU on a busy unit.

When to escalate or reset

Escalate to Fortinet TAC when you see kernel crashes (diagnose debug crashlog read), hardware acceleration offload errors, or failover flapping you cannot explain. Factory reset only as a last resort, and always export the full configuration and a diagnose debug application capture first — TAC will ask for both.

For error messages not covered here, search the Stackvora knowledge base or paste the exact log line into Stackvora AI.

Key takeaways

  • Filter Forward Traffic logs by IP first — the policy ID field names the exact rule that allowed or denied the flow.
  • Policy ID 0 means implicit deny: your traffic never matched a rule you wrote.
  • Debug flow is the definitive tool, but always stop the trace when you're done.
  • Collect crashlogs and full configs before escalating or resetting — evidence disappears fast.

Fortinet errors look cryptic until you map them to the right log category and policy ID. With the filters and debug commands in this guide, most "mystery" drops resolve in one sitting. For anything firmware-specific, cross-check the Stackvora knowledge base — FortiOS behavior changes between trains, and yesterday's fix can become today's default.

More blog posts · Knowledge base