FortiGate Session Troubleshooting with Flow Debug, Sessions and Logs

Mastering FortiGate session troubleshooting is an essential skill for network security engineers working in complex enterprise environments. When users report intermittent application drops, slow file transfers, or broken connections, standard ping tests rarely reveal the root cause. You must peek inside the FortiOS kernel to inspect routing decisions, firewall policy matches, Network Address Translation (NAT) operations, stateful session tables, and real-time packet flow debugs.

This technical guide details a practical, repeatable workflow for diagnosing session failures on FortiGate firewalls. You will learn how to read raw session tables, trace packets step-by-step through the FortiOS architecture using CLI flow debugs, correlate system logs, and identify common drop mechanisms like Reverse Path Forwarding (RPF) checks or policy mismatches.

Real-Life Scenario

An enterprise organization recently migrated its core financial database application to a dedicated Data Center subnet. Immediately following the migration, accounting staff working on the LAN subnet (192.0.2.0/24) reported intermittent connectivity failures. Workstations frequently lose connection to the HTTPS web application running on 198.51.100.20.

Initial network checks confirm that basic IP routing exists. However, connection handshakes frequently stall or drop after initiating requests. As the network engineer, you must isolate whether the FortiGate firewall is dropping traffic due to an unintended policy match, NAT port exhaustion, asymmetric routing drops, or stateful session timeouts.

Lab Topology

The troubleshooting workflow described in this tutorial uses the simplified enterprise network topology below. All IP addresses and interfaces represent lab examples and must be adapted for production environments.

+-------------------------+
| Accounting Workstation  |
| IP: 192.0.2.50/24       |
+------------+------------+
             |
             | (Port2)
+------------+------------+
|     FortiGate Firewall  |
|   (FortiOS Kernel Flow) |
+------------+------------+
             | (Port1)
             |
+------------+------------+
| DC HTTPS Application    |
| IP: 198.51.100.20/32    |
+-------------------------+

Example Addressing and Objects

The table below summarizes the example network interfaces, subnets, and security policy configuration used throughout this guide.

Prerequisites

• Administrative access (read/write or super_admin permissions) to the FortiGate CLI and GUI.
• Basic understanding of TCP stateful connection establishment (SYN, SYN-ACK, ACK).
• FortiOS operating system (commands shown apply generally to FortiOS 6.4, 7.0, 7.2, and 7.4 releases).
• An SSH client (such as PuTTY or OpenSSH) for real-time CLI output capture.

Configuring Logging and Session Visibility in the GUI

Before initiating real-time CLI flow traces, verify that your firewall policies are properly configured to capture traffic session logs. GUI views provide an immediate high-level summary of active connections.

Step 1: Enable Full Session Logging on the Policy

1. Log into the FortiGate GUI.
2. Navigate to Policy & Objects > Firewall Policy.
3. Select and edit the target policy (e.g., Policy ID 10: LAN_to_DC).
4. Scroll down to the Logging Options section.
5. Ensure Log Allowed Traffic is set to All Sessions rather than Security Events during active troubleshooting.
6. Click OK to save changes.

Note: GUI paths and feature visibility may vary slightly depending on the active FortiOS release, platform hardware, and whether Central NAT or VDOMs are enabled.

Step 2: Inspecting Active Sessions in the GUI

To inspect active connections without using the CLI:

1. Navigate to FortiView Sessions (or Dashboard > Status and add the Sessions widget in older versions).
2. Use the search filter bar to filter by Source IP 192.0.2.50 or Destination IP 198.51.100.20.
3. Double-click an active session line to view session attributes including incoming interface, outgoing interface, NAT translations, and packet counters.

CLI Session Troubleshooting Tools

The command-line interface provides real-time, granular visibility into stateful connection handling. You can filter and inspect the internal session table, run flow debugs, and packet capture live traffic.

1. Managing the FortiGate Session Table

The FortiOS stateful firewall maintains a session table for all active connections. Always set strict session filters before listing or clearing sessions to avoid overwhelming the system CLI session.

Clear any existing CLI session filters and set specific criteria:

diagnose sys session filter clear
diagnose sys session filter src 192.0.2.50
diagnose sys session filter dst 198.51.100.20
diagnose sys session filter dport 443

Display the active session table matching your filter criteria:

diagnose sys session list

An example session output from the FortiGate kernel looks like this:

session info: proto=6 proto_state=01 duration=12 expire=3588 timeout=3600 flags=00000000 sockdef=0 sockstate=0 src=192.0.2.50 dst=198.51.100.20 sport=52140 dport=443 [src]
	policy_dir=0 tunnel=/ vlan_cos=0/0
	state=log start nat 
	statistic: pkt=5 bytes=740 dir=0 allocation=1 bytes=430 pkts=3
	statistic: pkt=4 bytes=610 dir=1 allocation=1 bytes=310 pkts=2
	org-in-act: side=0 ip=192.0.2.50 port=52140
	reply-out-act: side=1 ip=198.51.100.20 port=443
	dev=4/3 gwy=198.51.100.20/port1
	hook=post dir=0 act=snat 198.51.100.1:52140
	hook=pre dir=1 act=dnat 192.0.2.50:52140
	misc=0 policy_id=10 auth_info=0 chk_act=0 serial=0004e12a

