Fortinet CLI Commands Cheat Sheet für FortiOS 7.4

get system status - General system information.

execute tac report - Generates report for support.

get system performance status - General performance infos.

diagnose system top [sec] [number] Control + C to stop command - Process list, Sort with P (CPU) / M (Memory).

diagnose debug crashlog read - Crash log.

execute factoryreset - Reset whole configuration.

execute factoryreset-shutdown - Reset config and shutdown.

execute factoryreset2 - Reset with retaining admin, interfaces and static routing.

execute factoryreset keepvmlicense - Reset whole config but retain VM license.

diagnose ip address list - List of IPs on FGT interfaces.

diagnose firewall iplist list - List of IPs on VIP.

diagnose firewall ippool list - List of IP on pools.

diagnose netlink interface list - List IF with MTU & device ID.

get hardware nic <interface> - Interface Information.

diagnose ip arp list / get system arp - ARP table.

execute clear system arp table - Clears ARP table.

execute ping x.x.x.x

execute ping-options <option> - Ping utility.

execute traceroute x.x.x.x

execute traceroute-options <option> - Traceroute utility.

execute telnet x.x.x.x <port>

execute telnet-options <option> - Telnet utility.

diagnose traffictest server-intf

diagnose traffictest client-intf

diagnose traffictest port [port]

diagnose traffictest run -c [iperf_server_ip] - Iperf test directly run from FortiGate.

ref: Basic site-to-site VPN with pre-shared key

execute ha manage [index] [admin] - Jump to cluster member.

get system ha status - Information about HA status.

diagnose system ha history read - Details about past HA events.

diagnose system ha dump-by vcluster - Show cluster member uptime.

diagnose system ha reset-uptime - Reset cluster member uptime.

diagnose debug appl hatalk -1

diagnose debug appl hasync -1 - Debugging of HA-Talk/-Sync protocol.

execute ha ignore-hardware-revision status / enable / disable - Set ignore status for different HW revisions.

execute ha failover status - View failover status.

execute ha failover set <cluster_id> - Device stays in failover state regardless of condition. Triggers a HA failover on master device.

diagnose sys ha checksum cluster - Show config checksums of all cluster members.

diagnose sys ha checksum show [vdom] - Detailed config checksum for a VDOM.

diagnose sys ha checksum recalculate - Recalculation of config checksums when Master and Slave are out of sync.

FortiOS allows setting thresholds to control system responses to memory usage levels:

• Extreme Threshold: Triggers when memory usage exceeds a set percentage of total RAM, leading to new sessions being dropped. Default is 95%, configurable between 70% and 97%.
• Red Threshold: Crossing this threshold enters the system into conserve mode. Default is 88% of total RAM, with a range of 70% to 97%.
• Green Threshold: The memory usage level at which FortiGate exits conserve mode. Default is 82% of total RAM, configurable between 70% and 97%.

Proxy and Flow Inspection in Conserve Mode

Behavior under conserve mode is adjustable:

• Proxy Inspection: Configured with the antivirus failopen command, it determines how the antivirus proxy operates in conserve mode, with options to pass, off, or one-shot.
• Flow Inspection: Managed by the IPS failopen command, controlling the IPS engine's behavior towards new sessions requiring flow-based inspection.

Diagnostics

FortiOS generates logs and SNMP traps in conserve mode, with tools to view current memory conservation status and check via CLI diagnose hardware sysinfo conserve.

FGT01 # diagnose hardware sysinfo conserve
memory conserve mode:                        off
total RAM:                                         2043 MB
memory used:                                        666 MB   32% of total RAM
memory freeable:                                    317 MB   15% of total RAM
memory used + freeable threshold extreme:          1940 MB   95% of total RAM
memory used threshold red:                         1797 MB   88% of total RAM
memory used threshold green:                       1675 MB   82% of total RAM
                        

diagnose system csf upstream / downstream - List of up/downstream devices.

diagnose system csf neighbor list - MAC/IP list of connected FGT devices.

diagnose test appl csfd 1 - Display security fabric statistics.

diagnose debug appl csfd -1 - Real-time debugger.

diagnose automation test <stitch_name> - Test stitches in the CLI.

diagnose endpoint record list - Endpoint records on FortiGate.

diagnose report-runner trigger security-rating-reports - Manually run security rating reports.

diagnose system modem detect - Detect attached modem.

diagnose debug appl modemd 3 - Debugger for modem commands.

diagnose debug config-error-log read - Show config errors after firmware upgrades.

sudo global/ vdom-name diagnose / execute / show / get - Sudo-command to access global / VDOM settings directly.

diagnose netlink brctl name host <name> - Bridge MAC table.

execute config-transaction start/abort/commit - Start/abort/commit of Workspace Mode.

diagnose system config-transaction status - State of Workspace Mode (enabled/disabled).

diagnose system config-transaction show txn-info - Shows all active Workspace Modes.

diagnose system config-transaction show txn-cli-commands - Pending CLI commands of Workspace Mode.

diagnose endpoint fctems test connectivity <EMS name> - Verify FortiGate to FortiClient EMS connectivity.

diagnose test app fcnacd 2 - Dump the EMS connectivity information.

diagnose debug application fcnacd -1 diagnose debug enable - Run real-time FortiClient NAC daemon debugs.

diagnose endpoint record list <ip> - Show endpoint record list, filter by the endpoint IP address.

diagnose wad dev query-by ipv4 <ip> - Query from WAD diagnose command IP address.

diagnose firewall dynamic list - List EMS ZTNA tags and all dynamic IP and MAC addresses.

