TCP port 53, breaking local DNS resolvers (dnscrypt-proxy, Pi-hole-style tools) #1466

New issue

Open

opened 2026-10-13 20:42:59 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-13 20:42:59 +00:00

Owner

Originally created by @ddd100et on GitHub (Sep 12, 2026).
Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/3160

Describe the bug
When AmneziaVPN's DNS Leak Protection / Kill Switch is enabled, it appears to register a WFP filter that blocks all outbound UDP/TCP traffic on port 53, including traffic to 127.0.0.1 (loopback). Since loopback traffic can never leave the machine, it cannot leak to the ISP by definition — blocking it does not add any privacy protection, but it does break any local DNS proxy/filter running on 127.0.0.1:53 (dnscrypt-proxy, Pi-hole-style local resolvers, parental-control software, ad-blocking DNS proxies, etc.).

This may be related to #986 ("No local network access"), which reports a similar symptom for a "local secure DNS" server becoming unreachable after connecting.

To Reproduce

Run any local DNS proxy listening on 127.0.0.1:53 (e.g. dnscrypt-proxy configured with listen_addresses = ["127.0.0.1:53"]).
Confirm it works: nslookup github.com 127.0.0.1 returns a valid IP.
Connect AmneziaVPN with DNS Leak Protection / Kill Switch enabled.
Run nslookup github.com 127.0.0.1 again.

Actual behavior
nslookup github.com 127.0.0.1 times out ("DNS request timed out") while the VPN tunnel is connected with DNS Leak Protection / Kill Switch on. The same resolver responds instantly (<1s) once DNS Leak Protection is turned off (VPN tunnel itself stays connected), and instantly after the Amnezia process is fully stopped. This was reproduced consistently across multiple toggles and survives a full reboot in both directions (protection on -> broken, protection off -> works).

Windows Firewall logging (netsh advfirewall set allprofiles logging dropped connections enable) does not show these drops — confirming the block happens at a lower WFP layer registered directly by the Amnezia service, not via netsh advfirewall rules.

Environment

OS: Windows 10/11 x64
AmneziaVPN: 5.0.1.5
Protocol: AmneziaWG
Reproduced with DNS Leak Protection / Kill Switch toggled independently of the VPN connection itself (tunnel stays up in both cases)

Suggested fix

Exclude the loopback range (127.0.0.0/8, or at minimum 127.0.0.1) from the destination-IP match condition of the port-53 block filter. This is a one-line change to the filter's IP range condition and carries no downside for the leak-protection guarantee, since loopback traffic is not exposed to the network by construction.

As a possibly simpler alternative: expose DNS Leak Protection as configurable (e.g. an allow-list for local resolver addresses, or a toggle between "block all non-tunnel DNS" and "block all external DNS, allow loopback"), so users running a local filtering/parental-control DNS proxy aren't forced to choose between VPN leak protection and local DNS filtering entirely.

Additional context

Raw pfirewall.log excerpt showing the drop (captured with Windows Firewall dropped-connection logging enabled, while AmneziaVPN Kill Switch was active):

2026-09-11 14:41:18 DROP UDP 127.0.0.1 127.0.0.1 56453 53 0 - - - - - - - SEND 15456
2026-09-11 14:41:20 DROP UDP 127.0.0.1 127.0.0.1 56454 53 0 - - - - - - - SEND 15456

netsh wfp show filters diff (filters added specifically when DNS Leak Protection / Kill Switch is turned on, isolated by diffing a snapshot taken right before enabling it against one taken right after — see the two "Block all DNS" entries and the loopback exception below):

FilterId    : 3417543
RuleName    : Block all DNS
Description : Block outgoing v4 on Port 53
Layer       : FWPM_LAYER_ALE_AUTH_CONNECT_V4
Action      : FWP_ACTION_BLOCK

FilterId    : 3417544
RuleName    : Block all DNS
Description : Block incoming v4 on Port 53
Layer       : FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V4
Action      : FWP_ACTION_BLOCK

FilterId    : 3417542
RuleName    : Block all DNS
Description : Block outgoing v6 on Port 53
Layer       : FWPM_LAYER_ALE_AUTH_CONNECT_V6
Action      : FWP_ACTION_BLOCK

