Troubleshooting network connectivity issues can often feel like navigating a labyrinth. You know data is flowing, but where is it getting lost? This is where the humble yet powerful traceroute command becomes an invaluable tool, especially when dealing with enterprise-grade firewalls like Fortinet FortiGates. Understanding how to perform and interpret a traceroute on Fortinet devices is a critical skill for any network administrator or security professional. It allows you to map the path that packets take from your FortiGate to a destination, revealing each hop along the way and highlighting potential bottlenecks or failures.

This comprehensive guide will dive deep into using traceroute on your FortiGate, covering everything from basic commands to advanced interpretation and troubleshooting scenarios. Whether you're using the FortiGate CLI or the graphical interface, you'll gain the confidence to diagnose and resolve complex network path problems.

Why Use Traceroute on Fortinet?

Before we get into the 'how,' let's quickly cover the 'why.' Network administrators often turn to traceroute (or tracert on Windows, though the core functionality is the same) for several key reasons:

• Identifying Latency Issues: Pinpointing which hop in the network path is introducing significant delays. This is crucial for optimizing application performance.
• Locating Packet Loss: Determining at which router or network segment packets are being dropped.
• Verifying Network Paths: Confirming that traffic is taking the intended route across your network and beyond.
• Diagnosing Connectivity Problems: When users report they can't reach a specific server or website, traceroute can show if the issue lies within your internal network, your ISP, or further out.
• Understanding Firewall Policies: In complex FortiGate setups, traceroute can sometimes indirectly help understand how traffic is being processed at each firewall rule.

The insights gained from a fortinet traceroute are fundamental to maintaining a healthy and performant network. It provides a clear, hop-by-hop view that static configurations or simple ping tests cannot offer.

Performing Traceroute from the FortiGate CLI

The Command Line Interface (CLI) is often the most direct and powerful way to interact with your FortiGate. For performing a traceroute, the CLI offers flexibility and detailed output. The primary command you'll use is execute traceroute.

Basic Traceroute Command

The most straightforward traceroute fortinet cli command involves specifying the destination host or IP address:

execute traceroute <destination_ip_or_hostname>

Example:

execute traceroute 8.8.8.8

or

execute traceroute www.google.com

When you execute this command, the FortiGate will begin sending out UDP packets (by default) to the specified destination. Each packet will have an incrementally increasing Time To Live (TTL) value. As the TTL reaches zero at each router along the path, that router sends back an ICMP "Time Exceeded" message. The FortiGate captures the IP address and response time from these ICMP messages, effectively mapping out each hop.

Understanding the Output (CLI)

The output from execute traceroute typically looks like this:

1  192.168.1.1 (192.168.1.1)  1.234ms  1.567ms  1.890ms
2  10.0.0.1 (10.0.0.1)  5.678ms  5.901ms  6.123ms
3  203.0.113.1 (203.0.113.1)  10.111ms  10.333ms  10.555ms
...

Let's break down what each part means:

