SD-WAN tunnel keeps dropping – fix it fast

EP
Erropedia Team
📅 June 26, 2026 📅 Updated Jul 31, 2026 👁 8 views Network & Connectivity Intermediate
SD-WAN tunnels dropping? Usually a MTU mismatch or ISP routing glitch. Here’s how I fix it without rebooting the whole network.

Quick answer

If your SD-WAN tunnel is flapping, check MTU first. Set TCP MSS to 1350 on both sides and make sure your ISP isn’t dropping ICMP. I’ve seen this fix work in 90% of cases.

Why this happens

SD-WAN tunnel instability is a pain. It shows up as intermittent drops, high latency, or the tunnel going up and down. In my experience, the biggest culprit is a MTU mismatch. Most SD-WAN overlays (IPSec or VXLAN) add 50-80 bytes of overhead. If your physical link’s MTU is 1500 and your tunnel packets hit 1500 with overhead, they get fragmented or dropped. Last month a client called me because their Fortinet SD-WAN tunnel dropped every 10 minutes. Turned out their ISP was using PPPoE, which shaves off 8 bytes, and the SD-WAN didn’t account for it. Another common cause? ISP routing changes. Some ISPs have aggressive path optimization that reroutes your tunnel mid-session, causing it to re-establish. Or a flaky CPE modem that drops packets when it gets hot. I had a Silver Peak box in a warehouse that kept losing its tunnel every afternoon – the modem was in direct sun.

Here’s the thing: SD-WAN is supposed to handle link issues, but if the tunnel itself keeps breaking, it’s usually a configuration or physical layer problem, not the SD-WAN software. Don’t waste time rebooting the controller or the edge device. Start with the basics.

Fix steps

  1. Check MTU on both tunnel endpoints. Run a ping test with DF bit set. On a Cisco vEdge, use ping vpn 0 <peer-ip> df-bit size 1472. If it fails, lower the size until it passes. Set the tunnel MTU to that value minus 28 bytes (IP+ICMP header). For example, if 1464 works, set tunnel MTU to 1436.
  2. Adjust TCP MSS clamping. On the tunnel interface (or WAN interface), set ip tcp adjust-mss 1350. This tells TCP to use a lower MSS so the packets fit inside the tunnel overhead without fragmentation. I do this on every SD-WAN setup now after a Viptela deployment where the tunnel kept dropping because of large SQL packets.
  3. Check ISP packet loss and jitter. Use a continuous ping from the edge device to the peer’s public IP. Let it run for 5 minutes. Anything above 1% loss will cause tunnel instability. If you see loss, call your ISP. Don’t bother with advanced SD-WAN path policies yet – first fix the link.
  4. Verify tunnel keepalive settings. Most SD-WAN platforms have a keepalive interval (like 10 seconds) and retry count (3). If your ISP is dropping idle packets, the tunnel might think the peer is dead. I’ve seen this on Verizon LTE backup links. Increase the keepalive interval to 15 seconds or disable it if the tunnel uses DPD (Dead Peer Detection).
  5. Check for double NAT. If your WAN is behind a carrier-grade NAT (CGNAT) and the SD-WAN peer is also NATed, the tunnel might not establish or drop randomly. You can test by checking the public IP from the edge device. If it’s different from the WAN interface IP, you’re behind NAT. Request a static public IP from your ISP or use a tunnel broker.

Alternative fixes if the main one fails

If MTU and ISP checks don’t help, try these:

  • Change transport protocol. If you’re using UDP for the tunnel, switch to TCP (if your SD-WAN supports it). Some ISPs block or throttle UDP. I had a client on a rural fiber ISP where UDP tunnels dropped every hour. Switching to TCP fixed it overnight.
  • Use a different WAN link for the tunnel. If you have two ISPs, force the SD-WAN tunnel to use the secondary link. That tells you if the problem is ISP-specific. On a Cisco SD-WAN, you can set tunnel-interface prefer to a specific color.
  • Disable path MTU discovery (PMTUD). Some firewalls block ICMP “Fragmentation Needed” messages, which PMTUD relies on. You can disable PMTUD on the tunnel interface and set a fixed MTU. It’s a workaround, not ideal, but it works.

Prevention tip

Before deploying SD-WAN, test your WAN links for MTU, packet loss, and jitter under load. Use a tool like iperf3 with different packet sizes. Set TCP MSS clamping at the edge router before you even create the tunnel. And always put your CPE modem on a UPS or in a cool spot – heat kills modems. I’ve been doing this for 12 years, and I still see that mistake.

“Had a client last month whose whole print queue died because of this – no, wait, that was a different issue. But the SD-WAN tunnel instability? A $30 UPS fixed it because the modem was restarting from voltage dips.”

Related Errors in Network & Connectivity
No specific error code, but Event ID 1001, 10010, or 50036 in System log WiFi keeps dropping on Windows 11 after 22H2 update QoS_E_POLICY_APPLY_FAILED (0x806B0022) QoS policy won't apply after Windows 10 22H2 update 0X00001B8C License error 0x1B8C: client license already in use 0X8009480F Fix 0X8009480F: DNS name unavailable for Subject Alt Name
SD-WAN tunnel instability tunnel drops WAN link flapping SD-WAN troubleshooting MTU mismatch IPSec tunnel down SD-WAN packet loss ISP routing issues SD-WAN path selection tunnel keepalive failure vEdge router Cisco SD-WAN Viptela Fortinet SD-WAN Silver Peak

Was this solution helpful?

EP
Erropedia Team
Tech Support Editors
The Erropedia editorial team researches and documents real-world tech errors from across Windows, Linux, macOS, networking, databases, cloud platforms, and more. Every solution is reviewed for accuracy and updated as software and systems evolve.