executeute fctems verify <EMS name> - Verify the FortiClient EMS certificate.

diagnose debug appl [appl] [level] - Realtime debugger for different applications.

diagnose debug application dnsproxy - Useful for diagnosing DNS proxy issues and ensuring proper DNS operations.

diagnose debug application sslvpn - Critical for troubleshooting SSL-VPN connection problems.

diagnose debug application dhcp - Helps in diagnosing DHCP server or client issues within the network.

diagnose debug application ike - Essential for debugging VPN IKE phase negotiations, crucial for VPN tunnel establishment.

diagnose debug application ipsengine - Debugs IPS sensor operations, key for intrusion prevention efforts.

diagnose debug application httpsd - Crucial for diagnosing issues with the HTTPS daemon, impacting web management access.

diagnose debug application sshd - Essential for troubleshooting SSH daemon issues, affecting remote management.

diagnose debug application radiusd - Helps in diagnosing RADIUS authentication issues, crucial for network access control.

diagnose debug application ntpd - Diagnoses NTP daemon for time synchronization issues, crucial for log accuracy and scheduling.

FortiGate devices offer extensive diagnostic capabilities through the diagnose debug application command, allowing detailed debugging of various system processes and daemons. Below is a comprehensive list of applications that can be debugged, ranging from network services to security daemons and system management processes.

• SMTP Proxy
• POP3 Proxy
• IMAP Proxy
• NNTP Proxy
• Proxy Services
• Router Advertisement Daemon
• Log Daemon (miglogd, kmiglogd)
• FortiCloud Daemon
• Alert Mail Daemon
• PPP Daemon
• L2TP Daemon
• PPTP Daemon (Server and Client)
• Authentication Daemons (authd, foauthd)
• FortiClient NAC Daemon
• FSSO Daemon
• DHCP (Server, Relay, Client) Daemons
• Update Daemon
• VPN Policy Daemon
• IPS Monitor and Sensor
• URL Filter Daemon
• DDNS Client Daemon
• SNMP Daemon
• Chassis Management
• WiFi Settings
• DNS Proxy Module
• sFlow Protocol Module
• HA Protocol and Synchronization Daemons
• Quarantine Daemon
• ZebOS Networking Daemon
• RADIUS Daemon
• SSH Daemon
• SSL-VPN Proxy Daemon
• SIP and SCCP ALG
• IKE Daemon
• WCCP Daemon
• ...

To debug a specific application, use the syntax: diagnose debug application <app_name> -1, where <app_name> is the name of the daemon or process you wish to debug, and -1 sets the debug level to the most verbose output. Remember to enable debugging with diagnose debug enable before starting and to disable it afterwards to conserve system resources.

When using the diagnose debug application command on FortiGate devices, different debug levels can be specified to control the verbosity of the output. Here's a list of these levels and their typical use cases:

• -1: The most verbose debug level, providing the most detailed information available. This level is useful for in-depth troubleshooting of specific issues but can generate a lot of data very quickly.
• 0: Disables debug output for the specified application. This level is used to stop debugging.
• 1: Basic debugging level, offering a high-level overview of operations and errors. Suitable for initial diagnostics where you want a quick look at the application's activities without overwhelming detail.
• 2: Medium verbosity level, offering more detailed information than level 1 without the extensive detail of the highest levels. This is often a good balance for regular troubleshooting.
• 3 and above: Higher levels of verbosity provide increasingly detailed information, which can be useful for troubleshooting specific, complex issues. The exact nature and volume of the information depend on the application being debugged and the implementation in the FortiOS version.

To set a debug level, use the syntax: diagnose debug application <app_name> <level>, where <app_name> is the name of the process or daemon you wish to debug, and <level> is the desired verbosity level. Remember to enable system-wide debugging with diagnose debug enable before setting application-specific debug levels, and to disable it with diagnose debug disable when you're finished to conserve system resources and avoid unnecessary logging.

To debug SMTP proxy: diagnose debug application smtp -1

To investigate issues with the IKE daemon: diagnose debug application ike -1

For debugging the SSL-VPN process: diagnose debug application sslvpn -1

diagnose test appl [appl] [test_level] - Monitor proxy operations.

diagnose debug console timestamp enable - Enables timestamp in console.

diagnose debug [enable/disable] - Enables/disables output for "diagnose debug" command.

diagnose debug reset - Reset debug levels.

ref: Basic site-to-site VPN with pre-shared key

diagnose debug appl ike 63 - Debugging of IKE negotiation.

diagnose vpn ike log filter … - Filter for IKE negotiation output.

diagnose vpn ike gateway list - Phase 1 state.

diagnose vpn ike gateway flush - Delete Phase 1.

diagnose vpn tunnel list - Phase 2 state.

diagnose vpn tunnel flush - Delete Phase 2.

get vpn ike gateway - Detailed gateway information.

get vpn ipsec tunnel details - Detailed tunnel information.

get vpn ipsec stats tunnel - Detailed tunnel statistics.

