FortiGate routing and SD-WAN answer related but different questions. Ordinary routing determines which destinations are reachable through available next hops. SD-WAN introduces link membership, health assessment and rule-based path selection for traffic that can use multiple WAN paths. A valid firewall allow rule cannot force traffic across an unavailable route, and a healthy SD-WAN link does not mean that an application is authorized to traverse it.
The FortiOS 7.6 Administrator exam includes static routes, routing tables, route redundancy/load balancing, SD-WAN concepts, link quality, health status and routing behavior. A candidate needs to explain not only which link is configured as preferred but also whether that link is eligible for the actual destination and what happens when it degrades.
Read the routing table before diagnosing policy
A FortiGate’s effective routing table is a set of eligible paths selected from configured and learned routes. A default route provides a catch-all for destinations that have no more-specific path; a connected or explicitly configured route may override it. The FortiOS 7.6 routing reference describes selection by prefix specificity, administrative distance and priority.
A common misunderstanding is that the last static route created or the one with the most obvious label must win. In reality, a more-specific prefix can take precedence, and two candidate routes to the same destination can have different administrative distances. When routes have the same distance, configured priority becomes relevant. An administrator should verify which route is active instead of reading only the configuration objects.
Imagine a branch with a default route to its ISP and a more specific static route toward a private datacenter subnet. Users can browse the public internet but cannot reach an application in that subnet. A missing or inactive private route is a plausible cause, but so is a policy mismatch or a failure of the return path. The right first observation is the installed route and the packet’s intended next hop.
Understand configuration versus installed route state
A static route can exist in the configuration without being the route used by live traffic. Interface state, dynamic competitors, health monitoring and the availability of a next hop can affect which entries are active. In some designs, a DHCP-learned default gateway may have a different distance from a manually configured default route, so the apparent preference may surprise an administrator who considered only the manually entered values.
Fortinet’s documentation for static routing in FortiOS 7.6 covers dual internet connections, policy routes and equal-cost multi-path (ECMP) topics. These mechanisms should not be collapsed into one generic “load balancing” feature. ECMP can distribute eligible traffic among equal routes, while policy routing makes a more explicit decision based on traffic selectors. SD-WAN adds another layer of member and service strategy.
A useful table for a design review includes destination prefix, preferred next hop, backup next hop, administrative distance, priority, expected egress and operational owner. That table helps an incident responder understand why a failover did or did not occur without guessing from interface names.
SD-WAN members, zones and service rules
FortiOS SD-WAN groups participating interfaces into configured members and zones. The zone abstraction can be used in firewall policy, while service rules determine which eligible member carries selected traffic. A rule might prefer a link because of cost, quality or a defined priority, depending on strategy. The important distinction is that the rule can choose only among paths that the routing and health context make eligible.
For example, an office has one MPLS circuit for enterprise applications and two internet broadband links. A single-zone design may simplify broad policies but provide insufficient granularity where private links require different security treatment from public internet paths. Fortinet’s SD-WAN architectural guidance explains why separate zones can be useful for traffic with different security requirements.
When troubleshooting, inspect the member and zone assignment, matching SD-WAN rule, route eligibility and firewall policy. A route or zone change can make an otherwise valid rule unreachable. Do not assume that naming an internet link “preferred” causes all clients to use it in every circumstance.
Health checks measure quality, not merely link lights
An interface can be physically up while a provider experiences heavy loss or unacceptable latency. SD-WAN performance SLAs can measure quality through probes or supported passive observation and compare it with configured thresholds. The FortiOS 7.6 Performance SLA reference explains measurements of latency, jitter and packet loss and the effect of failed checks on route eligibility.
For a voice service, jitter and loss may matter more than peak download throughput. For a bulk backup, available bandwidth and stability may dominate. The correct SLA target reflects the application’s tolerance, while the measurement endpoint should be appropriate to the real path. A probe to one internet host is a useful signal, not proof that every possible destination on that ISP is reachable.
Health thresholds also create operational trade-offs. A too-strict threshold can cause repeated movement between links when conditions fluctuate around the limit. A too-permissive threshold may leave sensitive traffic on a degraded circuit. Monitoring should record actual quality and the selection changes produced by the policy.
Path selection under different service strategies
Lowest-cost eligible selection, priority-based preferences and quality-aware service strategies solve different business requirements. Fortinet’s SLA-based lowest-cost rule describes how the system chooses the lowest-cost member satisfying a target, with tie handling by interface preference. A design that always forces the cheapest link regardless of quality would violate that intent.
Suppose broadband A costs less but exceeds loss thresholds during peak time; broadband B is more expensive but meets the SLA. For a quality-aware rule, B can be selected while A is degraded, even though A remains physically connected. When A recovers, the next choice depends on the specific rule strategy and system state rather than an absolute promise that all existing sessions instantly move back.
Failover behavior needs attention to session state and source NAT. A new path may use a different public address; external services with source-IP allowlists or long-lived sessions can be affected. The fact that a backup route exists does not guarantee a seamless application session. Communicate the expected disruption rather than equating available links with uninterrupted transactions.
Relate SD-WAN to firewall policy, NAT and IPsec
Routing and security policy must agree on interface or zone relationships. If a private tunnel and a public internet path share a loosely designed policy scope, traffic may receive a different inspection or access outcome from the one intended. FortiOS policy and SD-WAN structures should represent those differences explicitly. An operator should be able to state which policy permits a given SD-WAN-selected path.
Source NAT can change between links. On an internet failover, a SaaS service may see a new source address; an application that permits only the first ISP’s address may break despite working routing. With IPsec overlays, the tunnel interface and route selection determine where encrypted site-to-site traffic is sent. The routing decision for the encrypted peer and the routing decision for the protected application subnet are related but distinct.
These dependencies explain why static route fundamentals remain relevant within a sophisticated SD-WAN design. The SD-WAN rule does not eliminate the need to understand destination prefixes, active routes or the reverse traffic path.
Diagnose unexpected member selection
A branch reports that its backup ISP is carrying video conferences even though the primary interface is up. Rather than rewriting the policy, determine which service rule matched, whether the primary link meets the configured SLA, and whether an eligible route exists through it. The performance monitor may show that the primary’s packet loss is above threshold; if so, choosing the backup is correct behavior, not a misconfiguration.
In another case, both ISP health checks pass but a private application fails. The relevant destination may match a more-specific route to a broken private tunnel. A health check aimed at the public internet does not prove that the private tunnel and datacenter prefix are usable. Inspect route and overlay state separately.
When one application is affected, consider the application classification or internet-service mapping used by the SD-WAN rule. A change in application behavior can change which service rule matches. Check observed traffic and rule criteria instead of assuming every flow to the same hostname will behave identically.
Design a measured, reversible troubleshooting change
For each incident, record the active route, chosen SD-WAN member, health metrics, matched service rule, firewall policy, NAT behavior and relevant session age. Make a narrow adjustment only after the evidence points to one of those components. A temporary health-threshold change should have a clear expected result and a rollback plan; otherwise it may mask a provider fault and introduce unstable path switching.
Useful post-change checks include new-session success, application quality, loss and jitter, correct source NAT and expected behavior when a member is deliberately taken out of service in an authorized test environment. Avoid claiming live failover was verified unless the outcome was actually measured.
FortiOS 7.6 routing competence is the ability to explain why the effective route and chosen member differ from a simplistic diagram and to correct the cause without bypassing security. Understanding that chain makes routing and SD-WAN questions much less dependent on memorized GUI labels.