[GH-ISSUE #112] IPv6 Privacy Leak in Windows Client under Split Routing (/1) without Client IPv6 Address Assigned #74

New issue

Open

opened 2026-10-13 21:11:37 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

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

Owner

Originally created by @DallasSandoval on GitHub (Jul 23, 2026).
Original GitHub issue: https://github.com/amnezia-vpn/amneziawg-windows-client/issues/112

Description:
This issue details an IPv6 privacy leak observed in the AmneziaWG Windows client. When using split routing (e.g., /1 subnets) to bypass the default WFP kill-switch, and the client interface is not assigned an IPv6 address, Windows routing falls back to the physical network adapter, exposing the user's real IPv6 address.
Environment:
OS: Windows 10 / 11
Client: AmneziaWG Windows Client (Current Release)
Server: Dual-stack AmneziaWG server
Steps to Reproduce:
Configure the server as a dual-stack VPN.
In the AmneziaWG Windows client, use a configuration where only an IPv4 address is assigned to the interface, but IPv6 routes are included using /1 to allow local LAN access.
Minimal Configuration Example:


[Interface]
PrivateKey = ...
Address = 10.0.0.2/32  # Note: No IPv6 address/ULA is assigned here.

[Peer]
PublicKey = ...
Endpoint = ...
AllowedIPs = 0.0.0.0/1, 128.0.0.0/1, ::/1, 8000::/1

Connect the tunnel and visit an IP leak detection site (e.g., ipleak.net).
Result: The IPv4 address shows the VPN server's IP, but the IPv6 address shows the real, physical IPv6 address of the local machine.
Expected Behavior:
The client should either route the IPv6 traffic into the tunnel (resulting in a blackhole/drop if unconfigured) or proactively block it. The real IPv6 address should never be leaked.
Root Cause Analysis:
This appears to be a combination of Windows routing stack behavior and the absence of WFP (Windows Filtering Platform) blocking rules for split-tunnel configurations:
Since AllowedIPs uses ::/1 instead of ::/0, the client relies purely on the Windows routing table instead of activating the strict /0 WFP kill-switch.
The client injects ::/1 and 8000::/1 pointing to the Wintun adapter.
However, because the [Interface] lacks an Address = assignment, the Wintun adapter does not have an active IPv6 stack.
When an application initiates an IPv6 connection, the Windows network stack evaluates the ::/1 route, determines the Wintun interface is incapable of handling IPv6, marks the route as invalid/unreachable, and falls back to the physical adapter's default ::/0 route.
The traffic escapes the VPN tunnel completely in plaintext.
Comparisons & Context:
Upstream WireGuard (Windows): Recent versions of the vanilla WireGuard Windows client do not exhibit this leak under the identical configuration.
Android Clients (WG/AWG): The Android ecosystem does not leak in this scenario because it utilizes policy routing (VpnService and fwmark). Unroutable traffic bound to the tun interface is strictly dropped rather than falling back to the cellular/Wi-Fi interface.
Current Workarounds:
Adding a dummy IPv6 ULA (e.g., Address = 10.0.0.2/32, fd00::1/128) to the interface forces Windows to recognize the IPv6 stack on Wintun, successfully blackholing the traffic within the tunnel and preventing the leak.
Using strict ::/0 activates WFP but sacrifices local LAN accessibility.
Questions and Discussion:
Is the AWG team aware of this routing fallback behavior specifically inherited from older upstream WireGuard codebases?
As a short-term mitigation, would it be feasible to add a warning prompt in the UI, or automatically inject a dummy IPv6 ULA/blackhole route when the parser detects ::/1 routes without a configured IPv6 interface address?
Thank you for your efforts, I would appreciate your insights on this matter and how we can effectively close this privacy gap for users utilizing split routing.

Originally created by @DallasSandoval on GitHub (Jul 23, 2026). Original GitHub issue: https://github.com/amnezia-vpn/amneziawg-windows-client/issues/112 Description: This issue details an IPv6 privacy leak observed in the AmneziaWG Windows client. When using split routing (e.g., /1 subnets) to bypass the default WFP kill-switch, and the client interface is not assigned an IPv6 address, Windows routing falls back to the physical network adapter, exposing the user's real IPv6 address. Environment: OS: Windows 10 / 11 Client: AmneziaWG Windows Client (Current Release) Server: Dual-stack AmneziaWG server Steps to Reproduce: Configure the server as a dual-stack VPN. In the AmneziaWG Windows client, use a configuration where only an IPv4 address is assigned to the interface, but IPv6 routes are included using /1 to allow local LAN access. Minimal Configuration Example: ``` [Interface] PrivateKey = ... Address = 10.0.0.2/32 # Note: No IPv6 address/ULA is assigned here. [Peer] PublicKey = ... Endpoint = ... AllowedIPs = 0.0.0.0/1, 128.0.0.0/1, ::/1, 8000::/1 ``` Connect the tunnel and visit an IP leak detection site (e.g., ipleak.net). Result: The IPv4 address shows the VPN server's IP, but the IPv6 address shows the real, physical IPv6 address of the local machine. Expected Behavior: The client should either route the IPv6 traffic into the tunnel (resulting in a blackhole/drop if unconfigured) or proactively block it. The real IPv6 address should never be leaked. Root Cause Analysis: This appears to be a combination of Windows routing stack behavior and the absence of WFP (Windows Filtering Platform) blocking rules for split-tunnel configurations: Since AllowedIPs uses ::/1 instead of ::/0, the client relies purely on the Windows routing table instead of activating the strict /0 WFP kill-switch. The client injects ::/1 and 8000::/1 pointing to the Wintun adapter. However, because the [Interface] lacks an Address = <IPv6> assignment, the Wintun adapter does not have an active IPv6 stack. When an application initiates an IPv6 connection, the Windows network stack evaluates the ::/1 route, determines the Wintun interface is incapable of handling IPv6, marks the route as invalid/unreachable, and falls back to the physical adapter's default ::/0 route. The traffic escapes the VPN tunnel completely in plaintext. Comparisons & Context: Upstream WireGuard (Windows): Recent versions of the vanilla WireGuard Windows client do not exhibit this leak under the identical configuration. Android Clients (WG/AWG): The Android ecosystem does not leak in this scenario because it utilizes policy routing (VpnService and fwmark). Unroutable traffic bound to the tun interface is strictly dropped rather than falling back to the cellular/Wi-Fi interface. Current Workarounds: Adding a dummy IPv6 ULA (e.g., Address = 10.0.0.2/32, fd00::1/128) to the interface forces Windows to recognize the IPv6 stack on Wintun, successfully blackholing the traffic within the tunnel and preventing the leak. Using strict ::/0 activates WFP but sacrifices local LAN accessibility. Questions and Discussion: Is the AWG team aware of this routing fallback behavior specifically inherited from older upstream WireGuard codebases? As a short-term mitigation, would it be feasible to add a warning prompt in the UI, or automatically inject a dummy IPv6 ULA/blackhole route when the parser detects ::/1 routes without a configured IPv6 interface address? Thank you for your efforts, I would appreciate your insights on this matter and how we can effectively close this privacy gap for users utilizing split routing.

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/amneziawg-windows-client#74

No description provided.

Rows
Columns