diagnose vpn ipsec status - Shows IPSEC crypto status.

            # diagnose vpn ike gateway
            vd: root/0
            name: to_HQ2
            version: 1
            interface: port1 11
            addr: 172.16.200.1:500 -> 172.16.202.1:500
            created: 5s ago
            IKE SA: created 1/1 established 1/1 time 0/0/0 ms
            IPsec SA: created 2/2 established 2/2 time 0/0/0 ms
            id/spi: 12 6e8d0532e7fe8d84/3694ac323138a024
            direction: responder
            status: established 5-5s ago = 0ms
            proposal: aes128-sha256
            key: b3efb46d0d385aff-7bb9ee241362ee8d
            lifetime/rekey: 86400/86124
            DPD sent/recv: 00000000/00000000
            
            # diagnose vpn tunnel list
            list all ipsec tunnel in vd 0
            name=to_HQ2 ver=1 serial=1 172.16.200.1:0->172.16.202.1:0 tun_id=172.16.202.1 
            bound_if=11 lgwy=static/1 tun=intf/0 mode=auto/1 encap=none/528 options[0210]=create_dev frag-rfcaccept_traffic=1
            proxyid_num=1 child_num=0 refcnt=11 ilast=7 olast=87 ad=/0
            stat: rxp=0 txp=0 rxb=0 txb=0
            dpd: mode=on-demand on=1 idle=20000ms retry=3 count=0 seqno=0
            natt: mode=none draft=0 interval=0 remote_port=0
            proxyid=to_HQ2 proto=0 sa=1 ref=2 serial=1 auto-negotiate
            src: 0:0.0.0.0/0.0.0.0:0
            dst: 0:0.0.0.0/0.0.0.0:0
            SA: ref=3 options=18227 type=00 soft=0 mtu=1438 expire=42927/0B replaywin=2048
            seqno=1 esn=0 replaywin_lastseq=00000000 itn=0
            life: type=01 bytes=0/0 timeout=42930/43200
            dec: spi=ef9ca700 esp=aes key=16 a2c6584bf654d4f956497b3436f1cfc7
            ah=sha1 key=20 82c5e734bce81e6f18418328e2a11aeb7baa021b
            enc: spi=791e898e esp=aes key=16 0dbb4588ba2665c6962491e85a4a8d5a
            ah=sha1 key=20 2054b318d2568a8b12119120f20ecac97ab730b3
            dec:pkts/bytes=0/0, enc:pkts/bytes=0/0
        

Running diagnostic commands on a FortiGate device provides crucial data about IPsec VPN tunnels. This example details the output from commands run on a device named HQ1 for a tunnel to HQ2.

This command provides information about IKE gateways. For the gateway named "to_HQ2" in the virtual domain "root" (ID 0), we observe the following:

• Interface: port1, bound to interface 11
• Address Mapping: This indicates the mapping of IP addresses and ports for the VPN tunnel. Traffic originating from the local IP address 172.16.200.1, on port 500, is being sent to the remote IP address 172.16.202.1, also on port 500.
• Creation Time: 5 seconds ago
• IKE SA:
  • created: 1/1 - One IKE (Internet Key Exchange) Security Association (SA) has been created.
  • established: 1/1 - The created IKE SA has been successfully established.
  • time: 0/0/0 ms - The time it took for the IKE SA to be created and established (in milliseconds).
• IPsec SA:
  • created: 2/2 - Two IPsec (Internet Protocol Security) Security Associations have been created.
  • established: 2/2 - Both IPsec SAs have been successfully established.
  • time: 0/0/0 ms - The time it took for the IPsec SAs to be created and established (in milliseconds).
• id/spi: 12 6e8d0532e7fe8d84/3694ac323138a024 - Specifies the identification (id) and Security Parameter Index (SPI) associated with the VPN tunnel.
• Direction: responder - Indicates that the device is acting as a responder in the VPN tunnel setup.
• Status:
  • established: 5-5s ago = 0ms - Indicates that the VPN tunnel has been established 5 seconds ago with no latency (0 milliseconds).
• Proposal: aes128-sha256 - Specifies the cryptographic algorithms proposed for securing the VPN tunnel (AES 128-bit encryption with SHA-256 hashing).
• Key: b3efb46d0d385aff-7bb9ee241362ee8d - The encryption and decryption key used within the VPN tunnel.
• Lifetime/rekey: 86400/86124 - Indicates the lifetime of the VPN tunnel (86400 seconds or 24 hours) and the time remaining until rekeying (86124 seconds).
• DPD sent/recv:
  • 00000000/00000000 - Shows the Dead Peer Detection (DPD) status for the VPN tunnel, indicating that no DPD packets have been sent or received.

Running this command on HQ1 provides a list of all IPsec tunnels in virtual domain 0. For the tunnel "to_HQ2", the details are as follows:

• Name: to_HQ2, Version: 1, Serial: 1, Tunnel ID: 172.16.202.1
  • Name: Identifier for the VPN tunnel.
  • Version: Indicates the version number of the tunnel configuration.
  • Serial: A unique identifier for the tunnel instance.
  • Tunnel ID: The IP address used to identify the tunnel endpoint on the remote side.
• Bound Interface: 11, Local Gateway: static/1, Tunnel Interface: intf/0
  • Bound Interface: Interface number to which the tunnel is bound.
  • Local Gateway: Specifies the gateway mode, with 'static' indicating a fixed gateway configuration.
  • Tunnel Interface: The internal interface designation used by the tunnel.
• Mode: auto/1, Encapsulation: none/528
  • Mode: Tunnel mode, with 'auto' suggesting automatic negotiation.
  • Encapsulation: Defines the encapsulation method used, 'none' indicates no additional encapsulation like GRE.
• Options: create_dev, frag-rfc, accept_traffic=1
  • create_dev: Indicates a virtual device is created for the tunnel.
  • frag-rfc: Fragmentation behavior follows RFC standards.
  • accept_traffic: The tunnel is configured to accept traffic.
• Proxy ID Number: 1, Child Number: 0, Reference Count: 11
  • Proxy ID Number: The identifier for the proxy setting within the tunnel.
  • Child Number: Indicates the number of child sessions under the main tunnel.
  • Reference Count: Number of references or dependencies on this tunnel.
