WireGuard tunnel connects but large TCP transfers stall — small requests OK (likely PMTU / MSS black hole)

Environment

Ubuntu 22.04 server running WireGuard 1.0.202 as gateway (public IP from ISP), clients: macOS 13 laptop and Android 12 phone using WireGuard clients, server NATs client traffic to internet via home router/modem combo.

Symptoms

After establishing the WireGuard connection, interactive traffic (SSH, small web pages) works fine. Large TCP transfers (scp, git clone of multi-GB repo, HTTP downloads) start, transfer a portion, then stall indefinitely; connections eventually time out. ICMP pings and small UDP traffic are unaffected.

Observations

Lowering WireGuard MTU on the client to 1280 allows the large transfers to complete without stalling. Traceroute/mtr over the tunnel shows higher latency hops but no obvious route change. tcpdump on the server shows outgoing packets with DF (don't fragment) set and no 'Fragmentation needed' ICMP replies returning to the originating client. The home router/modem does not have a visible option to expose ICMP or to change packet handling. Disabling NAT on server (making client route direct) is not an option on current topology.

Already attempted

Tested different MTU values (1400, 1300, 1280); 1280 consistently resolves the issue. Disabled offloading (ethtool -K) on the server NIC with no change; added temporary iptables ACCEPT rules; restarted WireGuard. Captured packets on client and server during transfer to compare sizes and flags; saw that Path MTU Discovery (PMTUD) ICMP 'fragmentation needed' replies were not reaching the client.

Question

What is the safest way to fix these large-TCP-transfer stalls without forcing every client to use a low MTU? How do I identify which network hop is dropping PMTU-related ICMP messages and what configuration changes will resolve the stalls reliably?

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

An upstream NAT/firewall or ISP device is dropping ICMP 'fragmentation needed' responses, preventing PMTU discovery. 90%

The home router/modem does not correctly handle tunneled (WireGuard) DF packets, causing a black hole for larger encapsulated packets. 75%

TCP MSS not being clamped on the box that performs NAT for the WireGuard client, allowing endpoints to attempt too-large packets. 65%

Summary

This is a classic PMTU black hole: large packets with DF set cannot be forwarded because an intermediate link cannot handle their size, and ICMP 'Fragmentation Needed' messages are being dropped (or not routed back) so the sender never reduces packet size. WireGuard encapsulation increases packet overhead so packets that previously fit now exceed MTU on some path. The fact that reducing MTU on the endpoint fixes the issue confirms a PMTU discovery failure. Common causes include ISP or home gateway filtering ICMP, NAT devices stripping ICMP messages, or not performing TCP MSS clamping on NAT devices.

Suggested Fixes

Diagnostic step 1

On the WireGuard server, add TCP MSS clamping to the PREROUTING/FORWARD chain so TCP SYNs get MSS reduced automatically: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu. If using nftables, use equivalent inet mangle chain rules. This fixes most PMTU black hole cases without changing client configs.

Diagnostic step 2

If you control the gateway/router, enable or allow ICMP type 3/code 4 (Fragmentation Needed) through NAT and firewall. Consult router/modem documentation or ISP if no option is visible in the UI.

Diagnostic step 3

As an alternative, set a conservative MTU on the WireGuard server/interface (e.g., 1420 or 1380) and advertise it via AllowedIPs or client configuration; use PostUp/PostDown in wg-quick to set permanent rules. Changing MTU is reversible and low-risk.