From: Zack Newman Subject: Re: Should the default MTU of wg(4) be 1408? To: tech@openbsd.org Date: Thu, 10 Sep 2026 08:53:10 -0600 > It may be indeed a problem that we don't clip the the packet to t->t_mtu > but at the same time the code in wg_encap() is certainly not doing this > right since that bit caused pool panics for various people. While I was never affected, I do recall people experiencing these panics; and this commit causing such panics to go away. > The problem is that padding by 16 bytes and a MTU of 1420 don't play well > since 1420 is not a multiple of 16. The code tries to hard to be smart and > then spectacularly fails. The WireGuard protocol requires padding but also requires that padding not cause the payload to exceed the MTU hence the clamping. As my last reply said, this thread should be ignored for now. I hastily concluded the issue was with OpenBSD's implementation, but I'm not as confident in that anymore. When I remove vio(4) and the public Internet from the equation, an OpenBSD 7.9-stable peer and OpenBSD-current peer do not experience fragmentation when an MTU of 1420 is used, the peers are connected via an IPv6 endpoint, and the physical connection uses a 1500 MTU. I need to see if I can replicate this issue at my house and also see if the issue affects Linux. Right now what I have is the following: * ixl(4) -> vio(4) over the public Internet with 1500 MTU[^1] and two wg(4) peers that connect via IPv6 with MTUs > 1408 experience fragmentation. * vlan(4) with ixl(4) parent -> em(4) with 1500 MTU on the same L2 network and two wg(4) peers that connect via IPv6 using 1420 MTU don't experience fragmentation. * Linux peers on the same L2 network using 1500 MTU for the physical connection don't experience fragmentation when the WireGuard devices use a 1420 MTU and the endpoint uses IPv6. In summary please throw this thread in the trash until I at least can more reliably replicate the behavior and illustrate it only affects OpenBSD. [^1]: ping6(8) confirms fragmentation doesn't occur until the data size exceeds 1452 (i.e., 1500 MTU is appropriate).