Windows Client - high packet loss after fragmented packet

[peter at steel-hub.co.uk]

Hello,

I am using the wireguard windows client (v0.5.3) and driver (v0.10.1).

Whenever I send data that is larger than the mtu, packet loss goes 
through the roof.  Some packets get through, but almost all of them 
(about 98%) are lost. This will continue until I deactivate and then 
reactivate the tunnel in the windows client.

This does not seem to happen when receiving large packets. However, I 
haven't spent much time testing that.

I tested using an android wireguard client connected to the same server. 
It had no problems.

I used large ping requests to replicate the issue while capturing the 
traffic on the wg and eth interfaces for both the client and server.

When I send a large packet (e.g. 1700 bytes), the client wg interface 
shows two frames: the first frame length equals the mtu (1420 bytes) and 
the second makes up the difference + overhead (328 bytes). However, the 
eth interface on the client only shows the first frame. This is 
confirmed on the server which only receives the first frame. After a 
significant delay, the second frame seems to be sent and a response 
received, but the request has already timed out by then.

After that, packets still come and go but there is some kind of delay 
between packets being received on one interface and appearing on the 
other. By the time the response comes in, the packet is already 
considered lost. For example, normal-sized ping requests mostly showed 
as timed out on the command line but I could see that a response was 
eventually received on the wg interface.

The more large packets I send through the tunnel, the worse it gets. If 
I just send one large packet, there is a delay and most requests 
time-out. After more large packets are sent, I stop receiving responses 
at all on the wg interface. At this point the wireguard client will 
start reporting handshake failures.

As before, deactivating and reactivating the tunnel restores normal 
operation.

Here are some logs that demonstrate the problem:  
https://we.tl/t-qb1ChyWDIC

There are three systems to note:

10.106.15.10 = windows client (win-client)
10.106.0.2 / 10.106.15.1 = wireguard server, debian 11 (server)
10.106.0.3 = test system accessible on lan attached to server, debian 11 
(host)


Thanks,
Peter.