• Inbound/Outbound Last Sequence Number: 7/87, Address: /0
  • Inbound/Outbound Last Sequence Number: Last sequence numbers for inbound and outbound traffic, indicating traffic flow.
  • Address: Represents the IP address scope the tunnel covers, with /0 indicating all addresses.
• Statistics: RX packets=0, TX packets=0, RX bytes=0, TX bytes=0
  • Tracks the number of packets and bytes received (RX) and transmitted (TX), essential for monitoring traffic volume.
• DPD: Mode=on-demand, Idle Timeout=20000ms, Retry Count=3, DPD Sequence No.=0
  • Mode: Dead Peer Detection mode, with 'on-demand' activating DPD based on traffic patterns.
  • Idle Timeout: Time before DPD checks are initiated during idle periods.
  • Retry Count: Number of retries for DPD checks before declaring the peer dead.
  • DPD Sequence No.: Current sequence number for DPD messages.
• NAT Traversal: Mode=none
  • Specifies that NAT Traversal (NAT-T) is not used, important for tunnels crossing NAT devices.
• Proxy ID: to_HQ2, Protocol=0, SA Reference=2, Serial=1, Auto-negotiate
  • Proxy ID: Identifier linking this configuration to a specific proxy policy.
  • Protocol: The protocol number, with 0 typically representing a wildcard or all protocols.
  • SA Reference: Reference to the Security Association used.
  • Serial: Serial number for the SA, useful in SA management.
  • Auto-negotiate: Indicates if the SA is renegotiated automatically.
• Source/Destination: 0:0.0.0.0/0.0.0.0:0
  • Defines the source and destination IP ranges for the tunnel, here indicating a default or catch-all range.
• SA: Reference Count=3, Options=18227, Type=00, MTU=1438, Expire Time=42927/0B, Replay Window=2048
  • Reference Count: The number of times this SA is referenced within the configuration, indicating its usage.
  • Options: Additional SA options set, affecting how the SA operates.
  • MTU: Maximum Transmission Unit, the largest size of IP packets that the SA can transmit.
  • Expire Time: Time after which the SA expires and needs renewal or re-establishment.
  • Replay Window: Size of the window for checking packet replay, a security feature against replay attacks.
• Life Type=01, Bytes=0/0, Timeout=42930/43200
  • Life Type: Indicates the lifetime type of the SA, typically based on time or bytes.
  • Bytes: The maximum bytes that can be transmitted before the SA expires, here indicating unlimited.
  • Timeout: Time in seconds before SA expiration or rekeying needs to occur.
• Decryption: SPI=ef9ca700, ESP Algorithm=AES, Key Length=16, AH Algorithm=SHA1, AH Key Length=20
  • Details the decryption parameters for incoming traffic, including the algorithm and key lengths used.
• Encryption: SPI=791e898e, ESP Algorithm=AES, Key Length=16, AH Algorithm=SHA1, AH Key Length=20
  • Specifies the encryption parameters for outgoing traffic, including the Security Parameter Index and key specifics.
• Decrypted Packets/Bytes=0/0, Encrypted Packets/Bytes=0/0
  • Tracks the count of decrypted and encrypted packets and bytes, indicating traffic volume and encryption activity.

This diagnostic output meticulously details the setup, status, and security settings of the IPsec VPN tunnel "to_HQ2", enabling comprehensive insight for effective management and troubleshooting.

Packet Sniffer

ref: Troubleshooting Tip: Using the FortiOS built-in packet sniffer for capturing packets

ref: Troubleshooting Tip: Enable Policy Trace in Debug Flow

The packet sniffer 'sits' in the FortiGate and can display the traffic on a specific interface or on all interfaces.

The diagnose sniffer packet command supports a variety of filter options to help narrow down the packet capture to exactly what you're interested in. Below are some of the key filtering options:

diagnose sniffer packet <interface> '<filter>' <verbose> <count> a

• host - Captures packets with a specific IP address, either source or destination.
• src - Captures packets originating from a specific source IP address.
• dst - Captures packets destined for a specific destination IP address.
• net - Captures packets within a specified network or subnet.
• port - Captures packets with a specific TCP or UDP port number.
• src port - Captures packets originating from a specific source port.
• dst port - Captures packets destined to a specific destination port.
• tcp - Captures only TCP packets.
• udp - Captures only UDP packets.
• icmp - Captures only ICMP packets.
• ip - Captures packets based on IP protocol number.
• arp - Captures ARP (Address Resolution Protocol) packets.
• ether proto - Captures packets based on Ethernet protocol type.
• less - Captures packets smaller than a certain byte size.
• greater - Captures packets larger than a certain byte size.

These filter options can be combined using logical operators like and, or, and not to create more complex filters. This allows for highly specific and targeted packet captures for troubleshooting and analysis.

There are three different levels of information, also known as Verbose Levels 1 to 3, where verbose 1 shows less information and verbose 3 shows the most. Verbose Levels 4, 5, and 6 additionally provide the interface details. 6 can be used to convert captured packages with a perl script to a .pcap

• 1: Print header of packets.
• 2: Print header and data from IP of packets.
• 3: Print header and data from Ethernet of packets.
• 4: Print header of packets with interface name.
• 5: Print header and data from IP of packets with interface name.
• 6: Print header and data from Ethernet of packets with interface name.

This article walks through some examples to show the different possibilities for debugging with the packet sniffer.

