Home

FortiGate CLI Traffic Monitoring: The Network Administrator's Essential Guide

.

In today's complex network environments, real-time traffic visibility is not just a convenience—it's a necessity for security and performance management. While FortiGate's graphical interface offers user-friendly dashboards, the command-line interface (CLI) provides unparalleled depth and precision for network troubleshooting. CLI commands offer "more detailed information" and enable "faster troubleshooting" than GUI tools alone, particularly when dealing with complex traffic flow issues.

Experienced administrators consistently turn to CLI tools when diagnosing network anomalies, policy misconfigurations, or performance bottlenecks. As one Reddit user transitioning from another firewall platform noted, "I just can't find a way to monitor the traffic flow on the firewall, for example if it's denying packets on certain ports coming from the outside." This comprehensive guide synthesizes official Fortinet documentation, community wisdom, and expert techniques to provide a complete CLI monitoring methodology.

Core CLI Traffic Verification Concepts

Packet Sniffing with Diagnose Sniffer

The diagnose sniffer packet command serves as your network microscope, allowing packet-level inspection of traffic traversing interfaces. This tool is invaluable for verifying connectivity, examining protocol details, and confirming packet paths.

Basic syntax: diagnose sniffer packet <interface> '<filter>' <verbose_level> <count> <timeout>

According to Fortinet's 7.6.5 Administration Guide, you can examine specific traffic flows with commands like:

# diagnose sniffer packet any 'host 10.0.2.10' 4 0 1 interfaces=[any]

The verbose level (1-6) controls detail displayed:

  • Level 1: Print packet headers only
  • Level 4: Print headers with interface names
  • Level 6: Maximum detail including Ethernet data

An example from a troubleshooting case shows this in action:

FW # diagnose sniffer packet port1 'dst 10.10.20.1' 1 4 interfaces=[port1] filters=[dst 10.10.20.1] 10.880000 10.10.10.1.60368 -> 10.10.20.1.22: syn 2179876642 13.880000 10.10.10.1.60368 -> 10.10.20.1.22: syn 2179876642 19.880000 10.10.10.1.60368 -> 10.10.20.1.22: syn 2179876642

This output reveals three unanswered SYN packets, indicating a potential blockage.

Session Analysis with Diagnose Sys Session

While packet sniffing shows individual packets, session analysis provides a higher-level view of active connections. The diagnose sys session command family reveals how the firewall is processing traffic flows.

Key session commands:

  • diagnose sys session list - View all active sessions
  • diagnose sys session filter - Filter sessions by criteria
  • diagnose sys session stat - Display session statistics

Filtering capabilities are particularly powerful. To examine traffic to a specific destination:

# diagnose sys session filter dst 10.0.2.20 # diagnose sys session list

The output provides comprehensive session details including policy IDs, interface paths, NAT translations, and performance metrics. In Fortinet's SD-WAN example, this verified "that HTTPS and HTTP traffic destined for the Web server at 10.0.2.20 uses FGT_AWS_Tun."

Flow Debugging for Deep Troubleshooting

When you need to understand the firewall's decision process, diagnose debug flow reveals the internal packet walk. This tool shows exactly how packets are evaluated against policies, routed, and potentially blocked.

Setting up a flow trace:

FW # diagnose debug enable FW # diag debug flow filter addr 10.10.10.1 10.10.20.2 FW # diag debug flow show console enable FW # diag debug flow trace start 1000

The number in the trace command (1000 in this case) limits captured lines—crucial in busy environments. As one administrator advises, "In dense environments, I advise you limit this number to avoid capturing too much traffic."

Sample debug output reveals the firewall's decision-making:

id=20085 trace_id=1 func=print_pkt_detail line=4378 msg="vd-root received a packet(proto=6, 10.10.10.1:60369->10.10.20.1:22) from port1." id=20085 trace_id=1 func=init_ip_session_common line=4527 msg="allocate a new session-0000003c" id=20085 trace_id=1 func=fw_forward_handler line=545 msg="Denied by forward policy check (policy 0)"

