Fortinet FCF study materials
Fortinet FCF study resources

Branch HA and SD-WAN Voice Failover

Fortinet FCF · Put your knowledge to work in context.

All case studies

Branch HA and SD-WAN Voice Failover

Northwind Retail runs a 220-employee distribution branch on a FortiGate 100F active-passive HA pair running FortiOS 7.2. WAN 1 is 500/100 Mbps fiber; WAN 2 is a 100/20 Mbps LTE backup. An SD-WAN zone carries SIP/RTP to a hosted PBX and an IPsec overlay to headquarters. SLA health checks send five probes every 500 ms. On Tuesday the fiber link develops 18% packet loss for 40 minutes. SD-WAN moves new sessions to LTE, but 30 active calls drop, the IPsec tunnel to HQ re-establishes after 95 seconds, and FortiAnalyzer records repeated session clash and asymroute entries. The business wants zero-impact failover for voice and asks whether to enable asymmetric routing, raise HA failover timers, or place both ISPs in one SD-WAN zone with session pickup. The change window is 30 minutes and the hosted PBX cannot be modified. No packet capture was taken during the event.

1. Explain why established VoIP calls dropped even though SD-WAN shifted new sessions to LTE. What would you verify in the configuration before changing anything?

Read the worked answer

SD-WAN SLA selection is applied when a session is created. The existing SIP/RTP flow was NATed to the fiber address and the PBX was sending return traffic to that address. When the route changed, the FortiGate either re-evaluated the flow or received return packets on a different interface, so the session no longer matched state and FortiAnalyzer logged session clash and asymroute symptoms. Session pickup preserves sessions across an HA node failover; it does not preserve a UDP flow across a WAN IP change. Before changing anything, verify: HA session-pickup is enabled; asymroute is disabled; the SD-WAN service rule for voice has the intended priority and SLA target; health-check interval, failtime, and recoverytime; whether the IPsec overlay has redundant tunnels or BGP; and whether both WAN links apply source NAT. The 95-second tunnel recovery points to DPD or route convergence, not merely SD-WAN rule selection. Also confirm the PBX does not require a fixed source IP; if it does, the LTE path cannot preserve active calls.

2. The customer proposes enabling asymmetric routing to stop the session-clash logs. Evaluate that proposal and state what you would do in the 30-minute change window.

Read the worked answer

Do not enable asymmetric routing. It is a return-path workaround that can cause FortiGate to skip stateful inspection for some flows, weakening UTM and creating an audit gap; it also will not migrate an established UDP flow to a new public IP. In the 30-minute window, make reversible changes: set voice to a priority SD-WAN rule with a tight SLA target and a hold-time to prevent flapping; tune health checks from five probes at 500 ms to a faster, site-appropriate profile; confirm session-pickup and disable asymroute; verify IPsec DPD and add a second tunnel over LTE if the design allows. Do not change HA failover timers unless evidence shows HA, not WAN, failed. Validate with a test handset and packet-loss injection on the primary link. If the contract truly requires active-call preservation, state that no FortiGate setting can preserve a SIP/RTP flow across a public IP change; the fix is provider dual-registration or an overlay with a stable endpoint.

3. What validation proves the fix without disrupting production, and what residual risk remains?

Read the worked answer

Use a lab VLAN or one test SIP handset, not production. Baseline registration and call quality; inject 20 percent loss on the primary for 60 seconds; record new-call setup time, whether the active test call survives, IPsec re-establishment time, and whether session clash or asymroute logs recur. Confirm the voice rule matches before and after failover, UTM is still applied to business traffic, and no policy bypass was introduced. Check FortiAnalyzer for the test session and FortiGate SD-WAN monitor for SLA state. Residual risk: active calls will drop on a public IP change unless the provider supports session continuity; the realistic goal is fast new-call failover, not zero-impact for established calls. Document that distinction for the business.