IPv6 Packet Too Big: Why Big VPN Transfers Stall

Ping works, the browser loads a small page, and the file transfer hangs, all over IPv6 through the same tunnel. That pattern usually means the sender never learned the path's real size, not that the tunnel is slow. IPv6 expects routers to report the problem with a Packet Too Big message, and encapsulation adds overhead before a packet ever reaches the outer network. If that message is filtered, the sender keeps repeating a size that cannot pass.

Small Requests, Large Stalls

A tunnel wraps each packet in another header, so the usable size inside is smaller than the size outside. A packet sized for the physical link before encapsulation becomes too large afterwards. IPv4 routers may fragment in path, while IPv6 routers do not do that on the sender's behalf, so the sender has to adjust instead. That adjustment depends entirely on receiving the feedback.

A single lost message is enough to produce the classic symptom: handshakes and small replies succeed, and a directory listing or an upload stalls at the same point every time. Users describe it as the VPN being slow, and the logs show nothing wrong with authentication. Both observations are accurate, and neither one locates the fault.

Packet Too Big Is Feedback, Not Traffic

An ICMPv6 Packet Too Big message carries the size the next hop can accept, and the sender uses it to lower its estimate. Filtering it is the equivalent of removing a road sign and then blaming the drivers. A rule that drops all ICMPv6 looks strict while breaking path discovery on every link that needs it. The message is control information about the path, not application payload.

Selective filtering is still reasonable. Echo requests and neighbour discovery play different roles from error messages, and a policy can treat them differently. Follow the platform's documented filtering guidance rather than accepting or dropping the entire protocol, because RFC 8201 defines how that feedback drives discovery.

Check Both Address Families Separately

Test IPv6 on its own, because a successful IPv4 transfer proves nothing about the IPv6 path. Then capture control messages while the large transfer stalls. The two records together either show the feedback leaving or prove it never arrived.

ping -6 -M do -s 1400 host.internal
ip -6 route get 2001:db8:2::10
sudo tcpdump -ni any 'icmp6 and ip6[40] == 2'

The probe sends a packet with the do-not-fragment bit set and reports the size at which it fails, which is the number the tunnel has to accommodate. The route query names the interface that would carry the destination, so you know which link's MTU applies. The capture filters ICMPv6 type 2, the Packet Too Big message, and shows whether it reaches this host at all. If the message appears in the capture and the transfer still stalls, the sender is ignoring it, which moves the investigation into the stack rather than the network.

Adjust Tunnel Size Only After the Evidence

Lowering the tunnel MTU can hide a filtered message and make the symptom disappear, at the cost of more overhead on every packet. That is a workaround rather than a diagnosis, and it should follow the capture instead of replacing it. An arbitrary low value also breaks nothing visibly, which is why it survives in configurations for years. Change it deliberately, record the value, and note which measurement justified it.

When you control the gateway, inspect the rule that drops the message instead of disabling the firewall. One corrected rule is narrower than a policy exception and much easier to defend later. The same reasoning applies to timeouts: not every stall is a size problem, and a capture is what separates the two.