amnezia-vpn/amnezia-client

Fork 0

mirror of https://github.com/amnezia-vpn/amnezia-client.git synced 2026-10-14 05:42:24 +00:00

[GH-ISSUE #2219] AmneziaVPN app does not pass S3/S4 to amneziawg-go — transport data blocked with AWG 2.0 servers #985

New issue

Closed

opened 2026-10-13 20:32:23 +00:00 by bsakaguchi · 8 comments

bsakaguchi commented

2026-10-13 20:32:23 +00:00

Owner

Originally created by @remotetohome on GitHub (Feb 14, 2026).
Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/2219

Summary

The AmneziaVPN app (iOS and Android) completes the AWG 2.0 handshake with a server that has non-zero S3/S4, but no transport data flows. The app shows "connected" status, but web traffic does not work. Confirmed on both platforms.

The root cause is that S3 and S4 are never passed to amneziawg-go via UAPI, even though the config file contains them.

Evidence

Server config (OpenWrt kernel module, amneziawg-linux-kernel-module):

s1=53  s2=46  s3=38  s4=21

App UAPI log (observed on both iOS and Android) shows S1, S2, H1-H4, Jc, Jmin, Jmax, I1-I5 all set correctly — but S3 and S4 are completely absent.

Server-side awg show for phone peers:

transfer: 2.15 KiB received, 19.43 KiB sent

Handshake-only traffic. The server keeps sending keepalives (sent increases), but the phone sends almost nothing back (received stays flat).

Phone log:

Received message with unknown type: 2545529037

The first 4 bytes of the S4 random padding are being interpreted as a WireGuard message type.

Control test: Same server, same phones, a WireGuard/AWG 1.0 interface with S3=0/S4=0 works perfectly — 22+ MiB received, 160+ MiB sent.

What's happening

The server kernel module applies S4 bytes before each transport packet:

[S4 random bytes][H4-obfuscated type][encrypted payload]

The phone expects (because S4=0 from its perspective):

[H4-obfuscated type][encrypted payload]

The phone sees S4 junk as the message type → unknown type → discarded. Traffic in both directions fails because the framing assumptions don't match.

Where the bug is

amneziawg-go fully supports S3/S4. The UAPI parser in device/uapi.go handles s3 and s4 cases, send.go prepends padding, receive.go strips it. The Go backend would work correctly if it received the values.

The bug is in the app layer between config import and the UAPI call to amneziawg-go. The source code pipeline appears complete (importController.cpp → platform controller → network extension → UAPI), but at runtime S3/S4 values are dropped somewhere in this chain — on both iOS and Android.

Affected versions

iOS — AmneziaVPN 4.8.10
Android — AmneziaVPN 4.8.11.5 (Nov 22, 2025)
amneziawg-go: v0.2.13 (bundled in app)
Server: amneziawg-linux-kernel-module AWG 2.0 (February 2026 build)
Tested: February 2026

Workaround

Set S3=0/S4=0 on the server so both sides agree on no transport padding. This means all peers on that interface lose S3/S4 padding, including kernel-module clients that would handle it correctly.

Originally created by @remotetohome on GitHub (Feb 14, 2026). Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/2219 ## Summary The AmneziaVPN app (iOS and Android) completes the AWG 2.0 handshake with a server that has non-zero S3/S4, but no transport data flows. The app shows "connected" status, but web traffic does not work. Confirmed on both platforms. The root cause is that S3 and S4 are never passed to amneziawg-go via UAPI, even though the config file contains them. ## Evidence **Server config** (OpenWrt kernel module, amneziawg-linux-kernel-module): ``` s1=53 s2=46 s3=38 s4=21 ``` **App UAPI log** (observed on both iOS and Android) shows S1, S2, H1-H4, Jc, Jmin, Jmax, I1-I5 all set correctly — but S3 and S4 are completely absent. **Server-side `awg show`** for phone peers: ``` transfer: 2.15 KiB received, 19.43 KiB sent ``` Handshake-only traffic. The server keeps sending keepalives (sent increases), but the phone sends almost nothing back (received stays flat). **Phone log:** ``` Received message with unknown type: 2545529037 ``` The first 4 bytes of the S4 random padding are being interpreted as a WireGuard message type. **Control test:** Same server, same phones, a WireGuard/AWG 1.0 interface with S3=0/S4=0 works perfectly — 22+ MiB received, 160+ MiB sent. ## What's happening The server kernel module applies S4 bytes before each transport packet: ``` [S4 random bytes][H4-obfuscated type][encrypted payload] ``` The phone expects (because S4=0 from its perspective): ``` [H4-obfuscated type][encrypted payload] ``` The phone sees S4 junk as the message type → `unknown type` → discarded. Traffic in both directions fails because the framing assumptions don't match. ## Where the bug is **amneziawg-go fully supports S3/S4.** The UAPI parser in `device/uapi.go` handles `s3` and `s4` cases, `send.go` prepends padding, `receive.go` strips it. The Go backend would work correctly if it received the values. The bug is in the app layer between config import and the UAPI call to amneziawg-go. The source code pipeline appears complete (`importController.cpp` → platform controller → network extension → UAPI), but at runtime S3/S4 values are dropped somewhere in this chain — on both iOS and Android. ## Affected versions - **iOS** — AmneziaVPN 4.8.10 - **Android** — AmneziaVPN 4.8.11.5 (Nov 22, 2025) - **amneziawg-go:** v0.2.13 (bundled in app) - **Server:** amneziawg-linux-kernel-module AWG 2.0 (February 2026 build) - **Tested:** February 2026 ## Workaround Set S3=0/S4=0 on the server so both sides agree on no transport padding. This means all peers on that interface lose S3/S4 padding, including kernel-module clients that would handle it correctly.

bsakaguchi closed this issue

2026-10-13 20:32:23 +00:00

bsakaguchi commented

2026-10-13 20:32:25 +00:00

Author

Owner

@remotetohome commented on GitHub (Feb 14, 2026):

AWG1.0 control test was done with mobile clients running AmneziaWG app (iphone & android).

Bug becomes apparent when running AWG2.0 using AmneziaVPN app with s3/4 values set to non-zero.

Thank you.

@remotetohome commented on GitHub (Feb 14, 2026): AWG1.0 control test was done with mobile clients running AmneziaWG app (iphone & android). Bug becomes apparent when running AWG2.0 using AmneziaVPN app with s3/4 values set to non-zero. Thank you.

bsakaguchi commented

2026-10-13 20:32:25 +00:00

Author

Owner

@vkamn commented on GitHub (Feb 17, 2026):

AWG2 support is available starting from AmneziaVPN ~~4.8.9.12~~ 4.8.12.9

@vkamn commented on GitHub (Feb 17, 2026): AWG2 support is available starting from AmneziaVPN ~~4.8.9.12~~ 4.8.12.9

bsakaguchi commented

2026-10-13 20:32:26 +00:00

Author

Owner

@remotetohome commented on GitHub (Feb 17, 2026):

AWG2 support is available starting from AmneziaVPN 4.8.9.12

This bug was discovered on:
iOS — AmneziaVPN 4.8.10
Android — AmneziaVPN 4.8.11.5 (Nov 22, 2025)

Neither app passes the s3/4 values through to the Go backend, so they are not implemented in the AWG2 connection and connections fail. The same peer profiles can connect from native linux clients with proper s3/4 support.

@remotetohome commented on GitHub (Feb 17, 2026): > AWG2 support is available starting from AmneziaVPN 4.8.9.12 This bug was discovered on: iOS — AmneziaVPN 4.8.10 Android — AmneziaVPN 4.8.11.5 (Nov 22, 2025) Neither app passes the s3/4 values through to the Go backend, so they are not implemented in the AWG2 connection and connections fail. The same peer profiles can connect from native linux clients with proper s3/4 support.

bsakaguchi commented

2026-10-13 20:32:26 +00:00

Author

Owner

@vkamn commented on GitHub (Feb 17, 2026):

AWG2 support is available starting from AmneziaVPN 4.8.9.12

that means AWG2 and S3/S4 are not supported in versions below ~~4.8.9.12~~ 4.8.12.9

@vkamn commented on GitHub (Feb 17, 2026): > AWG2 support is available starting from AmneziaVPN 4.8.9.12 that means AWG2 and S3/S4 are not supported in versions below ~~4.8.9.12~~ 4.8.12.9

bsakaguchi commented

2026-10-13 20:32:27 +00:00

Author

Owner

@remotetohome commented on GitHub (Feb 17, 2026):

AWG2 support is available starting from AmneziaVPN 4.8.9.12

that means AWG2 and S3/S4 are not supported in versions below 4.8.9.12

My apologies for not understanding. The bugs I've found are in 4.8.10 and 4.8.11. Wouldn't these both be more recent than 4.8.9.x?

@remotetohome commented on GitHub (Feb 17, 2026): > > AWG2 support is available starting from AmneziaVPN 4.8.9.12 > > that means AWG2 and S3/S4 are not supported in versions below 4.8.9.12 My apologies for not understanding. The bugs I've found are in 4.8.10 and 4.8.11. Wouldn't these both be more recent than 4.8.9.x?

bsakaguchi commented

2026-10-13 20:32:27 +00:00

Author

Owner

@vkamn commented on GitHub (Feb 17, 2026):

sorry, misspelled the version, i mean 4.8.12.9

@vkamn commented on GitHub (Feb 17, 2026): sorry, misspelled the version, i mean 4.8.12.9

bsakaguchi commented

2026-10-13 20:32:28 +00:00

Author

Owner

@remotetohome commented on GitHub (Feb 17, 2026):

sorry, misspelled the version, i mean 4.8.12.9

Ah.. perfect. Thank you!

@remotetohome commented on GitHub (Feb 17, 2026): > sorry, misspelled the version, i mean 4.8.12.9 Ah.. perfect. Thank you!

bsakaguchi commented

2026-10-13 20:32:28 +00:00

Author

Owner

@remotetohome commented on GitHub (May 7, 2026):

For anyone watching this thread: I've filed a followup at #2582 confirming this bug is still reproducible in AmneziaVPN-Android 4.8.15.5 (build b4c03ed, 2026-05-04 — 5 minor releases past the claimed-fix in 4.8.12.9). Single-variable A/B test (phone + control device on the same WiFi/NAT, identical [Interface] parameters, only S3/S4 differs across runs) isolates the failure to client-side handling of non-zero S3/S4 in awg-go v0.2.16. Full evidence and reproducer in #2582.

@remotetohome commented on GitHub (May 7, 2026): For anyone watching this thread: I've filed a followup at #2582 confirming this bug is still reproducible in AmneziaVPN-Android **4.8.15.5** (build `b4c03ed`, 2026-05-04 — 5 minor releases past the claimed-fix in 4.8.12.9). Single-variable A/B test (phone + control device on the same WiFi/NAT, identical `[Interface]` parameters, only S3/S4 differs across runs) isolates the failure to client-side handling of non-zero S3/S4 in awg-go v0.2.16. Full evidence and reproducer in #2582.

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/amnezia-client#985

No description provided.

Rows
Columns