In enterprise networking, diagnostic tools like ping and traceroute are the bread and butter of daily troubleshooting. When a user reports that they cannot access a remote server or that a branch office connection is slow, a network administrator's first instinct is to run a traceroute from the central firewall. However, executing a standard traceroute from a FortiGate firewall often fails to tell the whole story.

By default, when you run a traceroute command directly from the FortiGate Command Line Interface (CLI), the firewall uses its default routing table to select the egress interface. It then populates the source IP address of the traceroute packets with the primary IP address of that outbound interface. In highly segmented enterprise environments—especially those utilizing IPsec VPNs, Virtual Routing and Forwarding (VRF) instances, or complex SD-WAN architectures—this default behavior is highly problematic.

If you trace a route to an internal host over a VPN tunnel using your public WAN IP as the source, the remote endpoint will likely drop the packets because they do not match security policies or VPN encryption domains. To solve this, you must configure a fortigate traceroute source to control exactly which IP and interface the firewall uses for its diagnostic probes.

Unlike traditional network operating systems (such as Cisco IOS) where you can append a source parameter directly to the end of a single traceroute command, FortiOS separates traceroute configuration from execution. This guide provides an in-depth, step-by-step walkthrough of how to configure and execute a FortiGate traceroute with a source IP, specify egress interfaces, handle advanced routing contexts like VRFs and SD-WAN, and apply these commands to real-world troubleshooting scenarios.

The Core Commands: Configuring the FortiGate Traceroute Source

To troubleshoot routing issues effectively, you need to understand the syntax of FortiOS diagnostic tools. FortiOS handles traceroute options globally per CLI session. This means you must define your traceroute options first, run the traceroute, and then reset the options so that they do not interfere with subsequent tests.

1. Specifying the Traceroute Source IP Address

To set a specific source IP address for your traceroute, use the execute traceroute-options source command:

execute traceroute-options source <source_ip>

For example, if you want to test connectivity to a remote server and simulate traffic originating from your corporate LAN gateway IP (192.168.10.1), you would enter:

execute traceroute-options source 192.168.10.1

Once this command is entered, every traceroute command you run during your current CLI session will use 192.168.10.1 as the source IP address in the IP header of the traceroute packets.

2. Specifying the Traceroute Source Interface (Device)

In multi-WAN or highly redundant networks, simply changing the source IP address might not be enough. You may also want to force the traceroute packets to leave the FortiGate via a specific physical or logical interface. To configure the source interface (referred to as "device" in FortiOS), use the following command:

execute traceroute-options device <interface_name>

For example, if you want to force your traceroute probes to egress through your backup ISP interface (port2 or wan2), run:

execute traceroute-options device port2

Setting the device parameter forces the packet out of the specified interface, regardless of what the main routing table suggests, making it an indispensable tool for diagnosing asymmetric routing or gateway issues.

3. Verifying Your Traceroute Settings

Before running your diagnostic test, it is highly recommended to verify your configured traceroute options. This prevents you from running tests with lingering settings from previous troubleshooting sessions. View your active configuration by executing:

execute traceroute-options view-settings

If you configured the source IP and source interface as shown in the previous steps, the output will look like this:

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

4. Executing the Traceroute

Once you have verified that your fortigate traceroute source ip and fortigate traceroute source interface are set correctly, execute the trace to your destination IP or hostname:

execute traceroute 8.8.8.8

or

execute traceroute corporate-hq.local

The FortiGate will initiate the trace using ICMP packets with an escalating Time-to-Live (TTL) value. It sends three probes per hop by default, displaying the IP addresses and response times of each intermediate router until it reaches the destination or hits the maximum hop limit (typically 32 hops).

5. Resetting to Default Settings (Crucial Step)

Because traceroute options persist throughout your active CLI session, leaving them modified can lead to false diagnostic results during your next troubleshooting task. Once your tests are complete, reset all traceroute options back to their system defaults:

