pjhtech Tools
FortiGate · FortiOS 7.4

FortiGate session table commands for policy and NAT checks

Quick answer #

The session table connects an actual flow to its firewall policy, translated addresses, interfaces and packet counters. Start with a narrow filter and inspect the live connection. This is more useful than guessing which policy should match from the configuration alone.

Scope: FortiGate/FortiOS 7.4-family IPv4 session inspection in the relevant VDOM; no session deletion.

Find a single connection #

Replace the addresses and port, then run:

Find a single connection
FortiOS 7.4 · Traffic VDOM; administrative scope as described below

Diagnostic state
diagnose sys session filter clear
Diagnostic state

Replace these example values: 10.20.30.40.

diagnose sys session filter src 10.20.30.40
Diagnostic state

Replace these example values: 192.0.2.80.

diagnose sys session filter dst 192.0.2.80
Diagnostic state
diagnose sys session filter proto 6
Diagnostic state
diagnose sys session filter dport 443
Read-only
diagnose sys session filter
Read-only
diagnose sys session list
Output may contain sensitive operational data.

The filter display is a checkpoint: verify that only the intended criteria remain. A fresh browser request may still reuse an existing TCP connection, so use the application deliberately and record which connection you are inspecting. For destination NAT, an unsuccessful destination filter can reflect the tuple being queried; start with the client filter alone and inspect translations before refining it.

Use policy filtering separately #

To inspect sessions associated with one known policy, clear the previous filters first:

Use policy filtering separately
FortiOS 7.4 · Traffic VDOM; administrative scope as described below

Diagnostic state
diagnose sys session filter clear
Diagnostic state

Replace these example values: 123.

diagnose sys session filter policy 123
Read-only
diagnose sys session list
Output may contain sensitive operational data.
Diagnostic state
diagnose sys session filter clear

A busy policy can still return substantial output. Prefer a client-specific search when investigating one person's issue. Clearing a filter only changes diagnostic selection; it does not close sessions.

Read the fields together #

Locate policy_id to identify the policy used by the session. Examine NAT actions on the original and reply directions: snat and dnat describe transformations at particular processing hooks, not two unrelated user connections. Record the original tuple and the translated tuple explicitly so that a subsequent packet-capture filter follows the correct address on each side.

Compare original and reply packet counts across two observations. Increasing original counts with no reply counts is evidence of one-way visibility, not a complete diagnosis. Check the remote service, next hop and return route before blaming NAT. Record offload information as context: it helps explain why a live session can be visible here but sparse in CPU-based debugging.

Preserve the evidence #

Do not delete sessions as the first diagnostic step. Deletion can interrupt active traffic and remove the state needed to explain the failure. Copy only the relevant session, with usernames, public identifiers and unrelated data redacted before sharing. Finish by clearing the diagnostic filter so the next investigation starts from a known selection.

Sources

Documentation reviewed: 8 October 2026