1. Introduction to Network Path Analysis on FortiGate Firewalls

When managing enterprise networks, visualizing the exact path your packets take as they traverse from your internal networks to remote destinations is fundamental to troubleshooting. Whether you are dealing with a degraded WAN connection, an unstable IPsec VPN tunnel, or asymmetric routing across a complex SD-WAN topology, identifying where a communication chain breaks down is critical. In the Fortinet ecosystem, the primary CLI diagnostic utility designed for this purpose is the traceroute utility.

Using the traceroute command fortigate administrator shell allows network engineers to inspect hop-by-hop latency and confirm packet paths directly from the security gateway. Unlike consumer network devices, a FortiGate firewall offers advanced controls to fine-tune your path tracing. You can manipulate the source IP address, force traffic through designated physical interfaces, bind queries to specific Virtual Domains (VDOMs), or align traces with SD-WAN rules.

Understanding how to execute and customize these traces from the FortiGate Command Line Interface (CLI) is an indispensable skill. In this comprehensive guide, we will break down the syntax, explore the underlying protocols, configure stateful options, and walk through real-world scenarios to help you locate and resolve network bottlenecks with speed and precision.

2. FortiGate Traceroute Foundations: Syntax and Mechanics

To begin troubleshooting, you must first access the FortiGate CLI, either via the GUI-integrated CLI Console widget or through a secure SSH session. The foundational command to execute a standard network path trace to an IPv4 target is:

execute traceroute <destination>

Here, <destination> can be either a target IPv4 address or a Fully Qualified Domain Name (FQDN). For example:

execute traceroute 8.8.8.8

Or, using a domain name:

execute traceroute www.fortinet.com

If your network utilizes IPv6 routing and you have the feature enabled within your FortiGate interface configuration, you can execute a path trace to an IPv6 target using the companion command:

execute tracert6 <destination_ipv6>

For example:

execute tracert6 2001:db8:a0b:13e0::6

The Underlying Mechanics: UDP vs. ICMP

To fully interpret traceroute results and avoid common troubleshooting pitfalls, you must understand the underlying protocols at play. Many network engineers assume that all traceroutes behave identically. However, there is a fundamental difference in how different operating systems execute this utility:

• Windows OS (tracert): By default, Microsoft Windows sends ICMP Echo Request packets (Type 8, Code 0) with incrementally increasing Time-to-Live (TTL) values.
• Linux, macOS, and FortiGate (traceroute): By default, these platforms send UDP datagrams to a range of high-numbered destination ports (typically starting at UDP port 33434 and incrementing by 1 for each subsequent probe).

When the FortiGate executes execute traceroute, it transmits UDP packets with a TTL of 1. The first hop router decrements the TTL to 0, discards the packet, and returns an ICMP Time Exceeded message (Type 11, Code 0) to the FortiGate. The FortiGate records the IP address of this router and the round-trip response time. This process repeats, incrementing the TTL by 1 with each set of probes, until the destination host is reached. When the UDP packets arrive at the destination, the target host attempts to process the packet on the specified high-numbered UDP port. Since that port is typically closed, the host sends back an ICMP Destination Port Unreachable message (Type 3, Code 3), signifying that the trace is complete.

This architectural difference explains a very common point of confusion: Why does a traceroute from a Windows host succeed, while an execute traceroute from the FortiGate CLI to the same destination fails?

The answer lies in security policy configurations. Intermediate firewalls, service providers, or the target network itself may be configured to permit standard ICMP traffic (like pings) while blocking high-range UDP ports (33434–33534). Conversely, some networks block all ICMP messages to prevent network mapping, which results in asterisks (* * *) along the path even though application traffic flows smoothly. Recognizing this protocol distinction is key to formulating accurate diagnoses.

3. Mastering the Stateful Nature of execute traceroute-options

One of the most powerful and unique features of the FortiGate CLI is the statefulness of its troubleshooting configurations. In Cisco IOS, if you want to run a traceroute with a specific source IP, you must define all arguments inline within a single command structure. FortiGate approaches this differently by utilizing a dedicated configuration environment called execute traceroute-options.

When you modify options within this namespace, your choices are saved globally for your active CLI session. Subsequent executions of execute traceroute will respect these customized parameters until you either manually reset them or close your connection.

To view the current configuration of your traceroute utility, execute:

execute traceroute-options view-settings

A default, unmodified system will return the following output:

Traceroute Options:
Number of probes per hop: 3
Source Address: auto
Device: auto
SD-WAN: no
VRF: 0

Let's explore each sub-command within the execute traceroute-options family to see how you can customize your diagnostics.

3.1 Specifying a Source IP Address (source)

