FortiGate Routing: Patterns and Pitfalls

FortiGate routing sits at the intersection of network engineering and security policy. A packet can have a perfectly valid firewall rule and still fail because the route is wrong, asymmetric, withdrawn, or learned from an unexpected source. Conversely, a correct routing table can create a security problem if path changes send traffic through an interface or inspection point that was never intended. Production routing on FortiGate therefore needs to be designed as part of the security architecture, not as a separate configuration layer.

The July 2026 Fortinet certification transition makes NSE 4 the current FortiGate administration level. The Fortinet NSE roadmap explains that program shift; the operational skills below remain central regardless of naming.

Read the routing table before changing policy

When a flow fails, administrators often start with firewall policy because it is visible and familiar. A better sequence is to understand forwarding first. Confirm the destination route, next hop, outgoing interface, administrative distance, priority, and whether the route is active. If multiple candidates exist, determine why one won. Only after the path is clear should you decide whether policy is the problem.

This habit prevents a common failure mode: loosening security rules to solve what is actually a routing issue. It also makes troubleshooting faster because FortiGate policy matching depends on the interface path selected by routing.

Static routes are simple until redundancy arrives

Static routing is predictable, but production networks rarely stay simple. Backup links, multiple internet providers, private circuits, and site-to-site VPNs introduce competing paths. A static route design should account for distance, priority, link monitoring, and failure behavior. It is not enough to configure a secondary route and assume it will behave as expected when the primary path fails.

Test failure explicitly. Remove or disable the primary next hop, observe route convergence, confirm sessions recover or re-establish correctly, and check whether the return path follows the same design. Redundancy that has never been tested is only a diagram.

Policy routes can solve one requirement and create another

Policy-based routing is useful when forwarding must depend on source, destination, service, or other traffic attributes rather than destination prefix alone. Typical examples include directing selected applications through a specific WAN link or sending a management subnet over a private path. The danger is that policy routes add another decision layer administrators must remember during troubleshooting.

Use policy routes sparingly and document their intent. When a path looks inexplicable, check whether policy routing is overriding the normal route table before changing dynamic-routing metrics or firewall policies.

Dynamic routing needs clear control boundaries

OSPF and BGP can make FortiGate participate in resilient enterprise designs, but dynamic routing increases the number of ways reachability can change. Define which prefixes may be learned and advertised, where redistribution is allowed, and what filters or route maps enforce policy. An unrestricted redistribution point can turn a local routing mistake into a network-wide incident.

FortiGate routing and SD-WAN should be evaluated with security context as well as reachability. Route acceptance, advertisement, health checks, and path preference can change which security boundary a flow crosses, so a technically valid route can still violate the intended inspection or segmentation design.

Dynamic routing should be governed by an explicit advertisement policy. Decide which prefixes belong in the protocol, where summarization is safe, what redistribution is allowed, and which paths should be preferred before tuning protocol attributes. A stable adjacency can still carry the wrong routes, so session health and routing intent must be verified separately.

Route leaks and accidental default propagation are examples of failures that may look healthy at the protocol level. Prefix filters, route maps, communities, or equivalent policy controls should be reviewed as security and resilience mechanisms, not only as optimization tools.

Asymmetric routing is a security problem as well as a path problem

Stateful inspection expects to see enough of a session to maintain state. If forward and return traffic take different firewalls or different paths, session handling can fail or behave unexpectedly. Asymmetric designs may be intentional in some environments, but they need explicit support and testing rather than accidental tolerance.

When troubleshooting intermittent connectivity, compare the forward path and return path. Look for ECMP, multiple upstream routers, dynamic-routing changes, or external devices choosing a different exit. A packet capture on only one interface can be misleading if half the conversation is somewhere else.

SD-WAN changes how path selection is expressed

FortiGate Secure SD-WAN can select paths using performance, business policy, and service health rather than static preference alone. That improves resilience but also means the routing question becomes, “Which rule and health state selected this member?” Administrators should understand the relationship between the routing table, SD-WAN rules, performance SLAs, and firewall policy.

Do not treat an SLA as a decorative monitoring object. Validate the probes, thresholds, target availability, and failback behavior. A badly chosen target can declare a healthy circuit failed or keep an unusable path active.

Troubleshooting SD-WAN routing should separate control-plane reachability from member selection. A destination can exist in the routing table while health checks or service rules steer traffic onto a different member. Verify the candidate routes, health-check state, rule match, selected member, and return path in that order so route changes do not mask a policy or SLA problem.

VPN routes should be reviewed with selectors and policy

IPsec connectivity depends on more than the tunnel status indicator. Check how routes reach the tunnel, which selectors or phase-2 settings apply, which policies permit the traffic, and whether NAT is changing addresses unexpectedly. Route-based VPNs simplify many designs, but the tunnel interface still participates in the forwarding and policy model.

FortiGate VPN design and troubleshooting becomes part of routing analysis whenever tunnel selectors, negotiation state, learned routes, or security policy determine whether a destination is actually reachable through the encrypted path.

Routing changes need a before-and-after evidence set

For a meaningful change, capture the current route, expected new route, relevant neighbors, and one or two representative traffic flows. After implementation, verify the same evidence. This creates a disciplined comparison and makes rollback decisions easier. It also reveals unintended changes, such as a default route winning where only a specific prefix was meant to move.

