Dual‑WAN Edge Router Sends HTTPS Traffic Out Slower Link Despite Healthy Primary — Large TCP Transfers Stall

Environment

Home lab: Edge router (firmware 2.4.18) with two WAN uplinks (WAN1: fiber 600/150 Mbps; WAN2: LTE 50/10 Mbps). Policy-based failover configured to prefer WAN1 with per‑host health checks (ICMP + TCP 443 probe every 5s). Multiple desktop and server clients behind NAT (192.168.1.0/24).

Symptoms

HTTPS downloads and large POST requests to a single external host saturate and stall when client initially resolves via WAN1; tcpdump shows initial SYN leaves via WAN1 but most established sessions' packets egress via WAN2 after a few seconds, causing retransmits and stalled throughput. Small web requests (HTML pages, small images) are unaffected.

Observations

Router telemetry logs show health checks for WAN1 succeed continuously; NAT connection table entries show same 5-tuples but next-hop changes in routing table to WAN2 for the same source IP within 10–20s of connection establishment. No CPU or memory saturation on router; per‑interface counters show increased retransmits on WAN1 during affected flows. External host reachable and responds when tested directly from WAN1 using a connected test device.

Already attempted

Restarted router, toggled policy routing to hard-failover (cut WAN1) and back, increased health-check frequency to 1s, enabled connection tracking sticky option (session affinity) and tried disabling MSS clamping—issue persisted. Captured pcap on LAN and both WAN interfaces for 120s during an affected transfer.

Question

What could cause the router to move established TCP sessions from WAN1 to WAN2 mid‑flow despite health checks showing WAN1 healthy, and what safe diagnostics or reversible config changes can I perform to restore stable large-transfer throughput without losing connection state?

Post timeline

COMMUNITY RESPONSES

Verified community troubleshooting

0 replies

No answers yet..

Showing 0 of 0 community responses

AI DIAGNOSTICS

Incident analysis

Updated 1w ago• Trouble ID

Most likely causes

Router bug in policy-based routing module that recalculates next‑hop for existing NAT sessions after periodic health checks (per‑flow affinity not honored). 85%

NAT/connection-tracking table entry corruption or exhaustion causing recreation of sessions that get hashed to WAN2 for subsequent packets. 40%

MSS/MTU mismatch on WAN1 leading to stalled large transfers; router heuristics mark WAN1 as degraded for large flows and shift them to WAN2, while small flows continue on WAN1. 35%

Summary

Symptoms fit asymmetric path selection or a routing decision change inside the edge device after connection establishment (policy/failover re-evaluation, per‑flow hashing bug, or broken session‑affinity). Large TCP transfers are more sensitive because retransmits expose return path asymmetry and MTU/MSS interactions. Router firmware or NAT implementation may be switching next‑hop for established connections based on external conditions (e.g., perceived congestion, probe failures, or incorrect sticky hashing).

Suggested Fixes

Diagnostic step 1

Capture simultaneous pcaps on LAN, WAN1, and WAN2 during an affected transfer and compare TCP sequence numbers and NAT mapping to prove which interface carries which packets and whether NAT entries are recreated.

Diagnostic step 2

Enable persistent per‑flow session affinity (source IP + port sticky NAT) if your router supports it; document current settings and apply change temporarily for testing, then revert if no improvement.

Diagnostic step 3

Test large transfer from a host directly attached to WAN1 (or via a bridged test device) to confirm WAN1 path capacity and MTU independent of router policy logic.