By default, when you run a traceroute from the CLI, the FortiGate selects the IP address of the egress interface as the source IP, determined by a lookup in the routing table. However, this may not reflect the real-world traffic paths of your internal clients. For instance, if you are troubleshooting traffic from a secure VLAN or a DMZ, you need to verify if that specific subnet can reach the destination.

To force the traceroute to originate from a designated IP address, use:

execute traceroute-options source <source_ip>

For example, to test the path as if the traffic is originating from a local LAN gateway of 192.168.10.1:

execute traceroute-options source 192.168.10.1

Now, any execute traceroute command you run will use 192.168.10.1 as the source IP in the IP header of the UDP probe packets.

3.2 Forcing an Egress Interface (device)

If your FortiGate has multiple active WAN interfaces (e.g., dual ISPs on wan1 and wan2), or if you are running complex internal segmentation, you might want to bypass standard routing table decisions to test a specific physical or virtual link.

To pin the traceroute to a specific interface, use:

execute traceroute-options device <interface_name>

For example, to force the trace to exit out of your second ISP interface:

execute traceroute-options device wan2

3.3 Adjusting Probe Count (queries)

For each hop along the path, the FortiGate sends a default of three probe packets (queries) to calculate response variance and detect intermittent packet loss. If you are conducting a broad diagnostic trace and want to speed up the execution, or if you require deeper packet sampling to identify jitter, you can modify this value:

execute traceroute-options queries <integer>

The configurable range is 1 to 10. To limit the query count to a single probe per hop for rapid path identification, enter:

execute traceroute-options queries 1

3.4 Aligning with SD-WAN Rules (use-sdwan)

By default, the FortiGate handles CLI-generated traffic (such as self-originated pings and traceroutes) as local-out traffic. Local-out traffic is traditionally routed strictly via the main Routing Information Base (RIB) table, bypassing SD-WAN rules. In modern SD-WAN deployments, this means a CLI traceroute might exit a different WAN link than the production traffic from your LAN.

To ensure your diagnostics accurately reflect your SD-WAN policies, you can instruct FortiOS to run the traceroute against your active SD-WAN rule base:

execute traceroute-options use-sdwan {yes | no}

To enable this feature:

execute traceroute-options use-sdwan yes

3.5 Routing within Virtual Routing and Forwarding (vrf)

In complex enterprise networks, Virtual Routing and Forwarding (VRF) is used to segment routing tables at Layer 3. If your management interface or a specific customer network resides in a separate VRF context, you must direct your traceroute queries to look inside that specific table:

execute traceroute-options vrf <integer>

To test connectivity within VRF 2:

execute traceroute-options vrf 2

3.6 Resetting Your Traceroute Environment (reset)

Because these settings are stateful, failing to clear them is one of the most common mistakes network administrators make. If you set a specific source IP or egress device, finish your troubleshooting, and leave the session open, any future traces you (or a colleague using the same console session) run will continue to use those static parameters. This can lead to highly inaccurate diagnostic conclusions.

To return all traceroute options back to their system defaults, always run:

execute traceroute-options reset

Confirm the reset by verifying the settings:

execute traceroute-options view-settings

4. Real-World Troubleshooting Scenarios

Let's walk through concrete scenarios where combining these commands helps isolate complex network issues.

Scenario A: Debugging IPsec VPN Tunnel Path Failures

Imagine a scenario where users on your local network (10.100.1.0/24) cannot access a file server at a remote site (10.200.1.50). The IPsec VPN tunnel between the two sites is up and negotiating phase 2 security associations, but no traffic is passing.

If you run a simple execute traceroute 10.200.1.50, the FortiGate will attempt to source the packet from its public WAN IP because it is local-out traffic. Because the VPN security policies are configured to only encrypt traffic moving from the local subnet (10.100.1.0/24) to the remote subnet (10.200.1.0/24), the public WAN IP source does not match the tunnel's "interesting traffic" selectors. The packet is routed out to the public internet where it is promptly dropped, yielding a failing trace.

To accurately troubleshoot, you must force the trace to originate from the internal LAN gateway IP:

1. Set the source IP:

   execute traceroute-options source 10.100.1.1
   

2. Verify your options are applied:

   execute traceroute-options view-settings
   

3. Execute the traceroute:

   execute traceroute 10.200.1.50
   

Interpreting the Output:

• If hop 1 is the local IPsec virtual interface (e.g., tunnel interface IP) but subsequent hops are asterisks (* * *), the traffic successfully entered the VPN tunnel. The issue resides either on the remote firewall's security policies (blocking incoming UDP queries) or on the return path from the remote subnet back to your local subnet.
• If hop 1 attempts to exit via your public ISP gateway, the FortiGate's routing table does not have an active route pointing target subnet 10.200.1.0/24 to the IPsec virtual interface. Double-check your static or dynamic routes.