FilterId    : 3417545
RuleName    : Block all DNS
Description : Block incoming v6 on Port 53
Layer       : FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V6
Action      : FWP_ACTION_BLOCK

FilterId    : 3417546
RuleName    : Allow Loopback traffic on device loopback_0
Description : Allow out traffic on Adapter 1
Layer       : FWPM_LAYER_ALE_AUTH_CONNECT_V4
Action      : FWP_ACTION_PERMIT

FilterId    : 3417547
RuleName    : Allow Loopback traffic on device loopback_0
Description : Allow in traffic on Adapter 1
Layer       : FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V4
Action      : FWP_ACTION_PERMIT

FilterId    : 3418068
RuleName    : Allow DNS-Server
Description : Permit traffic to 1.1.1.1 on port 53
Layer       : FWPM_LAYER_ALE_AUTH_CONNECT_V4
Action      : FWP_ACTION_PERMIT

FilterId    : 3418070
RuleName    : Allow DNS-Server
Description : Permit traffic to 1.0.0.1 on port 53
Layer       : FWPM_LAYER_ALE_AUTH_CONNECT_V4
Action      : FWP_ACTION_PERMIT

Key observation:
the Block all DNS filters carry no address condition at all — they block port 53 unconditionally except for the handful of explicit /32 exceptions above (the VPN's own DNS resolvers) and an adapter-scoped exception named loopback_0 / Adapter 1. That adapter exception does not appear to match Windows' actual Loopback Pseudo-Interface 1 (the interface a plain 127.0.0.1:53 UDP packet from nslookup.exe or a local DNS proxy actually travels through), which is why traffic to 127.0.0.1:53 is dropped by the port-53 block instead of matching the loopback exception. Adding an address-based condition (127.0.0.0/8) to the two Block all DNS filters — the same approach already used for the 1.1.1.1/1.0.0.1 exceptions above, just with a loopback range instead of single IPs — would fix this without weakening the leak-protection guarantee for actual network-facing traffic.

Originally created by @ddd100et on GitHub (Sep 12, 2026). Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/3160 **Describe the bug** When AmneziaVPN's DNS Leak Protection / Kill Switch is enabled, it appears to register a WFP filter that blocks **all** outbound UDP/TCP traffic on port 53, including traffic to `127.0.0.1` (loopback). Since loopback traffic can never leave the machine, it cannot leak to the ISP by definition — blocking it does not add any privacy protection, but it does break any local DNS proxy/filter running on 127.0.0.1:53 (dnscrypt-proxy, Pi-hole-style local resolvers, parental-control software, ad-blocking DNS proxies, etc.). This may be related to #986 ("No local network access"), which reports a similar symptom for a "local secure DNS" server becoming unreachable after connecting. **To Reproduce** 1. Run any local DNS proxy listening on `127.0.0.1:53` (e.g. `dnscrypt-proxy` configured with `listen_addresses = ["127.0.0.1:53"]`). 2. Confirm it works: `nslookup github.com 127.0.0.1` returns a valid IP. 3. Connect AmneziaVPN with DNS Leak Protection / Kill Switch enabled. 4. Run `nslookup github.com 127.0.0.1` again. **Actual behavior** `nslookup github.com 127.0.0.1` times out ("DNS request timed out") while the VPN tunnel is connected with DNS Leak Protection / Kill Switch on. The same resolver responds instantly (<1s) once DNS Leak Protection is turned off (VPN tunnel itself stays connected), and instantly after the Amnezia process is fully stopped. This was reproduced consistently across multiple toggles and survives a full reboot in both directions (protection on -> broken, protection off -> works). Windows Firewall logging (`netsh advfirewall set allprofiles logging dropped connections enable`) does **not** show these drops — confirming the block happens at a lower WFP layer registered directly by the Amnezia service, not via `netsh advfirewall` rules. **Environment** - OS: Windows 10/11 x64 - AmneziaVPN: 5.0.1.5 - Protocol: AmneziaWG - Reproduced with DNS Leak Protection / Kill Switch toggled independently of the VPN connection itself (tunnel stays up in both cases) **Suggested fix** Exclude the loopback range (127.0.0.0/8, or at minimum 127.0.0.1) from the destination-IP match condition of the port-53 block filter. This is a one-line change to the filter's IP range condition and carries no downside for the leak-protection guarantee, since loopback traffic is not exposed to the network by construction. As a possibly simpler alternative: expose DNS Leak Protection as configurable (e.g. an allow-list for local resolver addresses, or a toggle between "block all non-tunnel DNS" and "block all external DNS, allow loopback"), so users running a local filtering/parental-control DNS proxy aren't forced to choose between VPN leak protection and local DNS filtering entirely. **Additional context** Raw `pfirewall.log` excerpt showing the drop (captured with Windows Firewall dropped-connection logging enabled, while AmneziaVPN Kill Switch was active): ``` 2026-09-11 14:41:18 DROP UDP 127.0.0.1 127.0.0.1 56453 53 0 - - - - - - - SEND 15456 2026-09-11 14:41:20 DROP UDP 127.0.0.1 127.0.0.1 56454 53 0 - - - - - - - SEND 15456 ``` `netsh wfp show filters` diff (filters added specifically when DNS Leak Protection / Kill Switch is turned on, isolated by diffing a snapshot taken right before enabling it against one taken right after — see the two "Block all DNS" entries and the loopback exception below): ``` FilterId : 3417543 RuleName : Block all DNS Description : Block outgoing v4 on Port 53 Layer : FWPM_LAYER_ALE_AUTH_CONNECT_V4 Action : FWP_ACTION_BLOCK FilterId : 3417544 RuleName : Block all DNS Description : Block incoming v4 on Port 53 Layer : FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V4 Action : FWP_ACTION_BLOCK FilterId : 3417542 RuleName : Block all DNS Description : Block outgoing v6 on Port 53 Layer : FWPM_LAYER_ALE_AUTH_CONNECT_V6 Action : FWP_ACTION_BLOCK FilterId : 3417545 RuleName : Block all DNS Description : Block incoming v6 on Port 53 Layer : FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V6 Action : FWP_ACTION_BLOCK FilterId : 3417546 RuleName : Allow Loopback traffic on device loopback_0 Description : Allow out traffic on Adapter 1 Layer : FWPM_LAYER_ALE_AUTH_CONNECT_V4 Action : FWP_ACTION_PERMIT FilterId : 3417547 RuleName : Allow Loopback traffic on device loopback_0 Description : Allow in traffic on Adapter 1 Layer : FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V4 Action : FWP_ACTION_PERMIT FilterId : 3418068 RuleName : Allow DNS-Server Description : Permit traffic to 1.1.1.1 on port 53 Layer : FWPM_LAYER_ALE_AUTH_CONNECT_V4 Action : FWP_ACTION_PERMIT FilterId : 3418070 RuleName : Allow DNS-Server Description : Permit traffic to 1.0.0.1 on port 53 Layer : FWPM_LAYER_ALE_AUTH_CONNECT_V4 Action : FWP_ACTION_PERMIT ``` **Key observation:** the `Block all DNS` filters carry no address condition at all — they block port 53 unconditionally except for the handful of explicit `/32` exceptions above (the VPN's own DNS resolvers) and an adapter-scoped exception named `loopback_0` / `Adapter 1`. That adapter exception does not appear to match Windows' actual `Loopback Pseudo-Interface 1` (the interface a plain `127.0.0.1:53` UDP packet from `nslookup.exe` or a local DNS proxy actually travels through), which is why traffic to `127.0.0.1:53` is dropped by the port-53 block instead of matching the loopback exception. Adding an address-based condition (`127.0.0.0/8`) to the two `Block all DNS` filters — the same approach already used for the `1.1.1.1`/`1.0.0.1` exceptions above, just with a loopback range instead of single IPs — would fix this without weakening the leak-protection guarantee for actual network-facing traffic.

bsakaguchi referenced this issue

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

[PR #1466] [MERGED] chore: fixed proxyStorageUrl typo #2374