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 #2048] AmneziaWG Protocol Fails to Route Traffic on Linux Despite Successful Connection #896

New issue

Open

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

bsakaguchi commented

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

Owner

Originally created by @anothervoyager on GitHub (Dec 9, 2025).
Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/2048

Describe the bug
AmneziaWG protocol fails to provide internet access on Linux distributions despite the AmneziaVPN client reporting a successful connection. Browsers cannot load any websites, while the same configuration works correctly on Windows 11. Other protocols (e.g., Xray) function properly on the same Linux systems.

To Reproduce

Install AmneziaVPN version 4.8.11.4 on a Linux system (tested on Arch Linux, Ubuntu 24.04, Debian 13).
Configure a server using the AmneziaWG protocol.
Connect to the server via the AmneziaVPN client.
Observe that the client displays "Connected", but no websites load in the browser.

Expected behavior
After a successful connection using the AmneziaWG protocol, internet traffic should be properly routed through the VPN, and websites should load normally—consistent with behavior on Windows 11.

Log files
Relevant log snippet (from Arch Linux):

[2025-12-09 12:28:24.089Z] [DEBUG] Amnezia  : IpcClient::init succeed  
[2025-12-09 12:28:24.094Z] [INFO] Amnezia  : Logging has enabled on AmneziaVPN version 4.8.11.4 3b3a0aa  
[2025-12-09 12:28:24.094Z] [INFO] Amnezia  : Arch Linux (x86_64)  
[2025-12-09 12:28:28.968Z] [DEBUG] Amnezia  : VpnConfigurator::getDnsForConfig "1.1.1.1" "1.0.0.1"  
[2025-12-09 12:28:28.969Z] [DEBUG] Amnezia  : "ConnectToVpn, Server index is 0, container is amnezia-awg, route mode is" Settings::VpnOnlyForwardSites  
[2025-12-09 12:28:28.970Z] [DEBUG] Amnezia LocalSocketController : Daemon connected  
[2025-12-09 12:28:30.515Z] [DEBUG] Amnezia LocalSocketController : Parse command: connected  
[2025-12-09 12:28:30.515Z] [DEBUG] Amnezia LocalSocketController : Handshake completed with: B6GAa2Z/0+91ap3orgi0Z2yPL3hTAakytAkDEyhemTo=

Screenshots
Not included, but UI shows "Connected" status while browser requests time out.

Desktop (please complete the following information):

OS: Arch Linux, Ubuntu 24.04, Debian 13
Version: AmneziaVPN 4.8.11.4 (build 3b3a0aa)

Smartphone (please complete the following information):

Not applicable

Server (please complete the following information):

OS: Not specified (assumed standard Amnezia server setup; same server works with Windows client)

Additional context

The issue is Linux-specific; identical configuration works flawlessly on Windows 11.
Xray protocol functions correctly on the same Linux machines, confirming general connectivity and client functionality.
Builds tested from official GitHub source, AUR (Arch), and Ubuntu installation guide—all exhibit the same problem.
All required dependencies are installed.
DNS settings in the client are set to "1.1.1.1" and "1.0.0.1".
Route mode: VpnOnlyForwardSites.

