#1399 - [GH-ISSUE #3043] Windows 11 + AWG 3.1: handshake completes but no traffic passes — server sees 2 KiB received vs 21 KiB sent (kernel module 3.1, clean install) - amnezia-vpn/amnezia-client

bsakaguchi commented

2026-10-13 20:41:40 +00:00

Owner

Originally created by @ZindRom on GitHub (Aug 25, 2026).
Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/3043

Summary

On Windows 11 with AmneziaVPN 5.0.1.5 and a self-hosted AmneziaWG 3.1 server, the handshake completes reliably but no transport traffic passes. The client sits on "Connecting…" or reports connected while nothing loads.

The distinguishing detail versus other reports: the server side confirms the handshake and shows a strongly asymmetric counter — it answers, the client never processes the replies and retries.

peer: <redacted>
  endpoint: <client-ip>:47970
  latest handshake: 1 minute, 26 seconds ago
  transfer: 2.17 KiB received, 21.66 KiB sent

Same ratio (roughly 1:10, received:sent) reproduced across every configuration listed below.

Environment


Client	AmneziaVPN 5.0.1.5 (pre-release), Windows 11 26100
Server	self-hosted VPS, Ubuntu 24.04, kernel 6.8.0-117-generic
Protocol	AmneziaWG 3.1, container deployed by the client itself over SSH
Server engine	kernel module `amneziawg 3.1.20260812` (amneziawg-dkms), confirmed via `ip -d link` — not the userspace `amneziawg-go`

Server-generated interface config:

Jc = 6
S1 = 76, S2 = 47, S3 = 33, S4 = 12
HeaderProtectionKey = <redacted>
ContentPaddingAddition = 10-100
RandomTrailers = on
DisableCookies = on

What was ruled out

Each of these was tested separately, and the symptom did not change once:

