A FortiGate is a firewall, but it is also a router. Every permitted session still needs a valid path to its destination, and modern branch designs often have multiple WAN links whose quality changes during the day. The Fortinet NSE4_FGT_AD-7.6 exam therefore requires more than knowing how to create a firewall rule: candidates need to understand how routing and SD-WAN decisions interact.
FortiOS 7.6 can combine static routes, dynamic routing, policy routes, SD-WAN zones, service rules, and performance SLAs. The difficult part is knowing which mechanism is making a decision at a particular moment. A path can exist in the routing table yet still be a poor SD-WAN choice; an SD-WAN rule can prefer a link that is no longer healthy; and a correct path can still fail when the firewall policy does not use the matching SD-WAN zone.
The concepts are transferable across the network engineering certification landscape: route selection decides reachability, while policy and steering decide which reachable path should carry a given application.
Routing answers the basic next-hop question
Before SD-WAN can optimize a path, FortiGate needs routing information. Static routes are manually configured and remain useful even in networks that also use dynamic protocols or overlays. A typical edge firewall has a default route toward an upstream provider, while internal routes point toward local networks, VPNs, or routing peers.
Route selection considers destination prefix specificity, administrative distance, and other route attributes. The most specific usable route normally wins before broader alternatives. This is why a default route does not override a more specific route to a private network.
When troubleshooting, read the route that matches the actual destination address. Looking only at the default route can hide a more specific route that sends traffic elsewhere. Likewise, route presence does not prove the next hop is operational; interface state and neighbor reachability still matter.
Policy routes are exceptions, not replacements for design
A policy route can steer traffic using characteristics beyond the destination prefix, such as source, protocol, or service. That can solve requirements that a conventional destination-based routing table cannot express. It also creates an additional decision layer that administrators must remember during troubleshooting.
Use policy routing deliberately. If large portions of the network depend on many special-case policy routes, the design becomes difficult to reason about and easy to break. A conventional routing architecture should carry the majority of traffic, while policy routes handle genuine exceptions.
Whenever the path surprises you, check whether a policy route exists before rewriting static or dynamic routing. The apparent routing-table answer may not be the final forwarding answer if policy routing has matched first.
SD-WAN turns multiple links into a policy domain
FortiGate SD-WAN groups member interfaces into a logical construct that can be referenced by routing and firewall policy. Instead of writing separate security rules for every ISP link, administrators can often point a route and firewall policy toward an SD-WAN zone and let the SD-WAN engine choose an appropriate member.
That abstraction improves operational flexibility. A new circuit can be added to the zone, health checks can evaluate it, and service rules can determine which applications should prefer it. The firewall policy can remain focused on source, destination, service, and security posture rather than encoding every WAN choice directly.
The abstraction does not remove interfaces. Each member still has addressing, link state, gateway reachability, bandwidth characteristics, and provider behavior. When an SD-WAN decision is wrong, inspect both the logical rule and the health of the physical members.
Performance SLAs make link quality measurable
FortiOS performance SLAs use health checks to measure link conditions and can evaluate latency, jitter, and packet loss against defined targets. The thresholds should reflect the needs of the application. Voice may tolerate very little jitter, while a bulk transfer might prefer lower cost even if latency is higher.
Thresholds that are too strict can cause unnecessary path changes. Thresholds that are too loose allow users to remain on a degraded link. The best value is therefore not the lowest number; it is a threshold that represents unacceptable application experience and allows enough stability to avoid constant flapping.
Health checks should also probe a meaningful target. Proving that the immediate ISP gateway responds does not necessarily prove that a SaaS application is reachable. Choose probes that represent the service whose path you are trying to protect.
SD-WAN rules express business preference
SD-WAN rules identify traffic and select an outgoing member or set of members according to a strategy and current conditions. One rule might reserve the best-performing link for interactive business applications, while another balances general internet traffic across multiple providers.
Rule ordering and match criteria matter. If a broad rule captures traffic before a specific application rule can match, the intended steering will not happen. As with firewall policies, an administrator should be able to describe exactly what traffic is expected to match the rule and why.
FortiOS also has an implicit SD-WAN rule for traffic not matched by explicit service rules. Do not rely on the implicit behavior as a substitute for deliberate design when business-critical applications require predictable path selection.
Firewall policy must align with the SD-WAN zone
A route or SD-WAN rule can choose a path, but the traffic still needs an allowing firewall policy. A common design uses the SD-WAN zone as the outgoing interface in the policy. If the policy points to an individual WAN member while the routing and SD-WAN design expects the zone, traffic can fail or behave inconsistently.
NAT must also be considered. Internet-bound branch traffic often uses source NAT on the SD-WAN policy. If different providers require different translated addresses or upstream assumptions, validate how NAT behaves as sessions move between members.
Existing sessions may remain on their original path depending on conditions and configuration. Testing should distinguish new-session path selection from what happens to established flows during link degradation or failure.
Dynamic routing can coexist with SD-WAN
Enterprise deployments often combine SD-WAN with BGP, OSPF, or overlay technologies. Dynamic routing provides reachability information, while SD-WAN can steer traffic according to performance or application requirements. Those two systems must agree on which paths are actually usable.
For example, a healthy underlay link is not useful for a private application if the required route was withdrawn over the overlay. Conversely, a route may remain present while an SLA indicates unacceptable latency. Good design uses routing and health information together rather than assuming either one alone is sufficient.
This interaction is especially important with VPN overlays and ADVPN-style architectures. The administrator must know whether a session is being selected by an underlay route, an overlay route, an SD-WAN rule, or a combination of those decisions.
Troubleshoot SD-WAN with evidence, not preference settings alone
Start by confirming that the destination has a valid route through the SD-WAN construct. Then verify member status and health-check results. Review latency, jitter, and loss. Confirm the service rule that matches the traffic. Check the firewall policy and NAT. Finally, validate the actual egress with session information or packet capture.
If a link is not selected, ask whether it is eligible, healthy, and preferred. If traffic uses the wrong link, ask which rule matched and what metrics existed at that moment. If no traffic passes at all, return to routing and policy before tuning performance thresholds.
The exam-level goal is to reason about the control stack. Static and dynamic routing provide paths; SD-WAN measures and chooses among eligible paths; firewall policy permits the session; NAT and security profiles process it; diagnostics verify what FortiGate actually did.
Design for convergence, not only steady state
Most architecture diagrams show the network when every circuit is healthy. Operations teams experience the network during transitions: a link starts dropping packets, a health check crosses a threshold, BGP withdraws a route, or a tunnel is re-established on another underlay. The important question is how quickly FortiGate recognizes the condition and whether the resulting path change preserves application behavior.
Convergence can expose asymmetric routing. One direction may move to a new path while the return direction still follows the old route, leaving stateful inspection without the expected session context. When multiple sites and providers participate, verify routing policy on both ends rather than assuming the FortiGate alone controls symmetry.
Operational documentation should record why each SD-WAN rule exists, which SLA it depends on, and what backup behavior is expected. This converts a collection of GUI settings into an understandable traffic-engineering policy. Candidates who continue through the Fortinet exam path will repeatedly encounter the same principle: policy is easier to operate when its intent is explicit.
Capacity and policy should be reviewed together
Link quality is only one part of WAN design. A circuit can meet its latency target and still become congested because the selected traffic exceeds available bandwidth. SD-WAN policy should therefore be reviewed alongside interface utilization, application growth, and business priority. An SLA that measures latency and loss cannot compensate for a branch that regularly saturates its preferred link during backup windows.
Engineers should also distinguish path preference from guaranteed service quality. Steering an application onto the “best” link does not reserve bandwidth for that application unless the broader design includes shaping or other quality controls. This distinction prevents teams from treating SD-WAN as a substitute for capacity planning.