FortiGate administration<\/a>, the durable diagnostic sequence is route table \u2192 exact lookup \u2192 policy route\/SD-WAN \u2192 protocol state \u2192 debug flow\/session \u2192 packet capture \u2192 return path.<\/p>\nThat sequence prevents policy, NAT, and VPN changes from becoming random experiments around a routing problem.<\/p>\n
Routing changes should be correlated with session age. Existing sessions can continue using state created before a route change, while new sessions may follow the new path. When testing, clear only the relevant sessions where safe or use a new flow so the result reflects current routing rather than stale state.<\/p>\n
ECMP and multiple default routes deserve explicit testing because two equal-cost paths can send different sessions through different upstream devices. If only one path has the required NAT, VPN, or return route, the symptom can look intermittent. Confirm the selected next hop per session instead of relying on a single successful ping.<\/p>\n
VRFs and virtual domains add scope to every diagnostic. Check the correct VDOM, routing instance, and interface context before interpreting output. A command run in the wrong scope can show a valid table that simply belongs to another tenant or routing domain.<\/p>\n
Finally, keep routing telemetry and change history accessible. A failed BGP neighbor, SD-WAN SLA change, or route redistribution update often explains the incident faster than manual configuration review. Diagnostics improve when current state and recent changes can be compared side by side.<\/p>
Administrative distance and priority should be interpreted correctly. Multiple routes can cover the same destination, and FortiGate selects among them according to route type, distance, priority, metric, and other protocol-specific attributes. A backup static route with a higher distance can sit in configuration while the primary dynamic route remains preferred; seeing both routes does not mean both are forwarding.<\/p>\n
Recursive next-hop resolution can create another hidden dependency. A BGP-learned prefix can be present while the route to its next hop is missing or points somewhere unexpected. When a route looks valid but is inactive, inspect how the next hop itself is resolved and whether the correct interface is reachable.<\/p>\n
Blackhole routes can be intentional safeguards. They are often used to prevent traffic from following an unwanted default path when a more specific dynamic or VPN route disappears. During troubleshooting, recognize intentional blackhole entries before deleting them; the route may be protecting against leakage rather than causing an outage.<\/p>\n
SD-WAN health checks need to be correlated with path selection. A member can be administratively up but removed from eligible service because latency, jitter, packet loss, or SLA status failed. If a route exists through an SD-WAN zone yet traffic uses another member, inspect the service rule and health state rather than only the kernel route.<\/p>\n
Policy routes should be treated as business exceptions. Because they can steer based on source, destination, service, or other fields, they can override what engineers expect from the ordinary routing table. Maintain clear comments and owners for policy routes, and include them in change review whenever an application unexpectedly changes egress.<\/p>\n
Packet capture should be placed at more than one point when possible. Seeing the request enter the LAN interface proves only that the host sent it. Seeing it leave the WAN interface proves routing and policy reached that point. Seeing no reply points the investigation outside or toward the return path; seeing a reply arrive but no response leave the LAN shifts attention back to session or policy state.<\/p>\n
Debug flow should be correlated with a new test session. Existing sessions can bypass full policy and route reevaluation because FortiGate already has state. When safe, clear only the relevant session or use a fresh source port so diagnostic output reflects current configuration. Never clear the global session table on a production firewall merely to simplify one test.<\/p>\n
Multi-VDOM environments require discipline around scope. Each VDOM can have its own routes, policies, interfaces, and sessions. Global administrators should confirm the target VDOM before running diagnostics or interpreting an interface name that exists in several contexts.<\/p>\n
Route changes should be recorded with timestamps. When an outage begins at 14:03 and a BGP neighbor reset, SD-WAN SLA failure, or static-route edit occurred at 14:02, the correlation can narrow the investigation immediately. Central logging of routing events is an operational control, not just a convenience.<\/p>\n
The best routing troubleshooter uses evidence to remove ambiguity. The routing table explains intended control-plane state; route lookup explains the best path; debug flow explains FortiGate’s per-packet decision; sessions explain established state; and packet capture explains what actually crossed the interfaces. Together they turn routing from guesswork into a reproducible diagnosis.<\/p>\n
Routing incidents should also consider MTU and fragmentation when the path appears correct. IPsec, SD-WAN, provider links, and encapsulation can reduce effective MTU, creating application failures that look like routing loss because small pings work while large TLS or file transfers fail. Packet captures and path-MTU tests can reveal the difference.<\/p>\n
Keep route diagnostics reproducible in runbooks: commands, filters, expected output, and the next decision each result implies. This helps less-experienced operators follow evidence instead of making broad configuration changes during an outage.<\/p>\n
When the issue is intermittent, collect evidence across several failed and successful sessions. Compare selected routes, SD-WAN member, policy ID, NAT, and return path. Intermittent routing problems often come from ECMP, health-check flaps, or inconsistent upstream paths that a single test cannot reveal.<\/p>\n
Review route diagnostics after major topology changes so the runbook still reflects the current interfaces, VDOMs, VRFs, SD-WAN zones, and routing protocols.<\/p>\n
Keep routing evidence attached to incident records so recurring path failures can be compared instead of rediscovered from scratch.<\/p>","protected":false},"excerpt":{"rendered":"
FortiGate routing diagnostics should answer one question at a time: where does the appliance believe this packet should go, and why? Routing problems are often misdiagnosed as firewall policy, VPN, or NAT failures because the packet never reaches the expected interface pair. A systematic workflow starts with the routing table and route lookup, then checks policy routes or SD-WAN, dynamic-protocol state, packet flow, session state, and finally the return path. FortiOS 7.6 provides CLI diagnostics for routing tables, protocol databases, policy routes, SD-WAN health, packet sniffing, session tables, and debug…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-11706","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t