Originally created by @anothervoyager on GitHub (Dec 9, 2025). Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/2048 **Describe the bug** AmneziaWG protocol fails to provide internet access on Linux distributions despite the AmneziaVPN client reporting a successful connection. Browsers cannot load any websites, while the same configuration works correctly on Windows 11. Other protocols (e.g., Xray) function properly on the same Linux systems. **To Reproduce** 1. Install AmneziaVPN version 4.8.11.4 on a Linux system (tested on Arch Linux, Ubuntu 24.04, Debian 13). 2. Configure a server using the AmneziaWG protocol. 3. Connect to the server via the AmneziaVPN client. 4. Observe that the client displays "Connected", but no websites load in the browser. **Expected behavior** After a successful connection using the AmneziaWG protocol, internet traffic should be properly routed through the VPN, and websites should load normally—consistent with behavior on Windows 11. **Log files** Relevant log snippet (from Arch Linux): ``` [2025-12-09 12:28:24.089Z] [DEBUG] Amnezia : IpcClient::init succeed [2025-12-09 12:28:24.094Z] [INFO] Amnezia : Logging has enabled on AmneziaVPN version 4.8.11.4 3b3a0aa [2025-12-09 12:28:24.094Z] [INFO] Amnezia : Arch Linux (x86_64) [2025-12-09 12:28:28.968Z] [DEBUG] Amnezia : VpnConfigurator::getDnsForConfig "1.1.1.1" "1.0.0.1" [2025-12-09 12:28:28.969Z] [DEBUG] Amnezia : "ConnectToVpn, Server index is 0, container is amnezia-awg, route mode is" Settings::VpnOnlyForwardSites [2025-12-09 12:28:28.970Z] [DEBUG] Amnezia LocalSocketController : Daemon connected [2025-12-09 12:28:30.515Z] [DEBUG] Amnezia LocalSocketController : Parse command: connected [2025-12-09 12:28:30.515Z] [DEBUG] Amnezia LocalSocketController : Handshake completed with: B6GAa2Z/0+91ap3orgi0Z2yPL3hTAakytAkDEyhemTo= ``` **Screenshots** Not included, but UI shows "Connected" status while browser requests time out. **Desktop (please complete the following information):** - OS: Arch Linux, Ubuntu 24.04, Debian 13 - Version: AmneziaVPN 4.8.11.4 (build 3b3a0aa) **Smartphone (please complete the following information):** - Not applicable **Server (please complete the following information):** - OS: Not specified (assumed standard Amnezia server setup; same server works with Windows client) **Additional context** - The issue is Linux-specific; identical configuration works flawlessly on Windows 11. - Xray protocol functions correctly on the same Linux machines, confirming general connectivity and client functionality. - Builds tested from official GitHub source, AUR (Arch), and Ubuntu installation guide—all exhibit the same problem. - All required dependencies are installed. - DNS settings in the client are set to "1.1.1.1" and "1.0.0.1". - Route mode: `VpnOnlyForwardSites`.

bsakaguchi commented

2026-10-13 20:30:43 +00:00

Author

Owner

@developsessions commented on GitHub (Dec 10, 2025):

I have the same issue on Fedora 43

@developsessions commented on GitHub (Dec 10, 2025): I have the same issue on Fedora 43

bsakaguchi commented

2026-10-13 20:30:44 +00:00

Author

Owner

@goldic342 commented on GitHub (Dec 11, 2025):

I think the problem is related to Qt. The daemon logs show:

Dec 11 15:43:37 abc AmneziaVPN-service.sh[1197]: No suitable DNS manager found.`

The check comes from:

if (isServiceActive("nscd.service")) {
    p.start("systemctl", { "restart", "nscd" });
} else if (isServiceActive("systemd-resolved.service")) {
    p.start("systemctl", { "restart", "systemd-resolved" });
} else {
    qDebug() << "No suitable DNS manager found.";
}

And the status check:

bool RouterLinux::isServiceActive(const QString &serviceName) {
    QProcess p;
    p.start("systemctl", { "is-active", "--quiet", serviceName });
    p.waitForFinished();
    return p.exitCode() == 0;
}

This code works correctly in a minimal standalone Qt test app, but inside the Amnezia daemon the exit codes are wrong, so it never detects an active DNS manager. Likely caused by the service’s execution environment.

OS: Arch Linux

The issue appeared without updating the amnezia client to new versions, updating the client didn't help.

@goldic342 commented on GitHub (Dec 11, 2025): I think the problem is related to Qt. The daemon logs show: ``` Dec 11 15:43:37 abc AmneziaVPN-service.sh[1197]: No suitable DNS manager found.` ``` The check comes from: ```cpp if (isServiceActive("nscd.service")) { p.start("systemctl", { "restart", "nscd" }); } else if (isServiceActive("systemd-resolved.service")) { p.start("systemctl", { "restart", "systemd-resolved" }); } else { qDebug() << "No suitable DNS manager found."; } ``` And the status check: ```cpp bool RouterLinux::isServiceActive(const QString &serviceName) { QProcess p; p.start("systemctl", { "is-active", "--quiet", serviceName }); p.waitForFinished(); return p.exitCode() == 0; } ``` This code works correctly in a minimal standalone Qt test app, but inside the Amnezia daemon the exit codes are wrong, so it never detects an active DNS manager. Likely caused by the service’s execution environment. OS: Arch Linux The issue appeared without updating the amnezia client to new versions, updating the client didn't help.

bsakaguchi commented

2026-10-13 20:30:45 +00:00

Author

Owner

@developsessions commented on GitHub (Dec 11, 2025):

But it is not only a DNS issue, because in my case, I am also not able to ping IP Adresses behind the VPN network.

@developsessions commented on GitHub (Dec 11, 2025): But it is not only a DNS issue, because in my case, I am also not able to ping IP Adresses behind the VPN network.