• <interface>: Can be a specific interface name or 'any' for all interfaces.
• <'filter'>: A powerful filter functionality for targeted packet capture.
• <verbose>: Determines the level of detail provided in the packet information.
• <count>: The number of packets to read before stopping the capture.
• a: Timestamps the packets with the absolute UTC time.
• l: Timestamps the packets with LOCAL time on the unit.
• (blank/no letter): Timestamps are relative to the beginning of the capture.

diagnose sniffer packet any 'host x.x.x.x' - Captures all packets from or to IP address x.x.x.x.

GUI: Network > Diagnostics > Packet Capture - Packet Capture in WebUI.

diagnose sniffer packet any 'net x.x.x.x/24' - Captures all packets within the x.x.x.x/24 subnet.

diagnose sniffer packet any 'tcp' - Captures all TCP packets regardless of source or destination.

diagnose sniffer packet any 'tcp port xx' - Captures all packets for TCP port xx.

diagnose sniffer packet any 'udp' - Captures all UDP packets regardless of source or destination.

diagnose sniffer packet any 'udp port xx' - Captures all packets for UDP port xx.

diagnose sniffer packet any 'icmp' - Captures all ICMP packets (used for ping).

diagnose sniffer packet any 'host x.x.x.x and host y.y.y.y' - Captures all traffic between IP addresses x.x.x.x and y.y.y.y.

diagnose sniffer packet any 'not icmp' - Captures all packets except ICMP.

diagnose sniffer packet any 'src x.x.x.x and tcp port xx' - Captures all packets from source IP x.x.x.x to TCP port xx.

diagnose sniffer packet any 'dst host y.y.y.y' - Captures all packets destined for IP address y.y.y.y, regardless of the source.

diagnose sniffer packet any 'src host x.x.x.x and dst host y.y.y.y' - Captures all packets originating from IP address x.x.x.x and destined for IP address y.y.y.y.

Flow Trace

Flow trace commands allow for detailed inspection of how packets are processed within the FortiGate, offering insights into traffic handling and routing decisions.

diagnose debug enable - Crucial for initiating detailed flow analysis, enabling execution debugging offers deep insight into packet processing.

diagnose debug flow filter <filter> - Apply filters to pinpoint trace outcomes. Utilize source IP (saddr), destination IP (daddr), port, among others, to refine results.

diagnose debug flow show iprop en - Activates IP routing info display for packet tracing, essential for understanding packet paths.

diagnose debug flow show func en - Shows function names in packet processing, aiding in pinpointing processing stages.

diagnose debug flow trace start [count] - Begins tracing for a defined packet count, offering real-time flow insights.

GUI: Network > Diagnostics > Debug Flow - Leverage WebUI for a more intuitive flow trace experience, featuring visual aids.

diagnose debug flow filter addr x.x.x.x - Isolates traffic to/from a specific IP, simplifying flow analysis.

diagnose debug flow filter net x.x.x.x/24 - Focuses on a subnet's traffic, useful for network segment troubleshooting.

diagnose debug flow filter port xx - Narrows down traffic by TCP/UDP port, facilitating service-level inspection.

diagnose debug flow filter protocol tcp|udp|icmp - Filters by protocol type, crucial for protocol-specific debugging.

Advanced Filtering: Combine conditions like source IP and destination port for tailored analysis. Example: diagnose debug flow filter saddr x.x.x.x daddr y.y.y.y port xx for targeted tracing.

Session Troubleshooting

Understanding and managing firewall sessions are critical for diagnosing network issues and ensuring optimal performance of your FortiGate firewall.

diagnose system session filter - Sets a filter for session listing, allowing for targeted troubleshooting. Filters can be applied based on source or destination IP, ports, and more.

• Source IP: Filter sessions originating from a specific IP address.
• Destination IP: Filter sessions destined to a specific IP address.
• Ports: Specify source or destination ports to filter sessions based on application traffic.
• Protocol: Filter by protocol (TCP/UDP/ICMP) to isolate sessions of a specific type.
• Policy ID: Focus on sessions handled by a specific firewall policy.

To use the command, you specify one or more filter criteria, which then apply to subsequent session list or clear commands. For example, to filter by source IP, you would use:

diagnose system session filter src x.x.x.x

This sets the session filter to only include sessions with the specified source IP address. You can clear the filter with:

diagnose system session filter clear

Using these filters effectively can greatly simplify the process of diagnosing and resolving network flow issues through your FortiGate device.

diagnose system session list - Displays a list of all current sessions that match the filter criteria. Adding "expect" shows only sessions that are expected based on the filter, helping in isolating specific flows.

diagnose system session clear - Clears all current sessions or those matching a previously set filter. Useful for resetting session states during troubleshooting or after configuration changes.

diagnose system session stat - Provides statistics about sessions and memory usage, including dropped sessions and clashes. This command offers insights into the health and performance of the firewall's session handling capabilities.

diagnose firewall iprope clear 100004 [<id>] - Resets counters for specific firewall policy IDs or all policies if no ID is specified. This can be helpful in monitoring the effects of policy changes or in resetting counters for troubleshooting or for hardening firewall policies by removing the unsued onces and purposes.

These commands are powerful tools for diagnosing and troubleshooting issues related to firewall sessions, offering insights into how sessions are initiated, processed, and terminated through the FortiGate device.

Wireless Controller

execute wireless-controller restart-acd - Restart wireless controller daemon.

execute wireless-controller reset-wtp - Restart FortiAPs.

diagnose wireless-controller wlac -c ap-rogue - List rogue APs.

execute wireless-controller spectral-scan <wtp-id> <radio-id> <on | off> <duration> <channel> <report-interval> - Start or stop spectrum analysis.

diagnose wireless-controller wlac -c rf-sa <wtp-id> <radio-id> <channel>