Engine: userspace amneziawg-go 3.1 and kernel module 3.1 — identical behaviour. (The kernel module accepts the full AWG3 parameter set: s1–s4, header-protection-key, content-padding-addition, random-trailers.)
Client: AmneziaVPN 5.0.1.5 and the standalone amneziawg-windows-client (the latter cannot import AWG3 configs at all — see amneziawg-windows-client#114).
Obfuscation level: full AWG3; partial (header protection removed, S1–S4 kept); and none at all (only Jc/Jmin/Jmax + randomized H1–H4).
MTU: 1420 and 1280, applied on both ends.
Split tunneling: on and off. Note: the setting re-enables itself after being disabled via the registry, and mullvad-split-tunnel.sys stays loaded and Running even with both toggles off and the VPN disconnected.
DNS: default 1.1.1.1/1.0.0.1 replaced with 77.88.8.8/8.8.8.8.
Windows reboot after the client update (per the update instructions).
Full purge: all Amnezia containers, images and networks removed from the server, then a clean install from the client. Symptom identical on the fresh deployment.

Server health (not the cause)

Container reaches the internet: ping 1.1.1.1 0% loss, DNS resolution works, curl https://github.com returns 200 in ~0.1 s.
net.ipv4.ip_forward = 1; MASQUERADE and FORWARD rules for the tunnel subnet present after every restart.
UDP port listening and reachable — the handshake proves the path works in both directions for small packets.
Hysteria2 on the same host, same public IP, works flawlessly throughout, so the network path itself is fine.

Observation

Handshake obfuscation (Jc/Jmin/Jmax, H1–H4) and transport obfuscation (S3/S4, header protection, padding) behave independently here: the handshake always succeeds, the transport never carries data. That points at transport-packet handling on the Windows client rather than at the handshake or the server.

#3038 — "3.1 версия не работает, вечное подключение" on Windows 11; another user: "Установил новый протокол. Теперь подключение - переподключение и не открывается ничего"
#3016 — AWG 3.0 vs 3.1 compatibility, 3.1 server support only in pre-release 5.0.1.5
#2996, #3033 — AmneziaWG not passing traffic in RU networks
amneziawg-go#168 — stale S4 on the first transport packet (matrix in that report shows Sx as the trigger; still reproduces on 3.1)

Happy to provide packet captures or run any diagnostic on either side — the server is under my control and reproduction takes under a minute.

Originally created by @ZindRom on GitHub (Aug 25, 2026). Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/3043 ## Summary On Windows 11 with AmneziaVPN 5.0.1.5 and a self-hosted AmneziaWG 3.1 server, the handshake completes reliably but **no transport traffic passes**. The client sits on "Connecting…" or reports connected while nothing loads. The distinguishing detail versus other reports: **the server side confirms the handshake and shows a strongly asymmetric counter** — it answers, the client never processes the replies and retries. ``` peer: <redacted> endpoint: <client-ip>:47970 latest handshake: 1 minute, 26 seconds ago transfer: 2.17 KiB received, 21.66 KiB sent ``` Same ratio (roughly 1:10, received:sent) reproduced across every configuration listed below. ## Environment | | | |---|---| | Client | AmneziaVPN 5.0.1.5 (pre-release), Windows 11 26100 | | Server | self-hosted VPS, Ubuntu 24.04, kernel 6.8.0-117-generic | | Protocol | AmneziaWG 3.1, container deployed by the client itself over SSH | | Server engine | **kernel module `amneziawg 3.1.20260812`** (amneziawg-dkms), confirmed via `ip -d link` — not the userspace `amneziawg-go` | Server-generated interface config: ``` Jc = 6 S1 = 76, S2 = 47, S3 = 33, S4 = 12 HeaderProtectionKey = <redacted> ContentPaddingAddition = 10-100 RandomTrailers = on DisableCookies = on ``` ## What was ruled out Each of these was tested separately, and the symptom did not change once: - **Engine**: userspace `amneziawg-go` 3.1 *and* kernel module 3.1 — identical behaviour. (The kernel module accepts the full AWG3 parameter set: s1–s4, `header-protection-key`, `content-padding-addition`, `random-trailers`.) - **Client**: AmneziaVPN 5.0.1.5 and the standalone `amneziawg-windows-client` (the latter cannot import AWG3 configs at all — see amneziawg-windows-client#114). - **Obfuscation level**: full AWG3; partial (header protection removed, S1–S4 kept); and none at all (only `Jc/Jmin/Jmax` + randomized `H1–H4`). - **MTU**: 1420 and 1280, applied on both ends. - **Split tunneling**: on and off. Note: the setting re-enables itself after being disabled via the registry, and `mullvad-split-tunnel.sys` stays loaded and `Running` even with both toggles off and the VPN disconnected. - **DNS**: default `1.1.1.1`/`1.0.0.1` replaced with `77.88.8.8`/`8.8.8.8`. - **Windows reboot** after the client update (per the update instructions). - **Full purge**: all Amnezia containers, images and networks removed from the server, then a clean install from the client. Symptom identical on the fresh deployment. ## Server health (not the cause) - Container reaches the internet: `ping 1.1.1.1` 0% loss, DNS resolution works, `curl https://github.com` returns 200 in ~0.1 s. - `net.ipv4.ip_forward = 1`; MASQUERADE and FORWARD rules for the tunnel subnet present after every restart. - UDP port listening and reachable — the handshake proves the path works in both directions for small packets. - Hysteria2 on the same host, same public IP, works flawlessly throughout, so the network path itself is fine. ## Observation Handshake obfuscation (`Jc/Jmin/Jmax`, `H1–H4`) and transport obfuscation (`S3/S4`, header protection, padding) behave independently here: the handshake always succeeds, the transport never carries data. That points at transport-packet handling on the Windows client rather than at the handshake or the server. ## Possibly related - #3038 — "3.1 версия не работает, вечное подключение" on Windows 11; another user: "Установил новый протокол. Теперь подключение - переподключение и не открывается ничего" - #3016 — AWG 3.0 vs 3.1 compatibility, 3.1 server support only in pre-release 5.0.1.5 - #2996, #3033 — AmneziaWG not passing traffic in RU networks - amneziawg-go#168 — stale S4 on the first transport packet (matrix in that report shows Sx as the trigger; still reproduces on 3.1) Happy to provide packet captures or run any diagnostic on either side — the server is under my control and reproduction takes under a minute.

bsakaguchi commented

2026-10-13 20:41:42 +00:00

Author

Owner

@Vitalik93 commented on GitHub (Aug 25, 2026):

У меня на Windows тоже ни один сайт не открывается. Причем на Android тот же self hosted с теми же настройками летает. Заебись для десктопа релиз выпустили...

@Vitalik93 commented on GitHub (Aug 25, 2026): У меня на Windows тоже ни один сайт не открывается. Причем на Android тот же self hosted с теми же настройками летает. Заебись для десктопа релиз выпустили...

bsakaguchi commented

2026-10-13 20:41:42 +00:00

Author

Owner

@edshPC commented on GitHub (Aug 25, 2026):

Тоже самое, обновил на сервере AWG до 3.1, думал будет лучше работать, по итогу вообще ничего не работает теперь. На 2.0 с Windows было отлично, но с Android тот же ютуб сильно тупил, на 3.1 на Android ничего не изменилось, на Windows теперь ничего не работает 👍

@edshPC commented on GitHub (Aug 25, 2026): Тоже самое, обновил на сервере AWG до 3.1, думал будет лучше работать, по итогу вообще ничего не работает теперь. На 2.0 с Windows было отлично, но с Android тот же ютуб сильно тупил, на 3.1 на Android ничего не изменилось, на Windows теперь ничего не работает 👍

bsakaguchi commented

2026-10-13 20:41:42 +00:00

Author

Owner

@romabord commented on GitHub (Aug 25, 2026):

+++ Регулярные отвалы на шиндовсе без специфических ошибок в логах, 2.0 ведет себя стабильно.

@romabord commented on GitHub (Aug 25, 2026): +++ Регулярные отвалы на шиндовсе без специфических ошибок в логах, 2.0 ведет себя стабильно.

bsakaguchi commented

2026-10-13 20:41:43 +00:00

Author

Owner

@Vitalik93 commented on GitHub (Aug 25, 2026):

Тут в соседней ветке писали, что в последней версии приложения WG 2.0 как раз уже не работает)

