SD-WAN Prefers ISP-B but Return Traffic Uses ISP-A
A FortiGate 1800F at a data center runs FortiOS 7.4 with two ISP connections in an SD-WAN zone. Each ISP sends a BGP default route, and the FortiGate also has static defaults: ISP-A distance 10 and ISP-B distance 20. Internal prefixes are advertised to both ISPs with a route-map. The SD-WAN rule for Microsoft 365 prefers ISP-B and uses an SLA health check, but users report random Teams session resets. Packet captures show outbound traffic leaving ISP-B while return traffic arrives on ISP-A. ISP-A's eBGP session also receives a more specific route for the Microsoft 365 prefix. The SD-WAN zone contains both members, and there are no policy routes. Voice requires less than 100 ms latency and 1% loss; ISP-A measures 35 ms/0.2%, ISP-B 70 ms/0.8%. The site has 4,000 concurrent sessions and one active FortiGate.
1. Explain why the SD-WAN rule is not producing symmetric forwarding for Teams. Which routing and BGP mechanisms control the return path?
Read the worked answer
SD-WAN rules choose an egress member; they do not, by themselves, make the return path symmetric. The FortiGate has three route sources: static defaults (ISP-A distance 10, ISP-B 20), BGP defaults (eBGP distance 20), and a more specific BGP prefix for Microsoft 365 learned from ISP-A. Longest prefix wins first, so the specific M365 route is installed regardless of the default-route distances. If the SD-WAN rule still steers matching flows to ISP-B, outbound packets can leave B while the SaaS return traffic follows the more specific route toward A-especially if the FortiGate owns a public /24 and is not NATing to B. The result is asymmetric routing and session resets. The return path is controlled by BGP advertisements and path attributes, not by the SD-WAN rule. To fix it, either make B the preferred inbound path for the public prefix (more specific advertisement from B, AS-path prepending on A, or local preference where applicable) or NAT outbound traffic to B's address so return traffic must come to B. Then verify that the SD-WAN member and the BGP next hop agree.
2. Design a routing and SD-WAN policy that meets the voice SLA and keeps Microsoft 365 on the best available path. Include how BGP and SD-WAN should interact.
Read the worked answer
Separate the policies by traffic class. Voice: SD-WAN rule matching voice applications, priority member ISP-A (35 ms/0.2%), SLA threshold 100 ms/1%, and a hold-down to avoid flapping. M365: a second rule with ISP-B preferred only if its SLA is met; otherwise fall back to A. Do not use one 'prefer B' rule for everything. For outbound selection, use SD-WAN priority members and health checks. For inbound return, advertise the public prefix so the selected ISP is also the preferred BGP path: on ISP-A, prepend the AS path for the M365 prefix or advertise a less specific prefix; on ISP-B, advertise the specific prefix. If the FortiGate NATs, use a source NAT address from the chosen ISP and confirm the return route. Keep static defaults as backup, but make their distances consistent with the intended BGP behavior; do not let a static default and an SD-WAN rule disagree. Test with a pilot subnet before moving all 4,000 sessions.
3. What outputs would you collect before and after the change to prove the fix rather than just assuming it?
Read the worked answer
Collect: get router info routing-table all, get router info bgp network, get router info bgp neighbors <peer> advertised-routes, diagnose sys sdwan health-check, diagnose sys session list, and packet captures on both WAN interfaces. Before the change, record which member each application uses and the BGP best path for the public prefix. After the change, prove three things: the SD-WAN rule selects the intended member; the BGP table's best path for the return prefix points to the same ISP; and a captured flow has both directions on that ISP. Use an external looking glass to confirm what the Internet sees. A fix is not proven by outbound selection alone.