FortiGate routing and SD-WAN work together, but they are not the same control. Routing establishes which paths are valid for a destination; SD-WAN adds policy and health intelligence to choose among eligible members. That distinction is essential for anyone administering FortiOS 7.6 because a perfect SD-WAN rule cannot steer traffic onto a path the routing table does not consider usable. The current NSE 4 FortiOS Administrator scope expects practical understanding of FortiGate operation rather than memorized menu locations.
A sound design starts with the forwarding problem: what destinations must be reachable, through which underlays or overlays, and how should the firewall react when path quality changes? Static routes, dynamic routing, ECMP, SD-WAN zones, performance SLAs, and service rules are tools for answering different parts of that problem. Treating them as one feature leads to troubleshooting mistakes.
Build routing before expecting SD-WAN to steer traffic
FortiGate needs a route toward the destination before SD-WAN can make a useful member selection. In a simple internet design, a default route can point to an SD-WAN zone. Member interfaces can have their own gateway information, while the SD-WAN-aware route represents the forwarding option to the rest of the system.
This means the routing table is an early troubleshooting checkpoint. If traffic never becomes eligible for the SD-WAN zone, changing a performance SLA will not help. Confirm destination lookup, administrative distance, route priority, recursive dependencies, and whether the expected member paths are actually installed.
Static routing remains relevant even in advanced deployments. The fundamentals in static routing—prefix specificity, next-hop reachability, and deterministic forwarding—still apply when the route points toward an SD-WAN construct rather than a single physical WAN interface.
Use dynamic routing when topology outgrows manual routes
Static routes are simple and predictable, but the administrative burden grows as sites, overlays, and destinations multiply. Dynamic routing can advertise reachability and respond to topology changes without requiring a manual route for every remote prefix. FortiGate supports protocols such as OSPF and BGP that are often used in campus, data-center, WAN, and overlay designs.
The protocol should match the problem. OSPF is commonly used for internal topology exchange and shortest-path routing, while BGP provides strong policy controls and scales across administrative boundaries and large overlay designs. A deeper comparison of OSPF and BGP helps explain why neither is a universal replacement for the other.
Dynamic routing does not make SD-WAN health irrelevant. A route can remain logically reachable while the WAN path suffers severe loss or latency. Conversely, an SD-WAN member can have good probe quality while the destination prefix is not available through it. Routing reachability and service quality are separate signals that should agree before traffic is sent.
Organize members into meaningful SD-WAN zones
SD-WAN member interfaces are grouped into zones that can be referenced by firewall policy and routing. Zones provide an abstraction over individual circuits, allowing policies to describe “internet underlay” or “private overlay” rather than hard-coding a specific ISP interface. That simplifies failover because the policy relationship does not need to change when the selected member changes.
Zone design should reflect trust and function. Direct internet circuits and private overlay tunnels may both be WAN paths, but they can have different security and routing roles. Grouping every member into one zone simply because it participates in SD-WAN can erase distinctions the firewall policy still needs.
A useful zone remains stable even as circuits are replaced. If a branch changes ISP but the new circuit serves the same underlay purpose, replacing the member within the zone should require fewer policy changes than replacing references throughout the rule base.
Measure link quality with performance SLAs
FortiOS performance SLAs measure member health using metrics such as latency, jitter, and packet loss. Active probes send health-check traffic to defined targets, while supported passive measurements can derive quality information from real sessions. The purpose is not merely to draw a dashboard; the measurements can influence whether a member remains eligible for traffic.
Targets should represent the service path you care about. Probing a nearby ISP gateway can prove the first hop is alive while saying little about SaaS reachability beyond the provider. Probing a distant public endpoint may add internet variability that obscures a local issue. Choose targets and thresholds that correspond to the actual failure or degradation you want SD-WAN to react to.
Thresholds also need operational realism. Voice is sensitive to jitter and latency in ways a software download is not, so one global definition of “healthy” may be inappropriate. The SD-WAN concept is strongest when path quality is evaluated against application needs rather than a simple up/down link signal.
Use SD-WAN rules to express steering intent
SD-WAN rules, also called service rules, identify traffic and choose a path-selection strategy. They can match criteria such as source, destination, application, or internet service depending on configuration, then select members according to priority, quality, cost, bandwidth, or other supported strategies.
Rule order matters because the administrator may have a business-critical rule above a general internet rule. Define the most meaningful traffic classes first and keep the implicit rule behavior understood. An application that is not recognized as expected can fall through to a different steering rule, so application visibility and policy logging matter during validation.
Steering is not equivalent to access control. A firewall policy still determines whether the session may cross the device. The SD-WAN rule answers which eligible path should carry it. Keeping these decisions separate prevents the common mistake of changing an access policy when the real issue is path selection.
Understand the relationship between route preference and SD-WAN selection
FortiGate first needs routing eligibility; SD-WAN then applies its own logic among the viable members. This explains why an apparently correct service rule can be ignored when the best route does not point to the expected SD-WAN path. It also explains why changing administrative distance or route priority can alter traffic before any SD-WAN strategy is evaluated.
Equal Cost Multi-Path can expose more than one route with equivalent preference. SD-WAN can then add application-aware or health-aware selection on top of those choices. The goal is not to make the routing table disappear but to create a controlled set of candidate paths that the SD-WAN engine can evaluate.
Policy-based routing is another source of precedence that must be understood in designs that use it. The general policy-based routing idea is to override ordinary destination-based forwarding for selected traffic. When PBR, dynamic routing, and SD-WAN coexist, document which mechanism is supposed to win for each class of flow.
Plan failover around sessions, NAT, and remote expectations
Moving traffic from one WAN member to another can change more than the physical path. Source NAT may use a different public address, remote services may see a new origin, tunnels may need to renegotiate, and existing sessions may not survive the transition. A “healthy failover” should therefore be defined in application terms.
Partner allowlists are a common hidden dependency. If a SaaS or business partner accepts traffic only from ISP-A’s public range, steering to ISP-B can restore internet connectivity while the partner application remains broken. Either both egress identities must be approved or the design must provide a stable translated identity through another mechanism.
Testing should include preferred-path failure, degraded quality, and restoration. Observe when routes change, when the SLA marks a member out of service, which SD-WAN rule selects the alternate path, what source address the destination sees, and whether the application recovers without manual intervention.
Observe the system from routing table to SLA metrics
Troubleshooting is most efficient when it follows the decision chain. Start with the destination and routing table. Confirm that the expected SD-WAN zone and members are eligible. Check the performance SLA for packet loss, latency, and jitter. Then inspect the matching SD-WAN rule, firewall policy, NAT behavior, and session state.
This sequence avoids chasing a dashboard symptom. A member marked healthy does not prove the routing table contains the destination. A route in the table does not prove the performance SLA meets the application threshold. A correct SD-WAN selection does not prove the firewall policy or NAT is correct. Each layer answers a different question.
Historical data is useful because intermittent path degradation can disappear before an administrator opens the CLI. Monitoring platforms and logs should retain enough information to show whether a member was withdrawn, whether SLA thresholds were crossed, and whether traffic moved between paths during the incident window.
Route advertisement and health signaling should not fight each other. In an overlay design, a remote site may learn the same prefix across multiple tunnels while SD-WAN measures each transport independently. Decide whether routing metrics, BGP attributes, or SD-WAN service rules provide the primary preference. If all three are tuned independently, one change can produce a path that is technically reachable but contrary to operational intent.
Asymmetric routing is another design risk. A session may leave through one member while the return path reaches a different interface or device. FortiGate is stateful, so designs should preserve a predictable session path or explicitly account for asymmetry. Troubleshooting should compare the forward and reverse routing decisions rather than inspecting only the client-to-server direction.
Performance SLA targets need redundancy too. If every WAN link probes one external IP and that target itself fails, all members can appear unhealthy even though internet service is available. Use an appropriate set of targets or methods so the health check measures the transport rather than the availability of one unrelated server.
Cost and quality policies can also conflict. A low-cost circuit may be preferred while it meets an SLA, with traffic moving to a more expensive path only when quality falls below threshold. That strategy needs thresholds stable enough to avoid rapid oscillation. Review historical latency, loss, and jitter so the policy responds to meaningful degradation rather than ordinary internet variation.
Finally, document the expected implicit-rule behavior. Traffic that matches no explicit SD-WAN rule is still forwarded according to the configured implicit strategy. An unexplained application path often turns out not to be a broken explicit rule at all; the traffic never matched it and was handled by the implicit rule. Logs and session diagnostics should confirm the rule match before administrators change priorities.
Change control for SD-WAN should include a traffic-class impact statement. Adjusting an SLA threshold or member priority can move many applications at once even though no firewall policy changed. Record which service rules reference the modified SLA and which links could receive additional load after the change.
Bandwidth is not the same as quality. A high-capacity circuit with intermittent loss can perform worse for voice or interactive sessions than a smaller stable link. Conversely, bulk backup traffic may benefit from the wider circuit even if its latency is slightly higher. Design steering strategies around application characteristics instead of ranking links with one universal score.
When overlays such as IPsec or ADVPN participate, monitor both the underlay and the tunnel. A tunnel can be up while the underlying path is degraded, or the internet underlay can be healthy while route exchange across the overlay has failed. Keeping those health layers distinct makes branch-to-branch incidents much easier to isolate.
SD-WAN troubleshooting should always record the moment of observation. Routes, SLA state, and selected members can change quickly during a flap, so a screenshot taken after recovery may show a healthy system even though the prior forwarding decision was different. Correlate logs and monitoring timestamps to reconstruct the state when the user actually experienced the failure.
For branch designs, test loss of each individual transport and also partial degradation. A hard-down circuit is the easiest case; excessive loss, rising jitter, or a destination-specific outage better demonstrates whether the SLA and service-rule design can protect real applications.
Route summaries and default routes can hide destination-specific failures. During validation, test important SaaS, data-center, and branch prefixes individually instead of assuming that a successful default-route probe proves every service path. More specific routes can override the default and send selected traffic somewhere entirely different.
Keep an explicit topology map for every SD-WAN member showing provider, gateway, public addressing, NAT behavior, SLA targets, and overlay tunnels. When a member degrades, that map lets responders understand which applications and remote sites are likely to move before they begin changing policy.
Design SD-WAN for explainable behavior
The best SD-WAN configuration is not the one with the most rules. It is the one operators can explain during an outage. Give zones and rules meaningful names, keep SLA targets tied to service objectives, document routing dependencies, and avoid overlapping steering logic that requires guesswork to interpret.
When multiple technologies are available, use them for clear purposes. Static routes can provide simple defaults, BGP can distribute overlay reachability, performance SLAs can measure quality, and SD-WAN rules can steer selected traffic. The SD-WAN, MPLS, and other WAN designs is useful as background, but FortiGate administrators should focus on the forwarding evidence their own appliance provides.
For current FortiOS candidates, the durable skill is to take one packet and explain why it used a particular WAN member. That answer should include destination routing, SD-WAN eligibility, health measurement, service-rule match, firewall policy, and NAT. If any step cannot be explained, the design is harder to operate than it needs to be.