execute traceroute-options reset

Running view-settings after a reset will show that the Source Address and Device have reverted back to auto, meaning FortiOS will once again dynamically choose the egress interface and matching IP based on the active routing table.

Advanced Traceroute Options: SD-WAN, VRFs, and Probes

Modern FortiGate firewalls do much more than basic static routing. To troubleshoot modern enterprise architectures, you must know how the traceroute utility interacts with SD-WAN, Virtual Routing and Forwarding (VRFs), and packet probe quantities.

1. Integrating with SD-WAN Rules

In a standard configuration, administrative traffic generated by the FortiGate itself (local-out traffic) bypasses SD-WAN rules. It defaults to using the system's static routing table to determine the egress path. This means that if you run a traceroute to test a business-critical application, the traceroute might take a completely different physical path than actual user traffic.

To force your FortiGate traceroute to follow your configured SD-WAN rules and profiles, enable the use-sdwan parameter:

execute traceroute-options use-sdwan yes

When use-sdwan is set to yes, FortiOS evaluates your SD-WAN policy rules (such as Lowest Cost, SLA, or Manual path selection) to determine the egress interface for the diagnostic packets. This is the only reliable way to verify if your SD-WAN path-steering policies are working as intended.

2. Troubleshooting Segmented Networks with VRFs

Virtual Routing and Forwarding (VRF) allows you to run multiple independent routing tables on a single FortiGate physical firewall. If you are troubleshooting a multi-tenant network or a highly segmented architecture, running a traceroute from the default global routing table (VRF 0) will fail to reach destinations inside isolated routing domains.

To run your traceroute within a specific VRF context, assign the corresponding VRF ID:

execute traceroute-options vrf <vrf_id>

For example, to execute a traceroute inside VRF 2 (perhaps dedicated to your Guest or IoT network segment):

execute traceroute-options vrf 2

Once set, the traceroute command will look up destinations exclusively within the VRF 2 routing table, utilizing the interface mappings and gateways configured for that virtual routing instance.

3. Customizing the Probe Count per Hop

By default, traceroute sends three ICMP probe packets to each hop. If you are troubleshooting a network with high packet loss or want to speed up your diagnostics, you can adjust the number of queries sent per hop:

execute traceroute-options queries <1-10>

For a rapid, low-overhead path test, reduce the queries to one:

execute traceroute-options queries 1

Alternatively, if you suspect intermittent packet loss and want to gather a broader sample size per hop, increase the queries to five or six.

Real-World Troubleshooting Scenarios

Understanding CLI commands is only half the battle. To appreciate the value of configuring a FortiGate traceroute source, let us examine three common real-world network engineering scenarios where these commands are critical to solving connectivity problems.

Scenario 1: Troubleshooting IPsec VPN Phase 2 Selectors

One of the most frequent use cases for modifying the traceroute source is troubleshooting site-to-site IPsec VPN tunnels.

Consider a scenario where a FortiGate at a branch office has a VPN tunnel established with the Corporate HQ.

• Branch LAN Subnet: 192.168.10.0/24
• Corporate HQ Subnet: 10.100.20.0/24
• Phase 2 Selectors (Proxy-IDs): Only traffic originating from 192.168.10.0/24 and destined for 10.100.20.0/24 is allowed to pass through the encrypted tunnel.

If you log into the Branch FortiGate CLI and execute a default traceroute:

execute traceroute 10.100.20.50

The FortiGate will check its routing table, see that the route to 10.100.20.0/24 is accessible via the IPsec virtual interface, and send the packets. However, because it is local-out traffic, the firewall populates the source IP of the packet with its external public WAN IP (e.g., 203.0.113.5).

When this packet hits the IPsec encryption engine, it is immediately dropped or sent unencrypted out to the public internet because 203.0.113.5 does not match the Phase 2 selector source definition (192.168.10.0/24). To the administrator, the traceroute simply shows constant asterisks (* * *), indicating a routing failure, even though the tunnel is physically up and user traffic is flowing fine.

