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 #1630] [macOS] Amnezia VPN fails to connect when both IPv4 and IPv6 are present in the WireGuard Address field #689

New issue

Open

opened 2026-10-13 20:26:35 +00:00 by bsakaguchi · 3 comments

bsakaguchi commented

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

Owner

Originally created by @ARS1510 on GitHub (Jun 4, 2025).
Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/1630

Describe the bug
In the Amnezia VPN client for macOS, when the WireGuard configuration includes both an IPv4 and an IPv6 address in the Address field, like:

Address = 192.0.2.2/32, 2001:db8::2/128

the VPN interface is created, but the connection does not work — traffic does not go through the tunnel. Removing the IPv6 address from the config solves the issue. The same configuration works without any issues in the Amnezia VPN client for Windows.

To Reproduce
Steps to reproduce the behavior:

Open Amnezia VPN on macOS
Import a WireGuard config with:

Address = 192.0.2.2/32, 2001:db8::2/128

Start the VPN connection
Observe that the tunnel is established but there is no traffic

Expected behavior
Tunnel should work properly with both IPv4 and IPv6 addresses in the Address field — just like on Windows.

Log files
No log files attached — the issue is reproducible with any config that includes both address types.

Screenshots
N/A

Desktop (please complete the following information):

OS: macOS Sequoia 15.5
Amnezia VPN Version: 4.8.7.2

Smartphone (please complete the following information):
N/A

Server (please complete the following information):
N/A

Additional context
Removing the IPv6 part from the Address field (so it only contains IPv4) allows the connection to work properly.
This issue does not occur:

when using the same configuration on the Amnezia VPN client for Windows
or when using the AmneziaWG client on macOS

Originally created by @ARS1510 on GitHub (Jun 4, 2025). Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/1630 **Describe the bug** In the Amnezia VPN client for macOS, when the WireGuard configuration includes both an IPv4 and an IPv6 address in the Address field, like: ``` Address = 192.0.2.2/32, 2001:db8::2/128 ``` the VPN interface is created, but the connection does not work — traffic does not go through the tunnel. Removing the IPv6 address from the config solves the issue. The same configuration works without any issues in the Amnezia VPN client for Windows. **To Reproduce** Steps to reproduce the behavior: 1. Open Amnezia VPN on macOS 2. Import a WireGuard config with: ``` Address = 192.0.2.2/32, 2001:db8::2/128 ``` 3. Start the VPN connection 4. Observe that the tunnel is established but there is no traffic **Expected behavior** Tunnel should work properly with both IPv4 and IPv6 addresses in the Address field — just like on Windows. **Log files** No log files attached — the issue is reproducible with any config that includes both address types. **Screenshots** N/A **Desktop (please complete the following information):** - OS: macOS Sequoia 15.5 - Amnezia VPN Version: 4.8.7.2 **Smartphone (please complete the following information):** N/A **Server (please complete the following information):** N/A **Additional context** Removing the IPv6 part from the Address field (so it only contains IPv4) allows the connection to work properly. This issue does not occur: - when using the same configuration on the Amnezia VPN client for Windows - or when using the AmneziaWG client on macOS

bsakaguchi commented

2026-10-13 20:26:36 +00:00

Author

Owner

@vnxme commented on GitHub (Jan 2, 2026):

