SD-WAN Passive Health Check Flapping under Asymmetric TCP ACK Streams
We have all been there at 2 AM: your monitoring dashboard lights up with thousands of SD-WAN route flaps, branch VoIP calls suddenly drop into static, and the link health table claims your 1 Gbps primary fiber has 100% packet loss—even though ICMP pings sail through flawlessly. Here is the deep engineering reality behind Bug 0889201 and how to stabilize your cluster.
Technical Root Cause Analysis
To avoid artificial probe traffic charges on metered uplinks or avoid triggering upstream rate limits, many network engineers deploy FortiOS Passive SD-WAN Health Checking. Instead of transmitting constant synthetic probes, the kernel’s link_monitor daemon passively sniffs active production TCP sessions traversing the interface, calculating Round Trip Time (RTT) and packet loss by correlating outbound TCP data segments with inbound server TCP acknowledgments (ACKs).
However, when enterprise topologies involve asymmetric routing—such as when outbound client requests depart via wan1 but return ACKs traverse a low-latency wan2 or an MPLS/ADVPN overlay—the passive SLA engine on wan1 suffers from one-way blinders. The outbound sequence numbers are registered in the local SLA table, but because the matching ACK packets arrive on a different interface, the timer window on wan1 expires without receiving confirmation.
The real-world firmware trajectory illustrates the engineering challenge: Discovered in firmware 7.2.2 as branch passive monitoring became mainstream, an initial fix was attempted in firmware 7.2.5 by introducing an ACK sampling smoothing filter. However, during high-throughput asymmetrical TCP transfers, the smoothing filter still accumulated false loss events. The permanent verified resolution was integrated into firmware 7.2.8+ and 7.4.2+, implementing cross-interface session table synchronization so that return ACKs arriving on any firewall interface credit the original egress member's SLA metrics.
Affected Firmware & Blast Radius Matrix
| FortiOS Branch | Vulnerable Builds | Confirmed Clean Build | Status & Workaround |
|---|---|---|---|
| FortiOS 7.2 | 7.2.2 – 7.2.7 | 7.2.8+ | Switch to active probes or disable passive SLA |
| FortiOS 7.4 | 7.4.0 – 7.4.1 | 7.4.2+ | Upgrade to 7.4.2+ for bidirectional session sync |
| FortiOS 7.0 | Not Affected | 7.0.x Branch Clean | Passive SLA TCP stream calculation engine not present |
Platform Impact: Affects FortiGate 60F, 70F, 80F, 100F, 200F, and 400F desktop and mid-range appliances operating SD-WAN rules with detect-mode passive or hybrid active/passive health checks in topologies with asymmetric egress/ingress paths.
Step 01: Free Verification CLI (Safe Read-Only)
Run these non-disruptive commands from the FortiOS console to verify if passive SLA calculations are falsely flagging packet loss on healthy members:
Diagnostic Commands
# 1. Check SD-WAN health-check status and identify flapping members
diagnose sys sdwan health-check status
# 2. Inspect session table statistics to confirm asymmetric traffic flow
diagnose sys session stat
# 3. View real-time SD-WAN service rule steering decisions and state transitions
diagnose sys sdwan service
# 4. Read interface SLA metric logs for packet loss spikes during live traffic
diagnose sys sdwan intf-sla-log wan1Remediation & Workaround Steps (Teaser Preview)
Resolve passive health-check flapping immediately using the guided workflows in the Ferrite platform:
Frequently Asked Questions
Passive health checks calculate RTT and packet loss by sniffing outbound client TCP packets and their corresponding server ACKs on the same physical interface. When egress traffic leaves wan1 but return ACKs arrive via wan2, wan1's passive SLA engine assumes packet loss, reaching 100% loss and triggering constant route failovers.
Discovered in FortiOS 7.2.2, an initial fix was attempted in 7.2.5 using an ACK sampling smoothing filter. Permanent verified resolution arrived in FortiOS 7.2.8 and 7.4.2 with bidirectional cross-interface session state tracking.
Yes. Convert affected SD-WAN health checks from passive mode to active ping or HTTP probes targeting highly available DNS or gateway IPs, or apply strict policy routes to enforce symmetric routing.