This output clearly shows the SSH packet being denied by policy 0 (the implicit deny rule), pinpointing the exact issue.

Practical Traffic Monitoring Applications

Troubleshooting Connectivity Issues

When hosts cannot communicate through the firewall, follow this systematic approach:

  1. Verify basic connectivity with ping from the firewall itself:

    execute ping <destination-IP>

  2. Check routing decisions with traceroute:

    execute traceroute <destination-IP>

  3. Examine interface status and errors:

    get system interface physical diag netlink interface list

  4. Capture traffic on relevant interfaces:

    diagnose sniffer packet port1 'host <target-IP>' 4 0 10

A community member shared their method: "We are transitioning all our customers from Symantec endpoint to Kaspersky endpoint... traffic monitor -> filter by test machine IP, send a heartbeat... wait for the red entries, make a list of ports and protocols."

Diagnosing Policy and Blocked Traffic

Identifying why legitimate traffic is blocked requires policy-focused diagnostics:

Policy lookup:

diag firewall policy lookup <source-IP> <destination-IP>

Detailed policy examination:

show firewall policy diag firewall policy list

For real-time monitoring of blocked traffic, ensure logging is properly configured:

config log memory filter     set severity warning     set forward-traffic enable     set local-traffic disable     set sniffer-traffic enable end

One administrator noted that "log & report will alert instantaneously with traffic that is denied by the firewall" when properly configured.

Monitoring VPN Traffic Flows

For VPN troubleshooting, specific commands provide tunnel-specific visibility:

IPSec tunnel status:

diagnose vpn tunnel list

SD-WAN health and performance:

diagnose sys sdwan health-check diagnose sys sdwan service

The Fortinet Administration Guide shows SD-WAN verification examples:

# diagnose sys sdwan health-check Seq(1 AWS_VPG): state(alive), packet-loss(0.000%) latency(56.221), jitter(0.290) sla_map=0x0

VPN session debugging:

diag debug enable diag debug application ike -1

Performance and Resource Monitoring

High resource utilization often manifests as traffic issues. Monitor system health alongside traffic flows:

CPU and memory usage:

diag sys top get system performance status

Interface statistics and errors:

diag netlink interface list get system interface

Session table monitoring:

diag sys session stat

Kevin Darian advises, "If high CPU is due to a DDoS attack, block suspicious IPs" using address objects and policy modifications.

Advanced CLI Monitoring Techniques

Real-Time Log Monitoring

For continuous visibility, several approaches provide streaming log data:

Memory log monitoring:

execute log display

External syslog streaming (as suggested by a Reddit user):

# Configure syslog server first: config log syslogd setting     set status enable     set server <syslog-server-IP> end  # Then tail the syslog on your server tail -f /var/log/fortigate.log

One community member confirmed: "We use logging to Syslog (Linux server) and then 'tail -f' the corresponding log."

Local log file monitoring:

tail -f /var/log/system.log

Automation and Scripting

Power users can automate repetitive monitoring tasks through scripting:

Scheduled monitoring scripts:

# Example: Periodic interface check #!/bin/bash ssh admin@fortigate "get system interface" | grep -A 3 "port1"

Configuration backups before changes:

execute backup config ftp <server-IP> <filename>

Batch command execution:

# Using expect or similar tools for automated diagnostics

Diagnostic Tool Comparison

Tool Best For Performance Impact Output Detail
diagnose sniffer packet Packet-level analysis, protocol debugging Moderate to High Very High
diagnose debug flow Understanding firewall decision process High Maximum
diagnose sys session Active connection monitoring Low High
get system interface Interface status and statistics Minimal Medium
Log monitoring Historical analysis, compliance Minimal (when external) Variable

Integration with GUI Tools

While CLI provides depth, GUI integration enhances usability:

FortiView for real-time dashboards: As one Reddit user noted, "Fortiview in the GUI. This dashboard gives you a snapshot of all traffic currently flowing."