I'm experiencing the same issue on MacOS 26.2 with AmneziaVPN 4.8.11.4 (3b3a0aa). If I set Address = {IPv4}, {IPv6}, the connection won't establish (the circle connect button won't change its text to "connected") on MacOS while working flawlessly with the same config on iOS. If I change the config to have Address = {IPv4}, i.e. remove IPv6, the app works fine on MacOS.

@vnxme commented on GitHub (Jan 2, 2026): I'm experiencing the same issue on MacOS 26.2 with AmneziaVPN 4.8.11.4 (3b3a0aa). If I set `Address = {IPv4}, {IPv6}`, the connection won't establish (the circle connect button won't change its text to "connected") on MacOS while working flawlessly with the same config on iOS. If I change the config to have `Address = {IPv4}`, i.e. remove IPv6, the app works fine on MacOS.

bsakaguchi commented

2026-10-13 20:26:36 +00:00

Author

Owner

@stupalov commented on GitHub (Jan 15, 2026):

Такая же ошибка возникла с AWG протоколом.

Создал собственный сервер на easy-wg, там по умолчанию было 2 протокола IPv4/IPv6.

В мобильном приложении подключается без проблем.
На MAcOS только в приложении AmneziaWG.

AmneziaVPN сбрасывает подключение, в логах пишет:

[2026-01-15 16:58:57.222Z] [ERROR] Amnezia IPUtilsMacos : Failed to set IPv4:   error: Destination address required
[2026-01-15 16:58:57.222Z] [ERROR] Amnezia DaemonLocalServerConnection : Failed to activate the interface

Хорошо, что нашел эту задачу, буду пробовать без IPv6

@stupalov commented on GitHub (Jan 15, 2026): Такая же ошибка возникла с AWG протоколом. Создал собственный сервер на easy-wg, там по умолчанию было 2 протокола IPv4/IPv6. В мобильном приложении подключается без проблем. На MAcOS только в приложении AmneziaWG. AmneziaVPN сбрасывает подключение, в логах пишет: ``` [2026-01-15 16:58:57.222Z] [ERROR] Amnezia IPUtilsMacos : Failed to set IPv4: error: Destination address required [2026-01-15 16:58:57.222Z] [ERROR] Amnezia DaemonLocalServerConnection : Failed to activate the interface ``` Хорошо, что нашел эту задачу, буду пробовать без IPv6

bsakaguchi commented

2026-10-13 20:26:36 +00:00

Author

Owner

@Iver15 commented on GitHub (Oct 4, 2026):

Confirmed on AmneziaVPN 5.0.3.0 (de93650), macOS Tahoe 26.6.2, arm64, with a self-hosted AmneziaWG 3.1 configuration imported from a .conf file. This is also an internet-connectivity recovery problem when Soft KillSwitch is enabled.

Observed behavior

A config containing both IPv4 and IPv6 in [Interface] Address imports successfully but fails to activate the local tunnel interface. Four connection attempts in the collected service log show the same sequence:

WireguardUtilsMacos : Created wireguard interface utun5
MacOSFirewall : 100.blockAll: OFF -> ON
MacOSFirewall : 250.blockIPv6: OFF -> ON
MacOSFirewall : 310.blockDNS: OFF -> ON
IPUtilsMacos : Failed to set IPv4:   error: Destination address required
DaemonLocalServerConnection : Failed to activate the interface

There is no immediate PF anchor uninstall following the activation error in this log. On a subsequent explicit deactivate, the service does log Uninstalling PF root anchor and pf disabled; another activation reinstalls the blocking rules and fails again.

The device owner reported that ordinary VPN disconnect attempts did not restore internet access during the incident. A reboot restored it on the first occurrence; quitting AmneziaVPN restored it on a later occurrence. The final quit/cleanup is outside the supplied log excerpt, so the recovery observations are user-reported rather than a complete PF trace.

Source-level explanation in tag 5.0.3.0

ImportController::extractWireGuardConfig copies the entire Address value into clientIp.
LocalSocketController passes clientIp unchanged as deviceIpv4Address, and separately assigns a hardcoded IPv6 address.
IPUtilsMacos::addIP4AddressToDevice calls QHostAddress::parseSubnet on that value, without validating the result before inet_pton/SIOCAIFADDR. A comma-separated pair is not a single subnet. The empty address printed in the error is consistent with failed parsing.

For illustration, using synthetic addresses (not a complete importable config):

Address = 10.99.0.2/32, fd99:99::2/128
AllowedIPs = 0.0.0.0/0, ::/0

Verified workaround

A separate IPv4-only profile was created, changing only these two fields:

-Address = 10.99.0.2/32, fd99:99::2/128
+Address = 10.99.0.2/32
-AllowedIPs = 0.0.0.0/0, ::/0
+AllowedIPs = 0.0.0.0/0

The real profile retained the same keys, endpoint, MTU, DNS and AWG obfuscation parameters. With KillSwitch still enabled, the device owner confirmed successful connection and working internet after normal disconnect. IPv6 and abnormal termination were not validated by this workaround.

Suggested fixes

Parse imported interface addresses by address family before constructing the daemon JSON; validate addresses before enabling firewall rules or issuing ioctl calls.
Ensure failed activation rolls back the tunnel, routing and newly installed PF/KillSwitch state according to the selected policy, rather than reporting disconnected while leaving an unexplained block. If blocking is intentionally retained, expose that state and an explicit recovery action in the UI.
Add macOS regression coverage for comma-separated IPv4/IPv6 imports and cleanup after activation failure.

Only selected diagnostic messages and synthetic config fragments are included here; no VPN credentials, real server addresses or full raw logs are attached.

@Iver15 commented on GitHub (Oct 4, 2026): Confirmed on **AmneziaVPN 5.0.3.0 (`de93650`), macOS Tahoe 26.6.2, arm64**, with a self-hosted AmneziaWG 3.1 configuration imported from a `.conf` file. This is also an internet-connectivity recovery problem when **Soft KillSwitch is enabled**. ### Observed behavior A config containing both IPv4 and IPv6 in `[Interface] Address` imports successfully but fails to activate the local tunnel interface. Four connection attempts in the collected service log show the same sequence: ```text WireguardUtilsMacos : Created wireguard interface utun5 MacOSFirewall : 100.blockAll: OFF -> ON MacOSFirewall : 250.blockIPv6: OFF -> ON MacOSFirewall : 310.blockDNS: OFF -> ON IPUtilsMacos : Failed to set IPv4: error: Destination address required DaemonLocalServerConnection : Failed to activate the interface ``` There is **no immediate PF anchor uninstall following the activation error** in this log. On a subsequent explicit `deactivate`, the service does log `Uninstalling PF root anchor` and `pf disabled`; another activation reinstalls the blocking rules and fails again. The device owner reported that ordinary VPN disconnect attempts did not restore internet access during the incident. A reboot restored it on the first occurrence; quitting AmneziaVPN restored it on a later occurrence. The final quit/cleanup is outside the supplied log excerpt, so the recovery observations are user-reported rather than a complete PF trace. ### Source-level explanation in tag 5.0.3.0 1. [`ImportController::extractWireGuardConfig`](https://github.com/amnezia-vpn/amnezia-client/blob/5.0.3.0/client/core/controllers/selfhosted/importController.cpp#L572) copies the entire `Address` value into `clientIp`. 2. [`LocalSocketController`](https://github.com/amnezia-vpn/amnezia-client/blob/5.0.3.0/client/mozilla/localsocketcontroller.cpp#L141) passes `clientIp` unchanged as `deviceIpv4Address`, and separately assigns a hardcoded IPv6 address. 3. [`IPUtilsMacos::addIP4AddressToDevice`](https://github.com/amnezia-vpn/amnezia-client/blob/5.0.3.0/client/platforms/macos/daemon/iputilsmacos.cpp#L94) calls `QHostAddress::parseSubnet` on that value, without validating the result before `inet_pton`/`SIOCAIFADDR`. A comma-separated pair is not a single subnet. The empty address printed in the error is consistent with failed parsing. For illustration, using synthetic addresses (not a complete importable config): ```ini Address = 10.99.0.2/32, fd99:99::2/128 AllowedIPs = 0.0.0.0/0, ::/0 ``` ### Verified workaround A separate IPv4-only profile was created, changing **only** these two fields: ```diff -Address = 10.99.0.2/32, fd99:99::2/128 +Address = 10.99.0.2/32 -AllowedIPs = 0.0.0.0/0, ::/0 +AllowedIPs = 0.0.0.0/0 ``` The real profile retained the same keys, endpoint, MTU, DNS and AWG obfuscation parameters. With KillSwitch still enabled, the device owner confirmed successful connection and working internet after normal disconnect. IPv6 and abnormal termination were not validated by this workaround. ### Suggested fixes - Parse imported interface addresses by address family before constructing the daemon JSON; validate addresses before enabling firewall rules or issuing ioctl calls. - Ensure failed activation rolls back the tunnel, routing and newly installed PF/KillSwitch state according to the selected policy, rather than reporting `disconnected` while leaving an unexplained block. If blocking is intentionally retained, expose that state and an explicit recovery action in the UI. - Add macOS regression coverage for comma-separated IPv4/IPv6 imports and cleanup after activation failure. Only selected diagnostic messages and synthetic config fragments are included here; no VPN credentials, real server addresses or full raw logs are attached.

bsakaguchi referenced this issue

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

[PR #689] [MERGED] Shortening of translated text in Burmese #2033