bsakaguchi commented

2026-10-13 20:30:45 +00:00

Author

Owner

@galtsevt commented on GitHub (Dec 15, 2025):

I’ve run into the same issue: the client says “Connected” but nothing works except the web UI of the VPS where the VPN server is installed (reachable by IP).

@galtsevt commented on GitHub (Dec 15, 2025): I’ve run into the same issue: the client says “Connected” but nothing works except the web UI of the VPS where the VPN server is installed (reachable by IP).

bsakaguchi commented

2026-10-13 20:30:45 +00:00

Author

Owner

@Aranqar commented on GitHub (Feb 27, 2026):

OS: Linux 6.19.10-1-cachyos. Can confirm the same issue.
You could temporarily fix the problem by doing:

  sudo resolvectl domain amn0 ""
  sudo resolvectl default-route amn0 no
  sudo resolvectl flush-caches

And that fixes the problem, only until restart. I tried a couple different solutions, but in the end couldn't resolve the problem and just added 'ExecStartPost' to the amnezia.service after startup

P.S. Here is an update from my side. The above resolvectl fix didn't help me with my xray config, and only helped for amneziaWG and AmneziaWGv2
So what I'm doing now for xray config is:

❯ sudo ip route replace {your_vpn_ip}/32 via 192.168.0.1 dev wlan0
❯ sudo resolvectl domain tun2 ""

From what I understood, here is what happened, that caused it

Routing loop: Amnezia creates a tun2 interface and adds a default route through it, but fails to
add a bypass route for the VPN server IP itself. So traffic to the VPN server goes → tun2 → VPN
server → tun2 → ∞. That's why you need the manual ip route replace.

DNS issue: Amnezia sets tun2 as the DNS routing interface with a catch-all domain, so DNS queries
also go through the broken tunnel until you clear it with resolvectl domain tun2 "".

@Aranqar commented on GitHub (Feb 27, 2026): OS: Linux 6.19.10-1-cachyos. Can confirm the same issue. You could temporarily fix the problem by doing: ``` sudo resolvectl domain amn0 "" sudo resolvectl default-route amn0 no sudo resolvectl flush-caches ``` And that fixes the problem, only until restart. I tried a couple different solutions, but in the end couldn't resolve the problem and just added 'ExecStartPost' to the amnezia.service after startup -------------------- P.S. Here is an update from my side. The above resolvectl fix didn't help me with my xray config, and only helped for amneziaWG and AmneziaWGv2 So what I'm doing now for xray config is: ``` ❯ sudo ip route replace {your_vpn_ip}/32 via 192.168.0.1 dev wlan0 ❯ sudo resolvectl domain tun2 "" ``` From what I understood, here is what happened, that caused it > Routing loop: Amnezia creates a tun2 interface and adds a default route through it, but fails to > add a bypass route for the VPN server IP itself. So traffic to the VPN server goes → tun2 → VPN > server → tun2 → ∞. That's why you need the manual ip route replace. > > DNS issue: Amnezia sets tun2 as the DNS routing interface with a catch-all domain, so DNS queries > also go through the broken tunnel until you clear it with resolvectl domain tun2 "".

bsakaguchi commented

2026-10-13 20:30:45 +00:00

Author

Owner

@galtsevt commented on GitHub (Mar 22, 2026):

Ubuntu 24.04 LTS. The client shows "Connected" but no internet access.

Root cause: The VPN interface amn0 gets the wrong IP. Config says 10.8.0.4/24, but client assigns 10.8.0.0/32.

Why internet doesn't work: The client adds correct routes (0.0.0.0/1 and 128.0.0.0/1 via amn0), but with an invalid IP on the interface, the routes don't function.

Workaround (after connecting to VPN):

sudo ip addr del 10.8.0.0/32 dev amn0
sudo ip addr add 10.8.0.4/24 dev amn0
sudo ip route add 0.0.0.0/1 dev amn0
sudo ip route add 128.0.0.0/1 dev amn0
sudo resolvectl dns amn0 1.1.1.1 1.0.0.1
sudo resolvectl domain amn0 "~."

After this, traffic goes through the VPN and internet works.

I've made a script to automate this. Hope this helps others while the bug is being fixed.

OS: Ubuntu 24.04 LTS