Key fields in the session output include:

• proto=6: IP Protocol 6 (TCP).
• proto_state=01: TCP state (01 = ESTABLISHED in FortiOS state mapping).
• expire=3588: Seconds remaining before the session expires from inactivity.
• dir=0: Traffic sent in the original direction (Client to Server).
• dir=1: Traffic sent in the reply direction (Server to Client).
• policy_id=10: Firewall policy matching this flow.
• act=snat: Source NAT applied to the original outbound egress traffic.

2. Running the FortiGate Flow Debug

The Packet Flow Debug tool prints step-by-step kernel operations for incoming packets. It proves whether a packet is arriving on an interface, matching a route, matching a policy, undergoing NAT, or getting dropped by security modules.

CAUTION: Running real-time debugs on high-throughput firewalls without strict filters can cause high CPU utilization. Always apply specific IP and port filters before enabling debug traces.

Configure the flow debug step-by-step:

diagnose debug reset
diagnose debug flow filter clear
diagnose debug flow filter addr 192.0.2.50
diagnose debug flow filter port 443
diagnose debug flow show console enable
diagnose debug flow trace start 10
diagnose debug enable

To stop the flow debug cleanly and prevent CPU degradation after completing your test, execute:

diagnose debug disable
diagnose debug flow trace stop
diagnose debug reset

3. Real-Time Packet Capture (Sniffer)

To confirm whether packets are physically arriving at the ingress interface or exiting the egress interface, run the built-in packet sniffer:

diagnose sniffer packet port2 'host 192.0.2.50 and port 443' 4 10 a

Parameters explained:

• port2: Interface to capture on (use any for all interfaces).
• 'host 192.0.2.50 and port 443': Capture filter string.
• 4: Verbosity level (4 prints packet header with interface name).
• 10: Stop automatically after capturing 10 packets.
• a: Include absolute timestamps.

How Traffic Flows Through the FortiOS Kernel

Understanding packet processing sequence helps isolate connection failures faster during FortiGate session troubleshooting.

[ Ingress Packet ]
       │
       ▼
[ Session Lookup ] ──(Match Existing Session?)──► [ Forward Packet ]
       │ No
       ▼
[ Routing Lookup ] ──(Route Exists?)──► No ──► [ DROP: No Route ]
       │ Yes
       ▼
[ RPF Check ] ──────(Passes RPF?)────► No ──► [ DROP: Reverse Path ]
       │ Yes
       ▼
[ Policy Match ] ────(Policy Allows?)─► No ──► [ DROP: Implicit Deny ]
       │ Yes
       ▼
[ NAT / Session Create ]
       │
       ▼
[ Egress Interface Transmission ]

1. Ingress Packet Arrival: Packet enters the physical/logical interface.
2. Session Table Lookup: FortiOS checks if the packet belongs to an existing session (“dirty bit” check). If match found, policy processing is bypassed.
3. Destination Route Lookup: The kernel determines the egress interface and next-hop gateway.
4. Reverse Path Forwarding (RPF) Check: Verifies that reply traffic can route back out through the incoming interface to prevent spoofing and asymmetric routing issues.
5. Firewall Policy Lookup: Rules are evaluated sequentially top-to-bottom. If no policy matches, traffic hits the default implicit deny.
6. NAT Evaluation: Source NAT (SNAT) or Destination NAT (DNAT/VIP) rules are applied.
7. Security Inspection: Stateful IPS, Antivirus, Application Control, or Web Filtering occurs if configured.
8. Session Creation & Egress: The kernel records the session in the session table and forwards the packet out the destination interface.

Verification and Debug Output Analysis

When you trigger testing traffic from client host 192.0.2.50 to application server 198.51.100.20 while the debug flow trace is running, FortiOS outputs real-time step processing messages.

Successful Connection Flow Trace Analysis

id=65227 trace_id=1 msg="vd-root:00000000 received a packet(proto=6, 192.0.2.50:52140->198.51.100.20:443) from port2. type=0, id=0, seq=0, ack=0, flag=0x02(SYN)."
id=65227 trace_id=1 msg="allocate a new session-0004e12a"
id=65227 trace_id=1 msg="find a route: flag=00000001 gw=198.51.100.20 via port1"
id=65227 trace_id=1 msg="Allowed by Policy-10:"
id=65227 trace_id=1 msg="SNAT 192.0.2.50->198.51.100.1:52140"
id=65227 trace_id=1 msg="outgoing connection outbound cluster id=0"

This output proves:

• The TCP SYN packet arrived on port2.
• FortiOS allocated a new session ID (0004e12a).
• A valid route out port1 was identified.
• Firewall Policy ID 10 allowed the traffic.
• Source NAT translated the client IP to egress IP 198.51.100.1.

Structured Troubleshooting Workflow

Follow this systematic multi-layer workflow to quickly pinpoint session drops on a FortiGate firewall.