Once you have isolated the issue, clean up your diagnostic environment:

execute traceroute-options reset

Scenario B: Diagnosing Jitter and Loss in Multi-WAN SD-WAN Setups

Suppose your organization utilizes dual WAN connections: wan1 (a high-speed but occasionally unstable broadband connection) and wan2 (a symmetrical, stable fiber connection). Users report intermittent audio drops during VoIP calls. Your SD-WAN rules are designed to send traffic over wan1 under normal conditions, failing over to wan2 only if latency exceeds 150ms.

To verify if the instability is originating within the first few hops of your primary ISP (wan1), you can run a targeted trace:

1. Pin the trace to the wan1 interface:

   execute traceroute-options device wan1
   

2. Increase the query count to gather a better statistical sample per hop:

   execute traceroute-options queries 5
   

3. Run the trace to a reliable public host (e.g., a DNS server):

   execute traceroute 8.8.8.8
   

Interpreting the Output:

# execute traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 32 hops max, 5 probe packets per hop
 1  203.0.113.1  2.112 ms  1.989 ms  2.045 ms  1.991 ms  2.102 ms
 2  198.51.100.45  85.431 ms  12.110 ms  140.892 ms  12.441 ms  195.120 ms
 3  198.51.100.1  14.120 ms  13.989 ms  14.212 ms  13.881 ms  14.005 ms

In this sample output, notice the high variance in hop 2 (198.51.100.45), which ranges from a fast 12.11ms up to a highly latent 195.12ms. This tells you that the local link between your FortiGate and the ISP's gateway is stable (hop 1 is consistently around 2ms), but the immediate upstream hop within your provider's routing infrastructure is experiencing congestion or routing instability.

To compare this path behavior against your second provider, reset and redirect the trace:

execute traceroute-options reset
execute traceroute-options device wan2
execute traceroute-options queries 5
execute traceroute 8.8.8.8

If the trace through wan2 exhibits flat, low latency, you have solid evidence to present to your primary ISP regarding upstream link issues.

Scenario C: Troubleshooting inside Virtual Domains (VDOMs)

In multi-tenant environments where the physical FortiGate is segmented into multiple Virtual Domains (VDOMs), routing tables and interfaces are isolated. If you attempt to run a traceroute while logged in to the global administration layer, the CLI won't know which routing table to reference.

To run a trace within a specific VDOM, you must first switch your CLI context:

1. Enter the VDOM configuration mode:

   config vdom
   

2. Select and enter the target VDOM:

   edit Tenant_A_VDOM
   

3. Execute your traceroute options or run the trace directly:

   execute traceroute 1.1.1.1
   

By entering the specific VDOM context, the command utilizes that customer's unique routing table, local-in configurations, and physical/logical interface mapping.

5. Packet-Level Diagnostics and Verification

Sometimes, relying solely on the text-based output of a traceroute is not enough. If you run a trace and receive nothing but asterisks after the first hop, you must determine whether the FortiGate is actually transmitting the UDP packets, or if the incoming ICMP response packets are being dropped by the firewall itself.

To verify this, you can leverage FortiGate's built-in packet sniffer in a secondary CLI window while running your trace.

Sniffing Traceroute Traffic

Open an SSH session to your FortiGate and execute the following sniffer command. This filter targets the specific range of UDP destination ports used by FortiGate's traceroute utility, as well as incoming ICMP packets:

diagnose sniffer packet any 'udp portrange 33434-33534 or icmp' 4 10 a

Let's break down the sniffer arguments:

• any: Instructs the sniffer to monitor all interfaces.
• 'udp portrange 33434-33534 or icmp': Captures outgoing UDP probe packets and any incoming ICMP "Time Exceeded" or "Destination Unreachable" responses.
• 4: Verbosity level. Level 4 prints the packet headers along with interface names.
• 10: Capture count. Tells the sniffer to stop after capturing 10 matching packets.
• a: Formats the packet timestamps to show absolute system time, which is highly useful when correlating logs.

While the sniffer is active, run your traceroute in your primary CLI window. You should see output similar to the following:

port1 out 192.168.1.99.51001 -> 8.8.8.8.33434: udp 40
port1 in 10.0.0.1 -> 192.168.1.99: icmp: time exceeded in-transit
port1 out 192.168.1.99.51002 -> 8.8.8.8.33435: udp 40

Analyzing the Sniffer Logs:

1. Outgoing UDP Packets: If you see packets labeled out going to UDP ports like 33434, 33435, etc., you have confirmed that the FortiGate's local-out routing logic is functioning and the packets are physically leaving the firewall.
2. Missing Outgoing Packets: If you do not see outgoing packets, the firewall's local-out traffic might be blocked by a Local-In security policy, or there is a routing loop causing the packet to be dropped internally.
3. Incoming ICMP Responses: If you see incoming icmp: time exceeded packets labeled in, but your traceroute console output still shows asterisks (* * *), the FortiGate's operating system is receiving the path responses but dropping them before the traceroute application can process them. This is typically caused by overly restrictive Local-In security policies.

