> 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).