FortiGate diagnose debug flow

Overview

diagnose debug flow is one of the most useful FortiGate troubleshooting toolsets when traffic reaches the firewall but does not behave as expected.

It exposes FortiOS packet-processing decisions such as route lookup, session creation, policy matching, NAT processing, and deny reasons.

It is especially useful when a simple packet capture proves that traffic exists but does not explain why FortiGate made a particular forwarding decision.

What it does

A debug flow traces selected traffic through FortiOS packet processing.

Typical output can reveal:

• Incoming interface
• Source and destination addresses
• Route lookup result
• Session allocation
• Firewall policy decision
• Source or destination NAT
• Local-in handling
• Drop reason

The command family is not a single command. A useful debug usually consists of:

1. Resetting old debug state.
2. Applying one or more filters.
3. Optionally enabling function names.
4. Starting a limited number of traces.
5. Enabling debug output.
6. Generating the traffic being investigated.
7. Stopping and resetting the debug.

When to use it

Use debug flow when investigating issues such as:

• A host can reach the FortiGate but not the destination.
• Traffic appears to match the wrong firewall policy.
• NAT is being applied unexpectedly.
• A route is not being selected as expected.
• Inter-VLAN traffic is denied.
• VPN traffic reaches the FortiGate but is not forwarded correctly.
• Packet captures show traffic entering but not leaving the expected interface.

Do not make debug flow the first diagnostic step for every problem. Routing tables, interface state, policy configuration, logs, and a filtered packet capture are often faster ways to narrow the problem first.

Prerequisites

• CLI access with sufficient administrator permissions.
• A clear source, destination, port, or protocol to filter on.
• Awareness of the active VDOM when VDOMs are enabled.
• A controlled test that can generate repeatable traffic.

On busy production firewalls, avoid broad or unfiltered debug sessions.

Recommended procedure

Reset existing debug state:

diagnose debug reset

Filter on an IP address:

diagnose debug flow filter addr 10.1.10.20

For more precise testing, use source and destination filters:

diagnose debug flow filter saddr 10.1.10.20
diagnose debug flow filter daddr 10.2.20.10

Optionally filter by destination port:

diagnose debug flow filter dport 443

Display function names in output:

diagnose debug flow show function-name enable

Limit the trace to a defined number of flow events:

diagnose debug flow trace start 100

Enable debug output:

diagnose debug enable

Generate the traffic to reproduce the problem.

When finished:

diagnose debug flow trace stop
diagnose debug disable
diagnose debug reset

Common filters

Any traffic involving an address

diagnose debug flow filter addr 10.1.10.20

Source address

diagnose debug flow filter saddr 10.1.10.20

Destination address

diagnose debug flow filter daddr 10.2.20.10

Destination TCP/UDP port

diagnose debug flow filter dport 443

Protocol

ICMP uses protocol number 1:

diagnose debug flow filter proto 1

TCP uses protocol number 6 and UDP uses 17.

How to interpret the output

Do not read debug flow as a binary success/failure message. Follow the packet-processing sequence.

Incoming packet

A line indicating that a packet was received confirms the FortiGate actually saw the test traffic on the named interface.

Route lookup

Look for output indicating that a route was found and note the gateway and outgoing interface.

If the wrong route is selected, inspect:

get router info routing-table all

Session allocation

A new-session message confirms FortiOS is creating session state for the flow.

Firewall policy

Look for policy matching or deny output. Confirm the policy ID against the configured firewall policy.

NAT

Messages referring to SNAT or DNAT show that address translation is being applied. Verify that this is intentional for the tested flow.

Validation

A successful diagnostic session should let you answer at least these questions:

1. Did the packet enter the FortiGate?
2. On which interface?
3. Which route was selected?
4. Which policy processed the traffic?
5. Was NAT applied?
6. Was the flow accepted or dropped?
7. If dropped, what stage produced the drop?

If debug flow cannot answer the first question, use a packet sniffer to establish whether the FortiGate sees the traffic at all.

Risks and considerations

Large debug volume

An unfiltered debug on a busy firewall can generate a significant amount of output and make analysis difficult.

Always filter as narrowly as practical and limit the trace count.

FortiAnalyzer and FortiCloud logging

Fortinet warns that debug flow output can be recorded as event log messages and forwarded to connected logging services. Do not leave the diagnostic running longer than required.

Hardware-offloaded traffic

Traffic offloaded to NP6 or NP7 processors may not appear in normal debug flow output. If a known active session appears invisible to debug flow, hardware offload must be considered before assuming the traffic never passed through the FortiGate.

Disabling hardware acceleration is an intrusive diagnostic action and should not be done casually on production equipment.

Rollback / Stop

Use all three commands after a troubleshooting session:

diagnose debug flow trace stop
diagnose debug disable
diagnose debug reset

diagnose debug reset is important because it clears filters and debug state that might otherwise affect a later troubleshooting session.

Troubleshooting the troubleshooting

No output appears

Check:

• Is diagnose debug enable active?
• Does the test traffic actually occur?
• Are the filters too restrictive?
• Are you in the correct VDOM?
• Is the session hardware offloaded?
• Does a packet sniffer see the traffic?

Output is overwhelming

Stop the debug and narrow the filters using source address, destination address, protocol, and port.

Traffic is allowed but the application still fails

A firewall allow decision proves only that FortiGate permitted the tested flow. Continue with packet capture, return-path validation, endpoint firewall checks, server listening ports, and application-level diagnostics.

Related articles

• FortiGate packet sniffer
• FortiGate routing table
• FortiGate IPsec tunnel established but no traffic

Sources

See the authoritative Fortinet references in the article metadata.