The Solution: Force the traceroute to originate from the internal LAN interface IP, matching your Phase 2 selectors:

execute traceroute-options source 192.168.10.1
execute traceroute 10.100.20.50

Because the source IP is now 192.168.10.1, the packet successfully matches the VPN tunnel policies and Phase 2 selectors. The traffic is encrypted, traverses the tunnel, and you receive accurate hop-by-hop diagnostic data from the remote corporate network.

Scenario 2: Diagnosing Multi-WAN Routing and Asymmetric Paths

Imagine an enterprise headquarters configured with dual WAN links for ISP redundancy:

• WAN 1 (Primary): Fiber connection on port1
• WAN 2 (Backup): Broadband connection on port2

Users are complaining that a cloud-hosted application is running slowly. You want to see if the latency is coming from the primary ISP routing path or if traffic has failed over to the slower backup broadband path.

By default, a traceroute to the cloud application will exit whichever interface currently holds the active, lowest-distance default route. If you want to compare the performance of both ISPs side-by-side, you can use the device parameter to run isolated path tests:

Test Path via WAN 1:

execute traceroute-options device port1
execute traceroute cloudapp.com

Test Path via WAN 2:

execute traceroute-options device port2
execute traceroute cloudapp.com

By comparing the output of these two traceroutes, you can pinpoint exactly which ISP hop is experiencing high latency or packet loss. This allows you to open an accurate, evidence-backed support ticket with the responsible telecommunications provider.

Scenario 3: Troubleshooting Internal Security Policy Restrictions

Internal network segmentation is a best practice. Modern networks use multiple internal VLANs to isolate departments (e.g., HR, Engineering, Guest, and Management). Let's say a server in the Engineering VLAN (10.50.1.0/24) cannot reach a database server in the Secure Database VLAN (10.99.1.0/24).

You want to verify whether the issue is a core routing failure or if the firewall's internal security policies are blocking the traffic.

By running a default traceroute from the CLI, the firewall may bypass policy checks because local-out traffic to internal interfaces is processed differently than transit traffic. To simulate actual user transit traffic from the Engineering VLAN, set the traceroute source to the firewall's gateway IP on the Engineering VLAN:

execute traceroute-options source 10.50.1.1
execute traceroute 10.99.1.50

If the traceroute fails at the very first hop (the firewall itself), you likely have a local-in policy, a firewall interface block, or an security policy issue. If it hops to an internal core switch and then fails, you can isolate the issue to downstream internal routers or host-level firewalls on the database server itself.

FortiGate Traceroute vs. Ping Options

Traceroute and ping are highly complementary diagnostic tools. When troubleshooting, network engineers frequently alternate between them. Just as FortiOS provides execute traceroute-options, it also features a sister command suite: execute ping-options.

It is important to understand that changing settings for one does not affect the other. They operate as completely independent diagnostic configurations within your CLI session.

Pro-Tip: When troubleshooting a connection, first use execute ping-options source <IP> and run a ping. If the ping fails, transition to execute traceroute-options source <IP> and run a traceroute to identify exactly which hop along the path is dropping your packets.

Troubleshooting Traceroute Output: What Do the Results Mean?

Once you execute your configured traceroute, interpreting the terminal output correctly is key to resolving your ticket.

Interpreting Successful Hops

# execute traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 32 hops max, 3 probe packets per hop, 72 byte packets
 1  192.168.10.254  0.512 ms  0.489 ms  0.472 ms
 2  203.0.113.1 <isp-gateway.net>  2.311 ms  2.105 ms  2.244 ms
 3  198.51.100.45  12.450 ms  11.980 ms  12.112 ms
 4  8.8.8.8 <dns.google>  12.890 ms  12.750 ms  12.812 ms

