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

[GH-ISSUE #2539] WireGuard/AmneziaWG client config generation drops IPv6 peer address; client falls back to hardcoded fd58:baa6:dead::1 #1148

New issue

Open

opened 2026-10-13 20:35:16 +00:00 by bsakaguchi · 5 comments

bsakaguchi commented

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

Owner

Originally created by @colorprint on GitHub (Apr 28, 2026).
Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/2539

Summary

When generating a client config for a WireGuard or AmneziaWG connection, the server-side IPv6 address assigned to the peer is not included in the resulting [Interface] Address field. As a result, the AmneziaVPN client appears to substitute a hardcoded fallback IPv6 address (fd58:baa6:dead::1/128) on the tunnel interface. Since this fallback address is not part of the server's configured ULA prefix, IPv6 traffic through the tunnel does not work end-to-end without manual intervention.

Environment

Server: self-hosted Amnezia setup, AmneziaWG container (amnezia-awg2), Linux/Docker
Client: AmneziaVPN for Windows (latest stable), Windows 11
Protocol: AmneziaWG (also reproducible with WireGuard)

Server-side configuration (correct)

The server is properly configured with a dual-stack setup. From the server wg0.conf:

[Interface]
Address = 10.8.1.1/24, fd42:42:42::1/64
ListenPort = ...
PrivateKey = ...

[Peer]
# admin
PublicKey = YM5iSq2LFm+uSKv463ih3BgHhjGczIbT2jiweHy4JX4=
AllowedIPs = 10.8.1.2/32, fd42:42:42::1001/128

The clientsTable on the server also correctly stores the IPv6 peer address fd42:42:42::1001.

What the client receives

The client config file generated and exported by the server contains only the IPv4 address:

[Interface]
Address = 10.8.1.2/32
DNS = ...
PrivateKey = ...

[Peer]
PublicKey = ...
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = ...

Note: Address is missing the IPv6 component (fd42:42:42::1001/128), even though the server has assigned one to this peer.

Observed behavior on the client

After connecting, the AmneziaVPN tunnel interface on Windows ends up with the following addresses:

PS> Get-NetIPAddress -InterfaceAlias "AmneziaVPN" | Format-Table IPAddress, AddressFamily, PrefixLength

IPAddress         AddressFamily PrefixLength
---------         ------------- ------------
fd58:baa6:dead::1          IPv6          128
10.8.1.1                   IPv4           32

The IPv6 address fd58:baa6:dead::1/128 was not present in the imported config file. It appears to be injected by the AmneziaVPN client as a fallback when no IPv6 address is specified.

This address belongs to a different ULA prefix (fd58:baa6:dead::/64) than the one configured on the server (fd42:42:42::/64), so:

The server has no peer with AllowedIPs covering fd58:baa6:dead::1.
IPv6 packets sent from the client are dropped on the server by WireGuard's cryptokey routing.
ping -6 fd42:42:42::1 from the client fails.
ping -6 2606:4700:4700::1111 (Cloudflare) via the tunnel fails.

Workaround

Manually replacing the address on the client interface (PowerShell as Administrator) restores end-to-end IPv6 connectivity:

Remove-NetIPAddress -InterfaceAlias "AmneziaVPN" -IPAddress "fd58:baa6:dead::1" -Confirm:$false
New-NetIPAddress -InterfaceAlias "AmneziaVPN" -IPAddress "fd42:42:42::1001" -PrefixLength 128

After this, ping -6 fd42:42:42::1 succeeds and IPv6 traffic flows through the tunnel correctly.

Expected behavior

When the server has assigned an IPv6 address to a peer (visible in clientsTable and AllowedIPs), that address should be:

Included in the generated client config file as part of [Interface] Address, e.g.
```
Address = 10.8.1.2/32, fd42:42:42::1001/128
```
Applied to the tunnel interface on the client without any fallback substitution.

The hardcoded fd58:baa6:dead::1 fallback should not be injected when:

the imported config does include an IPv6 address, or
the server's IPv6 prefix is known (in which case the peer's actual assigned IPv6 should be used).

Suspected root cause

Two distinct issues, possibly in different components:

Server-side config exporter drops the IPv6 part of [Interface] Address when generating the client .conf file, even though the IPv6 address is stored in clientsTable.
Client-side (AmneziaVPN Windows app) silently injects a hardcoded fd58:baa6:dead::1/128 ULA address when the imported config has no IPv6, instead of either leaving the interface IPv4-only or surfacing a warning.

