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 #2554] [macOS] AmneziaWG client doesn't push DNS server from [Interface] config to system resolver #1156

New issue

Open

opened 2026-10-13 20:35:25 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

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

Owner

Originally created by @Shedogubov on GitHub (May 1, 2026).
Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/2554

Describe the bug
The macOS AmneziaWG client does not write the DNS server specified in [Interface] DNS = ... of the config to the macOS system DNS configuration (SCDynamicStore). As a result, scutil --dns shows the LAN router (e.g. 192.168.1.1) as resolver #1 on the Wi-Fi interface instead of the DNS configured for the tunnel (e.g. 1.1.1.1).

Because of split-default routing (0.0.0.0/1 and 128.0.0.0/1 via the tunnel), DNS queries to 192.168.1.1 are routed into the tunnel and dropped on the server. Result: system DNS resolution times out (~15 sec), new sites fail to load, while existing TCP connections continue to work normally. Manually triggering reconnect in Amnezia restores DNS for a while, but the issue eventually returns.

The same config works correctly on iOS — DNS is properly applied on the iOS Amnezia client and resolution is stable.

To Reproduce

Configure an AmneziaWG server with DNS = 1.1.1.1, 1.0.0.1 in the client config.
Connect from macOS Amnezia client (version 4.8.14.5).
Open Terminal and run: scutil --dns | head -10
Observe that resolver #1 is the LAN router IP via en0, not the configured DNS via utun*.
Run: time dig +short github.com — times out after 15 sec.
Run: time nslookup github.com 1.1.1.1 — succeeds in ~100 ms.

Expected behavior
The macOS client should write the DNS value from [Interface] into SCDynamicStore so that resolver #1 in scutil --dns becomes the configured tunnel DNS (e.g. 1.1.1.1 via utun*), as the iOS client correctly does.

Workaround
Manually pinning DNS at the OS level resolves the issue completely:
sudo networksetup -setdnsservers Wi-Fi 1.1.1.1 1.0.0.1

After this, no more "hang" episodes occur regardless of Amnezia reconnects.

Diagnostic data captured during the hang

pfctl -ss | wc -l → 401 (4% of state table limit, no overflow)
netstat -an | grep SYN_SENT | wc -l → 0 (apps not even attempting TCP — stuck on DNS)
wg show all latest-handshakes on server → fresh handshake, tunnel healthy
nslookup ... 1.1.1.1 (explicit) → works instantly through the tunnel
dig (system resolver) → 15 sec timeout
scutil --dns resolver #1 → nameserver[0]: 192.168.1.1, if_index: en0 (wrong)

This confirms the tunnel itself is fine — the issue is purely that the DNS configuration from [Interface] is not propagated to the macOS system resolver.

Log files
Client logs from the affected session show a normal connect cycle with no errors:
[2026-05-01 08:56:09.428Z] [DEBUG] Amnezia LocalSocketController : Handshake completed
[2026-05-01 08:56:09.474Z] [DEBUG] Amnezia : VpnConnection::onConnectionStateChanged: Successfully flushed DNS

Note Successfully flushed DNS — but the new DNS from config is never written to the system afterwards.

Desktop:

OS: macOS Tahoe 26.4.1 (x86_64)
Version: AmneziaVPN 4.8.14.5 (build 477afb9)

Smartphone (works correctly, no bug):

Device: iPhone
OS: iOS (current)
Version: AmneziaVPN (current from App Store)

Server:

OS: Ubuntu 24.04 LTS (kernel 6.8.0-110-generic)
Container: amnezia-awg2 (AmneziaWG)

Additional context

