SD-WAN SLA Not Steering and Asymmetric BGP Returns
A retailer has 200 branches, each with a FortiGate 100F, two internet ISPs, and SD-WAN. Branches run eBGP with each ISP and iBGP to a DC FortiGate 1800F; the DC also has DIA. The SD-WAN performance SLA uses HTTP probes to 8.8.8.8 and shows both members healthy. When ISP1 latency rises to 250 ms and packet loss to 8%, the service rule still sends Teams and SAP traffic via ISP1; users report resets. The DC's return traffic for some branch prefixes arrives via ISP2, and the branch FortiGate logs 'received packet without session' for TCP. DNS queries intermittently time out after failover. You must find the cause and propose a design that keeps stateful inspection and avoids asymmetric returns.
1. Why does the SD-WAN service rule continue to use ISP1 when the performance SLA says both members are healthy, and what would you verify?
Read the worked answer
The health check says healthy, but the service rule is not steering. Check diagnose sys sdwan health-check and diagnose sys sdwan service; the SLA probe may be using a source interface or protocol that does not reflect the real application. An HTTP probe to 8.8.8.8 can succeed over ISP1 while Teams and SAP are affected by loss or by a different path. The service rule must reference the correct SLA ID and have mode set to SLA, not load-balance; if it is in load-balance, both members are used regardless of latency. Also check rule order: a broad rule above the Teams/SAP rule may match first. Verify the member's gateway and source NAT; if the probe is excluded from SD-WAN or uses a different source IP, it may bypass the impaired path. Finally, SD-WAN only controls outbound selection; if the return path is pinned by BGP or by the application server, outbound steering alone will not fix the experience. Use application-aware probes, such as HTTP to the actual SaaS endpoint or a synthetic TCP check, and confirm with diagnose sniffer packet on both members. Do not lower the SLA threshold to hide 8% loss.
2. What causes the asymmetric return path and TCP resets, and how would you redesign the branch-to-ISP routing to keep stateful inspection working?
Read the worked answer
Asymmetry is coming from independent outbound and inbound decisions. The branch's SD-WAN rule chooses ISP1 for outbound, but the branch advertises its prefix via eBGP to both ISPs. The DC or internet return path follows BGP best path, which may be ISP2. FortiGate sees the return packet on ISP2 without a matching session and drops it, hence the TCP resets. Fix the design, not the symptom: make the branch's public prefix advertisement prefer the same ISP that carries the outbound flow, using AS-path prepending on the backup ISP and a consistent local preference or route-map. If both ISPs must be active, use per-ISP NAT pools and policy routing so a flow's outbound and return use the same ISP; do not use a single shared NAT pool across both. snat-route-change can help when a route changes, but it does not solve a statically asymmetric design. For inbound services, use DNS/GSLB or a provider-independent prefix with deterministic advertisement. Test with get router info bgp network on the DC and branch, and diagnose sniffer packet for the TCP handshake. If the business requires full active-active, use a load balancer or an anycast design with flow affinity, not two independent FortiGates.
3. Why do DNS queries time out after failover, and what design change would make DNS resilient across both ISPs?
Read the worked answer
DNS timeouts after failover usually mean DNS traffic is following a different path or the NAT pool or route changed without session state. Check whether DNS is included in the SD-WAN service rule; if it is not, it may still use the old default route. After a member fails, the route to the DNS server may point to the other ISP, but existing UDP sessions are still hashed to the dead path. Clear the sessions or use snat-route-change so new sessions use the new route, and ensure the DNS server is reachable via both ISPs. If the branch uses the ISP's DNS, failover to the other ISP may make that resolver unreachable; use a public resolver or a local DNS proxy with health checks. Also check the SD-WAN implicit rule and default route priority. For stateful inspection, keep the return path deterministic per flow; DNS is UDP and stateless from the FortiGate's perspective, but the client's query ID and NAT translation must stay consistent. Capture with diagnose sniffer packet any 'port 53' 4 during failover, and verify the DNS session with diagnose sys session filter. The design fix is to make DNS an explicit SD-WAN service with its own SLA and to avoid ISP-specific resolvers on a dual-ISP branch.