Packet capture GUI: "You could run a packet capture under Network > Packet Capture" with filtering options similar to CLI.

Log viewer synchronization: Ensure your log viewer displays "logs from memory (by default, it may try to display logs from cloud)."

Best Practices for Effective Traffic Monitoring

  1. Start with broad commands, then narrow focus using filters to avoid information overload.

  2. Limit debug output with count limits (e.g., trace start 1000) to prevent console flooding.

  3. Always disable debugging after completion:

    diag debug flow trace stop diagnose debug flow filter clear diag debug disable

  4. Combine tools strategically: Use session analysis to identify problematic flows, then apply packet sniffing or debug flow for microscopic examination.

  5. Document findings including specific commands used and their outputs for future reference and team knowledge sharing.

Conclusion

Mastering FortiGate CLI traffic monitoring transforms network troubleshooting from guesswork to precise diagnostics. As evidenced across official documentation, community discussions, and expert guides, the CLI provides unparalleled visibility into traffic flows, firewall decisions, and network performance.

Whether you're diagnosing blocked connections, optimizing SD-WAN paths, or investigating performance issues, these CLI techniques form an essential toolkit for any FortiGate administrator. By strategically applying packet sniffing, session analysis, and flow debugging—complemented by GUI tools when appropriate—you can maintain comprehensive visibility into your network's traffic flows and security posture.

Frequently Asked Questions

How can I monitor traffic in real-time without FortiAnalyzer?

You have several options without FortiAnalyzer:

  1. CLI commands like diagnose sniffer packet and diagnose sys session list provide real-time visibility.
  2. FortiView in the GUI offers real-time dashboards using its internal buffer.
  3. Memory logging can be configured: config log memory filter with appropriate severity settings.
  4. External syslog streaming to a server, then using tail -f on the log file.
  5. Packet capture in the GUI under Network > Packet Capture.

What's the difference between packet sniffing and flow debugging?

Packet sniffing (diagnose sniffer packet) shows actual packets crossing interfaces, similar to a network tap. Flow debugging (diagnose debug flow) reveals the firewall's internal decision process—how policies are evaluated, routing decisions made, and why packets might be blocked. Use sniffing to see what traffic exists, and flow debugging to understand how the firewall processes that traffic.

How do I check if traffic is being blocked by a policy?

  1. Use flow debugging with filters: diag debug flow filter addr <src> <dst> then diag debug flow trace start 50.
  2. Check the session list for denied sessions: diagnose sys session filter state deny then diagnose sys session list.
  3. Verify policy matches: diag firewall policy lookup <src-IP> <dst-IP>.
  4. Examine memory logs for deny entries: ensure forward-traffic logging is enabled in memory filter settings.

Can I monitor traffic for a specific user or IP address?

Yes, using filters in various commands:

  • Session filtering: diagnose sys session filter src <IP> or dst <IP>
  • Packet sniffing filters: diagnose sniffer packet any 'host <IP>' 4 0 10
  • Flow debug filters: diag debug flow filter addr <src-IP> <dst-IP>
  • Policy lookup: diag firewall policy lookup <src-IP> <dst-IP>

How do these methods impact firewall performance?

Performance impact varies:

  • diagnose sniffer packet: Moderate impact, increases with verbose level and traffic volume.
  • diagnose debug flow: High impact—use with count limits in production.
  • diagnose sys session: Low impact for listing, moderate with extensive filtering.
  • Logging to memory/disk: Minimal impact with proper severity filtering. Always limit debug scope and disable when finished to minimize performance impact.

What alternatives exist if my FortiGate has no local storage?

For devices without local storage (like the 80E mentioned):

  1. External syslog server - Configure remote logging and monitor there.
  2. FortiCloud - Even the free tier provides some logging capability.
  3. CLI commands - These don't require storage, just active sessions.
  4. FortiView - Uses internal buffer independent of storage.
  5. Packet capture to PCAP file - Can export via FTP/SCP without local storage.