get wireless-controller spectral-info <wtp-id> <radio-id> - Show spectrum analysis results.

Switch Controller

diagnose switch-controller switch-info mac-table - Managed FortiSwitch MAC address list.

diagnose switch-controller switch-info port-stats - Managed FortiSwitch port statistics.

diagnose switch-controller switch-info trunk - Trunk information.

diagnose switch-controller switch-info mclag - Dumps MCLAG related information from FortiSwitch.

execute switch-controller get-conn-status - Get FortiSwitch connection status.

execute switch-controller diagnose-connection <switch> - Get FortiSwitch connection diagnostics.

FortiExtender

get extender sys-info <ext-sn> - Check the FortiExtender status.

get extender modem-status <ext-sn> - Get the detailed modem status of the FortiExtender.

diagnose debug appl extenderd -1 - FortiExtender debugging, collect information for about 5 minutes.

execute extender reset-fortiextender - Restart managed FortiExtender.

execute extender restart-fortiextender-daemon - Restart FortiExtender daemon.

ref: Technical Tip: How to identify Inactive Routes in the Routing Table

get router info routing-table all - Routing table.

# get router info routing-table all
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
       O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       V - BGP VPNv4
       * - candidate default

• K: Indicates routes learned from the kernel. These routes are usually directly connected to the device.
• C: Represents connected routes, which are networks directly connected to the FortiGate device.
• S: Denotes static routes, which are manually configured routes rather than dynamically learned.
• R: Indicates routes learned through the RIP (Routing Information Protocol) routing protocol.
• B: Represents routes learned through the BGP (Border Gateway Protocol) routing protocol.
• O: Denotes routes learned through the OSPF (Open Shortest Path First) routing protocol.
• IA: Represents OSPF inter area routes, which are routes between OSPF areas.
• N1: OSPF NSSA external type 1 routes.
• N2: OSPF NSSA external type 2 routes.
• E1: OSPF external type 1 routes.
• E2: OSPF external type 2 routes.
• i: Indicates routes learned through the IS-IS (Intermediate System to Intermediate System) routing protocol.
• L1: Represents IS-IS level-1 routes.
• L2: Denotes IS-IS level-2 routes.
• ia: IS-IS inter area routes.
• V: Indicates BGP VPNv4 routes.
• *: Marks a candidate default route. It is a route that may be used as the default route if no other more specific route matches.

get router info routing-table details x.x.x.x - Shows Routing decision for specified Destination-IP.

get router info routing-table database - Routing table with inactive routes.

get router info kernel - Forwarding information base.

diagnose firewall proute list - List of policy-based routes.

diagnose ip rtcache list - List of route cache.

get router info protocols - Overview of dynamic routing protocol configuration.

execute router restart - Restart of routing process.

diagnose system link-monitor status/interface/launch - Shows link monitor status / per interface / for WAN LLB.

get router info bgp summary - BGP summary of BGP status.

get router info bgp neighbors - Information on BGP neighbors.

diagnose ip router bgp all enable

diagnose ip router bgp level info - Real-time debugging for BGP protocol.

execute router clear bgp all - Restart of BGP session.

get router info ospf status - OSPF status.

get router info ospf interface - Information on OSPF interfaces.

get router info ospf neighbor - Information on OSPF neighbors.

get router info ospf database brief / router lsa - Summary / Details of all LSDB entries.

get router info ospf database self-originate - Information on LSAs originating from FortiGate.

diagnose ip router ospf all enable

diagnose ip router ospf level info - Real-time debugging of OSPF protocol.

execute router clear ospf process - Restart of OSPF session.

diagnose system sdwan member - Provide Interface details.

diagnose system sdwan health-check status | filter <name/member> - State of SLAs.

diagnose system sdwan service <rule-id> - SD-WAN-Rule-State.

diagnose system sdwan intf-sla-log <intf-name> - Link Traffic History.

diagnose system sdwan sla-log <sla> <link_id> - SLA-Log on specific interface.

diagnose test appl lnkmtd 0/1/2 - Statistics of link-monitor.

diagnose debug appl link-mon -1 - Real-time debugger of link-monitor.

FINALY UNDERSTANDING ROUTING

ref: Technical Note: Routing behavior depending on distance and priority for static routes, and Policy Based Routes

Imagine you have a big fortress (FortiGate) guarding your home (network). Inside your home, you have two doors leading outside, one in the front (WAN1) and one in the back (WAN2). Beyond those doors are two paths (ISP1 and ISP2) leading to different places. Now, let's talk about how your fortress decides which door to use when sending messages (traffic) out.

Scenario 1: Same Distance, Same Priority

Imagine both WAN connections are equally good, and they have the same priority. So, if you want to send a message, you can choose either WAN connection. Your fortress will send out messages through both connections equally.

Scenario 2: Different Distance, Same Priority

Now, let's say one WAN connection (WAN2) is a bit closer to some places than the other WAN connection (WAN1), but they still have the same priority. Your fortress will prefer the closer WAN connection, even though both connections are equally important.

Scenario 3a: Same Distance, Different Priority

Imagine both WAN connections are equally close to everywhere, but you've labeled one WAN connection (WAN1) as slightly more important (priority 2) than the other WAN connection (WAN2, priority 5). So, even though both connections are available, your fortress will mostly use the more important WAN connection for messages. The less important one is used only for certain special tasks.

Scenario 3b: Same Distance, Different Priority

Now, let's switch it around. The less important WAN connection (WAN2, priority 1) is labeled as more important than the other WAN connection (WAN1, priority 2). Your fortress will now mainly use the previously less important WAN connection for

