pjhtech Tools
FortiGate · FortiOS 7.4

FortiGate route lookup and policy route commands

Quick answer #

A route to the destination is only one part of the forwarding decision. Inspect the routing table, then test the complete source/destination flow against policy routing. If the connection already exists, inspect its session as well: a lookup prediction is not a substitute for observing the established flow.

Scope: FortiGate/FortiOS 7.4-family IPv4 route inspection. Run in the affected VDOM; VRF context must match the traffic.

Find the destination route #

Find the destination route
FortiOS 7.4 · Traffic VDOM; administrative scope as described below

Read-only

Replace these example values: 192.0.2.80.

get router info routing-table detail 192.0.2.80
Read-only
get router info routing-table all
Read-only
get router info routing-table database

Start with the destination-specific command. The full table gives context, while the database can expose route candidates that are not active. On a large routing system, retain only the relevant prefix and next-hop information in the incident record rather than dumping every route into a ticket.

Check that the destination belongs to the expected longest matching prefix. Record the selected interface and gateway. Also look up the source address when investigating reverse-path checks or asymmetric routing. A default route can hide the absence of the more-specific VPN route you expected.

Match policy routing with the real tuple #

Match policy routing with the real tuple
FortiOS 7.4 · Traffic VDOM; administrative scope as described below

Read-only
diagnose firewall proute list
Read-only

Replace these example values: 192.0.2.80, 10.20.30.40, port2, 55000.

diagnose ip proute match 192.0.2.80 10.20.30.40 port2 6 443 55000

The argument order is destination, source, incoming interface, IP protocol, destination port and source port. Here 6 is TCP; 55000 is an illustrative client source port. Substitute the actual values from a capture when a policy depends on them. Reversing the first two addresses produces a plausible-looking answer to the wrong question.

Interpret the two views #

The route table shows available IP forwarding paths. Policy routing adds conditions such as the incoming interface, source network and service. SD-WAN rule processing also needs separate attention when present. The policy-route result can therefore explain why a client's traffic uses a different path from the one suggested by a simple destination-only lookup.

If no policy-route match is returned, do not immediately call it a failure. Traffic may legitimately use ordinary routing, including after a stop-policy-route rule. Confirm the actual egress with a filtered capture or session entry.

Avoid a misleading test #

A ping generated by the firewall is not identical to a forwarded client session. Its source and processing context can differ, so a successful firewall ping does not prove that the client's policy route matches. Keep the client tuple, VDOM and ingress interface attached to every saved result. This makes the evidence reproducible for another administrator.

Sources

Documentation reviewed: 8 October 2026