Ancha (NL) WireGuard: ~13% packet loss inside the tunnel, single-stream TCP collapses to ~145 KB/s

[airvpn17 0]

Setup
- Server: Ancha (NL, Alblasserdam), WireGuard, endpoint 213.152.162.164:1637
- Client: kernel WireGuard on Linux 6.8 (x86_64), config from the AirVPN config generator, tunnel MTU 1320
- Line: 0% loss, 9.3 ms to the same destinations with the VPN bypassed, ~16 MB/s

Symptom
Single-stream TCP downloads through the tunnel collapse. Same box, same URLs,
same minute, all local traffic frozen so the tunnel was idle (RX 62 KB/s,
TX 35 KB/s):

  destination   direct        via AirVPN     ratio
  Fastly        16.1 MB/s     145 KB/s       110x
  OVH           11.9 MB/s     381 KB/s        31x
  Cloudflare     9.2 MB/s     1.33 MB/s      6.9x

Packet loss
mtr -rwnc 100 inside the tunnel, destination-hop loss:
  Fastly 151.101.2.132      14.0%   avg 24.1 ms
  Cloudflare 104.16.0.1     13.0%   avg 31.9 ms
  OVH 141.95.207.211        19.0%   avg 34.3 ms
Loss is present from hop 2 (134.19.179.129) onward on every path.
(Hop 1, 10.128.0.1, reads 75% -- ICMP policing, disregarded.)

mtr from the same host with the VPN bypassed:
  -> 151.101.2.132           0.0%   avg  9.3 ms, every hop 0.0%
  -> 213.152.162.164         0.0% on all 12 hops, 13.3% at the endpoint itself

Why the severity differs by destination
The loss is uniform but the throughput hit is not, because it depends on the
remote end's congestion control. Mathis with the measured values
(MSS 1280, RTT 24 ms, p = 0.14) predicts 173 KB/s for loss-based CC; Fastly
measures 146 KB/s. Cloudflare at 13% loss should be ~136 KB/s by the same
formula and delivers 1.33 MB/s, i.e. roughly 10x over the loss-based limit,
consistent with a loss-tolerant controller. So a single ~13% tunnel loss
explains all three rows.

Ruled out locally, with counters
- tun0, container eth0 and host NIC: 0 errors, 0 dropped
- UDP InErrors 0, RcvbufErrors 0
- CPU 65% idle, softirq 1% during the transfers
- MTU: payloads up to 1292 B traverse, no size cliff in a 500-1292 sweep
- Not local load: measured with all torrent traffic frozen
- Not CDN-side: Fastly serves from the correct POP (cache-ams-...-AMS, 19-42 ms)

Reproducer
Pause any local traffic, then, from inside the tunnel's network namespace:
  wget -O /dev/null --header='Range: bytes=0-1999999' \
    https://dl-cdn.alpinelinux.org/alpine/v3.22/community/x86_64/APKINDEX.tar.gz
  mtr -rwnc 100 151.101.2.132
and the same two commands with the VPN bypassed, for comparison.

Onset was around 22:40 CEST on 2026-09-20 and it was still reproducing at
01:35 CEST on 2026-09-21. Happy to run anything else you want from this end.

[Staff 10645]

@airvpn17

Hello!

We could not reproduce. Does the problem persist? Can you please re-test?

Kind regards