Stop letting your WireGuard interface become a black hole for MTU issues

Technical Briefing | 11/13/2026

You set up a WireGuard tunnel between two data centers, ping works, SSH is snappy, and then you try to transfer a database dump. Suddenly, the connection just hangs. It sits there for a few seconds and then dies. You check the firewall, you check the logs, but everything looks fine. This bit me in prod more times than I care to admit. It is almost always an MTU mismatch, and the silent failure is what makes it so maddening.

Why the tunnel is eating your packets

WireGuard adds its own encapsulation overhead to every packet. If your underlying network path has an MTU of 1500, the effective MTU inside the tunnel needs to be lower. When you push a full-sized packet through, it hits the limit, the kernel tries to fragment it, but if DF bits are set, it just drops. Because ICMP ‘packet too big’ messages often get filtered by over-eager firewall rules somewhere upstream, the sender never learns it needs to shrink its segment size.

nft add rule inet filter forward meta oifname wg0 tcp flags syn tcp option maxseg size set rt mtu

• Force the TCP MSS clamping at the firewall level to ensure it catches all internal traffic
• Set the MTU on your WireGuard interface explicitly to 1420 to account for the overhead
• Verify your path MTU using ping with the do-not-fragment bit to find the actual breaking point

Don’t rely on auto-negotiation

Most tutorials tell you to just set the MTU in your config and move on, but that assumes your ISP path is stable. If you are crossing tunnels or dealing with GRE-in-UDP, your path MTU might actually be lower than the standard 1420. If you keep hitting mysterious timeouts on large transfers, stop debugging the application and start checking your MSS clamps. It saves hours of packet capturing that never tells you the full story anyway.