amnezia-vpn/amnezia-client

Fork 0

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

[GH-ISSUE #3049] Updating/recreating an existing AmneziaWG protocol doesn't install the required kernel DKMS module #1402

New issue

Open

opened 2026-10-13 20:41:47 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-13 20:41:47 +00:00

Owner

Originally created by @koster99-blip on GitHub (Aug 25, 2026).
Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/3049

Problem:

On a self-hosted server (Ubuntu, Docker-based A-VPN setup), when trying to update an existing AmneziaWG protocol (not a fresh install, but an upgrade/recreation of an already existing one) through the desktop client, the Docker container is created, but the WireGuard interface inside it doesn't come up. On investigation, the cause turned out to be the absence of a suitable kernel DKMS module (amneziawg) on the host, either outdated or completely missing after the reinstall.

The client doesn't check for or install the module as part of the update process, so the container ends up stuck in a non-functional state (just "tail -f /dev/null" inside) with no visible error in the UI (the app just shows "Connecting..." indefinitely).

A broader scenario worth considering:

A single server can have not just the containerized A-VPN, but also a separate, independent "native" AmneziaWG installation (not through Docker, using the same kernel module directly). We had both present on our server at the same time, for different purposes. The client doesn't check whether a native AmneziaWG is already installed on the host separately from the Docker container, and this creates a version conflict between what the container needs and what's already installed and in use outside the container. We ran into this directly: having both installations at once is exactly what caused the described problem. This could be a source of similar issues for other users who use their server for multiple purposes, not just A-VPN.

What fixed it:

A full server reinstall through the "Automatic" option (the same path used when adding a completely new, clean server) worked correctly and installed the module as part of the process, but only after we manually removed both the containerized and the native AmneziaWG installations from the server entirely. So the problem is specific to the "update/recreate existing protocol" path on a server that already had something installed, not to installing on a genuinely clean server.

Also noticed:

During this process we also noticed that when the protocol is recreated, the new random port chosen by the container isn't automatically added to the server's firewall (UFW), so even with a working WireGuard interface, the connection would still be unreachable from outside without manually adding a rule.

Request:

Please check and unify both paths (fresh install and updating an existing protocol), so that updating also includes checking/installing system dependencies (the kernel module) and configuring the firewall for the new port. It would also help to explicitly detect and handle the case where a non-Docker-based AmneziaWG installation is already present on the server, to avoid module version conflicts.

Originally created by @koster99-blip on GitHub (Aug 25, 2026). Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/3049 Problem: On a self-hosted server (Ubuntu, Docker-based A-VPN setup), when trying to update an existing AmneziaWG protocol (not a fresh install, but an upgrade/recreation of an already existing one) through the desktop client, the Docker container is created, but the WireGuard interface inside it doesn't come up. On investigation, the cause turned out to be the absence of a suitable kernel DKMS module (amneziawg) on the host, either outdated or completely missing after the reinstall. The client doesn't check for or install the module as part of the update process, so the container ends up stuck in a non-functional state (just "tail -f /dev/null" inside) with no visible error in the UI (the app just shows "Connecting..." indefinitely). A broader scenario worth considering: A single server can have not just the containerized A-VPN, but also a separate, independent "native" AmneziaWG installation (not through Docker, using the same kernel module directly). We had both present on our server at the same time, for different purposes. The client doesn't check whether a native AmneziaWG is already installed on the host separately from the Docker container, and this creates a version conflict between what the container needs and what's already installed and in use outside the container. We ran into this directly: having both installations at once is exactly what caused the described problem. This could be a source of similar issues for other users who use their server for multiple purposes, not just A-VPN. What fixed it: A full server reinstall through the "Automatic" option (the same path used when adding a completely new, clean server) worked correctly and installed the module as part of the process, but only after we manually removed both the containerized and the native AmneziaWG installations from the server entirely. So the problem is specific to the "update/recreate existing protocol" path on a server that already had something installed, not to installing on a genuinely clean server. Also noticed: During this process we also noticed that when the protocol is recreated, the new random port chosen by the container isn't automatically added to the server's firewall (UFW), so even with a working WireGuard interface, the connection would still be unreachable from outside without manually adding a rule. Request: Please check and unify both paths (fresh install and updating an existing protocol), so that updating also includes checking/installing system dependencies (the kernel module) and configuring the firewall for the new port. It would also help to explicitly detect and handle the case where a non-Docker-based AmneziaWG installation is already present on the server, to avoid module version conflicts.

bsakaguchi commented

2026-10-13 20:41:48 +00:00

Author

Owner

@lfazliev commented on GitHub (Aug 31, 2026):

Same root cause, another trigger: module present but pre-3.0 — fresh 3.1
install produces a dead container

We hit the same missing-dependency check from the other side, after following
the official migration article (wiki.amnezia.host → awg-3-1-upgrade, the
"Installing 3.1 without losing a working 2.0" container-rename path):

Ubuntu host (kernel 5.15), Docker; desktop client 5.0.1.5
amneziawg DKMS module 1.0.20251009 (pre-3.0) already on the host, in use by
the still-running renamed 2.0 container
Re-added the server in the app → installed AmneziaWG → the app deployed the
3.1 container and reported success

Result: container Up, UDP port bound, but no awg0 interface and no VPN.
Running awg-quick up inside the container shows why:

[#] ip link add awg0 type amneziawg      # succeeds via the OLD host kernel module
[#] awg setconf awg0 /dev/fd/63
Unable to modify interface: Invalid argument
[#] ip link delete dev awg0

The pre-3.0 module rejects the 3.1 params — verified both ways: the same config
minus HeaderProtectionKey/ContentPaddingAddition/RekeyAfterTime/RandomTrailers/
DisableCookies is accepted by the kernel path, and the full config is accepted
by the bundled amneziawg-go. start.sh ignores the awg-quick failure and stays
alive on tail -f /dev/null, so the failure is invisible to the app.

So the installer verifies neither presence (this issue) nor version of the
module, and awg-quick always prefers the kernel path over the bundled
amneziawg-go.

One more note for the coexistence scenario the wiki recommends: only one
amneziawg module can be loaded per host and the 2.0 container is actively using
it, so upgrading DKMS would still require rmmod (killing 2.0) or a reboot. For
that scenario the 3.1 container arguably must use userspace amneziawg-go
regardless of the module version.

Workaround that works for us: patch add_if() in the container's
/usr/bin/awg-quick to always start amneziawg-go — 3.1 comes up immediately, the
2.0 container keeps working on the old kernel module. Having start.sh propagate
the failure instead of masking it would also make this class of bugs visible.

(Related by symptom but a different bug: amneziawg-linux-kernel-module#216 —
EINVAL from the new 3.1 module, already fixed in #217.)

@lfazliev commented on GitHub (Aug 31, 2026): **Same root cause, another trigger: module present but pre-3.0 — fresh 3.1 install produces a dead container** We hit the same missing-dependency check from the other side, after following the official migration article (wiki.amnezia.host → awg-3-1-upgrade, the "Installing 3.1 without losing a working 2.0" container-rename path): - Ubuntu host (kernel 5.15), Docker; desktop client 5.0.1.5 - amneziawg DKMS module 1.0.20251009 (pre-3.0) already on the host, in use by the still-running renamed 2.0 container - Re-added the server in the app → installed AmneziaWG → the app deployed the 3.1 container and reported success Result: container Up, UDP port bound, but no awg0 interface and no VPN. Running `awg-quick up` inside the container shows why: [#] ip link add awg0 type amneziawg # succeeds via the OLD host kernel module [#] awg setconf awg0 /dev/fd/63 Unable to modify interface: Invalid argument [#] ip link delete dev awg0 The pre-3.0 module rejects the 3.1 params — verified both ways: the same config minus HeaderProtectionKey/ContentPaddingAddition/RekeyAfterTime/RandomTrailers/ DisableCookies is accepted by the kernel path, and the full config is accepted by the bundled amneziawg-go. start.sh ignores the awg-quick failure and stays alive on `tail -f /dev/null`, so the failure is invisible to the app. So the installer verifies neither presence (this issue) nor *version* of the module, and awg-quick always prefers the kernel path over the bundled amneziawg-go. One more note for the coexistence scenario the wiki recommends: only one amneziawg module can be loaded per host and the 2.0 container is actively using it, so upgrading DKMS would still require rmmod (killing 2.0) or a reboot. For that scenario the 3.1 container arguably must use userspace amneziawg-go regardless of the module version. Workaround that works for us: patch add_if() in the container's /usr/bin/awg-quick to always start amneziawg-go — 3.1 comes up immediately, the 2.0 container keeps working on the old kernel module. Having start.sh propagate the failure instead of masking it would also make this class of bugs visible. (Related by symptom but a different bug: amneziawg-linux-kernel-module#216 — EINVAL from the *new* 3.1 module, already fixed in #217.)

bsakaguchi commented

2026-10-13 20:41:48 +00:00

Author

Owner

@koster99-blip commented on GitHub (Aug 31, 2026):

Thanks for the detailed breakdown, this explains a lot. Our workaround (full removal of both the container and the kernel module, then reinstalling via the "Automatic" option) effectively sidestepped this by forcing a fresh module install, since we didn't need to keep an old 2.0 container alive alongside it. Your fix (patching add_if() to prefer the userspace amneziawg-go) looks like the right approach for anyone who does need both versions running side by side. Good find on the kernel-path-over-userspace priority, that's the real root cause here.

@koster99-blip commented on GitHub (Aug 31, 2026): Thanks for the detailed breakdown, this explains a lot. Our workaround (full removal of both the container and the kernel module, then reinstalling via the "Automatic" option) effectively sidestepped this by forcing a fresh module install, since we didn't need to keep an old 2.0 container alive alongside it. Your fix (patching add_if() to prefer the userspace amneziawg-go) looks like the right approach for anyone who does need both versions running side by side. Good find on the kernel-path-over-userspace priority, that's the real root cause here.

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

No description provided.

Rows
Columns