@Vitalik93 commented on GitHub (Aug 25, 2026): Тут в соседней ветке писали, что в последней версии приложения WG 2.0 как раз уже не работает)

bsakaguchi commented

2026-10-13 20:41:43 +00:00

Author

Owner

@nikitoid commented on GitHub (Aug 25, 2026):

Тоже столкнулся с падением скорости после обновления AWG до 3.1 на сервере. Проблема только на ПК (Windows 11). Через смартфон (Android) скорость остается высокой.

@nikitoid commented on GitHub (Aug 25, 2026): Тоже столкнулся с падением скорости после обновления AWG до 3.1 на сервере. Проблема только на ПК (Windows 11). Через смартфон (Android) скорость остается высокой.

bsakaguchi commented

2026-10-13 20:41:43 +00:00

Author

Owner

@Sou1Jkeee commented on GitHub (Aug 25, 2026):

same issue but on linux

@Sou1Jkeee commented on GitHub (Aug 25, 2026): same issue but on linux

bsakaguchi commented

2026-10-13 20:41:44 +00:00

Author

Owner

@drcolombo commented on GitHub (Aug 26, 2026):

On Windows 11 after update to WG3.1:

[2026-08-26 06:05:29.403Z] [DEBUG] AmneziaVPN  : "Trying to connect to VPN, server id is f1baa3f6-fbd6-4d2d-9119-b2104919d504, container is amnezia-awg2, route mode is" amnezia::route_mode_ns::VpnOnlyForwardSites
[2026-08-26 06:05:29.404Z] [DEBUG] AmneziaVPN LocalSocketController : Deactivating
[2026-08-26 06:05:29.404Z] [DEBUG] AmneziaVPN  : VpnProtocol::setConnectionState "Disconnected"
[2026-08-26 06:05:29.404Z] [DEBUG] AmneziaVPN LocalSocketController : Deactivating
[2026-08-26 06:05:29.404Z] [DEBUG] AmneziaVPN  : VpnProtocol::setConnectionState "Disconnected"
[2026-08-26 06:05:29.605Z] [DEBUG] AmneziaVPN  : "Site split tunneling is disabled, route mode is 0"
[2026-08-26 06:05:29.605Z] [DEBUG] AmneziaVPN  : "App split tunneling is disabled, route mode is 0"
[2026-08-26 06:05:29.605Z] [DEBUG] AmneziaVPN LocalSocketController : Initializing
[2026-08-26 06:05:29.605Z] [DEBUG] AmneziaVPN LocalSocketController : Connecting to: \\.\pipe\amneziavpn
[2026-08-26 06:05:29.605Z] [DEBUG] AmneziaVPN LocalSocketController : Daemon connected
[2026-08-26 06:05:29.605Z] [DEBUG] AmneziaVPN LocalSocketController : Check status
[2026-08-26 06:05:29.605Z] [DEBUG] AmneziaVPN LocalSocketController : Reading
[2026-08-26 06:05:29.606Z] [DEBUG] AmneziaVPN LocalSocketController : Parse command: status
[2026-08-26 06:05:59.929Z] [DEBUG] AmneziaVPN LocalSocketController : Reading
[2026-08-26 06:05:59.929Z] [DEBUG] AmneziaVPN LocalSocketController : Parse command: backendFailure
[2026-08-26 06:05:59.929Z] [ERROR] AmneziaVPN LocalSocketController : generic backend failure error (fatal or error none)
[2026-08-26 06:05:59.929Z] [WARNING] AmneziaVPN LocalSocketController : Invalid command received: {"errorCode":1,"type":"backendFailure"}
[2026-08-26 06:05:59.929Z] [DEBUG] AmneziaVPN LocalSocketController : Parse command: disconnected

