SD-WAN Failover for Private Access at a Retail Branch
A 35-store retail chain uses FortiGate 60F at each branch and FortiSASE secure private access to 12 applications in two data centers. Each store has a 200/50 Mbps cable primary and a 40/10 Mbps LTE backup. Store 17 reports POS timeouts and poor VoIP during peak hours. The FortiGate has two IPsec tunnels to FortiSASE, one per WAN, but SD-WAN health checks only ping the cable ISP gateway. Both tunnels share a single static route, and the SD-WAN rule sends all private traffic to the overlay. POS uses TCP 443 to 10.20.0.0/16; voice uses UDP 5060 and 10000-20000 to 10.30.5.10. FortiSASE private access policies currently allow only 10.20.0.0/16, and the LTE tunnel has been flapping every 20 minutes. Cable packet loss is 3% during peak, while LTE latency is stable at 55 ms. The store cannot add MPLS, and the business wants automatic failover.
1. Why are POS timeouts occurring, and how should the SD-WAN design change?
Read the worked answer
The health check is measuring the cable ISP gateway, not the path to FortiSASE. A 3% loss on the gateway may look acceptable while the IPsec overlay is degraded, so SD-WAN never fails POS over. Configure a performance SLA per overlay member using a reachable FortiSASE target and thresholds for latency, jitter, and loss. Create an SD-WAN rule for POS traffic to 10.20.0.0/16 that selects the best-quality member, not a static route for all private traffic. Verify both IPsec tunnels have unique tunnel interfaces, routes, and local IDs, and check for asymmetric sessions. Confirm the FortiSASE private access policy allows 10.20.0.0/16. If LTE is stable at 55 ms, it can carry POS during cable loss, but capacity and session stickiness must be validated.
2. What must change for voice, and what would you check in FortiSASE?
Read the worked answer
Voice is failing because the FortiSASE private access policy allows only 10.20.0.0/16; UDP 5060 and 10000-20000 to 10.30.5.10 are not permitted. Add the voice destination and ports to the SPA policy, then create a dedicated SD-WAN rule that prefers the lowest-jitter member and marks voice with DSCP. Confirm the LTE backup can support the call volume; 10 Mbps may be enough for a few calls but not the whole store. Check FortiSASE logs for deny actions, verify return routing and NAT, and make sure no SSL inspection or application control profile is applied to voice. Use packet capture and SD-WAN health statistics to confirm the selected path.
3. Why is the LTE tunnel flapping every 20 minutes, and how do you stabilize it?
Read the worked answer
Repeated 20-minute flapping suggests an IKE or DPD or rekey mismatch, not just LTE signal. Check IKE gateway and tunnel logs on the FortiGate and the FortiSASE tunnel status. Confirm NAT-T is working if LTE is behind CGNAT, that both peers use matching DPD and rekey settings, and that MTU is not causing large packets to drop. Also verify the LTE link is not changing IP or dropping idle traffic. Use SD-WAN to keep cable preferred and reserve LTE for POS and voice, but do not leave both tunnels in an unstable equal-cost route. Stabilize the tunnel first, then test failover with a controlled cable loss event.