WireGuard MTU problems are plausible when the tunnel has a current handshake and small exchanges work, yet larger transfers stall, fail in one direction, or fail only over IPv4 or IPv6. Prove that size dependence with repeatable tests before changing MTU. Lower the tunnel MTU temporarily in measured steps, retest the same flows, and restore the original value if the failure boundary does not move.

The complete VPN guide covers broader failures. This guide assumes route and peer selection are already credible and focuses on packet-size evidence.

Key Takeaways

Slow speed alone is not an MTU diagnosis; look for a repeatable size threshold or direction-specific stall.

Record the original interface MTU and the effective routes before every experiment.

Test IPv4 and IPv6 independently because their PMTU mechanisms and minimum link MTUs differ.［2］［3］

A lower working MTU is diagnostic evidence, not automatically the correct permanent value.

Do not disable ICMP or prescribe one “magic” MTU for every path.

What does MTU change inside a WireGuard path?

MTU is the largest network-layer packet an interface expects to carry without requiring a different handling decision. WireGuard adds an outer IP header, a UDP header, and tunnel overhead around the inner packet. The usable inner MTU therefore depends on the outer address family and every link between the peers, not just the physical interface next to the client.

wg-quick can calculate an interface MTU from an endpoint route or a system default and allows an explicit MTU override.［1］ That convenience is not knowledge of every later path segment. Encapsulation by another tunnel, mobile carrier, virtual network, PPP link, cloud overlay, or an unexpectedly smaller intermediate link can reduce the effective Path MTU.

IPv4 Path MTU Discovery relies on routers reporting that a datagram requiring no fragmentation cannot be forwarded at its current size. RFC 1191 describes the ICMP feedback and the sender's adaptation.［2］ IPv6 routers do not fragment packets in transit; RFC 8201 defines Packet Too Big feedback and requires a minimum IPv6 link MTU of 1280 octets, with special handling below that threshold.［3］ Filtering or losing this feedback can create a “black hole” where small packets work and larger ones repeatedly disappear.

Which symptoms indicate WireGuard MTU problems?

Begin with contrast, not intuition. A handshake uses small protocol messages, so it may succeed across a path that drops larger encrypted transport packets. A short request may work while a large response stalls. One direction may fail because the forward and return paths have different limits.

Symptom	MTU signal strength	Competing explanations to exclude
Small request and response work; larger response consistently stalls	Strong	Application range handling, server limit, congestion
One packet size works and a slightly larger one repeatedly fails	Strong	Rate limit or stateful firewall threshold
IPv4 works but IPv6 large transfers fail	Moderate to strong	Missing IPv6 route, DNS preference, IPv6 firewall
One direction works at large size; the other stalls	Moderate to strong	Asymmetric routing, receiver firewall, service behavior
All packets fail, including tiny numeric probes	Weak	Routing, peer selection, key, endpoint, forwarding
Throughput is merely lower than expected	Weak	Congestion, CPU, radio quality, shaping, server load
One website fails but equal-size controlled transfers work	Weak	TLS, HTTP, CDN, application policy

If WireGuard TX and RX do not move for a small probe, return to the post-handshake counter matrix. MTU testing cannot repair traffic that never selected the peer.

Seven safe MTU tests

Step 1: Capture the original state

Record the WireGuard interface MTU, physical or outer interface MTU, endpoint route, address families, and whether another tunnel or overlay exists. Record a recent handshake and fresh TX/RX deltas for a small successful probe. Then capture the failing operation's direction, approximate payload, timeout behavior, and time.

Use a controlled endpoint where you can vary response or payload size without violating policy. An ordinary web page is poor evidence because content, CDN selection, TLS records, compression, and caching may change between attempts. Prefer an authorized test service or platform tool that reports the effective packet result.

Save the exact command or supported UI action needed to restore the initial MTU. If the device is managed, the interface may be recreated automatically; learn whether a temporary change persists across reconnects before relying on it.

Stop here if no small bidirectional flow works, if routing differs between tests, or if you cannot restore the setting. Fix the earlier layer before experimenting with packet size.

Step 2: Build a size ladder without overclaiming precision

Start with a clearly small probe that succeeds. Increase size in coarse steps until the result changes, then narrow the interval. Repeat each boundary result to separate a stable threshold from random loss. Keep destination, protocol, direction, address family, and network path fixed.

Account for headers. A tool's payload size is not necessarily the inner IP packet size, and the inner packet size is not the outer encrypted packet size. IPv4 and IPv6 headers differ, optional headers can exist, and utilities vary in what their size argument means. Record the tool and units rather than presenting a payload number as a universal WireGuard MTU.

For ping-style tests, use the platform's documented option when you need to prevent IPv4 fragmentation or request equivalent PMTU behavior. A blocked echo reply is not proof of failure, so corroborate it with a controlled TCP or UDP transfer. Never flood a destination or use a third-party system without permission.

Step 3: Lower the tunnel MTU temporarily

Choose a conservative step below the recorded interface MTU, apply it only to the WireGuard interface through a supported temporary control, and repeat the identical size ladder and application flow. Do not change DNS, routes, firewall rules, and MTU together.

If the previously failing threshold moves upward or the large flow becomes repeatably usable while small-flow behavior remains stable, the result supports an MTU or PMTU explanation. It does not show which link is limiting the outer path or whether the chosen value is optimal.

If nothing changes, restore the original MTU before investigating another hypothesis. Continuing to decrease it can add overhead and hide a route, firewall, congestion, or application problem. Never leave an undocumented low value merely because it did not make the test worse.

Step 4: Compare IPv4 and IPv6 separately

