[GH-ISSUE #222] kmod v3.1.20260812 as client: handshake ignored by amneziawg-go v3.1.20260813+ servers with HeaderProtectionKey (go client works) #127

New issue

Open

opened 2026-10-13 21:06:49 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-13 21:06:49 +00:00

Owner

Originally created by @Fedoseew on GitHub (Aug 26, 2026).
Original GitHub issue: https://github.com/amnezia-vpn/amneziawg-linux-kernel-module/issues/222

Originally assigned to: @ygurov on GitHub.

Environment

Client: OpenWrt 25.12.5 (kernel 6.12.94, ramips/mt7621), kmod-amneziawg 3.1.20260812 + amneziawg-tools 3.1.20260812 (built from the release tags), netifd proto with full 3.1 option support
Server: Amnezia Premium (amneziawg-go v3.1.x, HeaderProtectionKey enabled)

Summary

The kernel module at tag v3.1.20260812 cannot complete a handshake with a server running current amneziawg-go, while amneziawg-go as a client connects fine with the same config from the same network. amneziawg-go received the wire-format fix fix: wrong trailerLen for HandshakeCookie message (2026-08-13) after the last kmod tag, so the two implementations appear to have diverged.

Config (client side, from Amnezia Premium export; keys/endpoint omitted)

Jc=6, Jmin=10, Jmax=80, S1=612, S2=311, S3=1204, S4=12, H1–H4=1–4,
HeaderProtectionKey set, I1 set (signature packet), ContentPaddingAddition=10-100,
RekeyAfterTime=100-120, RekeyTimeout=3-8, RejectAfterTime=150-180,
KeepaliveTimeout=7-13, MaxHandshakeAttempts=15-20, PersistentKeepalive=25-35, PSK set.

awg show confirms every parameter above is applied to the interface (including header protection key and ranges).

Symptom

Initiation packets are sent (transfer: 0 B received, 4.40 KiB sent and growing), zero bytes ever received; no handshake within 60 s.
No errors in dmesg (only the module load banner) or netifd; interface configures cleanly.

Cross-checks (why this points at the kmod)

Same config imported into the AmneziaVPN desktop app (amneziawg-go) on the same LAN → connects immediately.
To rule out ISP/path/source-IP filtering: forwarded the kmod's handshake packets through a VPS UDP DNAT so they reached the server from the exact source IP the working go client had used → still ignored (iptables counters: 56 packets / ~17.7 KB forwarded to the server, zero replies).
Same kmod build works fine against a self-hosted amneziawg-go v3.1.20260814 server without HeaderProtectionKey (AWG 2.0-style params incl. S3/S4/I1) — so the divergence seems specific to the 3.1 header-protection/handshake path.

Ask

A kmod release aligned with amneziawg-go ≥ v3.1.20260813 (or a pointer if client-side 3.1 against current premium servers needs something else).

Originally created by @Fedoseew on GitHub (Aug 26, 2026). Original GitHub issue: https://github.com/amnezia-vpn/amneziawg-linux-kernel-module/issues/222 Originally assigned to: @ygurov on GitHub. ## Environment - Client: OpenWrt 25.12.5 (kernel 6.12.94, ramips/mt7621), `kmod-amneziawg 3.1.20260812` + `amneziawg-tools 3.1.20260812` (built from the release tags), netifd proto with full 3.1 option support - Server: Amnezia Premium (amneziawg-go v3.1.x, HeaderProtectionKey enabled) ## Summary The kernel module at tag `v3.1.20260812` cannot complete a handshake with a server running current amneziawg-go, while amneziawg-go as a client connects fine with the same config from the same network. amneziawg-go received the wire-format fix `fix: wrong trailerLen for HandshakeCookie message` (2026-08-13) *after* the last kmod tag, so the two implementations appear to have diverged. ## Config (client side, from Amnezia Premium export; keys/endpoint omitted) Jc=6, Jmin=10, Jmax=80, S1=612, S2=311, S3=1204, S4=12, H1–H4=1–4, HeaderProtectionKey set, I1 set (signature packet), ContentPaddingAddition=10-100, RekeyAfterTime=100-120, RekeyTimeout=3-8, RejectAfterTime=150-180, KeepaliveTimeout=7-13, MaxHandshakeAttempts=15-20, PersistentKeepalive=25-35, PSK set. `awg show` confirms every parameter above is applied to the interface (including `header protection key` and ranges). ## Symptom - Initiation packets are sent (`transfer: 0 B received, 4.40 KiB sent` and growing), zero bytes ever received; no handshake within 60 s. - No errors in dmesg (only the module load banner) or netifd; interface configures cleanly. ## Cross-checks (why this points at the kmod) 1. Same config imported into the AmneziaVPN desktop app (amneziawg-go) on the same LAN → connects immediately. 2. To rule out ISP/path/source-IP filtering: forwarded the kmod's handshake packets through a VPS UDP DNAT so they reached the server from the exact source IP the working go client had used → still ignored (iptables counters: 56 packets / ~17.7 KB forwarded to the server, zero replies). 3. Same kmod build works fine against a self-hosted amneziawg-go v3.1.20260814 server *without* HeaderProtectionKey (AWG 2.0-style params incl. S3/S4/I1) — so the divergence seems specific to the 3.1 header-protection/handshake path. ## Ask A kmod release aligned with amneziawg-go ≥ v3.1.20260813 (or a pointer if client-side 3.1 against current premium servers needs something else).

bsakaguchi commented

2026-10-13 21:06:50 +00:00

Author

Owner

@press-vm commented on GitHub (Sep 9, 2026):

The newest kmod tag (v3.1.20260906, via #232) fixes the I1-I5/junk-packet trailer issue but doesn't touch the cookie-reply path — wg_socket_send_buffer_as_reply_to_skb() is untouched by that PR. #189 ("fix: wrong cookie-reply size constant, UB shift in bogus_endpoints") looks like it might be the missing piece for the trailerLen-for-HandshakeCookie parity with amneziawg-go's #179. Still reproducible with the latest tag as far as I can tell.

@press-vm commented on GitHub (Sep 9, 2026): The newest kmod tag (v3.1.20260906, via #232) fixes the I1-I5/junk-packet trailer issue but doesn't touch the cookie-reply path — wg_socket_send_buffer_as_reply_to_skb() is untouched by that PR. #189 ("fix: wrong cookie-reply size constant, UB shift in bogus_endpoints") looks like it might be the missing piece for the trailerLen-for-HandshakeCookie parity with amneziawg-go's #179. Still reproducible with the latest tag as far as I can tell.

No labels

pull-request

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

amnezia-vpn/amneziawg-linux-kernel-module#127

No description provided.

Rows
Columns