In this output, each line represent a hop. The three millisecond (ms) values represent the Round-Trip Time (RTT) for each of the three ICMP probes sent to that router. This indicates a perfectly healthy, low-latency path.

Understanding Asterisks (* * *)

 3  198.51.100.45  12.450 ms  11.980 ms  12.112 ms
 4  * * *
 5  * * *
 6  8.8.8.8 <dns.google>  15.220 ms  14.980 ms  15.110 ms

If you see stars/asterisks on intermediate hops, but the final destination (Hop 6) successfully responds, this is not a routing failure. It simply means that the routers at Hop 4 and Hop 5 are configured to ignore ICMP Time-Exceeded messages or have ICMP rate-limiting enabled to protect their control planes from CPU exhaustion. Traffic is traversing them successfully to reach the target.

 3  198.51.100.45  12.450 ms  11.980 ms  12.112 ms
 4  * * *
 5  * * *
 (traceroute hangs until 32 hops are reached)

If the asterisks begin at a certain hop and continue indefinitely until the end of the trace, you have hit a genuine routing loop, black hole, or a firewall blocking diagnostic traffic. The last responding IP (Hop 3 in this case) is usually the device right before the failure point, giving you a clear indicator of where to begin checking routing tables or security policies.

Frequently Asked Questions

Does changing the traceroute source affect live customer traffic traversing the FortiGate?

No. Modifying options via execute traceroute-options only impacts diagnostic packets generated locally by the firewall's command-line interface during your active CLI session. It has absolutely zero impact on production traffic or transit packets flowing through the firewall's security policies.

Why does my traceroute fail when I specify a source IP, but work when I leave it on auto?

This usually points to one of three issues:

1. Routing: The specified source IP belongs to a subnet that the downstream router or ISP gateway does not know how to route back to.
2. Security Policies: There is no firewall policy or Local-In policy allowing traffic from that specific subnet to initiate outbound connections.
3. Asymmetric Routing: The return path for packets sent from that source IP takes a different route, which is being blocked by a security device or dropped due to strict Unicast Reverse Path Forwarding (uRPF) checks on the FortiGate or transit routers.

Can I configure traceroute options via the FortiGate GUI?

No. While newer FortiOS versions feature diagnostic tools under the GUI (usually via the "CLI Console" dashboard widget or via Network > Diagnostics on certain firmware versions), advanced parameter modification—such as setting VRF IDs, specific source interfaces, or adjusting probe counts—is exclusive to the CLI. Learning these commands is essential for advanced network administration.

Is the traceroute source configuration permanent?

No, it is session-based. It persists only as long as your current SSH or console session remains active. If you log out and log back in, the options revert to their default state (auto). However, it is still best practice to manually run execute traceroute-options reset when you finish a troubleshooting session to avoid immediate diagnostic errors.

What is the difference between setting the source IP and setting the device interface?

• Source IP (source): Changes the source address field inside the Layer 3 IP packet header. The packet will still be routed according to the system's routing table.
• Device (device): Overrides the routing table's egress decision, forcing the packet out of a physical interface (such as port1) regardless of standard route lookup. Combining both allows you to simulate exact, highly controlled egress scenarios.

Conclusion

Mastering CLI diagnostic utilities separates junior administrators from senior systems engineers. Understanding how to configure the fortigate traceroute source ensures that your network diagnostic traffic behaves precisely like user transit traffic. By setting the correct source IP, forcing egress out of specific interfaces, navigating VRF environments, and aligning probes with active SD-WAN rules, you can eliminate false negatives, accurately test IPsec VPN tunnels, and pinpoint routing errors across complex network topologies.

Remember to always run execute traceroute-options view-settings to verify your configuration before running a trace, and execute execute traceroute-options reset once your troubleshooting session concludes. Add these commands to your operational runbooks to drastically reduce your mean-time-to-resolution (MTTR) when tackling enterprise network routing issues.