Run the same small and large tests to explicit IPv4 and IPv6 destinations. Record the chosen route, source address, interface MTU, counter deltas, and result. Do not let a hostname silently switch address families between attempts.

For IPv4, inspect whether required ICMP “fragmentation needed” information reaches the sender and whether any device rewrites or fragments packets. RFC 1191 warns that old behavior and incorrect handling can impair discovery.［2］ For IPv6, inspect Packet Too Big feedback and avoid setting an IPv6-facing design below its architectural requirements without understanding the required fragmentation behavior.［3］

A family-specific failure can also be ordinary routing. If even the small IPv6 probe fails or uses another interface, consult the IPv6-only network guide before attributing the result to MTU.

Step 5: Test both directions and locate feedback loss

Reverse the controlled transfer when possible. Upload and download may cross different access links, policies, or tunnel stacks. Record where the larger packet is last observed and whether an ICMP error returns to the original sender.

If you administer the path, use narrow interface and firewall counters to see whether Packet Too Big or fragmentation-needed messages are generated and admitted. Permit the required control messages according to documented policy rather than disabling the firewall. ICMP carries essential network feedback; blocking it wholesale is not a hardening strategy.

If you do not administer the path, compare two permitted networks or endpoints while holding the device and configuration constant. A changed threshold narrows the problem to path-dependent overhead or feedback, but it does not authorize changing the intervening network.

Step 6: Decide whether a persistent MTU override is justified

A permanent override needs repeatable evidence across reconnects and both traffic directions. Select the highest documented value that works reliably for the intended path, leaving reasonable room for known encapsulation variation. Validate interactive traffic, large downloads, uploads, IPv4, IPv6 if supported, and the application's normal workload.

Prefer fixing broken PMTU feedback or a misconfigured outer link when you control it. A smaller tunnel MTU is sometimes the practical client-side mitigation, but it should be documented with the affected paths and reviewed when network topology changes. wg-quick supports an explicit MTU, yet that field should reflect evidence rather than folklore.［1］

After setting any persistent value, disconnect and reconnect through the supported lifecycle, confirm the actual interface MTU, and repeat the boundary tests. The file-download failure guide can help separate application or storage failures that remain after the packet path is sound.

Step 7: Roll back and preserve a compact record

Restore the original MTU when the test does not produce a repeatable improvement. Remove temporary firewall counters or test services, and verify that no system-wide interface or route was changed accidentally.

Keep a small record: original and tested MTUs, outer path and address family, tool payload semantics, success/failure threshold, direction, fresh TX/RX deltas, and whether relevant ICMP feedback appeared. Avoid packet captures containing unrelated traffic, account details, or destination history.

Escalate when a managed client rewrites the value, only an upstream operator can repair feedback, or no supported control exists. The evidence table is more useful than a recommendation to “try 1280” or another context-free number.

How do you repeat the size test through a managed VPN app?

You can repeat the small-versus-large test through a managed tunnel as a control. Connect AethoVPN on the same device and network, load a small page, then start a large download or upload and note whether it stalls. If both transfers complete there while your own WireGuard peer stalls only on large ones, the access path can carry full-size tunnelled traffic, which makes your own interface MTU the stronger suspect. The app does not document a manual MTU field, so any MTU change stays on your self-managed peer, and support requests should carry sanitized symptoms only. Start the 3-day free trial to run that control.

Summary

Require a repeatable small-versus-large contrast before calling the fault MTU-related.
Freeze the original state and test one numeric destination, direction, and family at a time.
Lower only the tunnel MTU temporarily; a changed boundary is evidence, not a universal answer.
Preserve essential ICMP feedback and inspect the first place it or the large packet disappears.
Validate both directions and both supported address families before making an override persistent.
Restore ineffective experiments and retain a compact, sanitized result record.

FAQ

What MTU should I use for WireGuard?

There is no universal value. The safe inner size depends on the outer address family, links, and additional encapsulation. Measure your path and use documented platform controls.

Why can the handshake work when downloads stall?

Handshake messages are small. They can cross a path that drops larger transport packets or loses the ICMP feedback needed to reduce packet size.

Is 1280 always the best WireGuard MTU?

No. The number is significant to IPv6 architecture, but it is not an automatic optimum for every WireGuard path. An arbitrary low setting can reduce efficiency and mask the real fault.

Should I block ICMP for security?

Do not block it wholesale. IPv4 and IPv6 use ICMP for essential errors and PMTU feedback. Apply documented, scoped firewall policy rather than discarding all control messages.

Can MTU affect only uploads or only downloads?

Yes. Directions can follow asymmetric paths or encounter different links and filters. Test a controlled transfer in both directions before choosing a mitigation.

Does a lower MTU proving successful identify the bad router?

No. It supports a size or PMTU problem along the tested path. You still need per-hop evidence or operator help to locate the limiting link or lost feedback.

Must I restart WireGuard after changing MTU?

That depends on the supported platform control. Confirm the live interface value, and if making it persistent, reconnect through the normal lifecycle and verify that the intended value returns.

Disclaimer: This guide provides general technical troubleshooting information. Change only systems you are authorized to administer, preserve required ICMP feedback, and restore temporary settings after testing.

Sources:

WireGuard Tools, "wg-quick(8)": https://git.zx2c4.com/wireguard-tools/tree/src/man/wg-quick.8
IETF, "RFC 1191: Path MTU Discovery": https://www.rfc-editor.org/info/rfc1191/
IETF, "RFC 8201: Path MTU Discovery for IP version 6": https://www.rfc-editor.org/info/rfc8201/

Sources checked 12 September 2026.

Related Articles:

WireGuard MTU Problems: Symptoms and Safe Tests