1. Layer 1 / Layer 2: Interface and Link Diagnostics

Verify that physical interfaces are up and not dropping frames due to link errors or duplex mismatches:

get system interface physical
diagnose hardware deviceinfo nic port1

2. Layer 3: Routing & RPF Verification

Check the Active Routing Table for a destination route:

get router info routing-table details 198.51.100.20

To test how the firewall matches a dynamic policy without sending traffic, use the policy lookup tool:

diagnose firewall iprope lookup 192.0.2.50 52140 198.51.100.20 443 6 port2

If the output shows matched policy equal to 0, traffic is failing the policy lookup stage.

3. Common Connection Drop Analysis via Debug Flow

Symptom A: Packet Dropped by Policy (Implicit Deny)

If traffic is blocked by security policy, the flow trace explicitly displays:

id=65228 trace_id=2 msg="vd-root:00000000 received a packet(proto=6, 192.0.2.50:52141->198.51.100.20:443) from port2."
id=65228 trace_id=2 msg="find a route: flag=00000001 gw=198.51.100.20 via port1"
id=65228 trace_id=2 msg="Denied by forward policy 0 (policy 0)"

Fix: Adjust policy parameters (source zone, destination object, service ports) or add an explicit firewall policy above implicit deny.

Symptom B: Reverse Path Forwarding Check Drop (Asymmetric Routing)

If return traffic enters an interface different from what the routing table expects, FortiOS drops the packet during the RPF check:

id=65229 trace_id=3 msg="vd-root:00000000 received a packet(proto=6, 192.0.2.50:52142->198.51.100.20:443) from port2."
id=65229 trace_id=3 msg="Reverse path check fail. Drop packet."

Fix: Ensure symmetric routing pathing across upstream routers, or configure asymmetrical routing settings on specific interfaces if design requires it.

Symptom C: TCP State Failure / Mid-Stream Packet Drop

If a client sends TCP ACK or PUSH packets without initiating a valid SYN handshake first, FortiOS drops non-SYN initial packets by default:

id=65230 trace_id=4 msg="vd-root:00000000 received a packet(proto=6, 192.0.2.50:52143->198.51.100.20:443) from port2."
id=65230 trace_id=4 msg="tcp session state bad: flag=0x10(ACK), state=0(NONE)"
id=65230 trace_id=4 msg="drop tcp packet fail session create"

Fix: Troubleshoot host applications sending out-of-order packets, or check for upstream load balancer resets.

Log File Correlation

To cross-reference real-time CLI trace output against stored system logs, display the traffic log directly from CLI:

execute log filter category 0
execute log filter field srcip 192.0.2.50
execute log filter field dstip 198.51.100.20
execute log display

Example traffic log result showing a session close action:

1: date=2024-03-15 time=10:14:22 logid="0000000013" type="traffic" subtype="forward" level="notice" vd="root" srcip=192.0.2.50 srcport=52140 srcintf="port2" dstip=198.51.100.20 dstport=443 dstintf="port1" sessionid=320042 policyid=10 action="close" rcvdbyte=1240 sentbyte=1850 action="timeout"

The action="timeout" field indicates that the session was closed cleanly because no traffic passed within the defined idle timeout period (default TCP idle timeout is 3600 seconds).

Common Mistakes

• Leaving Debug Active: Failing to run diagnose debug disable when finished. Active flow debugs create persistent CPU overhead on enterprise production units.
• Unfiltered Debug Commands: Running diagnose sys session list without setting filters first. On systems carrying tens of thousands of connections, this will lock up your terminal session.
• Ignoring Asymmetric Paths: Troubleshooting firewall policies when packets are actually being discarded silently by Reverse Path Forwarding (RPF) checks.
• Confusing Session Directions: Misinterpreting original direction (dir=0) vs reply direction (dir=1) when reviewing NAT translations in session outputs.

Production Considerations

When conducting effective FortiGate session troubleshooting in busy enterprise networks, observe the following constraints:

• Log Volume Tuning: Enabling Log Allowed Traffic – All Sessions on high-volume traffic policies can rapidly fill disk or FortiAnalyzer logging queues. Return logging settings to Security Events once issues are resolved.
• SNAT Port Allocation Exhaustion: When using Central NAT or Policy NAT with single IP pools, monitor source port range utilization. High connection counts from single IP pools can exhaust available ephemeral source ports.
• Session Table Capacity: Low-end hardware units have strict concurrent session limits. Review maximum hardware limits using get system performance status.

Related FortiGate Guides

• FortiGate packet sniffer and debug flow troubleshooting
• Troubleshoot FortiGate IPsec VPN Phase 1 and Phase 2
• FortiGate Syslog configuration and SIEM integration
• Apply FortiGate security profiles to firewall policies

Summary

Effective FortiGate session troubleshooting relies on a methodical layer-by-layer diagnostic process. By combining CLI session filtering, real-time flow debugs, packet sniffers, and detailed log analysis, network engineers can easily identify why traffic is dropped or delayed. Use this workflow to rapidly isolate stateful firewall issues, eliminate asymmetric routing problems, and maintain high performance across your FortiGate deployment.