amnezia-vpn/amnezia-client

Fork 0

mirror of https://github.com/amnezia-vpn/amnezia-client.git synced 2026-10-13 21:33:09 +00:00

4 (WireGuard defaults), and ranged H breaks the client in 3.1 mode #1421

New issue

Open

opened 2026-10-13 20:42:09 +00:00 by bsakaguchi · 7 comments

bsakaguchi commented

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

Owner

Originally created by @leonidorlov-hash on GitHub (Aug 27, 2026).
Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/3073

When installing AmneziaWG on a self-hosted server via the app, H1–H4 are always set to 1/2/3/4 — see client/core/utils/constants/protocolConstants.h (defaultInitPacketMagicHeader[] = "1" etc.) used by client/core/installers/awgInstaller.cpp, and again in importController.cpp. These are the standard WireGuard message-type values, so header obfuscation is effectively disabled: a DPI sees plain WireGuard packet types at offset 0.

Per the amneziawg-go docs, H1–H4 also accept ranges (x-y), which is the AWG 2.0+ way to randomize headers per packet. But if the server uses ranged H together with AWG 3.1 parameters (HeaderProtectionKey, RandomTrailers, etc.), the client connects yet throughput collapses to <1 Mbit/s and the log is flooded with Received packet with invalid mac1 (hundreds per second). Ranged H with plain AWG 2.0 (no 3.1 keys) works fine in the same client.

Tests I ran on the same server:

ranged H + 3.1 keys → <1 Mbit/s, invalid mac1 flood
fixed H = 1/2/3/4 + 3.1 keys → full speed (180 Mbit/s)
fixed random H (e.g. H1 = 1383913556, H2 = 974520887, H3 = 1095760722, H4 = 264520681) + 3.1 keys → full speed as well

Questions:

Why are 1/2/3/4 hardcoded instead of generating random values or ranges (as the 2.0 spec intends)? A single hardcoded set also means all self-hosted deployments share one signature.
Is ranged H officially supported by the client in 3.1 mode? If not, could the app warn on such configs instead of silently degrading to <1 Mbit/s?

Related: #2942 (3.0 parameters silently dropped on import).

Environment: AmneziaVPN desktop (Windows), server amneziavpn/amneziawg-go:latest in userspace mode (no kernel module on host).

Originally created by @leonidorlov-hash on GitHub (Aug 27, 2026). Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/3073 When installing AmneziaWG on a self-hosted server via the app, H1–H4 are always set to 1/2/3/4 — see `client/core/utils/constants/protocolConstants.h` (`defaultInitPacketMagicHeader[] = "1"` etc.) used by `client/core/installers/awgInstaller.cpp`, and again in `importController.cpp`. These are the standard WireGuard message-type values, so header obfuscation is effectively disabled: a DPI sees plain WireGuard packet types at offset 0. Per the amneziawg-go docs, H1–H4 also accept ranges (`x-y`), which is the AWG 2.0+ way to randomize headers per packet. But if the server uses ranged H together with AWG 3.1 parameters (`HeaderProtectionKey`, `RandomTrailers`, etc.), the client connects yet throughput collapses to <1 Mbit/s and the log is flooded with `Received packet with invalid mac1` (hundreds per second). Ranged H with plain AWG 2.0 (no 3.1 keys) works fine in the same client. Tests I ran on the same server: - ranged H + 3.1 keys → <1 Mbit/s, invalid mac1 flood - fixed H = 1/2/3/4 + 3.1 keys → full speed (180 Mbit/s) - fixed random H (e.g. H1 = 1383913556, H2 = 974520887, H3 = 1095760722, H4 = 264520681) + 3.1 keys → full speed as well Questions: 1. Why are 1/2/3/4 hardcoded instead of generating random values or ranges (as the 2.0 spec intends)? A single hardcoded set also means all self-hosted deployments share one signature. 2. Is ranged H officially supported by the client in 3.1 mode? If not, could the app warn on such configs instead of silently degrading to <1 Mbit/s? Related: #2942 (3.0 parameters silently dropped on import). Environment: AmneziaVPN desktop (Windows), server `amneziavpn/amneziawg-go:latest` in userspace mode (no kernel module on host).

bsakaguchi commented

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