Local-In Policies and Traceroute

FortiGate firewalls process traffic directed to the firewall itself differently than traffic passing through the firewall. Local-In policies control what traffic is allowed to terminate on the FortiGate's interfaces.

If you have implemented strict Local-In policies to harden your firewall against external discovery, you must ensure that you permit incoming ICMP Type 11 (Time Exceeded) and ICMP Type 3 (Destination Unreachable) packets on your external interfaces. If these are blocked, your CLI traceroutes will fail to register the return path, displaying a row of empty hops even though internet routing is working perfectly.

6. FortiGate Traceroute Troubleshooting FAQ

Why does my FortiGate traceroute only display asterisks (* * *)?

Asterisks indicate that the FortiGate did not receive a response within the timeout window for those specific probes. This can happen for several reasons:

1. Upstream Security Filtering: Intermediate routers or firewalls along the path are configured to drop UDP probe packets (ports 33434–33534) or block outbound ICMP Time Exceeded (Type 11) responses.
2. Asymmetric Routing: The probe packets are successfully reaching the target, but the return routing path for the ICMP response bypasses the FortiGate, preventing it from recording the hop.
3. Strict Local-In Policies: The incoming ICMP response packets are arriving at your FortiGate's WAN interface but are being discarded by a Local-In security policy before they reach the diagnostic application.

How do I specify a source IP for traceroute in FortiGate?

Because FortiGate's diagnostic utilities are stateful, you must first define the source IP within the options configuration and then run the trace. Run:

execute traceroute-options source <source_IP>
execute traceroute <destination_IP>

Remember to clear your settings when finished by executing execute traceroute-options reset.

Is there a GUI alternative to the CLI traceroute command on FortiGate?

Yes. Within the FortiGate GUI, you can access the CLI Console widget (typically located in the upper-right toolbar or under Dashboard > Status) to execute the commands. Additionally, under Network > SD-WAN, you can configure Performance SLAs. Performance SLAs utilize continuous background ping and traceroute-like probes (active probing) to measure latency, jitter, and packet loss across your WAN links, visualizing these metrics directly within the GUI dashboard.

How do I stop or abort an active traceroute in FortiOS?

If a traceroute is taking too long due to multiple non-responding hops, you can abort the active trace at any time by pressing the key combination:

Ctrl + C

This instantly terminates the query cycle and returns you to the standard CLI prompt.

What does the exclamation mark !H or !N mean in my traceroute output?

If you see characters next to the round-trip times in your traceroute, these represent ICMP error codes returned by a downstream router:

• !H (Host Unreachable): The router has no path to the specific target host IP.
• !N (Network Unreachable): The router has no route in its routing table for the destination subnet.
• !P (Protocol Unreachable): The destination host does not support the specified transport protocol.
• !F (Fragmentation Needed): The packet size exceeds the MTU of a link along the path, and the Don't Fragment (DF) bit is set.

Does changing traceroute options affect production traffic?

No. Modifying settings under execute traceroute-options (such as setting a source IP or a specific egress device) only alters the behavior of diagnostic commands executed from your active CLI console session. It has zero impact on how transit traffic from your LAN or DMZ is routed, ensuring you can safely perform intensive path diagnostics without risking network downtime.

7. Conclusion and Best Practices

The traceroute command on FortiGate is a potent tool for dissecting network path behaviors and identifying where packets are dropped. However, its effectiveness relies heavily on your understanding of its protocol mechanics and stateful configuration environment.

To maximize the value of your diagnostics, incorporate the following best practices into your engineering workflows:

• Always Reset Your Options: Make running execute traceroute-options reset an automatic habit after completing any trace session to prevent subsequent session contamination.
• Align with Production Realities: When testing client connectivity, use execute traceroute-options source to match the exact source IP of the client's subnet, and enable use-sdwan yes to ensure the trace is evaluated against your SD-WAN rules.
• Account for Protocol Discrepancies: Remember that FortiGate uses UDP traceroute probes by default. If a trace fails but standard ping works, check for firewall rules or upstream security policies blocking ports 33434–33534.
• Correlate with Sniffers: When dealing with completely silent traces (all asterisks), run a simultaneous packet sniffer to confirm if probe packets are successfully leaving the gateway and if ICMP responses are returning.

By mastering these CLI commands and diagnostic strategies, you can turn a basic path trace into a comprehensive network audit, rapidly isolating and resolving connectivity issues across even the most complex enterprise topologies.