The SD-WAN Rule That Never Matches
A FortiGate 200F uses an SD-WAN zone with wan1 (1 Gbps fiber) and wan2 (200 Mbps LTE). Health check HC probes 8.8.8.8 and 1.1.1.1 every 500 ms with failtime 5, recoverytime 5, and an SLA of latency <100 ms, jitter <30 ms, loss <2%. Rules: 1) Teams - source all, destination all, application Microsoft Teams, strategy lowest latency (SLA), members wan1/wan2; 2) O365 - destination Internet Service Microsoft Office 365, manual wan1; 3) default - all, best quality. The only outbound policy is internal -> virtual-wan-link, service ALL, NAT enabled, profile 'default' containing AV and IPS but no application control. Teams calls are choppy and the SD-WAN monitor shows rule 1 with 0 sessions; O365 works. During short fiber spikes all traffic moves to LTE and stays there for several minutes.
1. Why does the Teams rule show zero sessions while O365 works, and what change makes rule 1 effective?
Read the worked answer
SD-WAN rules are evaluated top-down and the first match wins. Rule 1 matches on an application, but the outbound policy has no application control profile. Without application control, the FortiGate cannot identify Microsoft Teams, so the application condition never matches; the flow falls through to rule 2 (which does not match, because it is ISDB-destination based) and then rule 3. Rule 3's best-quality strategy then selects whichever member currently has the best measured quality, which is often LTE.
O365 works because rule 2 matches on Internet Service destination objects, which are IP/prefix lookups and do not require application control.
Fix: attach an application control profile to the outbound policy. It must identify Teams; it does not have to block it. Keep rule 1 above the default rule. If application control cannot be deployed, replace the application match with an Internet Service or explicit service/port match, but that is less precise.
Confirm with diagnose sys session list on a Teams flow and check the SD-WAN rule counter in the monitor.
2. Why does traffic fail over to LTE on brief fiber spikes and remain there, and what would you change?
Read the worked answer
The health check is aggressive: a 500 ms interval with failtime 5 means roughly 2.5 seconds of poor probes can take wan1 out of SLA. Short fiber spikes commonly exceed that. Recovery is also 5 probes, so the member may be restored quickly, but the default rule's best-quality strategy will keep preferring LTE if LTE reports better latency or if one probe target still looks bad. LTE often has lower latency but less capacity and is metered, so 'best quality' is the wrong default for bulk traffic.
Changes to consider:
- Increase interval to 1000 ms and failtime/recoverytime to 10, so brief spikes do not trigger a move.
- Use probe targets that represent the actual path and are not rate-limited; public DNS servers may deprioritize ICMP.
- Make the default rule manual wan1 with wan2 as standby, or use lowest cost, rather than best quality.
- Keep the SLA thresholds aligned to the application requirement; a 100 ms latency SLA is generous for voice but not for all traffic.
The goal is stable primary usage with deliberate failover, not a constant quality contest between links.
3. After a failover to LTE, a remote worker's IPsec VPN to the wan1 public address drops. Is this an SD-WAN rule problem?
Read the worked answer
No. SD-WAN rules select the egress member for outbound flows; they do not preserve the public IP address of a link. When wan1 fails, traffic sourced from the wan1 address or terminating on it is affected. An IPsec tunnel bound to the wan1 IP will not survive a move to wan2's different public address.
Options are to use a dynamic DNS name for the remote peer, run the tunnel on a stable address that does not depend on the failed link, or accept that the tunnel re-establishes only when wan1 returns. For inbound services, the same limitation applies: a VIP on wan1 is not reachable via wan2 unless a second VIP/policy exists on wan2.
This is a design decision about link-dependent versus link-independent services, not a rule-ordering issue.