Author

Owner

@Advisorrry commented on GitHub (Aug 28, 2026):

это вы правильно подметили, жаль раньше не наткнулся. У меня амнезия поднимается через исходники, а не через self-hosted. Долго пришлось думать в чем была проблема низкой скорости. Странно, что никакой документации еще не было выложено

@Advisorrry commented on GitHub (Aug 28, 2026): это вы правильно подметили, жаль раньше не наткнулся. У меня амнезия поднимается через исходники, а не через self-hosted. Долго пришлось думать в чем была проблема низкой скорости. Странно, что никакой документации еще не было выложено

bsakaguchi commented

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

Author

Owner

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

Мне кажется в версии 3.1 рандомизацию H1-H4 отключили не просто так. Вместо диапазона ее заменили на Header Protection. Просто мое предположение.

@Vitalik93 commented on GitHub (Aug 28, 2026): Мне кажется в версии 3.1 рандомизацию H1-H4 отключили не просто так. Вместо диапазона ее заменили на Header Protection. Просто мое предположение.

bsakaguchi commented

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

Author

Owner

@Autolocsia commented on GitHub (Aug 28, 2026):

Лично я откатился на 2.0 потому что версия 3.1 сырая и неработоспособная, даже на бета версию не тянет, альфа

@Autolocsia commented on GitHub (Aug 28, 2026): Лично я откатился на 2.0 потому что версия 3.1 сырая и неработоспособная, даже на бета версию не тянет, альфа

bsakaguchi commented

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

Author

Owner

@leonidorlov-hash commented on GitHub (Aug 28, 2026):

Update: the question raised here («why are H1–H4 hardcoded to 1,2,3,4?») now has a well-documented answer, and it turns out the hardcode is accidentally the safe option.

Two independent deep-dives filed in the last few days analyse the packet classifier in both implementations:

amnezia-vpn/amneziawg-go#186 — with RandomTrailers = on, the relaxed size check (>= instead of ==) admits ordinary transport packets into the H1/H2/H3 handshake branches. If the 4 bytes at the branch offset fall inside the configured range, the packet dies at CheckMAC1 («Received packet with invalid mac1») — silently, with zero counters moving. Per-branch loss probability ≈ range width / 2³². Wide auto-generated ranges (e.g. 50–350M values wide) cost 16–25% of all traffic; measured 75% loss at 50% width.
amnezia-vpn/amneziawg-linux-kernel-module#226 — the same defect in the kernel module, plus an important refinement: if the window's high byte lands on a constant field of the transport packet (the 04 00 00 00 type field, key_idx, or the counter's high bytes), even a narrow range can match ~100% of packets. So «just narrow the ranges» is not a reliable mitigation.

This is exactly the failure mode we hit and reported here: a 3.1 install with wide auto-generated H1–H4 ranges showed thousands of Received packet with invalid mac1 and throughput below 1 Mbit/s; replacing the ranges with fixed values instantly restored full speed.

