amnezia-vpn/amneziawg-tools
1
0
Fork 0
mirror of https://github.com/amnezia-vpn/amneziawg-tools.git synced 2026-10-14 05:41:59 +00:00
Code Issues 37 Projects Packages Wiki Activity

[GH-ISSUE #51] Stopped connecting with version v1.0.20260618 #21

New issue
Closed
opened 2026-10-13 21:02:27 +00:00 by bsakaguchi · 5 comments
bsakaguchi commented 2026-10-13 21:02:27 +00:00
Owner
Copy link

Originally created by @eternal-sorrow on GitHub (Jun 18, 2026).
Original GitHub issue: https://github.com/amnezia-vpn/amneziawg-tools/issues/51

Originally assigned to: @ygurov on GitHub.

After updating amneziawg-tools and restarting the awg-quick service it fails to establish the connection. I noticed that H1 and H2 values are missing in the awg output.

Originally created by @eternal-sorrow on GitHub (Jun 18, 2026). Original GitHub issue: https://github.com/amnezia-vpn/amneziawg-tools/issues/51 Originally assigned to: @ygurov on GitHub. After updating amneziawg-tools and restarting the awg-quick service it fails to establish the connection. I noticed that `H1` and `H2` values are missing in the `awg` output.
bsakaguchi commented 2026-10-13 21:02:28 +00:00
Author
Owner
Copy link

@ygurov commented on GitHub (Jun 18, 2026):

Hi @eternal-sorrow
What backend do you use? awg-go or awg-kmod?

<!-- gh-comment-id:4741492317 --> @ygurov commented on GitHub (Jun 18, 2026): Hi @eternal-sorrow What backend do you use? awg-go or awg-kmod?
bsakaguchi commented 2026-10-13 21:02:28 +00:00
Author
Owner
Copy link

@eternal-sorrow commented on GitHub (Jun 18, 2026):

Does amneziawg-tools work with both? Anyway, I use kmod.

<!-- gh-comment-id:4741512912 --> @eternal-sorrow commented on GitHub (Jun 18, 2026): Does amneziawg-tools work with both? Anyway, I use kmod.
bsakaguchi commented 2026-10-13 21:02:29 +00:00
Author
Owner
Copy link

@ygurov commented on GitHub (Jun 18, 2026):

I apologize for the mistake I have made yesterday during a small rework - both h1/h2 was handled improperly leading to a lack of value sent to the targeting interface
Pushed a fix and introduced v1.0.20260618-2

<!-- gh-comment-id:4741786083 --> @ygurov commented on GitHub (Jun 18, 2026): I apologize for the mistake I have made yesterday during a small rework - both h1/h2 was handled improperly leading to a lack of value sent to the targeting interface Pushed a fix and introduced v1.0.20260618-2
bsakaguchi commented 2026-10-13 21:02:29 +00:00
Author
Owner
Copy link

@eternal-sorrow commented on GitHub (Jun 18, 2026):

Everyone makes mistakes. Still, you do amazing stuff.

<!-- gh-comment-id:4741801715 --> @eternal-sorrow commented on GitHub (Jun 18, 2026): Everyone makes mistakes. Still, you do amazing stuff.
bsakaguchi commented 2026-10-13 21:02:29 +00:00
Author
Owner
Copy link

@RuxaXa commented on GitHub (Aug 17, 2026):

Independent confirmation of the same root cause and fix on the userspace backend:

Environment

  • Server: Debian 13
  • Backend: amneziawg-go v0.2.19
  • Tools: amneziawg-tools v1.0.20260618 (commit 4cdc357c68b39a0d1e19417b7f03d604c1e1b4cf)
  • Client: official AmneziaWG Windows client 2.0.2
  • Full-tunnel IPv4 configuration; all key material and endpoint details omitted

Observed behavior

The Windows client emitted the expected junk packets and padded AWG handshake initiations, and those datagrams reached the server listener. The server sent no response. The peer's latest-handshake and transfer counters did not change.

The config file contained non-default H1/H2 ranges, but the live interface showed H1=1 and H2=2. H3/H4 loaded correctly. Public keys and PSK matched.

Reproducer

  1. Start an ephemeral amneziawg-go interface.
  2. Load a config with distinct H1-H4 ranges using awg setconf (the same path used by awg-quick).
  3. Compare awg show <interface> h1|h2|h3|h4 with the config.

With v1.0.20260618, this unchanged regression test fails at H1/H2.

Root cause and verification

In src/config.c, successful strdup(value) calls for H1/H2 are checked with == NULL, so their presence flags are not set. H3/H4 use != NULL.

Changing only the H1/H2 checks to != NULL makes the unchanged regression test pass for all H1-H4 values. After rebuilding and reloading the interface:

  • the live H1-H4 values matched the config;
  • a Linux external full-tunnel test passed;
  • the official Windows client completed the handshake;
  • gateway, DNS and IPv4 full-tunnel egress passed with 0% packet loss;
  • no usable IPv6 path was exposed by the intentionally IPv4-only profile.

This independently confirms the maintainer fix released as v1.0.20260618-2. One subtle diagnostic trap is that two Linux endpoints using the same broken tools can still interoperate because both silently fall back to H1/H2 defaults, while the Windows client correctly applies the configured ranges and therefore cannot handshake.

<!-- gh-comment-id:5316518681 --> @RuxaXa commented on GitHub (Aug 17, 2026): Independent confirmation of the same root cause and fix on the userspace backend: ## Environment - Server: Debian 13 - Backend: `amneziawg-go v0.2.19` - Tools: `amneziawg-tools v1.0.20260618` (commit `4cdc357c68b39a0d1e19417b7f03d604c1e1b4cf`) - Client: official AmneziaWG Windows client `2.0.2` - Full-tunnel IPv4 configuration; all key material and endpoint details omitted ## Observed behavior The Windows client emitted the expected junk packets and padded AWG handshake initiations, and those datagrams reached the server listener. The server sent no response. The peer's latest-handshake and transfer counters did not change. The config file contained non-default H1/H2 ranges, but the live interface showed H1=`1` and H2=`2`. H3/H4 loaded correctly. Public keys and PSK matched. ## Reproducer 1. Start an ephemeral `amneziawg-go` interface. 2. Load a config with distinct H1-H4 ranges using `awg setconf` (the same path used by `awg-quick`). 3. Compare `awg show <interface> h1|h2|h3|h4` with the config. With `v1.0.20260618`, this unchanged regression test fails at H1/H2. ## Root cause and verification In `src/config.c`, successful `strdup(value)` calls for H1/H2 are checked with `== NULL`, so their presence flags are not set. H3/H4 use `!= NULL`. Changing only the H1/H2 checks to `!= NULL` makes the unchanged regression test pass for all H1-H4 values. After rebuilding and reloading the interface: - the live H1-H4 values matched the config; - a Linux external full-tunnel test passed; - the official Windows client completed the handshake; - gateway, DNS and IPv4 full-tunnel egress passed with 0% packet loss; - no usable IPv6 path was exposed by the intentionally IPv4-only profile. This independently confirms the maintainer fix released as `v1.0.20260618-2`. One subtle diagnostic trap is that two Linux endpoints using the same broken tools can still interoperate because both silently fall back to H1/H2 defaults, while the Windows client correctly applies the configured ranges and therefore cannot handshake.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
experimental
feature/awg4
new_fields_to_config
build/deb
v3.1.20260812
v3.0.20260805
v3.0.20260730
v1.0.20260618-2
v1.0.20260618
v1.0.20260223
v1.0.20250903
v1.0.20250901
v1.0.20250706
v1.0.20250704
v1.0.20241018
v1.0.20240213
v1.0.20240202
v1.0.20240201
v1.0.20240102
v1.0.20240120
v0.0.1-kmod
v1.0.20231215
Labels
Clear labels   
pull-request
Mirrored from GitHub Pull Request

No labels
pull-request
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
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-tools#21
No description provided.