An AmneziaWG 2.0 server configured with ranged H1-H4 values (e.g., H1=1568029198-1568094733) cannot communicate with AmneziaWG 1.0 clients configured with fixed H1-H4 values matching the range starts (e.g., H1=1568029198).
The server correctly accepts the client's handshake initiation (since the fixed value falls within the range), but responds with a random value from the range via mh_genheader(). The AWG 1.0 client only recognizes the exact fixed value it was configured with and rejects the response.
Root cause
mh_genheader() calls get_random_u32_inclusive(mh->start, mh->end), which returns a random value from the full range. This is correct for AWG 2.0 peers that validate against the same range, but breaks AWG 1.0 peers that perform exact-match validation against a single value.
The issue affects all four header types — the server generates random values from its H2 range for the handshake response, H3 range for cookies, and H4 range for transport data. The AWG 1.0 client rejects all of them because none match its configured fixed values (except by rare coincidence when the random value happens to equal the range start).
Steps to reproduce
- Configure an AWG 2.0 server with ranged headers:
H1 = 1568029198-1568094733
H2 = 1173948051-1174013586
H3 = 1244736618-1244802153
H4 = 1997741353-1997806888
- Configure an AWG 1.0 client with fixed headers matching the range starts:
H1 = 1568029198
H2 = 1173948051
H3 = 1244736618
H4 = 1997741353
-
Attempt to connect — handshake fails. The server's response uses a random H2 value that the client does not recognize.
-
Change the server to use the same fixed values (H1=1568029198, etc.) — connection succeeds.
Expected behavior
An AWG 2.0 server should be backward-compatible with AWG 1.0 clients whose fixed header values fall within the server's ranges. The server could detect that the peer used the range start value in its initiation (suggesting a fixed-header client) and respond with range start values rather than random ones.
Affected code
src/send.c — all calls to mh_genheader() for handshake initiation, response, cookie, and transport headers. There is no per-peer distinction between AWG 1.0 (fixed) and AWG 2.0 (ranged) peers; all AWG peers unconditionally receive random headers from the configured ranges.
Relationship to other issues
This is a separate concern from the legacy WireGuard client support regression described in #160, though both stem from the same AWG 2.0 refactoring (PR #88, commit e939553). That issue is about standard WireGuard clients being unable to connect; this issue is about AWG 1.0 clients being unable to connect to AWG 2.0 servers with ranged headers.
An AmneziaWG 2.0 server configured with ranged H1-H4 values (e.g.,
H1=1568029198-1568094733) cannot communicate with AmneziaWG 1.0 clients configured with fixed H1-H4 values matching the range starts (e.g.,H1=1568029198).The server correctly accepts the client's handshake initiation (since the fixed value falls within the range), but responds with a random value from the range via
mh_genheader(). The AWG 1.0 client only recognizes the exact fixed value it was configured with and rejects the response.Root cause
mh_genheader()callsget_random_u32_inclusive(mh->start, mh->end), which returns a random value from the full range. This is correct for AWG 2.0 peers that validate against the same range, but breaks AWG 1.0 peers that perform exact-match validation against a single value.The issue affects all four header types — the server generates random values from its H2 range for the handshake response, H3 range for cookies, and H4 range for transport data. The AWG 1.0 client rejects all of them because none match its configured fixed values (except by rare coincidence when the random value happens to equal the range start).
Steps to reproduce
Attempt to connect — handshake fails. The server's response uses a random H2 value that the client does not recognize.
Change the server to use the same fixed values (H1=1568029198, etc.) — connection succeeds.
Expected behavior
An AWG 2.0 server should be backward-compatible with AWG 1.0 clients whose fixed header values fall within the server's ranges. The server could detect that the peer used the range start value in its initiation (suggesting a fixed-header client) and respond with range start values rather than random ones.
Affected code
src/send.c— all calls tomh_genheader()for handshake initiation, response, cookie, and transport headers. There is no per-peer distinction between AWG 1.0 (fixed) and AWG 2.0 (ranged) peers; all AWG peers unconditionally receive random headers from the configured ranges.Relationship to other issues
This is a separate concern from the legacy WireGuard client support regression described in #160, though both stem from the same AWG 2.0 refactoring (PR #88, commit e939553). That issue is about standard WireGuard clients being unable to connect; this issue is about AWG 1.0 clients being unable to connect to AWG 2.0 servers with ranged headers.