• Hop Number: The first column indicates the hop number, starting from 1 (usually your FortiGate's outbound interface IP). Each subsequent number represents a router along the path.
• IP Address (and Hostname if resolved): The second column shows the IP address of the router at that hop. If the FortiGate can resolve the IP address to a hostname (via DNS), it will display that as well. This can be very helpful for identifying specific ISPs or network providers.
• Round-Trip Times (RTTs): The subsequent columns (usually three) display the round-trip time in milliseconds (ms) for probe packets sent to that specific hop. These times indicate the latency to reach and receive a response from that router.

Key observations from the output:

• Consistent low RTTs: Indicates a healthy and responsive hop.
• Sudden increase in RTTs: Suggests a bottleneck or congestion at that specific hop or further down the path.
• Asterisks (* * *): This signifies that no response was received from that hop within the allotted time. This could indicate packet loss, that the router is configured to not send ICMP "Time Exceeded" messages, or that a firewall is blocking the ICMP responses. Multiple consecutive asterisks can point to a network outage or a significant problem.

Advanced Traceroute Options (CLI)

The execute traceroute command offers some helpful options for more granular analysis:

• -n (Numeric output): Prevents DNS lookups for IP addresses, speeding up the process and showing only IP addresses. This is useful if DNS resolution is slow or failing.

  execute traceroute -n 8.8.8.8
  

• -I (Use ICMP Echo): By default, traceroute uses UDP packets. Using ICMP echo requests (ping) can sometimes be more effective, especially if intermediate devices block UDP probes or if the destination server primarily responds to ICMP. Note: Not all FortiGate versions or configurations might fully support this option directly within execute traceroute in the same way a standalone ping -I works. It's often more reliable to stick with UDP for the traceroute command itself.

• -p <port> (Specify UDP Port): Allows you to specify the destination UDP port for the probes. The default is usually 33434.

  execute traceroute -p 80 8.8.8.8
  

• -m <max_ttl> (Set Maximum TTL): Limits the number of hops the traceroute will attempt. The default is usually 30.

  execute traceroute -m 15 8.8.8.8
  

Traceroute from a Specific Source Interface (CLI)

In complex FortiGate deployments with multiple interfaces and routing policies, it's often crucial to understand the traffic path originating from a specific internal network or VLAN. You can achieve this by specifying the source interface and IP address.

First, you need to determine the source IP address and associated interface that would logically be used to reach your destination. This often involves checking your static routes or policy routes.

Once you have the source IP address, you can use it with the traceroute command:

execute traceroute host <destination_ip_or_hostname> source <source_ip>

Example: If you want to traceroute from your internal "LAN" interface (assuming its IP is 192.168.10.1) to 8.8.8.8:

execute traceroute host 8.8.8.8 source 192.168.10.1

This is an extremely powerful feature for diagnosing routing issues specific to certain internal segments. It helps confirm that the correct outbound policy and routing are in place.

Performing Traceroute from the FortiGate GUI

While the CLI offers more control, the FortiGate GUI also provides a user-friendly way to perform a traceroute, particularly for quick checks. The exact location might vary slightly between FortiOS versions, but it's generally found under Network > Tools.

1. Log in to your FortiGate GUI.
2. Navigate to Network > Tools.
3. Locate the Traceroute section.
4. Enter the Destination IP Address or Hostname.
5. You may have an option to select the Source Interface or Source IP Address.
6. Click Start (or a similar button).

The GUI will then display the traceroute results in a clear, often tabular format, similar to the CLI output but rendered graphically. This is an excellent option for less technical users or for quickly verifying a path without needing CLI access.

Interpreting Traceroute Results: Common Scenarios

Understanding the output is key to effective troubleshooting. Let's look at some common scenarios:

Scenario 1: Successful Traceroute to a Public IP

1  192.168.1.254 (192.168.1.254)  0.5ms  0.7ms  0.9ms
2  10.10.10.1 (10.10.10.1)  2.1ms  2.3ms  2.5ms
3  * * *
4  203.0.113.1 (203.0.113.1)  15.5ms  16.0ms  15.8ms
...
50 8.8.8.8 (8.8.8.8)  30.1ms  30.5ms  30.2ms

• Interpretation: This looks like a healthy traceroute. Hops 1 and 2 are likely internal to your network or your ISP's network. Hop 3 showing asterisks might mean that router doesn't respond to ICMP, or it's a deliberate configuration. Crucially, the trace reaches the destination (8.8.8.8) with reasonable latency (around 30ms). This indicates good overall connectivity.

Scenario 2: Packet Loss or High Latency

1  192.168.1.254 (192.168.1.254)  0.8ms  1.0ms  1.2ms
2  10.10.10.1 (10.10.10.1)  2.5ms  2.7ms  2.9ms
3  203.0.113.1 (203.0.113.1)  80.5ms  95.2ms  88.1ms  <-- High Latency
4  203.0.113.5 (203.0.113.5)  85.0ms  120.5ms  90.1ms
5  *
6  *
7  203.0.113.20 (203.0.113.20)  150.1ms  *  160.5ms <-- Intermittent Loss
...

• Interpretation: Observe the significant jump in latency at hop 3. This is the first indicator of a problem. The subsequent hops also show elevated and inconsistent times, with hops 5 and 6 not responding at all, and hop 7 showing intermittent packet loss (one out of three probes failed). The problem likely lies at or after hop 3. This might be a congested link, a faulty router, or a misconfiguration further upstream.

Scenario 3: Traceroute Stops Prematurely

1  192.168.1.254 (192.168.1.254)  0.7ms  0.9ms  1.1ms
2  10.10.10.1 (10.10.10.1)  3.1ms  3.3ms  3.5ms
3  203.0.113.1 (203.0.113.1)  18.2ms  18.5ms  18.8ms
4  *
5  *
6  *

• Interpretation: The traceroute stops responding after hop 3. This is a critical issue. It means packets are not reaching the destination. Potential causes include:
  • A firewall rule blocking ICMP Time Exceeded messages from hop 4 onwards.
  • A complete network outage beyond hop 3.
  • A routing misconfiguration preventing packets from being forwarded.
  • The destination itself is unreachable or blocking the probes.

To investigate further, you might need to try pinging the destination directly or traceroute from a different source to isolate the problem.

Troubleshooting with Fortinet Traceroute

When you encounter issues, using traceroute on Fortigate is just the first step. Here’s how to leverage the results:

1. Isolate the Problematic Hop: Identify the first hop where latency significantly increases or where packets are lost (asterisks). This is your primary suspect.

2. Check FortiGate Routing: If the issue appears to be with internal routing, review your FortiGate's routing table (get router info routing-table all). Ensure static routes and policy routes are correctly configured to direct traffic towards the problematic hop's next step.

3. Verify Firewall Policies: Does your FortiGate policy allow the traffic type (UDP/ICMP) to be sent to the destination? While traceroute uses ICMP or UDP probes, the actual application traffic might be blocked by a different policy.

4. Source Interface/IP: If the traceroute stops or shows issues only when originating from a specific internal IP or interface, re-examine the routing and policies associated with that source. Use the source option in the CLI command (execute traceroute host <dest> source <src_ip>).

5. Intermediate Device Checks: If the problematic hop is within your direct control (e.g., another internal router or switch), log into that device and perform a traceroute from its perspective to see if it can reach the subsequent hop.

6. ISP Engagement: If the problematic hops are clearly outside your network and belong to your ISP or upstream providers, you'll need to provide them with the traceroute output. Clearly stating the source IP, destination IP, and the problematic hop number will be crucial for them to investigate.

7. DNS Resolution Issues: If hostnames are not resolving in your traceroute output, it might indicate a DNS problem on your FortiGate or within your network. Try using the IP address directly.

What About "Trace Route Fortigate" or "Fortigate Trace Route"?

Users searching for variations like "trace route fortigate" or "fortigate trace route" are looking for the same core functionality: understanding the path network packets take through their FortiGate firewall and beyond. The underlying command and principles remain identical whether you use traceroute or trace route. The FortiGate CLI uses execute traceroute, and the GUI presents a similar tool. These searches are simply alternative phrasings for the same diagnostic need.

Common Pitfalls and Considerations

• ICMP Blocking: Many network devices are configured to not respond to ICMP requests for security or performance reasons. This can lead to asterisks (* * *) in your traceroute output even if the path is functional. If your traceroute stops prematurely, try using a UDP-based traceroute (the default) or specifying a common port like 80 or 443.
• Asymmetric Routing: In some network designs, traffic may take one path from source to destination and a different path back. A traceroute might only show one of these paths. If you're experiencing one-way connectivity, a traceroute from both ends can be helpful.
• Dynamic IP Addresses: Intermediate hops might have dynamic IP addresses, meaning their IP could change between tests. Relying on hostnames can be helpful here, but if they don't resolve, stick to IP addresses.
• FortiOS Version Differences: While the core traceroute functionality remains consistent, the exact command syntax or GUI options might have minor variations across different FortiOS versions. Always refer to the official Fortinet documentation for your specific version if you encounter unexpected behavior.

Frequently Asked Questions (FAQ)

Q: What is the default protocol for traceroute on FortiGate?

A: By default, execute traceroute on FortiGate uses UDP packets to trace the route.

Q: How do I traceroute from a specific internal network on my FortiGate?

A: Use the execute traceroute host <destination> source <source_ip> command in the CLI, replacing <source_ip> with the IP address of the FortiGate interface that should be used for outbound traffic from that internal network.

Q: Why do I see asterisks (* * *) in my traceroute output?

A: Asterisks indicate that no ICMP Time Exceeded message was received from that hop within the timeout period. This could be due to the router not responding to ICMP, a firewall blocking the ICMP response, or packet loss.

Q: Can I trace a route to an IP address or a hostname?

A: Yes, you can provide either an IP address or a hostname (e.g., www.example.com) as the destination. The FortiGate will attempt to resolve hostnames to IP addresses.

Q: How can I tell if my FortiGate itself is the bottleneck?

A: If the first hop (your FortiGate's outbound IP) shows unusually high latency, or if latency increases dramatically right after the first hop, it could indicate an issue with the FortiGate's processing or its immediate link. However, a single high latency on hop 1 is more likely an issue with the downstream network. Consistent high latency across multiple probes to hop 1 is more concerning.

Conclusion

Mastering the traceroute Fortinet functionality is an essential skill for effective network diagnostics. By understanding the commands, interpreting the output, and knowing how to troubleshoot common issues, you can quickly pinpoint network path problems. Whether you're performing a simple execute traceroute for a quick check or using the source IP option for complex routing scenarios, this tool provides invaluable visibility into your network's traffic flow. Regularly using these diagnostic capabilities on your FortiGate will lead to a more stable, performant, and secure network.