Scenario 4: Same Distance, Same Priority, Policy-Based Route

Suppose you have a rule saying that all letters (HTTP traffic) should go out through WAN2, regardless of how important the WAN connections are. So, even if WAN1 is closer or more important, all letters will still go out through WAN2 because of this special rule.

Scenario 5: Same Distance, Different Priority, Policy-Based Route

Now, imagine WAN2 is less important, but you still want all letters to go out through it. Your fortress will mostly use the more important WAN1 for messages, but all letters will still go out through the less important WAN2 because of the special rule.

ref: Equal cost multi-path

Imagine you have a big fortress (FortiGate) guarding your home (network). Inside your home, you have two doors leading outside, one in the front (WAN1) and one in the back (WAN2). Beyond those doors are two paths (ISP1 and ISP2) leading to the same place. ECMP is like having multiple paths to the same forest, and you want to use them all equally to avoid congestion.

Prerequisites for ECMP:

1. Same destination and costs: All paths (Doors) leading to the same forest (ISP) must have the same distance and priority. This ensures that your Fortress knows these paths are equally good.
2. Same routing protocol: All these paths should be part of the same routing system. It's like they all speak the same language so they can work together smoothly.

ECMP and SD-WAN:

ECMP and SD-WAN are like two different ways of managing traffic. They have similar rules, but they work in slightly different situations.

Different Load-Balancing Algorithms:

Configuring ECMP:

Your Fortress can be set to use different ECMP modes. You can do this through the settings. If you're using SD-WAN, it's a bit different but still easy to set up.

Examples of ECMP in Action:

1. Default ECMP: Imagine you have two paths (Doors) to the same forest (ISP). Your Fortress sends traffic equally through both paths (Doors).
2. Different Priority: If one path (Door) is more important but both go to the same forest (ISP), your Fortress sends most of the traffic through the more important path (Door), but still uses the other one.
3. Weight-Based: Imagine one path (Door) can handle more traffic than the other. Your Fortress sends more traffic through the wider path (Door).
4. Load-Balancing BGP Routes: If you're using BGP (Border Gateway Protocol) to find the best routes, ECMP helps balance traffic across multiple BGP paths.

Hardware Information Commands:

Gaining insight into your FortiGate device's hardware is crucial for understanding its capabilities and monitoring its health. Below are commands that provide information on CPU, memory, and hardware acceleration, among others.

• diagnose hardware sysinfo cpu - Retrieves information about the CPU, including its type, usage, and performance statistics. For example, you might see CPU model, core count, and current utilization percentage.
• diagnose hardware sysinfo conserve - Provides details about the conserve mode, which is triggered when the system is under resource pressure. It shows the cause, such as "Mem" for Memory or "FD" for File Descriptor limitations.
• diagnose hardware sysinfo memory - Displays memory size and utilization, including total memory, used memory, and available memory. This command helps in monitoring the overall memory health of the device.
• diagnose hardware sysinfo shm - Shows shared memory (SHM) size and utilization, which is important for processes that require inter-process communication.
• diagnose hardware test suite all - Runs a comprehensive hardware test, available only on newer models. This can help identify potential hardware issues or failures.
• get hardware status - Provides information about ASICs (Application-Specific Integrated Circuits) and NP (Network Processors), offering insights into the hardware acceleration capabilities of the device.
• get vpn status ssl hw-acceleration-status - Displays the hardware acceleration status for SSL VPN, indicating whether SSL VPN traffic is being accelerated by dedicated hardware.
• get hardware nic <interface> - Shows physical interface information, including status, speed, and other physical layer details. Replace <interface> with the specific interface name, like "port1".
• get system interface physical / transceiver - Retrieves signal information for copper or SFP/SFP+ interfaces, useful for diagnosing physical connectivity issues.

Examples:

diagnose hardware sysinfo cpu - Retrieves CPU information, such as type and usage statistics, essential for assessing the processing capacity and performance of the device.

diagnose hardware sysinfo conserve - Shows details about Conserve Mode, which indicates the device is under resource strain, typically due to memory or file descriptor limitations. Useful for identifying when and why the device enters a resource conservation state.

diagnose hardware sysinfo memory - Displays memory size and utilization stats. This command is crucial for monitoring the device's memory health, showing total, used, and available memory.

get vpn status ssl hw-acceleration-status - Shows the hardware acceleration status for SSL VPN, indicating whether SSL encryption and decryption are being offloaded to dedicated hardware, thus enhancing VPN performance.

get hardware nic port1 - Provides physical interface information for "port1", including status, speed, duplex, and other relevant physical layer details. This is useful for troubleshooting connectivity issues or assessing link status.

FortiGate provides several commands for disk operations, allowing administrators to check usage, list disks and partitions, perform disk checks, and format disks or partitions.

• diagnose system logdisk usage - Provides information on log disk usage. This command is essential for monitoring the amount of space logs are consuming on the disk, helping to manage storage capacity effectively.
• diagnose hardware deviceinfo disk - Lists all disks along with their partitions. It's useful for getting a detailed overview of the disk layout and understanding how storage is allocated on the device.
• execute disk list - Similar to the previous command, it lists the disks and their partitions. This command is handy for quickly checking disk and partition information.
• execute disk scan [ref_int] - Initiates a disk check operation that scans for and attempts to repair any disk errors. The optional [ref_int] parameter allows specifying a particular disk or partition for the scan. This command is crucial for maintaining disk integrity and preventing data corruption.
• execute disk format [ref_int] - Formats the specified disk or partition ([ref_int] refers to the disk or partition reference identifier) and reboots the system. This operation is used for cleaning a disk or partition, effectively removing all data and resetting it to its initial state. Due to the data loss involved, it should be used with caution.
• execute formatlogdisk - Specifically formats the log disk and includes a system reboot. This command is particularly useful when needing to clear all logs from the device, such as during troubleshooting or when preparing the device for a fresh configuration. As with any format operation, it results in data loss and should be performed carefully.