Consequence for generators (panels, install scripts): fixed single-value H1–H4 — whether hardcoded 1,2,3,4 or a random u32 per install — are currently the only safe shape, since width-1 ranges make the loss probability ~2⁻³² per branch and the chance of landing on the constant band negligible. Ranged H1–H4 combined with RandomTrailers = on (which the client's own defaults ship) are effectively broken on both implementations until the classifier is fixed upstream.

So the practical ask stands: until #186 / #226 are resolved, please either document that H1–H4 must be single values when RandomTrailers is on, or have the client tooling reject ranged values in that combination — otherwise third-party generators keep producing configs that lose most of their traffic with no visible error anywhere.

@leonidorlov-hash commented on GitHub (Aug 28, 2026): Update: the question raised here («why are H1–H4 hardcoded to 1,2,3,4?») now has a well-documented answer, and it turns out the hardcode is accidentally the *safe* option. Two independent deep-dives filed in the last few days analyse the packet classifier in both implementations: - **amnezia-vpn/amneziawg-go#186** — with `RandomTrailers = on`, the relaxed size check (`>=` instead of `==`) admits ordinary transport packets into the H1/H2/H3 handshake branches. If the 4 bytes at the branch offset fall inside the configured range, the packet dies at CheckMAC1 («Received packet with invalid mac1») — silently, with zero counters moving. Per-branch loss probability ≈ range width / 2³². Wide auto-generated ranges (e.g. 50–350M values wide) cost 16–25% of all traffic; measured 75% loss at 50% width. - **amnezia-vpn/amneziawg-linux-kernel-module#226** — the same defect in the kernel module, plus an important refinement: if the window's high byte lands on a *constant* field of the transport packet (the `04 00 00 00` type field, key_idx, or the counter's high bytes), even a **narrow** range can match ~100% of packets. So «just narrow the ranges» is not a reliable mitigation. This is exactly the failure mode we hit and reported here: a 3.1 install with wide auto-generated H1–H4 ranges showed thousands of `Received packet with invalid mac1` and throughput below 1 Mbit/s; replacing the ranges with fixed values instantly restored full speed. Consequence for generators (panels, install scripts): **fixed single-value H1–H4 — whether hardcoded 1,2,3,4 or a random u32 per install — are currently the only safe shape**, since width-1 ranges make the loss probability ~2⁻³² per branch and the chance of landing on the constant band negligible. Ranged H1–H4 combined with `RandomTrailers = on` (which the client's own defaults ship) are effectively broken on both implementations until the classifier is fixed upstream. So the practical ask stands: until #186 / #226 are resolved, please either document that H1–H4 must be single values when `RandomTrailers` is on, or have the client tooling reject ranged values in that combination — otherwise third-party generators keep producing configs that lose most of their traffic with no visible error anywhere.

bsakaguchi commented

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

Author

Owner

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

Статью про AmneziaWG кстати обновили. Там в частности написано, почему H1-H4 стоят на 1-4. https://docs.amnezia.org/ru/documentation/amnezia-wg

@Vitalik93 commented on GitHub (Aug 29, 2026): Статью про AmneziaWG кстати обновили. Там в частности написано, почему H1-H4 стоят на 1-4. https://docs.amnezia.org/ru/documentation/amnezia-wg

bsakaguchi commented

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

Author

Owner

@leonidorlov-hash commented on GitHub (Aug 30, 2026):

Closing the loop on this one — the case is now solved, and the answer is «it's documented behaviour, not a bug».

The official AmneziaWG documentation was updated (https://docs.amnezia.org/ru/documentation/amnezia-wg/) and now states explicitly:

При использовании Header Protection рекомендуется оставлять H1-H4 в стандартных значениях совместимости: H1 = 1, H2 = 2, H3 = 3, H4 = 4. В этом режиме механизм пользовательских заголовков отключается, а скрытие типа сообщения выполняет Header Protection.

And in the parameter table: H1 is disabled at value 1, H2 at 2, etc.

So the client's hardcoded 1,2,3,4 is the documented «compatibility mode»: when HeaderProtectionKey is set, custom headers are intentionally off and message-type hiding is done by Header Protection (ChaCha20 keyed with the random per-server key). Config uniqueness between servers comes from the HP key, junk sizes and port — not from H values.

This also aligns with the classifier research in amnezia-vpn/amneziawg-go#186 / amnezia-vpn/amneziawg-linux-kernel-module#226: ranged H1–H4 combined with RandomTrailers = on cause silent transport packet loss, while width-1 values (1,2,3,4 or any fixed value) are safe. The docs now even carry a related warning («при использовании RandomTrailers рекомендуется задавать одинаковые значения для S1–S4... пакеты могут быть интерпретированы неверно»).

For anyone generating configs (panels, scripts): with AWG 3.1 + HeaderProtectionKey, emit H1–H4 = 1,2,3,4. Don't use ranged H with RandomTrailers on until the classifier issues are fixed upstream.

Closing as answered — thanks to the authors of #186/#226 for the deep-dives that made the whole picture clear.

@leonidorlov-hash commented on GitHub (Aug 30, 2026): Closing the loop on this one — the case is now solved, and the answer is «it's documented behaviour, not a bug». **The official AmneziaWG documentation was updated** (https://docs.amnezia.org/ru/documentation/amnezia-wg/) and now states explicitly: > При использовании Header Protection рекомендуется оставлять H1-H4 в стандартных значениях совместимости: H1 = 1, H2 = 2, H3 = 3, H4 = 4. В этом режиме механизм пользовательских заголовков отключается, а скрытие типа сообщения выполняет Header Protection. And in the parameter table: H1 is *disabled* at value 1, H2 at 2, etc. So the client's hardcoded 1,2,3,4 is the documented «compatibility mode»: when `HeaderProtectionKey` is set, custom headers are intentionally off and message-type hiding is done by Header Protection (ChaCha20 keyed with the random per-server key). Config uniqueness between servers comes from the HP key, junk sizes and port — not from H values. This also aligns with the classifier research in amnezia-vpn/amneziawg-go#186 / amnezia-vpn/amneziawg-linux-kernel-module#226: ranged H1–H4 combined with `RandomTrailers = on` cause silent transport packet loss, while width-1 values (1,2,3,4 or any fixed value) are safe. The docs now even carry a related warning («при использовании RandomTrailers рекомендуется задавать одинаковые значения для S1–S4... пакеты могут быть интерпретированы неверно»). For anyone generating configs (panels, scripts): with AWG 3.1 + HeaderProtectionKey, emit H1–H4 = 1,2,3,4. Don't use ranged H with RandomTrailers on until the classifier issues are fixed upstream. Closing as answered — thanks to the authors of #186/#226 for the deep-dives that made the whole picture clear.

bsakaguchi commented

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

Author

Owner

@HeisLuka commented on GitHub (Sep 9, 2026):

I re-checked this against current dev, the current AmneziaWG documentation, and current master of both amneziawg-go and the Linux kernel module.

I think this issue now has two very different parts.

1. `H1 = 1, H2 = 2, H3 = 3, H4 = 4` is no longer a bug

The original question about the hardcoded values has effectively been answered by the current protocol design.

Current AwgInstaller still deliberately initializes:

H1 = 1
H2 = 2
H3 = 3
H4 = 4

and also generates a HeaderProtectionKey.

The current AmneziaWG documentation now explicitly describes these as the compatibility values for Header Protection.

With:

H1 = 1
H2 = 2
H3 = 3
H4 = 4

the old custom-message-header mechanism is disabled and the packet type is instead hidden by Header Protection.

So I would not change the installer to generate random fixed H values merely to make every self-hosted configuration different.

When Header Protection is enabled, the current 1/2/3/4 defaults are intentional.

The issue reporter already reached the same conclusion in the later discussion.

2. The ranged-H + RandomTrailers failure is still real

The underlying classifier problem reported in:

amnezia-vpn/amneziawg-go#186
amnezia-vpn/amneziawg-linux-kernel-module#226

is still present in current source.

The Go implementation currently classifies in this order:

H1 / initiation
H2 / response
H3 / cookie
H4 / transport

and for the first three branches, when RandomTrailers is enabled, the size condition becomes approximately:

size == expectedSize ||
randomTrailers && size > expectedSize

Only after those branches does it try the transport classifier.

Therefore a sufficiently long ordinary transport packet can enter one of the handshake H-range tests.

If its four bytes happen to fall inside that configured H range, it can be classified as a handshake candidate and subsequently fail authentication instead of reaching the transport branch.

The current Linux kernel module has the same ordering and equivalent relaxed size conditions.

So the observed:

ranged H
+
RandomTrailers = on
+
large packet loss
+
Received packet with invalid mac1

has a real source-level explanation.

This part is not resolved merely because 1/2/3/4 became the recommended default.

3. Current Amnezia client can still create the problematic configuration

This is the client-side part that I think remains actionable.

In current:

PageProtocolAwgSettings.qml

all four server H fields explicitly use:

rangeValidation: true

so values such as:

100000-200000

are accepted.

The same page also exposes:

HeaderProtectionKey
RandomTrailers

independently.

Therefore the UI permits:

AWG 3.1
HeaderProtectionKey = enabled
RandomTrailers      = on
H1                  = range
H2                  = range
H3                  = range
H4                  = range

with no compatibility warning.

Given the current upstream classifier behavior, this is a configuration shape capable of causing severe silent packet loss.

4. The existing H1-H4 validation does not actually validate range overlap

There is another deterministic validation bug here.

Before saving, the QML calls:

AwgConfigModel.isHeadersEqual(h3, h4, h2, h1)

and rejects the configuration with:

The values of the H1-H4 fields must be unique

But the underlying implementation is:

QSet<QString> uniqueHeaders;
int filledHeaders = 0;

for (const QString &header : { h1, h2, h3, h4 }) {
    if (!header.trimmed().isEmpty()) {
        ++filledHeaders;
        uniqueHeaders.insert(header);
    }
}

return uniqueHeaders.size() != filledHeaders;

This checks string equality, not numerical range intersection.

So:

H1 = 100-200
H2 = 100-200

is rejected.

But:

H1 = 100-200
H2 = 150-250

is accepted.

Those ranges overlap from:

150..200

despite the current AmneziaWG documentation explicitly requiring H1-H4 ranges not to overlap.

So the useful invariant is not:

H1 string != H2 string != H3 string != H4 string

It is:

intersection(H1, H2) = empty
intersection(H1, H3) = empty
...
intersection(H3, H4) = empty

after parsing each single value as a width-1 range.

5. Cross-field validation is needed

There are two separate levels of validation.

Basic H-range validity

For every H field:

0 <= low <= high <= UINT32_MAX

and all four resulting ranges must be disjoint.

Known-bad runtime combinations

While the upstream classifier bug remains present, the client should at minimum detect:

RandomTrailers = on
AND
one or more of H1-H3 is a non-singleton range

and either:

reject it

or present a very explicit warning.

For AWG 3.1 with Header Protection, the strongest safe UX is probably to guide users toward:

H1 = 1
H2 = 2
H3 = 3
H4 = 4

which is also the documented compatibility configuration.

I would avoid silently rewriting imported third-party configurations, though. A loud validation error/warning preserves user intent while making the compatibility problem visible.

6. Imported/stored configurations preserve these values as strings

The current model serializes and restores:

H1
H2
H3
H4
HeaderProtectionKey
RandomTrailers

independently.

AwgConfigurator also copies H values directly from the generated/native config map into AwgClientConfig.

There is no central semantic validator establishing:

H ranges are disjoint
AND
configuration is compatible with RandomTrailers

when the configuration enters the model.

So putting the check only in one QML page would still leave:

import
migration
API-created configuration
other future configuration paths

able to bypass it.

This should ideally be a model/protocol-level validation invariant, with the UI only displaying the resulting diagnostic.

Suggested regression cases

Default AWG 3.1:

HeaderProtectionKey = set
RandomTrailers = on
H1 = 1
H2 = 2
H3 = 3
H4 = 4

Expected:

accepted

This is the documented compatibility mode.

Completely identical H values:

H1 = 100-200
H2 = 100-200

Expected:

rejected

as today.

Partially overlapping ranges:

H1 = 100-200
H2 = 150-250

Expected:

rejected

Currently this passes the string-equality check.

Boundary overlap:

H1 = 100-200
H2 = 200-300

Expected:

rejected

because both include 200.

Disjoint ranges:

H1 = 100-199
H2 = 200-299

Expected:

accepted

subject to the RandomTrailers compatibility rule.

Fixed custom values:

H1 = 100
H2 = 200
H3 = 300
H4 = 400

Expected:

accepted

when valid for the selected protocol features.

Ranged H1-H3 + RandomTrailers = on.

Until the upstream classifier issue is fixed:

must not silently save as an apparently healthy configuration

Import a third-party AWG 3.1 config containing:

RandomTrailers = on
H1-H3 = wide ranges

Expected:

explicit compatibility diagnostic

rather than successful import followed by unexplained packet loss.

After the upstream classifier is fixed, remove/relax only the temporary compatibility restriction while retaining the permanent range-overlap validation.

Classification

So I would narrow the original issue rather than treat the whole report as one bug:

Resolved/by design:

self-hosted H1-H4 defaults = 1/2/3/4
when Header Protection is used

Still confirmed upstream:

RandomTrailers + ranged H1-H3
can misclassify ordinary transport packets

Still confirmed in current Amnezia client:

the UI accepts the problematic combination
without warning

and:

H1-H4 "uniqueness" validation compares strings
instead of checking whether numerical ranges overlap

The safest default is already present. The remaining client bug is that users and third-party configurations can leave that safe envelope without the client detecting a configuration known to be ambiguous/broken.

@HeisLuka commented on GitHub (Sep 9, 2026): I re-checked this against current `dev`, the current AmneziaWG documentation, and current `master` of both `amneziawg-go` and the Linux kernel module. I think this issue now has two very different parts. ### 1. `H1 = 1, H2 = 2, H3 = 3, H4 = 4` is no longer a bug The original question about the hardcoded values has effectively been answered by the current protocol design. Current `AwgInstaller` still deliberately initializes: ```text H1 = 1 H2 = 2 H3 = 3 H4 = 4 ``` and also generates a `HeaderProtectionKey`. The current AmneziaWG documentation now explicitly describes these as the compatibility values for Header Protection. With: ```text H1 = 1 H2 = 2 H3 = 3 H4 = 4 ``` the old custom-message-header mechanism is disabled and the packet type is instead hidden by Header Protection. So I would not change the installer to generate random fixed H values merely to make every self-hosted configuration different. When Header Protection is enabled, the current `1/2/3/4` defaults are intentional. The issue reporter already reached the same conclusion in the later discussion. ### 2. The ranged-H + RandomTrailers failure is still real The underlying classifier problem reported in: ```text amnezia-vpn/amneziawg-go#186 amnezia-vpn/amneziawg-linux-kernel-module#226 ``` is still present in current source. The Go implementation currently classifies in this order: ```text H1 / initiation H2 / response H3 / cookie H4 / transport ``` and for the first three branches, when `RandomTrailers` is enabled, the size condition becomes approximately: ```go size == expectedSize || randomTrailers && size > expectedSize ``` Only after those branches does it try the transport classifier. Therefore a sufficiently long ordinary transport packet can enter one of the handshake H-range tests. If its four bytes happen to fall inside that configured H range, it can be classified as a handshake candidate and subsequently fail authentication instead of reaching the transport branch. The current Linux kernel module has the same ordering and equivalent relaxed size conditions. So the observed: ```text ranged H + RandomTrailers = on + large packet loss + Received packet with invalid mac1 ``` has a real source-level explanation. This part is not resolved merely because `1/2/3/4` became the recommended default. ### 3. Current Amnezia client can still create the problematic configuration This is the client-side part that I think remains actionable. In current: ```text PageProtocolAwgSettings.qml ``` all four server H fields explicitly use: ```qml rangeValidation: true ``` so values such as: ```text 100000-200000 ``` are accepted. The same page also exposes: ```text HeaderProtectionKey RandomTrailers ``` independently. Therefore the UI permits: ```text AWG 3.1 HeaderProtectionKey = enabled RandomTrailers = on H1 = range H2 = range H3 = range H4 = range ``` with no compatibility warning. Given the current upstream classifier behavior, this is a configuration shape capable of causing severe silent packet loss. ### 4. The existing H1-H4 validation does not actually validate range overlap There is another deterministic validation bug here. Before saving, the QML calls: ```cpp AwgConfigModel.isHeadersEqual(h3, h4, h2, h1) ``` and rejects the configuration with: ```text The values of the H1-H4 fields must be unique ``` But the underlying implementation is: ```cpp QSet<QString> uniqueHeaders; int filledHeaders = 0; for (const QString &header : { h1, h2, h3, h4 }) { if (!header.trimmed().isEmpty()) { ++filledHeaders; uniqueHeaders.insert(header); } } return uniqueHeaders.size() != filledHeaders; ``` This checks string equality, not numerical range intersection. So: ```text H1 = 100-200 H2 = 100-200 ``` is rejected. But: ```text H1 = 100-200 H2 = 150-250 ``` is accepted. Those ranges overlap from: ```text 150..200 ``` despite the current AmneziaWG documentation explicitly requiring H1-H4 ranges not to overlap. So the useful invariant is not: ```text H1 string != H2 string != H3 string != H4 string ``` It is: ```text intersection(H1, H2) = empty intersection(H1, H3) = empty ... intersection(H3, H4) = empty ``` after parsing each single value as a width-1 range. ### 5. Cross-field validation is needed There are two separate levels of validation. #### Basic H-range validity For every H field: ```text 0 <= low <= high <= UINT32_MAX ``` and all four resulting ranges must be disjoint. #### Known-bad runtime combinations While the upstream classifier bug remains present, the client should at minimum detect: ```text RandomTrailers = on AND one or more of H1-H3 is a non-singleton range ``` and either: ```text reject it ``` or present a very explicit warning. For AWG 3.1 with Header Protection, the strongest safe UX is probably to guide users toward: ```text H1 = 1 H2 = 2 H3 = 3 H4 = 4 ``` which is also the documented compatibility configuration. I would avoid silently rewriting imported third-party configurations, though. A loud validation error/warning preserves user intent while making the compatibility problem visible. ### 6. Imported/stored configurations preserve these values as strings The current model serializes and restores: ```text H1 H2 H3 H4 HeaderProtectionKey RandomTrailers ``` independently. `AwgConfigurator` also copies H values directly from the generated/native config map into `AwgClientConfig`. There is no central semantic validator establishing: ```text H ranges are disjoint AND configuration is compatible with RandomTrailers ``` when the configuration enters the model. So putting the check only in one QML page would still leave: ```text import migration API-created configuration other future configuration paths ``` able to bypass it. This should ideally be a model/protocol-level validation invariant, with the UI only displaying the resulting diagnostic. ### Suggested regression cases 1. Default AWG 3.1: ```text HeaderProtectionKey = set RandomTrailers = on H1 = 1 H2 = 2 H3 = 3 H4 = 4 ``` Expected: ```text accepted ``` This is the documented compatibility mode. 2. Completely identical H values: ```text H1 = 100-200 H2 = 100-200 ``` Expected: ```text rejected ``` as today. 3. Partially overlapping ranges: ```text H1 = 100-200 H2 = 150-250 ``` Expected: ```text rejected ``` Currently this passes the string-equality check. 4. Boundary overlap: ```text H1 = 100-200 H2 = 200-300 ``` Expected: ```text rejected ``` because both include `200`. 5. Disjoint ranges: ```text H1 = 100-199 H2 = 200-299 ``` Expected: ```text accepted ``` subject to the RandomTrailers compatibility rule. 6. Fixed custom values: ```text H1 = 100 H2 = 200 H3 = 300 H4 = 400 ``` Expected: ```text accepted ``` when valid for the selected protocol features. 7. Ranged H1-H3 + `RandomTrailers = on`. Until the upstream classifier issue is fixed: ```text must not silently save as an apparently healthy configuration ``` 8. Import a third-party AWG 3.1 config containing: ```text RandomTrailers = on H1-H3 = wide ranges ``` Expected: ```text explicit compatibility diagnostic ``` rather than successful import followed by unexplained packet loss. 9. After the upstream classifier is fixed, remove/relax only the temporary compatibility restriction while retaining the permanent range-overlap validation. ### Classification So I would narrow the original issue rather than treat the whole report as one bug: **Resolved/by design:** ```text self-hosted H1-H4 defaults = 1/2/3/4 when Header Protection is used ``` **Still confirmed upstream:** ```text RandomTrailers + ranged H1-H3 can misclassify ordinary transport packets ``` **Still confirmed in current Amnezia client:** ```text the UI accepts the problematic combination without warning ``` and: ```text H1-H4 "uniqueness" validation compares strings instead of checking whether numerical ranges overlap ``` The safest default is already present. The remaining client bug is that users and third-party configurations can leave that safe envelope without the client detecting a configuration known to be ambiguous/broken.

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#1421

No description provided.

Rows
Columns

[GH-ISSUE #3073] AWG self-hosted: H1–H4 hardcoded to 1/2/3/4 (WireGuard defaults), and ranged H breaks the client in 3.1 mode #1421

1. H1 = 1, H2 = 2, H3 = 3, H4 = 4 is no longer a bug

2. The ranged-H + RandomTrailers failure is still real

3. Current Amnezia client can still create the problematic configuration

4. The existing H1-H4 validation does not actually validate range overlap

5. Cross-field validation is needed

Basic H-range validity

Known-bad runtime combinations

6. Imported/stored configurations preserve these values as strings

Suggested regression cases

Classification

1. `H1 = 1, H2 = 2, H3 = 3, H4 = 4` is no longer a bug