The combination produces a tunnel that appears to be dual-stack (the interface has an IPv6 address and a default route) but actually has no working IPv6 path.

Additional notes

The fallback prefix fd58:baa6:dead::/64 looks like a hardcoded debug/placeholder value (note dead as a recognizable hex marker) rather than something derived from server configuration.
This silent fallback is particularly confusing because IPv6 appears to work locally (ping -6 fd58:baa6:dead::1 to oneself succeeds), and there is no indication in the UI that IPv6 is effectively non-functional through the tunnel.

Reproduction steps

Set up an AmneziaWG server via the Amnezia client/server flow with default settings.
Verify the server has both IPv4 and IPv6 addresses configured on the wg0/awg0 interface and in peer AllowedIPs.
Generate and export a client config for any peer.
Inspect the exported .conf — note that [Interface] Address contains only the IPv4 address.
Import the config into the AmneziaVPN Windows client and connect.
On Windows, run Get-NetIPAddress -InterfaceAlias "AmneziaVPN" — observe fd58:baa6:dead::1/128 on the interface.
Try ping -6 fd42:42:42::1 (or any IPv6 destination through the tunnel) — fails.

Originally created by @colorprint on GitHub (Apr 28, 2026). Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/2539 ## Summary When generating a client config for a WireGuard or AmneziaWG connection, the server-side IPv6 address assigned to the peer is **not included** in the resulting `[Interface] Address` field. As a result, the AmneziaVPN client appears to substitute a hardcoded fallback IPv6 address (`fd58:baa6:dead::1/128`) on the tunnel interface. Since this fallback address is not part of the server's configured ULA prefix, IPv6 traffic through the tunnel does not work end-to-end without manual intervention. ## Environment - **Server:** self-hosted Amnezia setup, AmneziaWG container (`amnezia-awg2`), Linux/Docker - **Client:** AmneziaVPN for Windows (latest stable), Windows 11 - **Protocol:** AmneziaWG (also reproducible with WireGuard) ## Server-side configuration (correct) The server is properly configured with a dual-stack setup. From the server `wg0.conf`: ``` [Interface] Address = 10.8.1.1/24, fd42:42:42::1/64 ListenPort = ... PrivateKey = ... [Peer] # admin PublicKey = YM5iSq2LFm+uSKv463ih3BgHhjGczIbT2jiweHy4JX4= AllowedIPs = 10.8.1.2/32, fd42:42:42::1001/128 ``` The `clientsTable` on the server also correctly stores the IPv6 peer address `fd42:42:42::1001`. ## What the client receives The client config file generated and exported by the server contains only the IPv4 address: ``` [Interface] Address = 10.8.1.2/32 DNS = ... PrivateKey = ... [Peer] PublicKey = ... AllowedIPs = 0.0.0.0/0, ::/0 Endpoint = ... ``` Note: `Address` is missing the IPv6 component (`fd42:42:42::1001/128`), even though the server has assigned one to this peer. ## Observed behavior on the client After connecting, the AmneziaVPN tunnel interface on Windows ends up with the following addresses: ``` PS> Get-NetIPAddress -InterfaceAlias "AmneziaVPN" | Format-Table IPAddress, AddressFamily, PrefixLength IPAddress AddressFamily PrefixLength --------- ------------- ------------ fd58:baa6:dead::1 IPv6 128 10.8.1.1 IPv4 32 ``` The IPv6 address `fd58:baa6:dead::1/128` was **not** present in the imported config file. It appears to be injected by the AmneziaVPN client as a fallback when no IPv6 address is specified. This address belongs to a different ULA prefix (`fd58:baa6:dead::/64`) than the one configured on the server (`fd42:42:42::/64`), so: - The server has no peer with `AllowedIPs` covering `fd58:baa6:dead::1`. - IPv6 packets sent from the client are dropped on the server by WireGuard's cryptokey routing. - `ping -6 fd42:42:42::1` from the client fails. - `ping -6 2606:4700:4700::1111` (Cloudflare) via the tunnel fails. ## Workaround Manually replacing the address on the client interface (PowerShell as Administrator) restores end-to-end IPv6 connectivity: ```powershell Remove-NetIPAddress -InterfaceAlias "AmneziaVPN" -IPAddress "fd58:baa6:dead::1" -Confirm:$false New-NetIPAddress -InterfaceAlias "AmneziaVPN" -IPAddress "fd42:42:42::1001" -PrefixLength 128 ``` After this, `ping -6 fd42:42:42::1` succeeds and IPv6 traffic flows through the tunnel correctly. ## Expected behavior When the server has assigned an IPv6 address to a peer (visible in `clientsTable` and `AllowedIPs`), that address should be: 1. Included in the generated client config file as part of `[Interface] Address`, e.g. ``` Address = 10.8.1.2/32, fd42:42:42::1001/128 ``` 2. Applied to the tunnel interface on the client without any fallback substitution. The hardcoded `fd58:baa6:dead::1` fallback should not be injected when: - the imported config does include an IPv6 address, **or** - the server's IPv6 prefix is known (in which case the peer's actual assigned IPv6 should be used). ## Suspected root cause Two distinct issues, possibly in different components: 1. **Server-side config exporter** drops the IPv6 part of `[Interface] Address` when generating the client `.conf` file, even though the IPv6 address is stored in `clientsTable`. 2. **Client-side** (AmneziaVPN Windows app) silently injects a hardcoded `fd58:baa6:dead::1/128` ULA address when the imported config has no IPv6, instead of either leaving the interface IPv4-only or surfacing a warning. The combination produces a tunnel that *appears* to be dual-stack (the interface has an IPv6 address and a default route) but actually has no working IPv6 path. ## Additional notes - The fallback prefix `fd58:baa6:dead::/64` looks like a hardcoded debug/placeholder value (note `dead` as a recognizable hex marker) rather than something derived from server configuration. - This silent fallback is particularly confusing because IPv6 *appears* to work locally (`ping -6 fd58:baa6:dead::1` to oneself succeeds), and there is no indication in the UI that IPv6 is effectively non-functional through the tunnel. ## Reproduction steps 1. Set up an AmneziaWG server via the Amnezia client/server flow with default settings. 2. Verify the server has both IPv4 and IPv6 addresses configured on the `wg0`/`awg0` interface and in peer `AllowedIPs`. 3. Generate and export a client config for any peer. 4. Inspect the exported `.conf` — note that `[Interface] Address` contains only the IPv4 address. 5. Import the config into the AmneziaVPN Windows client and connect. 6. On Windows, run `Get-NetIPAddress -InterfaceAlias "AmneziaVPN"` — observe `fd58:baa6:dead::1/128` on the interface. 7. Try `ping -6 fd42:42:42::1` (or any IPv6 destination through the tunnel) — fails.