These commands are integral to the disk management and maintenance processes within a FortiGate environment. Proper use can help ensure optimal performance, prevent disk space issues, and maintain the integrity of stored data. However, commands that alter disk data, such as format operations, should be used judiciously to avoid unintended data loss.

config firewall policy
   set auto-asic-offload disable - Disable session offloading per firewall policy.

config vpn ipsec phase-1-int
   sset npu-offload disable - Disable VPN offloading per Phase 1.

cfg –a ADDR_MODE=DHCP|STATIC - Change IP from DHCP to static on FortiAP.

cfg –a AP_IPADDR=”xxx.xxx.xxx.xx” - Set static IP on FortiAP.

cfg –a AP_NETMASK=”255.255.255.0” - Set subnet mask on FortiAP.

cfg –a IPGW=”yyy.yyy.yyy.yyy” - Set gateway on FortiAP.

cfg –a AC_IPADDR_1=”zzz.zzz.zzz.zzz” - Specify IP of Wireless Controller on FortiAP.

cfg –s / -c - List / Save config on FortiAP.

cfg -x - Reset to factory default.

ref: Technical Tip: How to check the stats for the LTE modem

Description: Most LTE modems come with a preset APN in the SIM card, making it unnecessary to set the APN in FortiOS configuration most of the time. However, if internet access issues occur, consulting the carrier about the APN and configuring it in the LTE modem can be essential.

Solution: To configure the APN in the LTE modem, use the following commands:

config system lte-modem
   set status enable
   set apn "xxx.xxxxx.xxx"
end

INFO: Also make use to disable the PIN is any set on the SIM card to make life much easier

For Signal Strength

diagnose system lte-modem signal-info - Retrieves LTE modem signal information, providing details like RSSI, ECIO for WCDMA, and RSSI, RSRQ, RSRP, SNR for LTE, crucial for diagnosing signal quality and strength.

LTE Modem signal information example:

# diagnose system lte-modem signal-info
WCDMA:

    RSSI:       -57
    ECIO:       12

LTE:

    RSSI:       -67
    RSRQ:       -13
    RSRP:       -98
    SNR:        44

• WCDMA:

  • RSSI: Received Signal Strength Indication. It represents the strength of the received signal. In this example, the RSSI value is -57 dBm, where a higher (less negative) value indicates stronger signal strength.
  • ECIO: Energy to Interference Ratio. It measures the ratio of energy from the serving cell to the interference energy from other cells. A higher ECIO value indicates better signal quality. In this example, the ECIO value is 12.

• LTE:

  • RSSI: Received Signal Strength Indicator. Similar to WCDMA RSSI, it represents the strength of the received LTE signal. In this example, the RSSI value is -67 dBm.
  • RSRQ: Reference Signal Received Quality. It indicates the quality of the received signal, taking into account both signal strength and interference. In this example, the RSRQ value is -13 dB.
  • RSRP: Reference Signal Received Power. It represents the received signal power from a specific cell tower. In this example, the RSRP value is -98 dBm.
  • SNR: Signal-to-Noise Ratio. It measures the ratio of signal power to the noise power in the received signal. A higher SNR value indicates better signal quality. In this example, the SNR value is 44 dB.

For Traffic Status

diagnose system lte-modem traffic-status - Shows LTE modem traffic status, including counts of transmitted and received packets (both OK and error), overflows, bytes (OK), and dropped packets. This information is valuable for monitoring the data flow and identifying potential transmission issues.

LTE Modem traffic status example:

# diagnose system lte-modem traffic-status
TX packets OK:        8513
RX packets OK:        10842
TX packets error:     0
RX packets error:     0
TX overflows:         0
RX overflows:         0
TX bytes OK:          748973
RX bytes OK:          8770104
TX packets dropped:   0
RX packets dropped:   0

• TX packets OK: 8513 - Indicates the number of packets successfully transmitted without errors.
• RX packets OK: 10842 - Represents the number of packets successfully received without errors.
• TX/RX packets error: 0 - Shows the number of packets that encountered errors during transmission or reception. In this example, no errors were encountered.
• TX/RX overflows: 0 - Indicates the number of packet overflows that occurred during transmission or reception. A packet overflow happens when the system cannot process packets quickly enough. In this example, there were no overflows.
• TX bytes OK: 748973 - Specifies the total number of bytes successfully transmitted without errors.
• RX bytes OK: 8770104 - Specifies the total number of bytes successfully received without errors.
• TX/RX packets dropped: 0 - Indicates the number of packets that were dropped during transmission or reception. Packet dropping can occur due to various reasons such as congestion, buffer overflow, or configuration issues. In this example, no packets were dropped.

Some Other Commands:

• diagnose system lte-modem traffic-status - LTE Modem traffic status.
• diagnose system lte-modem modem-details - LTE Modem detailed information.
• diagnose system lte-modem sim-info - LTE Modem SIM card information.
• diagnose system lte-modem signal-info - LTE Modem signal information.
• diagnose system lte-modem data-session-info - LTE Modem data session information.
• diagnose system lte-modem gps-info - LTE Modem GPS information.
• diagnose system lte-modem data-usage - LTE Modem data usage.