And OpenVPN over cloak is not supported anymore (that's the only that was working on Windows 11 for me).

@drcolombo commented on GitHub (Aug 26, 2026): On Windows 11 after update to WG3.1: ``` [2026-08-26 06:05:29.403Z] [DEBUG] AmneziaVPN : "Trying to connect to VPN, server id is f1baa3f6-fbd6-4d2d-9119-b2104919d504, container is amnezia-awg2, route mode is" amnezia::route_mode_ns::VpnOnlyForwardSites [2026-08-26 06:05:29.404Z] [DEBUG] AmneziaVPN LocalSocketController : Deactivating [2026-08-26 06:05:29.404Z] [DEBUG] AmneziaVPN : VpnProtocol::setConnectionState "Disconnected" [2026-08-26 06:05:29.404Z] [DEBUG] AmneziaVPN LocalSocketController : Deactivating [2026-08-26 06:05:29.404Z] [DEBUG] AmneziaVPN : VpnProtocol::setConnectionState "Disconnected" [2026-08-26 06:05:29.605Z] [DEBUG] AmneziaVPN : "Site split tunneling is disabled, route mode is 0" [2026-08-26 06:05:29.605Z] [DEBUG] AmneziaVPN : "App split tunneling is disabled, route mode is 0" [2026-08-26 06:05:29.605Z] [DEBUG] AmneziaVPN LocalSocketController : Initializing [2026-08-26 06:05:29.605Z] [DEBUG] AmneziaVPN LocalSocketController : Connecting to: \\.\pipe\amneziavpn [2026-08-26 06:05:29.605Z] [DEBUG] AmneziaVPN LocalSocketController : Daemon connected [2026-08-26 06:05:29.605Z] [DEBUG] AmneziaVPN LocalSocketController : Check status [2026-08-26 06:05:29.605Z] [DEBUG] AmneziaVPN LocalSocketController : Reading [2026-08-26 06:05:29.606Z] [DEBUG] AmneziaVPN LocalSocketController : Parse command: status [2026-08-26 06:05:59.929Z] [DEBUG] AmneziaVPN LocalSocketController : Reading [2026-08-26 06:05:59.929Z] [DEBUG] AmneziaVPN LocalSocketController : Parse command: backendFailure [2026-08-26 06:05:59.929Z] [ERROR] AmneziaVPN LocalSocketController : generic backend failure error (fatal or error none) [2026-08-26 06:05:59.929Z] [WARNING] AmneziaVPN LocalSocketController : Invalid command received: {"errorCode":1,"type":"backendFailure"} [2026-08-26 06:05:59.929Z] [DEBUG] AmneziaVPN LocalSocketController : Parse command: disconnected ``` And OpenVPN over cloak is not supported anymore (that's the only that was working on Windows 11 for me).

bsakaguchi commented

2026-10-13 20:41:44 +00:00

Author

Owner

@samdark commented on GitHub (Aug 26, 2026):

Reproduced under Linux and Android clients. Fresh server. Automatic deployment. A handshake is fine, but traffic does not go through. Nothing suspicious in the client logs or server logs.

Rolling back to Linux client 5.0.0.5 + using AWG 2 works on the same server, so that's not networking/banned IP but a bug in provisioning.

Same behavior with XRay btw., so I don't think that's specific to recent AWG update.

@samdark commented on GitHub (Aug 26, 2026): Reproduced under Linux and Android clients. Fresh server. Automatic deployment. A handshake is fine, but traffic does not go through. Nothing suspicious in the client logs or server logs. Rolling back to Linux client 5.0.0.5 + using AWG 2 works on the same server, so that's not networking/banned IP but a bug in provisioning. Same behavior with XRay btw., so I don't think that's specific to recent AWG update.

bsakaguchi commented

2026-10-13 20:41:44 +00:00

Author

Owner

@samdark commented on GitHub (Aug 26, 2026):

btw., the Android client is still the latest and it works well. That makes me think that the issue is how the latest client release provisions the fresh server.

@samdark commented on GitHub (Aug 26, 2026): btw., the Android client is still the latest and it works well. That makes me think that the issue is how the latest client release provisions the fresh server.

bsakaguchi commented

2026-10-13 20:41:45 +00:00

Author

Owner

@samdark commented on GitHub (Aug 26, 2026):

I think the issue could be traced by provisioning fresh with 5.0.0.5 and 5.0.1.5 (AWG + XRay) and comparing:

docker inspect differences in networking / ports.
iptables of container / host.
awg0.conf
server.json

@samdark commented on GitHub (Aug 26, 2026): I think the issue could be traced by provisioning fresh with 5.0.0.5 and 5.0.1.5 (AWG + XRay) and comparing: 1. docker inspect differences in networking / ports. 2. iptables of container / host. 3. awg0.conf 4. server.json

bsakaguchi commented

2026-10-13 20:41:45 +00:00

Author

Owner

@RexSatanas commented on GitHub (Aug 26, 2026):

на маке такая же проблема.

@RexSatanas commented on GitHub (Aug 26, 2026): на маке такая же проблема.

bsakaguchi commented

2026-10-13 20:41:46 +00:00

Author

Owner

@Vitalik93 commented on GitHub (Aug 27, 2026):

В общем, как здесь и советовали, поменял в настройках протокола MTU на 1280 и теперь работает как надо. На телефоне это значение и так стояло и при переносе конфига с него на комп все параметры перенеслись нормально, кроме этого MTU.

@Vitalik93 commented on GitHub (Aug 27, 2026): В общем, как здесь и советовали, поменял в настройках протокола MTU на 1280 и теперь работает как надо. На телефоне это значение и так стояло и при переносе конфига с него на комп все параметры перенеслись нормально, кроме этого MTU.

bsakaguchi commented

2026-10-13 20:41:46 +00:00

Author

Owner

@Vitalik93 commented on GitHub (Aug 27, 2026):

https://github.com/amnezia-vpn/amnezia-client/issues/3064

@Vitalik93 commented on GitHub (Aug 27, 2026): https://github.com/amnezia-vpn/amnezia-client/issues/3064

bsakaguchi commented

2026-10-13 20:41:46 +00:00

Author

Owner

@SooLMV commented on GitHub (Sep 8, 2026):

Windows 11 Pro 10.0.26200, AmneziaVPN 5.0.1.5.

A sequential AWG3.1 connection establishes a handshake, but application traffic fails. The same pilot profile previously provided connectivity on Android and iPhone; this does not imply performance acceptance.

Confirmed during an active Windows run:

Tunnel adapter Up; IPv4/IPv6 addresses and default routes present.
MTU 1280.
Interface counters increased: RX +9323, TX +11367 bytes.
A bounded HTTPS request timed out.
Temporarily disabling the kill switch did not restore connectivity.

These observations exclude missing default-route installation for that run, but do not establish the root cause or successful payload transport.

The retained ring log cannot establish the UDP socket’s selected interface. It differs from the historical checksum and contains no matching binding events for the inspected date.

Could maintainers recommend a supported, narrowly scoped diagnostic to distinguish socket-binding failure from the AWG3.1 payload-processing path? We would prefer not to repeat adapter/route-presence or kill-switch tests.

@SooLMV commented on GitHub (Sep 8, 2026): Windows 11 Pro 10.0.26200, AmneziaVPN 5.0.1.5. A sequential AWG3.1 connection establishes a handshake, but application traffic fails. The same pilot profile previously provided connectivity on Android and iPhone; this does not imply performance acceptance. Confirmed during an active Windows run: - Tunnel adapter Up; IPv4/IPv6 addresses and default routes present. - MTU 1280. - Interface counters increased: RX +9323, TX +11367 bytes. - A bounded HTTPS request timed out. - Temporarily disabling the kill switch did not restore connectivity. These observations exclude missing default-route installation for that run, but do not establish the root cause or successful payload transport. The retained ring log cannot establish the UDP socket’s selected interface. It differs from the historical checksum and contains no matching binding events for the inspected date. Could maintainers recommend a supported, narrowly scoped diagnostic to distinguish socket-binding failure from the AWG3.1 payload-processing path? We would prefer not to repeat adapter/route-presence or kill-switch tests.

Rows
Columns

[GH-ISSUE #3043] Windows 11 + AWG 3.1: handshake completes but no traffic passes — server sees 2 KiB received vs 21 KiB sent (kernel module 3.1, clean install) #1399

Summary

Environment

What was ruled out

Server health (not the cause)

Observation

Possibly related