amnezia-vpn/amnezia-client

Fork 0

mirror of https://github.com/amnezia-vpn/amnezia-client.git synced 2026-10-14 21:34:26 +00:00

[GH-ISSUE #3008] Windows: VPN does not recover after sleep after 4.8.10.0 #1379

New issue

Open

opened 2026-10-13 20:41:14 +00:00 by bsakaguchi · 3 comments

bsakaguchi commented

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

Owner

Originally created by @Dmitriy2692 on GitHub (Aug 19, 2026).
Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/3008

Describe the bug

On Windows, after the PC wakes up from sleep, the VPN connection stops passing traffic and requires a manual reconnect in AmneziaVPN.

The same PC, network and VPN server work correctly with AmneziaVPN 4.8.10.0.

I tested the following versions:

4.8.10.0 — works correctly after sleep
4.8.21.0 — connection is lost after sleep, manual reconnect required
5.0.0.5 — same issue, manual reconnect required

So this appears to be a regression introduced somewhere after 4.8.10.0.

To reproduce

Connect to an AmneziaWG server.
Put Windows PC to sleep.
Wake the PC.
VPN appears connected, but traffic does not work correctly.
Manually reconnect the VPN.
Internet/VPN connectivity is restored.

Expected behavior

VPN connection should automatically recover after Windows resumes from sleep, as it does in version 4.8.10.0.

Environment

OS: Windows 10 64-bit
Protocol: AmneziaWG
Working version: 4.8.10.0
Affected versions tested: 4.8.21.0, 5.0.0.5

Originally created by @Dmitriy2692 on GitHub (Aug 19, 2026). Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/3008 Describe the bug On Windows, after the PC wakes up from sleep, the VPN connection stops passing traffic and requires a manual reconnect in AmneziaVPN. The same PC, network and VPN server work correctly with AmneziaVPN 4.8.10.0. I tested the following versions: 4.8.10.0 — works correctly after sleep 4.8.21.0 — connection is lost after sleep, manual reconnect required 5.0.0.5 — same issue, manual reconnect required So this appears to be a regression introduced somewhere after 4.8.10.0. To reproduce 1. Connect to an AmneziaWG server. 2. Put Windows PC to sleep. 3. Wake the PC. 4. VPN appears connected, but traffic does not work correctly. 5. Manually reconnect the VPN. 6. Internet/VPN connectivity is restored. Expected behavior VPN connection should automatically recover after Windows resumes from sleep, as it does in version 4.8.10.0. Environment OS: Windows 10 64-bit Protocol: AmneziaWG Working version: 4.8.10.0 Affected versions tested: 4.8.21.0, 5.0.0.5

bsakaguchi commented

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

Author

Owner

@samrustem commented on GitHub (Sep 24, 2026):

Since the service hangs exactly when the PC wakes up, you can force Windows to automatically restart it on the "Wake from Sleep" event (Event ID 107, source Kernel-Power).

Press Win + R, type taskschd.msc and press Enter.
On the right, select "Create Task".
Name it something like Amnezia_Fix.
On the Triggers tab, click New -> select On Event from the drop-down list .
Magazine: SystemSource:Kernel-PowerEvent code: 107
(This means waking up from sleep mode).
Click OK.
On the Actions tab, click New -> Action:
===cmd below=== or convert it to powershell
On the "Conditions" tab , uncheck "Run only when plugged in."
Click OK

===cmd start===
taskkill /f /im AmneziaVPN.exe
net stop AmneziaVPN-service
net stop AmneziaVPN-service
net start AmneziaVPN-service
start "" "C:\Program Files\AmneziaVPN\AmneziaVPN.exe"
===cmd end===

Duplicating the net stop command is a classic way to deal with stuck services in Windows. What happens is this: the first net stop sends a signal to the Amnezia service and encounters a "Pipe was closed" error, but it also forces Windows to forcefully change the service's status in the registry to STOPPING and close the handles to the crashed process. The second net stop finally clears its status to STOPPED. Only then is net start allowed to restart the service from scratch.…

@samrustem commented on GitHub (Sep 24, 2026): Since the service hangs exactly when the PC wakes up, you can force Windows to automatically restart it on the "Wake from Sleep" event (Event ID 107, source Kernel-Power). Press Win + R, type taskschd.msc and press Enter. On the right, select "Create Task". Name it something like Amnezia_Fix. On the Triggers tab, click New -> select On Event from the drop-down list . Magazine: SystemSource:Kernel-PowerEvent code: 107 (This means waking up from sleep mode). Click OK. On the Actions tab, click New -> Action: ===cmd below=== or convert it to powershell On the "Conditions" tab , uncheck "Run only when plugged in." Click OK ===cmd start=== taskkill /f /im AmneziaVPN.exe net stop AmneziaVPN-service net stop AmneziaVPN-service net start AmneziaVPN-service start "" "C:\Program Files\AmneziaVPN\AmneziaVPN.exe" ===cmd end=== Duplicating the net stop command is a classic way to deal with stuck services in Windows. What happens is this: the first net stop sends a signal to the Amnezia service and encounters a "Pipe was closed" error, but it also forces Windows to forcefully change the service's status in the registry to STOPPING and close the handles to the crashed process. The second net stop finally clears its status to STOPPED. Only then is net start allowed to restart the service from scratch.…

bsakaguchi commented

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

Author

Owner

@cyberianin commented on GitHub (Sep 30, 2026):

I can reproduce this on AmneziaVPN 4.8.21.0 on Windows 10 21H2 (build 19044.7725) with AmneziaWG.

The issue appears to be related to resume from sleep. The VPN may still appear connected, but connectivity becomes partially broken.

I found the following sequence in the Windows System event log:

20:44:29 — system resumed from sleep
(Microsoft-Windows-Power-Troubleshooter, Event ID 1)

20:44:39 — DNS Client Event ID 1014:
"Name resolution for the name download.wireguard.com timed out after none of the configured DNS servers responded."

So a DNS failure occurred only about 10 seconds after resume.

There was another DNS Client Event ID 1014 earlier the same day, this time specifically for chatgpt.com:

16:24:07 — DNS Client Event ID 1014:
"Name resolution for the name chatgpt.com timed out after none of the configured DNS servers responded."

No NDIS, WLAN or DHCP reset/reconnect event was logged around that earlier DNS failure.

During a previous occurrence of the same connectivity problem, Windows was still routing chatgpt.com through the AmneziaVPN interface:

InterfaceAlias: AmneziaVPN
SourceAddress: 10.8.1.3
TcpTestSucceeded: True

Additionally, curl was still able to establish TLS and receive HTTP/1.1 200 OK from chatgpt.com while the ChatGPT web UI and application were experiencing connectivity problems.

After a full Windows reboot, connectivity immediately returned.

I then captured the following healthy baseline for the AmneziaWG tunnel:

Interface: AmneziaVPN / WireGuard Tunnel
IPv4: 10.8.1.3
IPv6: fd58:baa6:dead::1
DNS: 1.1.1.1, 1.0.0.1

IPv4 default route:
Interface: AmneziaVPN
RouteMetric: 0
InterfaceMetric: 5
State: Alive

Physical Wi-Fi default route:
RouteMetric: 0
InterfaceMetric: 40
State: Alive

The VPN also installs and runs the following split-tunnel driver:

C:\Program Files\AmneziaVPN\mullvad-split-tunnel.sys

The AmneziaWG tunnel service is configured with:

MTU = 1376
Table = off

After reboot, direct DNS queries to both 1.1.1.1 and 1.0.0.1 resolve chatgpt.com normally, and the system resolver also works normally.

This suggests that some runtime state related to the tunnel, DNS routing, WFP and/or the split-tunnel driver may not be restored correctly after sleep, even though the tunnel interface and routes can remain present.

The timing is particularly suspicious because Windows logged the DNS timeout approximately 10 seconds after resume.

I have not yet tested whether simply disconnecting and reconnecting AmneziaVPN is sufficient to recover from the broken state. On the next occurrence I will test that before rebooting and compare the tunnel routes, DNS resolution, adapter counters and connectivity while the failure is active.

@cyberianin commented on GitHub (Sep 30, 2026): I can reproduce this on AmneziaVPN 4.8.21.0 on Windows 10 21H2 (build 19044.7725) with AmneziaWG. The issue appears to be related to resume from sleep. The VPN may still appear connected, but connectivity becomes partially broken. I found the following sequence in the Windows System event log: 20:44:29 — system resumed from sleep (Microsoft-Windows-Power-Troubleshooter, Event ID 1) 20:44:39 — DNS Client Event ID 1014: "Name resolution for the name download.wireguard.com timed out after none of the configured DNS servers responded." So a DNS failure occurred only about 10 seconds after resume. There was another DNS Client Event ID 1014 earlier the same day, this time specifically for chatgpt.com: 16:24:07 — DNS Client Event ID 1014: "Name resolution for the name chatgpt.com timed out after none of the configured DNS servers responded." No NDIS, WLAN or DHCP reset/reconnect event was logged around that earlier DNS failure. During a previous occurrence of the same connectivity problem, Windows was still routing chatgpt.com through the AmneziaVPN interface: InterfaceAlias: AmneziaVPN SourceAddress: 10.8.1.3 TcpTestSucceeded: True Additionally, curl was still able to establish TLS and receive HTTP/1.1 200 OK from chatgpt.com while the ChatGPT web UI and application were experiencing connectivity problems. After a full Windows reboot, connectivity immediately returned. I then captured the following healthy baseline for the AmneziaWG tunnel: Interface: AmneziaVPN / WireGuard Tunnel IPv4: 10.8.1.3 IPv6: fd58:baa6:dead::1 DNS: 1.1.1.1, 1.0.0.1 IPv4 default route: Interface: AmneziaVPN RouteMetric: 0 InterfaceMetric: 5 State: Alive Physical Wi-Fi default route: RouteMetric: 0 InterfaceMetric: 40 State: Alive The VPN also installs and runs the following split-tunnel driver: C:\Program Files\AmneziaVPN\mullvad-split-tunnel.sys The AmneziaWG tunnel service is configured with: MTU = 1376 Table = off After reboot, direct DNS queries to both 1.1.1.1 and 1.0.0.1 resolve chatgpt.com normally, and the system resolver also works normally. This suggests that some runtime state related to the tunnel, DNS routing, WFP and/or the split-tunnel driver may not be restored correctly after sleep, even though the tunnel interface and routes can remain present. The timing is particularly suspicious because Windows logged the DNS timeout approximately 10 seconds after resume. I have not yet tested whether simply disconnecting and reconnecting AmneziaVPN is sufficient to recover from the broken state. On the next occurrence I will test that before rebooting and compare the tunnel routes, DNS resolution, adapter counters and connectivity while the failure is active.

bsakaguchi commented

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

Author

Owner

@buzmakov commented on GitHub (Oct 7, 2026):

Same symptom here, and I think I found the mechanism: after a network change the endpoint exclusion route (<server>/32) is not moved to the active interface. It stays on the old (even disconnected) adapter, Windows then routes packets to the server through the tunnel itself, and the handshake can never complete. It is not specific to sleep — it also happens when switching Wi-Fi networks or plugging/unplugging Ethernet while connected.

Environment: AmneziaVPN 5.0.1.5 (7d4f3e0f5), Windows 11 26H2 x64, AmneziaWG (amnezia-awg2), route mode VpnAllExceptSites (site split tunneling on), kill switch on. Laptop with Wi-Fi + USB Ethernet.

Case 1 — no sleep, Wi-Fi network change + Ethernet unplugged (2026-10-07, times UTC)

15:14:47 Wi-Fi A disconnected, 15:14:49 Wi-Fi B connected; 15:15:31 Ethernet unplugged.
At 15:15:39 (8 s after the unplug) the only endpoint route was still on the unplugged adapter, while Wi-Fi B (gateway <wifi-B-gateway>) was up:

DestinationPrefix  Interface   NextHop    Adapter status
<server>/32        Ethernet 2  10.0.0.1   Disconnected

Find-NetRoute -RemoteIPAddress <server> returned the AmneziaVPN interface, i.e. handshake packets go into the tunnel.

Service log 15:14:40–15:16:30: 36 × Sending handshake initiation, 0 × Received handshake response. Tunnel adapter counters over 6 s: 44 KB sent, 0 B received.
When Wi-Fi B came up, WindowsRouteMonitor logged 28 × Failed to update route: 5010 (ERROR_OBJECT_ALREADY_EXISTS). When the Ethernet cable was unplugged (15:15:31) WindowsRouteMonitor logged nothing — no Routes changed at all between 15:15:00 and 15:16:30.
15:16:40 I switched back to Wi-Fi A: Routes changed ×18, Failed to update route: 5010 ×54, Failed to update/delete route: 87, and this time the endpoint route ended up on Wi-Fi A — the server's handshake arrived 0.5 s later, without reconnecting.

[2026-10-07 15:14:48.601Z] [DEBUG] AmneziaVPN WindowsRouteMonitor : Routes changed
[2026-10-07 15:14:48.637Z] [ERROR] AmneziaVPN WindowsRouteMonitor : Failed to update route: 5010
[2026-10-07 15:14:48.964Z] [DEBUG] AmneziaVPN WindowsRouteMonitor : Capturing route to <wifi-B-subnet>/24
[2026-10-07 15:14:48.964Z] [ERROR] AmneziaVPN WindowsRouteMonitor : Failed to update route: 5010
   ... (no WindowsRouteMonitor entries at all around the Ethernet unplug at 15:15:31) ...
[2026-10-07 15:16:40.867Z] [ERROR] AmneziaVPN WindowsRouteMonitor : Failed to delete route: 87
[2026-10-07 15:16:41.042Z] [ERROR] AmneziaVPN WindowsRouteMonitor : Failed to update route: 87
[2026-10-07 15:16:41.319Z] [INFO] AmneziaVPN tunnel.dll : [TUN] [AmneziaVPN] peer(…) - Received handshake initiation

Case 2 — sleep at home, wake at the office (2026-10-07, times UTC)

08:46:18 resume (Removing all keys, since we haven't received a new one in 540 seconds — expected).
08:46:20 Wi-Fi connected → 08:46:21.856 handshake succeeded.
08:46:29 office Ethernet came up → Failed to update route: 87 / Failed to delete route: 87; the endpoint route moved to Ethernet.
From then on: 79 handshake initiations, 0 responses in 5 minutes, until a manual reconnect (which re-added the exclusion route on Wi-Fi and worked in 1.4 s).
I have not yet verified whether that office Ethernet passes AmneziaWG at all on a clean connect, so this case is less conclusive than Case 1.

Notes

client/platforms/windows/daemon/windowsroutemonitor.cpp is byte-identical in 5.0.1.5, 5.0.3.0 and current dev (checked by SHA-256), so updating will not help.
PR #3030 handles ERROR_OBJECT_ALREADY_EXISTS in windowsroutemonitor.cpp and re-selects the physical interface — it looks like it targets exactly this. The missing reaction to an adapter going down (Case 1, Ethernet unplug) may need separate handling.
Workaround: reconnect after any network change.

I can provide the full service log for these if useful.

@buzmakov commented on GitHub (Oct 7, 2026): Same symptom here, and I think I found the mechanism: after a network change the **endpoint exclusion route (`<server>/32`) is not moved to the active interface**. It stays on the old (even disconnected) adapter, Windows then routes packets to the server through the tunnel itself, and the handshake can never complete. It is not specific to sleep — it also happens when switching Wi-Fi networks or plugging/unplugging Ethernet while connected. **Environment:** AmneziaVPN 5.0.1.5 (7d4f3e0f5), Windows 11 26H2 x64, AmneziaWG (`amnezia-awg2`), route mode `VpnAllExceptSites` (site split tunneling on), kill switch on. Laptop with Wi-Fi + USB Ethernet. ### Case 1 — no sleep, Wi-Fi network change + Ethernet unplugged (2026-10-07, times UTC) - 15:14:47 Wi-Fi A disconnected, 15:14:49 Wi-Fi B connected; 15:15:31 Ethernet unplugged. - At 15:15:39 (8 s after the unplug) the only endpoint route was still on the unplugged adapter, while Wi-Fi B (gateway `<wifi-B-gateway>`) was up: ``` DestinationPrefix Interface NextHop Adapter status <server>/32 Ethernet 2 10.0.0.1 Disconnected ``` `Find-NetRoute -RemoteIPAddress <server>` returned the **AmneziaVPN** interface, i.e. handshake packets go into the tunnel. - Service log 15:14:40–15:16:30: 36 × `Sending handshake initiation`, 0 × `Received handshake response`. Tunnel adapter counters over 6 s: 44 KB sent, 0 B received. - When Wi-Fi B came up, `WindowsRouteMonitor` logged 28 × `Failed to update route: 5010` (ERROR_OBJECT_ALREADY_EXISTS). When the Ethernet cable was unplugged (15:15:31) `WindowsRouteMonitor` logged **nothing** — no `Routes changed` at all between 15:15:00 and 15:16:30. - 15:16:40 I switched back to Wi-Fi A: `Routes changed` ×18, `Failed to update route: 5010` ×54, `Failed to update/delete route: 87`, and this time the endpoint route ended up on Wi-Fi A — the server's handshake arrived 0.5 s later, without reconnecting. ``` [2026-10-07 15:14:48.601Z] [DEBUG] AmneziaVPN WindowsRouteMonitor : Routes changed [2026-10-07 15:14:48.637Z] [ERROR] AmneziaVPN WindowsRouteMonitor : Failed to update route: 5010 [2026-10-07 15:14:48.964Z] [DEBUG] AmneziaVPN WindowsRouteMonitor : Capturing route to <wifi-B-subnet>/24 [2026-10-07 15:14:48.964Z] [ERROR] AmneziaVPN WindowsRouteMonitor : Failed to update route: 5010 ... (no WindowsRouteMonitor entries at all around the Ethernet unplug at 15:15:31) ... [2026-10-07 15:16:40.867Z] [ERROR] AmneziaVPN WindowsRouteMonitor : Failed to delete route: 87 [2026-10-07 15:16:41.042Z] [ERROR] AmneziaVPN WindowsRouteMonitor : Failed to update route: 87 [2026-10-07 15:16:41.319Z] [INFO] AmneziaVPN tunnel.dll : [TUN] [AmneziaVPN] peer(…) - Received handshake initiation ``` ### Case 2 — sleep at home, wake at the office (2026-10-07, times UTC) - 08:46:18 resume (`Removing all keys, since we haven't received a new one in 540 seconds` — expected). - 08:46:20 Wi-Fi connected → 08:46:21.856 **handshake succeeded**. - 08:46:29 office Ethernet came up → `Failed to update route: 87` / `Failed to delete route: 87`; the endpoint route moved to Ethernet. - From then on: 79 handshake initiations, 0 responses in 5 minutes, until a manual reconnect (which re-added the exclusion route on Wi-Fi and worked in 1.4 s). I have not yet verified whether that office Ethernet passes AmneziaWG at all on a clean connect, so this case is less conclusive than Case 1. ### Notes - `client/platforms/windows/daemon/windowsroutemonitor.cpp` is byte-identical in 5.0.1.5, 5.0.3.0 and current `dev` (checked by SHA-256), so updating will not help. - PR #3030 handles `ERROR_OBJECT_ALREADY_EXISTS` in `windowsroutemonitor.cpp` and re-selects the physical interface — it looks like it targets exactly this. The missing reaction to an adapter going down (Case 1, Ethernet unplug) may need separate handling. - Workaround: reconnect after any network change. I can provide the full service log for these if useful.

bsakaguchi referenced this issue

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

[PR #1379] [MERGED] Install apparmor #2334

bsakaguchi referenced this issue

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

[PR #1389] [MERGED] pull fixes #2338

bsakaguchi referenced this issue

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

[PR #1441] [MERGED] Merge branch 'dev' into check_sudo_permissions #2352