bsakaguchi commented

2026-10-13 20:35:17 +00:00

Author

Owner

@TudbuT commented on GitHub (Jul 20, 2026):

Bump, also having issues with this as I need IPv6. I am using the amnezia premium servers.

@TudbuT commented on GitHub (Jul 20, 2026): Bump, also having issues with this as I need IPv6. I am using the amnezia premium servers.

bsakaguchi commented

2026-10-13 20:35:18 +00:00

Author

Owner

@Viksilio commented on GitHub (Aug 8, 2026):

+++++

Need fix

@Viksilio commented on GitHub (Aug 8, 2026): +++++ Need fix

bsakaguchi commented

2026-10-13 20:35:18 +00:00

Author

Owner

@heX16 commented on GitHub (Aug 18, 2026):

I can't believe it! In the 21st century, in the most popular app that provides VPN, there is no IPv6 support 🙈

@heX16 commented on GitHub (Aug 18, 2026): I can't believe it! In the 21st century, in the most popular app that provides VPN, there is no IPv6 support 🙈

bsakaguchi commented

2026-10-13 20:35:18 +00:00

Author

Owner

@VoidEmptiness commented on GitHub (Sep 12, 2026):

Same here it’s even funny why IPv6 doesn’t work in such a popular app.

@VoidEmptiness commented on GitHub (Sep 12, 2026): Same here it’s even funny why IPv6 doesn’t work in such a popular app.

bsakaguchi commented

2026-10-13 20:35:18 +00:00

Author

Owner

@bestperson-free commented on GitHub (Sep 12, 2026):

https://github.com/amnezia-vpn/amnezia-client/discussions/2522#discussioncomment-18397376 I have the same problem

@bestperson-free commented on GitHub (Sep 12, 2026): https://github.com/amnezia-vpn/amnezia-client/discussions/2522#discussioncomment-18397376 I have the same problem

bsakaguchi referenced this issue

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

[GH-ISSUE #3279] [Windows][5.0.3.0] Excluding Weixin.exe via app split tunneling breaks voice/video calls, while text messaging works #1522