* Windows Client - high packet loss after fragmented packet
@ 2022-02-24 0:59 peter
0 siblings, 0 replies; only message in thread
From: peter @ 2022-02-24 0:59 UTC (permalink / raw)
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
Here are some logs that demonstrate the problem:
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
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2022-03-14 17:16 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-24 0:59 Windows Client - high packet loss after fragmented packet peter
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).