Bug appears intermittently — DNS is sometimes set correctly on first connect, but is lost on subsequent reconnects, network changes, or Power Nap events.
Tested with both DNS = 1.1.1.1, 1.0.0.1 and other DNS servers — same behavior.
iCloud Private Relay is disabled.
Tailscale is installed but disconnected during testing — no impact.
MTU was tested and lowered to 1280 — did not affect this issue (it's purely a DNS routing problem).
Workaround networksetup -setdnsservers fully eliminates the issue, confirming the tunnel works fine and the only missing piece is DNS injection into the system.

Originally created by @Shedogubov on GitHub (May 1, 2026). Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/2554 **Describe the bug** The macOS AmneziaWG client does not write the DNS server specified in `[Interface] DNS = ...` of the config to the macOS system DNS configuration (`SCDynamicStore`). As a result, `scutil --dns` shows the LAN router (e.g. `192.168.1.1`) as resolver #1 on the Wi-Fi interface instead of the DNS configured for the tunnel (e.g. `1.1.1.1`). Because of split-default routing (`0.0.0.0/1` and `128.0.0.0/1` via the tunnel), DNS queries to `192.168.1.1` are routed *into* the tunnel and dropped on the server. Result: system DNS resolution times out (~15 sec), new sites fail to load, while existing TCP connections continue to work normally. Manually triggering reconnect in Amnezia restores DNS for a while, but the issue eventually returns. The same config works correctly on iOS — DNS is properly applied on the iOS Amnezia client and resolution is stable. **To Reproduce** 1. Configure an AmneziaWG server with `DNS = 1.1.1.1, 1.0.0.1` in the client config. 2. Connect from macOS Amnezia client (version 4.8.14.5). 3. Open Terminal and run: `scutil --dns | head -10` 4. Observe that resolver #1 is the LAN router IP via `en0`, not the configured DNS via `utun*`. 5. Run: `time dig +short github.com` — times out after 15 sec. 6. Run: `time nslookup github.com 1.1.1.1` — succeeds in ~100 ms. **Expected behavior** The macOS client should write the `DNS` value from `[Interface]` into `SCDynamicStore` so that resolver #1 in `scutil --dns` becomes the configured tunnel DNS (e.g. `1.1.1.1` via `utun*`), as the iOS client correctly does. **Workaround** Manually pinning DNS at the OS level resolves the issue completely: `sudo networksetup -setdnsservers Wi-Fi 1.1.1.1 1.0.0.1` After this, no more "hang" episodes occur regardless of Amnezia reconnects. **Diagnostic data captured during the hang** - `pfctl -ss | wc -l` → 401 (4% of state table limit, no overflow) - `netstat -an | grep SYN_SENT | wc -l` → 0 (apps not even attempting TCP — stuck on DNS) - `wg show all latest-handshakes` on server → fresh handshake, tunnel healthy - `nslookup ... 1.1.1.1` (explicit) → works instantly through the tunnel - `dig` (system resolver) → 15 sec timeout - `scutil --dns` resolver #1 → `nameserver[0]: 192.168.1.1`, `if_index: en0` (wrong) This confirms the tunnel itself is fine — the issue is purely that the DNS configuration from `[Interface]` is not propagated to the macOS system resolver. **Log files** Client logs from the affected session show a normal connect cycle with no errors: [2026-05-01 08:56:09.428Z] [DEBUG] Amnezia LocalSocketController : Handshake completed [2026-05-01 08:56:09.474Z] [DEBUG] Amnezia : VpnConnection::onConnectionStateChanged: Successfully flushed DNS Note `Successfully flushed DNS` — but the new DNS from config is never written to the system afterwards. **Desktop:** - OS: macOS Tahoe 26.4.1 (x86_64) - Version: AmneziaVPN 4.8.14.5 (build 477afb9) **Smartphone (works correctly, no bug):** - Device: iPhone - OS: iOS (current) - Version: AmneziaVPN (current from App Store) **Server:** - OS: Ubuntu 24.04 LTS (kernel 6.8.0-110-generic) - Container: amnezia-awg2 (AmneziaWG) **Additional context** - Bug appears intermittently — DNS is sometimes set correctly on first connect, but is lost on subsequent reconnects, network changes, or Power Nap events. - Tested with both `DNS = 1.1.1.1, 1.0.0.1` and other DNS servers — same behavior. - iCloud Private Relay is disabled. - Tailscale is installed but disconnected during testing — no impact. - MTU was tested and lowered to 1280 — did not affect this issue (it's purely a DNS routing problem). - Workaround `networksetup -setdnsservers` fully eliminates the issue, confirming the tunnel works fine and the only missing piece is DNS injection into the system.

bsakaguchi commented

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

Author

Owner

@aegor commented on GitHub (Jul 25, 2026):

This workaround don't worked for me.
Tahoe 26.6
Amnezia vpn 4.8.21.0
Steps:
Connect annezia to self-hosted server
run sudo networksetup -setdnsservers Wi-Fi 1.1.1.1 8.8.8.8
names not resolved
other traffic worked

@aegor commented on GitHub (Jul 25, 2026): This workaround don't worked for me. Tahoe 26.6 Amnezia vpn 4.8.21.0 Steps: Connect annezia to self-hosted server run sudo networksetup -setdnsservers Wi-Fi 1.1.1.1 8.8.8.8 names not resolved other traffic worked

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/amnezia-client#1156

No description provided.

Rows
Columns