@galtsevt commented on GitHub (Mar 22, 2026): Ubuntu 24.04 LTS. The client shows "Connected" but no internet access. Root cause: The VPN interface amn0 gets the wrong IP. Config says 10.8.0.4/24, but client assigns 10.8.0.0/32. Why internet doesn't work: The client adds correct routes (0.0.0.0/1 and 128.0.0.0/1 via amn0), but with an invalid IP on the interface, the routes don't function. Workaround (after connecting to VPN): ```bash sudo ip addr del 10.8.0.0/32 dev amn0 sudo ip addr add 10.8.0.4/24 dev amn0 sudo ip route add 0.0.0.0/1 dev amn0 sudo ip route add 128.0.0.0/1 dev amn0 sudo resolvectl dns amn0 1.1.1.1 1.0.0.1 sudo resolvectl domain amn0 "~." ``` After this, traffic goes through the VPN and internet works. I've made a script to automate this. Hope this helps others while the bug is being fixed. OS: Ubuntu 24.04 LTS

bsakaguchi commented

2026-10-13 20:30:46 +00:00

Author

Owner

@KostaPo commented on GitHub (Sep 26, 2026):

Ubuntu 24.04.5 LTS + AmneziaVPN 5.0.3.0 problem remains

Protocol: AmneziaWG 3.1 (awg, UDP), server in Germany 31.76.44.76:42427 (+ Sweden as backup). Full tunnel (0.0.0.0/1 + 128.0.0.0/1 via amn0) → until the handshake completes, there's no internet at all (this is exactly the "network disappeared" symptom).
Linux client 5.0.3 routes the tunnel through userspace amneziawg-go (there's no kernel module, and v5 doesn't use it anyway). The userspace implementation starts slowly and its handshake tolerates UDP packet loss poorly.
The daemon marks the connection "active" immediately after bringing up the TUN interface/routes, not after a confirmed handshake (in the log: activate → 0.7s → "Checking for handshake...", but status is already 1). The GUI shows "Connected" even when the tunnel is dead.
In journalctl, your session is visible: 16:16–16:19, 8 consecutive toggles, each ~9 sec apart, handshake never completed (kept retrying) — each toggle spawns a new amneziawg-go process and a new series of handshake packets, until one series finally "gets through." So this is exactly the bug pattern you described.
Made worse by: AmneziaVPN restarts systemd-resolved on every connect/disconnect (23 times in this session) with DBus errors → DNS blackouts and race conditions around each toggle.
WiFi: Intel iwlwifi, NetworkManager powersave=default (usually enabled), signal -65 dBm (average/mediocre). WiFi power-save is a known killer of the first UDP handshake packet(s) — the packet gets dropped while the radio is asleep; TCP survives this via retransmission, but the WG/awg handshake needs to succeed "on the first try."

@KostaPo commented on GitHub (Sep 26, 2026): Ubuntu 24.04.5 LTS + AmneziaVPN 5.0.3.0 problem remains Protocol: AmneziaWG 3.1 (awg, UDP), server in Germany [31.76.44.76:42427](http://31.76.44.76:42427/) (+ Sweden as backup). Full tunnel (0.0.0.0/1 + 128.0.0.0/1 via amn0) → until the handshake completes, there's no internet at all (this is exactly the "network disappeared" symptom). Linux client 5.0.3 routes the tunnel through userspace amneziawg-go (there's no kernel module, and v5 doesn't use it anyway). The userspace implementation starts slowly and its handshake tolerates UDP packet loss poorly. The daemon marks the connection "active" immediately after bringing up the TUN interface/routes, not after a confirmed handshake (in the log: activate → 0.7s → "Checking for handshake...", but status is already 1). The GUI shows "Connected" even when the tunnel is dead. In journalctl, your session is visible: 16:16–16:19, 8 consecutive toggles, each ~9 sec apart, handshake never completed (kept retrying) — each toggle spawns a new amneziawg-go process and a new series of handshake packets, until one series finally "gets through." So this is exactly the bug pattern you described. Made worse by: AmneziaVPN restarts systemd-resolved on every connect/disconnect (23 times in this session) with DBus errors → DNS blackouts and race conditions around each toggle. WiFi: Intel iwlwifi, NetworkManager powersave=default (usually enabled), signal -65 dBm (average/mediocre). WiFi power-save is a known killer of the first UDP handshake packet(s) — the packet gets dropped while the radio is asleep; TCP survives this via retransmission, but the WG/awg handshake needs to succeed "on the first try."

bsakaguchi referenced this issue

2026-10-13 21:19:19 +00:00

[PR #896] [MERGED] dns fix for xray(ios) #2171