WireGuard Stalling: An MTU Limit or a Missing Forward Rule?

The habit is to lower the MTU as soon as WireGuard misbehaves, and that habit hides a different fault. A gateway that will not forward and a path that will not carry large packets produce distinguishable patterns: one fails in both directions and at every size, the other survives small requests and dies on big ones. Identify which shape you have before changing any number. The test is cheap and it removes half the possible causes.

Two failures, two different shapes

A forwarding problem appears immediately past the server. The handshake succeeds, the tunnel address answers, and nothing behind the gateway is reachable even with a tiny request. The packet reached the server and was not passed on, or the reply had no route back.

A size problem appears only above a threshold. DNS, a TCP handshake and a small API call all work, while a file download or a large response hangs. The packets that fit travelled end to end, and the ones that did not were dropped somewhere without a usable report.

Those descriptions point at different people and different config files, which is why measuring the shape is worth more than a guess. A single ping to the gateway cannot separate them.

Rule out forwarding before you shrink anything

Test a destination beyond the gateway, not the gateway itself. A ping to the server's tunnel address only proves that the interface is up and that you can reach the machine terminating the tunnel. Traffic for the wider network depends on IP forwarding being enabled on that machine and on a firewall that permits the forwarded flow. Both have to be true, and either one being false produces the same silence.

Return routing matters just as much. If the destination network does not know how to reach the client's tunnel address, the request arrives and the reply disappears, and the client reports a timeout that looks identical to a dropped forward.

Where the design uses address translation, the translation rule is part of that return path. Removing it while chasing an MTU problem turns one working design into a broken one, so read the existing rules before editing them.

Measure where the break starts

Read the forwarding state and the filter rules first. These are read-only checks and they answer the cheap question:

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
ip route get 10.30.0.9

Then probe sizes with the don't-fragment bit, from the client, toward a host beyond the gateway:

ping -M do -s 1200 10.30.0.9
ping -M do -s 1400 10.30.0.9

If the first probe works and the second fails with a fragmentation error, the path is telling you its usable size. If neither works, you are looking at forwarding or routing, and MTU is not the variable to change.

Fix the layer you proved

When forwarding is the fault, the correction is a forwarding rule or a route, expressed as narrowly as the design allows. When size is the fault, the correction is an MTU that accounts for the encapsulation on this particular path, applied to the interface that needs it rather than to every adapter in the fleet.

Either way, repeat the same task against the same destination afterwards. If the original large transfer now completes, the change addressed the layer that was failing. If only the small probe improved, you treated a symptom and the real limit is still in place.

Write down which shape you observed before the change. That one line, recorded next to the fix, is what stops the next person from lowering an MTU that was never the problem.