For dynamic protocols, include adjacency or peer state and advertised/received routes. For SD-WAN, include member health and rule selection. For static changes, confirm not just the route table but the traffic path.

A routing design should fail predictably

The true test of routing architecture is not normal operation; it is failure. Ask what happens when a WAN circuit drops, a BGP peer disappears, an SLA target becomes unreachable, or a route is accidentally advertised from another site. Define the preferred failover, acceptable convergence, and security implications before the event occurs.

FortiGate administration becomes much safer when routing, policy, NAT, and inspection are reviewed together. The FortiGate system configuration material supports that integrated view.

For every preferred path, define the backup path and the condition that makes it active. Then test whether the surviving path has enough reachability and capacity to carry the required traffic. Redundancy that exists only in the routing table is not sufficient if upstream dependencies, NAT, VPN selectors, or policy prevent useful failover.

Blackhole or discard routes can be deliberate safety controls when more-specific dynamic routes disappear. They prevent traffic from following an unsafe summary or default path during a failure. The design should document why the discard exists, its distance or preference, and the condition under which a more-specific route should normally supersede it.

Troubleshoot the forwarding decision, not the symptom

A practical workflow is route lookup, policy path, NAT behavior, session state, then packet evidence. That sequence follows how the device actually handles traffic. It is usually more productive than changing several settings and hoping connectivity returns.

The wider Fortinet certification ecosystem covers many products, but FortiGate routing skill remains foundational because almost every security control depends on traffic reaching the intended inspection point. Predictable forwarding is a prerequisite for predictable security.

Route summarization and advertisement boundaries deserve explicit design in larger FortiGate deployments. Summaries can simplify tables and improve stability, but they can also hide failures or attract traffic toward a site that cannot actually reach every summarized prefix. Before advertising a summary, understand what happens when only part of the underlying network is available. Black-holing caused by an overconfident aggregate is a routing design failure, not merely a protocol quirk.

Equal-cost multipath should also be tested with stateful inspection in mind. Multiple eligible next hops can improve utilization and resilience, but session distribution, return-path behavior, NAT, and upstream hashing all influence whether traffic remains stable. If an application is sensitive to path changes, measure actual session behavior instead of assuming that multiple routes automatically improve availability.

For BGP-connected environments, build troubleshooting around control-plane evidence: peer state, received prefixes, advertised prefixes, selected paths, route maps, communities, and next-hop reachability. A BGP session that is Established can still carry the wrong routes. Conversely, a missing prefix may be caused by policy rather than a failed neighbor. The evidence should explain both adjacency and routing intent.

A good routing runbook ends with a traffic proof. After confirming the control plane, test a representative flow, inspect the session, and verify the egress interface and return path. This connects protocol health to user experience and prevents teams from declaring success because a route exists on screen.

Route monitoring should include trend information rather than only up/down alarms. Flapping peers, repeated SLA failures, rising convergence times, or frequent route changes can indicate instability long before users report a sustained outage. Track the frequency and duration of control-plane changes so engineering teams can distinguish a one-time incident from a deteriorating circuit, unstable neighbor, or poorly tuned design.

When FortiGate is deployed in virtual or cloud environments, routing assumptions may also depend on the platform. Virtual NIC behavior, cloud route tables, transit services, and provider failover mechanisms can influence forwarding outside the appliance. Troubleshooting should identify where the routing decision is actually made at each hop. A correct FortiGate route does not prove the surrounding virtual network is delivering packets to the expected interface.

Document route ownership as well. A prefix learned from BGP, injected by SD-WAN, installed statically, or created through a tunnel may have different operational owners. Knowing who can change each path prevents troubleshooting from becoming a sequence of uncoordinated edits.

Finally, preserve packet evidence during unusual failures. A short capture showing ingress, egress, next-hop behavior, and return traffic can resolve disagreements between routing and security teams quickly and provides a baseline for later comparison.

For recurring incidents, compare route changes with application-impact timestamps. This helps separate harmless control-plane churn from events that actually affect service and gives engineering teams evidence for tuning thresholds or redesigning unstable paths.

Routing policy should make failure behavior explicit. For every preferred path, identify the alternate, the signal that declares the primary unusable, the convergence mechanism, and any security-policy or NAT change that the alternate path requires. A backup route that exists but cannot pass the same inspected traffic is not real resilience. Test the complete service path under failure, including return traffic, because stateful enforcement makes asymmetric recovery particularly dangerous.

Dynamic routing and SD-WAN can interact in ways that are easy to misdiagnose. A route may be present while an SD-WAN rule selects a different member based on health or service criteria; a member may be healthy at one probe target while the application path is degraded elsewhere. Collect the routing-table decision, SD-WAN rule match, health-check status, and session result together. Looking at only one table can produce a correct observation and still lead to the wrong conclusion.

Route changes also deserve a rollback threshold. Before adjusting distance, priority, policy route, BGP attribute, or SD-WAN rule, define the expected traffic movement and what evidence would indicate harm. After the change, verify representative flows instead of only protocol adjacency. This avoids a common production trap in which the control plane looks stable while a subset of sessions follows an unintended path or loses required inspection.