Dual‑WAN router shifts long TCP transfers to backup link despite primary health checks reporting OK — large flows slow unexpectedly

Environment

Edge office router in active-active dual‑WAN configuration: WAN1 (1 Gbps, primary), WAN2 (100 Mbps, backup). Router uses per‑session hashing with health probes (ICMP + HTTP every 5s). Session stickiness TTL set to 300s. Large HTTP/FTP uploads download at line-rate initially then throughput drops and flows appear routed via WAN2.

Symptoms

Large long-lived TCP transfers start at expected rates, then after ~120–300 seconds throughput collapses to ~10% and transfers persist on the backup link. Small web requests and short-lived flows are unaffected. Some clients report retransmits and long completion times for multi‑GB uploads.

Observations

Router logs show occasional 'WAN1 probe timeout' and immediately after probe failure there is a route change entry for existing connections. Packet captures on the router show large-window TCP flows with retransmits after the route change. NAT session table still holds the original mapping but outbound interface changes. Sender-side retransmits indicate packet loss after the route change. Attempts to pin policies failed to fully prevent re-routing under the same conditions.

Already attempted

Increased health-check frequency and sensitivity; added TCP-based health check to object store endpoint but transient probe timeouts still observed. Enabled stronger session stickiness but after ~10 minutes some sessions still rebalanced. Contacted ISP — they report no sustained outage; primary link shows microbursts and increased latency at times.

Question

What are likely root causes for existing TCP flows being moved mid‑session to the backup path, and what reversible diagnostics and router configurations will confirm the cause and mitigate user impact without broad topology changes?

Post timeline

COMMUNITY RESPONSES

Verified community troubleshooting

0 replies

No answers yet..

Showing 0 of 0 community responses

AI DIAGNOSTICS

Incident analysis

Updated 2h ago• Trouble ID

Most likely causes

Health-check probe(s) intermittently failing for WAN1 (false positives) causing the router to reassign existing flows to WAN2 mid‑session. 75%

Router connection-hash algorithm rebalances long-lived flows when certain state changes occur (e.g., NAT table resize, HA cluster sync), causing asymmetric egress selection for existing sessions. 55%

Underlying transient packet loss or congestion on WAN1 resulting in sender retransmits and the router triggers a failover on perception of degraded path. 45%

Summary

Mid‑session re-routing of established TCP flows typically stems from the router treating a health probe as authoritative and rebinding flows to a different egress when probe fails, or from connection-hash changes that occur when flow metadata (e.g., source port) or router state changes. The packet-capture evidence of retransmits immediately after route change indicates the re-route event, not upstream ISP congestion alone, is the proximate cause for stalls. Diagnostics should capture correlated probe/route-change timestamps, and mitigations should make health checks for primary link less sensitive or use TCP-based health checks with session pinning. Avoiding abrupt failover for already-established sessions (sticky NAT/pinning) is the reversible configuration change to test.

Suggested Fixes

Diagnostic step 1

Capture simultaneous tcpdump on both WAN interfaces and the LAN-facing interface with timestamps to correlate the moment of throughput collapse with router probe/route-change events.

Diagnostic step 2

Change health checks to a TCP handshake or HTTP GET against the specific destination (not just ICMP) and increase failure threshold to avoid false positives. Test with long-lived synthetic transfer while adjusting settings.

Diagnostic step 3

Enable (or increase) session pinning / sticky NAT for established flows so the router will not move existing sessions when a probe reports degraded state. Test for several hours under production-like load.