[GH-ISSUE #3169] Windows client DNS leak #6520

Open
opened 2026-08-05 01:08:45 -04:00 by saavagebueno · 22 comments
Owner

Originally created by @boardlord1 on GitHub (Jan 10, 2025).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/3169

Describe the problem

I've noticed that the Windows Netbird client suffers from DNS leak. I'm self-hosting Netbird in am Ubuntu Server VM behind nginx, and I also run a cli client on the same machine as a routing peer into my home LAN (and also as an exit peer).

My DNS server, Adguard home listens on my home router at 192.168.7.1:53, with Cloudflare and Quad9 as upstream resolvers.

When I connect with the Android client or from a Linux machine all is well - I only see my upstream resolvers come up on browserleaks.com. However, I connect with the Windows client, I see the resolvers of the network I'm connected to.

Isn't this because to Netbird use netmask 128.0.0.0?

Netbird status log
Peers detail:

 samsung-jetbird.netbird.selfhosted:
  NetBird IP: 100.126.117.117
  Public key: 5ieyO9Z1EjWIgF6gIefM2bZ9mxJjqR9E8IAfEfA7tFk=
  Status: Disconnected
  -- detail --
  Connection type:
  ICE candidate (Local/Remote): -/-
  ICE candidate endpoints (Local/Remote): -/-
  Relay server address:
  Last connection update: -
  Last WireGuard handshake: -
  Transfer status (received/sent) 0 B/0 B
  Quantum resistance: false
  Routes: -
  Networks: -
  Latency: 0s

 openwrt-ligetter.netbird.selfhosted:
  NetBird IP: 100.126.129.15
  Public key: bvIh3WRnvEz/gQNMz8FQQc8DgT2ypXSr/HxAZyMZnwo=
  Status: Connected
  -- detail --
  Connection type: P2P
  ICE candidate (Local/Remote): host/srflx
  ICE candidate endpoints (Local/Remote): 192.168.47.1:51825/198.51.100.0:51820
  Relay server address: rels://nb.anon-XMJBI.domain:443
  Last connection update: 5 seconds ago
  Last WireGuard handshake: -
  Transfer status (received/sent) 148 B/388 B
  Quantum resistance: false
  Routes: 192.168.5.0/24
  Networks: 192.168.5.0/24
  Latency: 11.9858ms

 samsung-netbird.netbird.selfhosted:
  NetBird IP: 100.126.169.113
  Public key: 2UO/tW8YZcQIp6VKDNdftRb+ZS3YqVadjrGv1pKxFQQ=
  Status: Disconnected
  -- detail --
  Connection type:
  ICE candidate (Local/Remote): -/-
  ICE candidate endpoints (Local/Remote): -/-
  Relay server address:
  Last connection update: -
  Last WireGuard handshake: -
  Transfer status (received/sent) 0 B/0 B
  Quantum resistance: false
  Routes: -
  Networks: -
  Latency: 0s

 netbird-vm-cli-client.netbird.selfhosted:
  NetBird IP: 100.126.220.138
  Public key: OaaNsK+ZQA0ninoQS1vWIgpPwgYyr5q23CjM3ozWrVU=
  Status: Connected
  -- detail --
  Connection type: Relayed
  ICE candidate (Local/Remote): -/-
  ICE candidate endpoints (Local/Remote): -/-
  Relay server address: rels://nb.anon-XMJBI.domain:443
  Last connection update: 6 seconds ago
  Last WireGuard handshake: 1 second ago
  Transfer status (received/sent) 3.7 KiB/21.5 KiB
  Quantum resistance: false
  Routes: 0.0.0.0/0, 192.168.7.0/24, 192.168.9.0/24
  Networks: 0.0.0.0/0, 192.168.7.0/24, 192.168.9.0/24
  Latency: 0s

 netbird-vm-docker-node.netbird.selfhosted:
  NetBird IP: 100.126.237.210
  Public key: 5UCfvdijK/2wNW+gwnpNPg+9Ul6+1T8sjG027jyz2wE=
  Status: Disconnected
  -- detail --
  Connection type:
  ICE candidate (Local/Remote): -/-
  ICE candidate endpoints (Local/Remote): -/-
  Relay server address:
  Last connection update: -
  Last WireGuard handshake: -
  Transfer status (received/sent) 0 B/0 B
  Quantum resistance: false
  Routes: -
  Networks: -
  Latency: 0s

OS: windows/amd64
Daemon version: 0.35.2
CLI version: 0.35.2
Management: Connected to https://nb.anon-XMJBI.domain:443
Signal: Connected to https://nb.anon-XMJBI.domain:443
Relays:
  [stun:turn.anon-XMJBI.domain:3478] is Available
  [turn:turn.anon-XMJBI.domain:3478?transport=udp] is Available
  [rels://nb.anon-XMJBI.domain:443] is Available
Nameservers:
  [192.168.7.1:53] for [.] is Available
FQDN: adam-zenbook-1.netbird.selfhosted
NetBird IP: 100.126.31.1/16
Interface type: Userspace
Quantum resistance: false
Routes: -
Networks: -
Peers count: 2/5 Connected

Windows route print

===========================================================================
Interface List
 15...........................WireSock Virtual Adapter
 43...........................WireGuard Tunnel
 14...16 ac 60 56 87 d3 ......Microsoft Wi-Fi Direct Virtual Adapter
 12...16 ac 60 56 97 c3 ......Microsoft Wi-Fi Direct Virtual Adapter #2
 19...14 ac 60 56 a7 f3 ......MediaTek Wi-Fi 6E MT7922 (RZ616) 160MHz PCIe Adapter
  5...00 50 56 c0 00 01 ......VMware Virtual Ethernet Adapter for VMnet1
  4...00 50 56 c0 00 08 ......VMware Virtual Ethernet Adapter for VMnet8
 18...14 ac 60 56 a7 f4 ......Bluetooth Device (Personal Area Network)
  1...........................Software Loopback Interface 1
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0     192.168.68.1   192.168.68.244     30
          0.0.0.0        128.0.0.0         On-link      100.126.31.1      6
      "My WAN IP"  255.255.255.255     192.168.68.1   192.168.68.244     31
      100.126.0.0      255.255.0.0         On-link      100.126.31.1    261
     100.126.31.1  255.255.255.255         On-link      100.126.31.1    261
  100.126.255.255  255.255.255.255         On-link      100.126.31.1    261
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    331
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    331
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    331
  127.255.255.255  255.255.255.255         On-link      100.126.31.1    261
        128.0.0.0        128.0.0.0         On-link      100.126.31.1      6
      192.168.5.0    255.255.255.0         On-link      100.126.31.1      6
    192.168.5.255  255.255.255.255         On-link      100.126.31.1    261
      192.168.7.0    255.255.255.0         On-link      100.126.31.1      6
    192.168.7.255  255.255.255.255         On-link      100.126.31.1    261
      192.168.9.0    255.255.255.0         On-link      100.126.31.1      6
    192.168.9.255  255.255.255.255         On-link      100.126.31.1    261
     192.168.17.0    255.255.255.0         On-link      192.168.17.1    291
     192.168.17.1  255.255.255.255         On-link      192.168.17.1    291
   192.168.17.255  255.255.255.255         On-link      192.168.17.1    291
     192.168.47.0    255.255.255.0         On-link      192.168.47.1    291
     192.168.47.1  255.255.255.255         On-link      192.168.47.1    291
   192.168.47.255  255.255.255.255         On-link      192.168.47.1    291
     192.168.68.0    255.255.255.0         On-link    192.168.68.244    286
   192.168.68.244  255.255.255.255         On-link    192.168.68.244    286
   192.168.68.255  255.255.255.255         On-link    192.168.68.244    286
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    331
        224.0.0.0        240.0.0.0         On-link      192.168.47.1    291
        224.0.0.0        240.0.0.0         On-link      192.168.17.1    291
        224.0.0.0        240.0.0.0         On-link    192.168.68.244    286
        224.0.0.0        240.0.0.0         On-link      100.126.31.1    261
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    331
  255.255.255.255  255.255.255.255         On-link      192.168.47.1    291
  255.255.255.255  255.255.255.255         On-link      192.168.17.1    291
  255.255.255.255  255.255.255.255         On-link    192.168.68.244    286
  255.255.255.255  255.255.255.255         On-link      100.126.31.1    261
===========================================================================
Persistent Routes:
  None

IPv6 Route Table
===========================================================================
Active Routes:
 If Metric Network Destination      Gateway
 43      6 ::/1                     On-link
  1    331 ::1/128                  On-link
 43      6 8000::/1                 On-link
  5    291 fe80::/64                On-link
  4    291 fe80::/64                On-link
  4    291 fe80::42b5:e70e:9b90:f630/128
                                    On-link
  5    291 fe80::6f24:5c0c:c019:2a1a/128
                                    On-link
  1    331 ff00::/8                 On-link
  5    291 ff00::/8                 On-link
  4    291 ff00::/8                 On-link
 43    261 ff00::/8                 On-link
===========================================================================
Persistent Routes:
  None

Expected behavior

Just like with Linux and Android, no DNS leaks.

Originally created by @boardlord1 on GitHub (Jan 10, 2025). Original GitHub issue: https://github.com/netbirdio/netbird/issues/3169 **Describe the problem** I've noticed that the Windows Netbird client suffers from DNS leak. I'm self-hosting Netbird in am Ubuntu Server VM behind nginx, and I also run a cli client on the same machine as a routing peer into my home LAN (and also as an exit peer). My DNS server, Adguard home listens on my home router at 192.168.7.1:53, with Cloudflare and Quad9 as upstream resolvers. When I connect with the Android client or from a Linux machine all is well - I only see my upstream resolvers come up on browserleaks.com. However, I connect with the Windows client, I see the resolvers of the network I'm connected to. Isn't this because to Netbird use netmask 128.0.0.0? **Netbird status log** Peers detail: ``` samsung-jetbird.netbird.selfhosted: NetBird IP: 100.126.117.117 Public key: 5ieyO9Z1EjWIgF6gIefM2bZ9mxJjqR9E8IAfEfA7tFk= Status: Disconnected -- detail -- Connection type: ICE candidate (Local/Remote): -/- ICE candidate endpoints (Local/Remote): -/- Relay server address: Last connection update: - Last WireGuard handshake: - Transfer status (received/sent) 0 B/0 B Quantum resistance: false Routes: - Networks: - Latency: 0s openwrt-ligetter.netbird.selfhosted: NetBird IP: 100.126.129.15 Public key: bvIh3WRnvEz/gQNMz8FQQc8DgT2ypXSr/HxAZyMZnwo= Status: Connected -- detail -- Connection type: P2P ICE candidate (Local/Remote): host/srflx ICE candidate endpoints (Local/Remote): 192.168.47.1:51825/198.51.100.0:51820 Relay server address: rels://nb.anon-XMJBI.domain:443 Last connection update: 5 seconds ago Last WireGuard handshake: - Transfer status (received/sent) 148 B/388 B Quantum resistance: false Routes: 192.168.5.0/24 Networks: 192.168.5.0/24 Latency: 11.9858ms samsung-netbird.netbird.selfhosted: NetBird IP: 100.126.169.113 Public key: 2UO/tW8YZcQIp6VKDNdftRb+ZS3YqVadjrGv1pKxFQQ= Status: Disconnected -- detail -- Connection type: ICE candidate (Local/Remote): -/- ICE candidate endpoints (Local/Remote): -/- Relay server address: Last connection update: - Last WireGuard handshake: - Transfer status (received/sent) 0 B/0 B Quantum resistance: false Routes: - Networks: - Latency: 0s netbird-vm-cli-client.netbird.selfhosted: NetBird IP: 100.126.220.138 Public key: OaaNsK+ZQA0ninoQS1vWIgpPwgYyr5q23CjM3ozWrVU= Status: Connected -- detail -- Connection type: Relayed ICE candidate (Local/Remote): -/- ICE candidate endpoints (Local/Remote): -/- Relay server address: rels://nb.anon-XMJBI.domain:443 Last connection update: 6 seconds ago Last WireGuard handshake: 1 second ago Transfer status (received/sent) 3.7 KiB/21.5 KiB Quantum resistance: false Routes: 0.0.0.0/0, 192.168.7.0/24, 192.168.9.0/24 Networks: 0.0.0.0/0, 192.168.7.0/24, 192.168.9.0/24 Latency: 0s netbird-vm-docker-node.netbird.selfhosted: NetBird IP: 100.126.237.210 Public key: 5UCfvdijK/2wNW+gwnpNPg+9Ul6+1T8sjG027jyz2wE= Status: Disconnected -- detail -- Connection type: ICE candidate (Local/Remote): -/- ICE candidate endpoints (Local/Remote): -/- Relay server address: Last connection update: - Last WireGuard handshake: - Transfer status (received/sent) 0 B/0 B Quantum resistance: false Routes: - Networks: - Latency: 0s OS: windows/amd64 Daemon version: 0.35.2 CLI version: 0.35.2 Management: Connected to https://nb.anon-XMJBI.domain:443 Signal: Connected to https://nb.anon-XMJBI.domain:443 Relays: [stun:turn.anon-XMJBI.domain:3478] is Available [turn:turn.anon-XMJBI.domain:3478?transport=udp] is Available [rels://nb.anon-XMJBI.domain:443] is Available Nameservers: [192.168.7.1:53] for [.] is Available FQDN: adam-zenbook-1.netbird.selfhosted NetBird IP: 100.126.31.1/16 Interface type: Userspace Quantum resistance: false Routes: - Networks: - Peers count: 2/5 Connected ``` **Windows route print** ``` =========================================================================== Interface List 15...........................WireSock Virtual Adapter 43...........................WireGuard Tunnel 14...16 ac 60 56 87 d3 ......Microsoft Wi-Fi Direct Virtual Adapter 12...16 ac 60 56 97 c3 ......Microsoft Wi-Fi Direct Virtual Adapter #2 19...14 ac 60 56 a7 f3 ......MediaTek Wi-Fi 6E MT7922 (RZ616) 160MHz PCIe Adapter 5...00 50 56 c0 00 01 ......VMware Virtual Ethernet Adapter for VMnet1 4...00 50 56 c0 00 08 ......VMware Virtual Ethernet Adapter for VMnet8 18...14 ac 60 56 a7 f4 ......Bluetooth Device (Personal Area Network) 1...........................Software Loopback Interface 1 =========================================================================== IPv4 Route Table =========================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 192.168.68.1 192.168.68.244 30 0.0.0.0 128.0.0.0 On-link 100.126.31.1 6 "My WAN IP" 255.255.255.255 192.168.68.1 192.168.68.244 31 100.126.0.0 255.255.0.0 On-link 100.126.31.1 261 100.126.31.1 255.255.255.255 On-link 100.126.31.1 261 100.126.255.255 255.255.255.255 On-link 100.126.31.1 261 127.0.0.0 255.0.0.0 On-link 127.0.0.1 331 127.0.0.1 255.255.255.255 On-link 127.0.0.1 331 127.255.255.255 255.255.255.255 On-link 127.0.0.1 331 127.255.255.255 255.255.255.255 On-link 100.126.31.1 261 128.0.0.0 128.0.0.0 On-link 100.126.31.1 6 192.168.5.0 255.255.255.0 On-link 100.126.31.1 6 192.168.5.255 255.255.255.255 On-link 100.126.31.1 261 192.168.7.0 255.255.255.0 On-link 100.126.31.1 6 192.168.7.255 255.255.255.255 On-link 100.126.31.1 261 192.168.9.0 255.255.255.0 On-link 100.126.31.1 6 192.168.9.255 255.255.255.255 On-link 100.126.31.1 261 192.168.17.0 255.255.255.0 On-link 192.168.17.1 291 192.168.17.1 255.255.255.255 On-link 192.168.17.1 291 192.168.17.255 255.255.255.255 On-link 192.168.17.1 291 192.168.47.0 255.255.255.0 On-link 192.168.47.1 291 192.168.47.1 255.255.255.255 On-link 192.168.47.1 291 192.168.47.255 255.255.255.255 On-link 192.168.47.1 291 192.168.68.0 255.255.255.0 On-link 192.168.68.244 286 192.168.68.244 255.255.255.255 On-link 192.168.68.244 286 192.168.68.255 255.255.255.255 On-link 192.168.68.244 286 224.0.0.0 240.0.0.0 On-link 127.0.0.1 331 224.0.0.0 240.0.0.0 On-link 192.168.47.1 291 224.0.0.0 240.0.0.0 On-link 192.168.17.1 291 224.0.0.0 240.0.0.0 On-link 192.168.68.244 286 224.0.0.0 240.0.0.0 On-link 100.126.31.1 261 255.255.255.255 255.255.255.255 On-link 127.0.0.1 331 255.255.255.255 255.255.255.255 On-link 192.168.47.1 291 255.255.255.255 255.255.255.255 On-link 192.168.17.1 291 255.255.255.255 255.255.255.255 On-link 192.168.68.244 286 255.255.255.255 255.255.255.255 On-link 100.126.31.1 261 =========================================================================== Persistent Routes: None IPv6 Route Table =========================================================================== Active Routes: If Metric Network Destination Gateway 43 6 ::/1 On-link 1 331 ::1/128 On-link 43 6 8000::/1 On-link 5 291 fe80::/64 On-link 4 291 fe80::/64 On-link 4 291 fe80::42b5:e70e:9b90:f630/128 On-link 5 291 fe80::6f24:5c0c:c019:2a1a/128 On-link 1 331 ff00::/8 On-link 5 291 ff00::/8 On-link 4 291 ff00::/8 On-link 43 261 ff00::/8 On-link =========================================================================== Persistent Routes: None ``` **Expected behavior** Just like with Linux and Android, no DNS leaks.
saavagebueno added the feature-requestclientwindowsdns labels 2026-08-05 01:08:45 -04:00
Author
Owner

@lixmal commented on GitHub (Jan 10, 2025):

I believe you suffer from a feature called Smart Multi-homed Name Resolution (SMHNR). You could try disabling it.

How did you arrive at the conclusion that it has something to do with the route?

<!-- gh-comment-id:2584361157 --> @lixmal commented on GitHub (Jan 10, 2025): I believe you suffer from a feature called Smart Multi-homed Name Resolution (SMHNR). You could [try disabling it](https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-admx-dnsclient#dns_smartmultihomednameresolution). How did you arrive at the conclusion that it has something to do with the route?
Author
Owner

@boardlord1 commented on GitHub (Jan 10, 2025):

Thanks for getting! Looked at that setting in Group Policy and it was not set (which meant it's off), but for good measure I disabled it, but unfortunately the result was the same.

The reason I thought the issue might be connected to the route is that If I use Wireguard, route two looks like this:

0.0.0.0 0.0.0.0 On-link My-Wireguart-client-IP 6

Whereas with Netbird it's 0.0.0.0 128.0.0.0..... But, there are more routes configured with Netbird in the routing table, so I might be mistaken :) I just know that with plain Wireguard only the correct resolvers are used. What's also pointing to a Windows client issue is that on my Android phone there is no DNS leak when connected to my Netbird network with the official client.

<!-- gh-comment-id:2584654921 --> @boardlord1 commented on GitHub (Jan 10, 2025): Thanks for getting! Looked at that setting in Group Policy and it was not set (which meant it's off), but for good measure I disabled it, but unfortunately the result was the same. The reason I thought the issue might be connected to the route is that If I use Wireguard, route two looks like this: `0.0.0.0 0.0.0.0 On-link My-Wireguart-client-IP 6` Whereas with Netbird it's 0.0.0.0 128.0.0.0..... But, there are more routes configured with Netbird in the routing table, so I might be mistaken :) I just know that with plain Wireguard only the correct resolvers are used. What's also pointing to a Windows client issue is that on my Android phone there is no DNS leak when connected to my Netbird network with the official client.
Author
Owner

@lixmal commented on GitHub (Jan 10, 2025):

There's another part to complete the 0.0.0.0/0

128.0.0.0 128.0.0.0 On-link 100.126.31.1 6

I just know that with plain Wireguard only the correct resolvers are used. What's also pointing to a Windows client issue is that on my Android phone there is no DNS leak when connected to my Netbird network with the official client.

Vanilla wireguard firewalls off the other DNS servers, but only if there's only a single peer and it has a /0 route. We currently don't do this.

https://github.com/WireGuard/wireguard-windows/blob/master/docs/netquirk.md

<!-- gh-comment-id:2584685365 --> @lixmal commented on GitHub (Jan 10, 2025): There's another part to complete the 0.0.0.0/0 ` 128.0.0.0 128.0.0.0 On-link 100.126.31.1 6` >I just know that with plain Wireguard only the correct resolvers are used. What's also pointing to a Windows client issue is that on my Android phone there is no DNS leak when connected to my Netbird network with the official client. Vanilla wireguard firewalls off the other DNS servers, but only if there's only a single peer and it has a /0 route. We currently don't do this. https://github.com/WireGuard/wireguard-windows/blob/master/docs/netquirk.md
Author
Owner

@boardlord1 commented on GitHub (Jan 10, 2025):

Oh, thanks lixmal for the explanation! In this case, what can I do? I don't want to risk having my DNS queries going through a resolver of a random network I'm connected to.

EDIT: reading this article, the VPN client has to explicitly deal with this (like OpenVPN, explained in the article).
https://medium.com/@ValdikSS/beware-of-windows-10-dns-resolver-and-dns-leaks-5bc5bfb4e3f1

<!-- gh-comment-id:2584700121 --> @boardlord1 commented on GitHub (Jan 10, 2025): Oh, thanks lixmal for the explanation! In this case, what can I do? I don't want to risk having my DNS queries going through a resolver of a random network I'm connected to. EDIT: reading this article, the VPN client has to explicitly deal with this (like OpenVPN, explained in the article). `https://medium.com/@ValdikSS/beware-of-windows-10-dns-resolver-and-dns-leaks-5bc5bfb4e3f1`
Author
Owner

@boardlord1 commented on GitHub (Jan 15, 2025):

@lixmal would you have a suggestion here on what I could do?

<!-- gh-comment-id:2592252119 --> @boardlord1 commented on GitHub (Jan 15, 2025): @lixmal would you have a suggestion here on what I could do?
Author
Owner

@boardlord1 commented on GitHub (Jan 17, 2025):

I've updated to 0.36.2 today and it seems there's no leak anymore :)

EDIT: false alarm, got the leak again.

<!-- gh-comment-id:2598845158 --> @boardlord1 commented on GitHub (Jan 17, 2025): I've updated to 0.36.2 today and it seems there's no leak anymore :) EDIT: false alarm, got the leak again.
Author
Owner

@vitormfgoncalves commented on GitHub (Jan 27, 2025):

I can confirm. It also happens on linux.

In my config, I have only my internal DNS that have many blacklisted domains (for security reasons).
When connected, those blacklisted domains are still avaliable but shouldn't.

It falls back to the system DNS when fails to resolve those domains in my internal DNS.
This do not happen on Android.

I'm on version 0.36.3 (Windows 11 and Linux Debian 12)

<!-- gh-comment-id:2617677780 --> @vitormfgoncalves commented on GitHub (Jan 27, 2025): I can confirm. It also happens on linux. In my config, I have only my internal DNS that have many blacklisted domains (for security reasons). When connected, those blacklisted domains are still avaliable but shouldn't. It falls back to the system DNS when fails to resolve those domains in my internal DNS. This do not happen on Android. I'm on version 0.36.3 (Windows 11 and Linux Debian 12)
Author
Owner

@boardlord1 commented on GitHub (Feb 13, 2025):

Any movement on this? Have the devs been able to replicate? This makes it impossible for me to use desktop client...

<!-- gh-comment-id:2657211996 --> @boardlord1 commented on GitHub (Feb 13, 2025): Any movement on this? Have the devs been able to replicate? This makes it impossible for me to use desktop client...
Author
Owner

@boardlord1 commented on GitHub (Mar 18, 2025):

Bump, this is still an issue on latest release

<!-- gh-comment-id:2731798037 --> @boardlord1 commented on GitHub (Mar 18, 2025): Bump, this is still an issue on latest release
Author
Owner

@nazarewk commented on GitHub (Mar 18, 2025):

I might be wrong, but I don't think Netbird itself is doing anything special in terms of ensuring that it is the only DNS server usable.

For starters, it must be able to resolve the *.netbird.io to establish a connection. This requires usage of the network-provided DNS unless we have our own Netbird-hosted fallback server for those domains enforced client side.

To prevent further DNS leaks I am pretty sure we would need to implement it for every specific host separately.


I can confirm. It also happens on linux.

Yeah, linux is using systemd-resolved when available which, in turn, provides no guarantees whatsoever as to which configured server resolves the queries.


Should we consider this a feature request instead?

If/until it is implemented your best bet would be to configure the operating system to prevent DNS leaks on your own. If you succeed we would be very happy to learn how you achieved it.

<!-- gh-comment-id:2732167167 --> @nazarewk commented on GitHub (Mar 18, 2025): I might be wrong, but I don't think Netbird itself is doing anything special in terms of ensuring that it is the only DNS server usable. For starters, it must be able to resolve the `*.netbird.io` to establish a connection. This requires usage of the network-provided DNS unless we have our own Netbird-hosted fallback server for those domains enforced client side. To prevent further DNS leaks I am pretty sure we would need to implement it for every specific host separately. --- > I can confirm. It also happens on linux. Yeah, linux is using `systemd-resolved` when available which, in turn, provides no guarantees whatsoever as to which configured server resolves the queries. --- Should we consider this a feature request instead? If/until it is implemented your best bet would be to configure the operating system to prevent DNS leaks on your own. If you succeed we would be very happy to learn how you achieved it.
Author
Owner

@boardlord1 commented on GitHub (Mar 18, 2025):

I'd want to have this feature so that NB mirrors what WireGuard and Tailscale does - that EVERYTHING goes through the tunnel once it's up and running.

Because, there is a chance that some requests would not go through the established NB tunnel - as can be seen when you do a DNS leak test.

<!-- gh-comment-id:2734131724 --> @boardlord1 commented on GitHub (Mar 18, 2025): I'd want to have this feature so that NB mirrors what WireGuard and Tailscale does - that EVERYTHING goes through the tunnel once it's up and running. Because, there is a chance that some requests would not go through the established NB tunnel - as can be seen when you do a DNS leak test.
Author
Owner

@boardlord1 commented on GitHub (Jun 21, 2025):

Any news on this issue? It's valid with client v0.48.0...

<!-- gh-comment-id:2993350445 --> @boardlord1 commented on GitHub (Jun 21, 2025): Any news on this issue? It's valid with client v0.48.0...
Author
Owner

@kalipso-cyber commented on GitHub (Jul 15, 2025):

I'm seeing the same happen on my macOS device with client v0.50.3. This user is also experiencing it on their Android device.

I'd expect that, once a VPN tunnel is established and the DNS server specified in the Netbird configuration is reachable, it would be exclusively used for all DNS queries. What are the reasons for using the client-configured DNS server as well?

<!-- gh-comment-id:3075427752 --> @kalipso-cyber commented on GitHub (Jul 15, 2025): I'm seeing the same happen on my macOS device with client v0.50.3. [This user](https://github.com/netbirdio/netbird/issues/3452) is also experiencing it on their Android device. I'd expect that, once a VPN tunnel is established and the DNS server specified in the Netbird configuration is reachable, it would be exclusively used for all DNS queries. What are the reasons for using the client-configured DNS server as well?
Author
Owner

@boardlord1 commented on GitHub (Jan 11, 2026):

still an issue with 0.62.2, situation is the same:

  • on Windows the resolver set for the network the device is connected to appears
  • on Android only the DNS resolvers are seen that are set on the network of the exit node

I'm also running a headscale network, and the Tailscale client on Windows can somehow manage to not have a DNS leak... As is the vanilla Wireguard client.

This still prevents me to use Netbird in production!

@lixmal @nazarewk

<!-- gh-comment-id:3734083719 --> @boardlord1 commented on GitHub (Jan 11, 2026): still an issue with 0.62.2, situation is the same: - on Windows the resolver set for the network the device is connected to appears - on Android only the DNS resolvers are seen that are set on the network of the exit node I'm also running a headscale network, and the Tailscale client on Windows can somehow manage to not have a DNS leak... As is the vanilla Wireguard client. This still prevents me to use Netbird in production! @lixmal @nazarewk
Author
Owner

@nmapx commented on GitHub (Jan 18, 2026):

v0.63 same issue. Windows Smart Multi-Homed Name Resolution is probably trying to utilize DNS servers provided by all network interfaces. IMO Netbird client should provide a GUI switch to force the system to use this one, specific interface (wt0) for name resolution.
Most (if not all) popular VPN providers have DNS leak prevention so it is definitely doable.

<!-- gh-comment-id:3765150521 --> @nmapx commented on GitHub (Jan 18, 2026): v0.63 same issue. Windows `Smart Multi-Homed Name Resolution` is probably trying to utilize DNS servers provided by all network interfaces. IMO Netbird client should provide a GUI switch to force the system to use this one, specific interface (`wt0`) for name resolution. Most (if not all) popular VPN providers have `DNS leak prevention` so it is definitely doable.
Author
Owner

@geelenbert commented on GitHub (Apr 29, 2026):

Any update on this?
I've switched back to tailscale because the windows clients leaking on the local network.

I want to use netbird on some devices just the way the exit-node works on tailscale. Route all "internet" traffic trough it, only local LAN traffic outside of the VPN

<!-- gh-comment-id:4341393624 --> @geelenbert commented on GitHub (Apr 29, 2026): Any update on this? I've switched back to tailscale because the windows clients leaking on the local network. I want to use netbird on some devices just the way the exit-node works on tailscale. Route all "internet" traffic trough it, only local LAN traffic outside of the VPN
Author
Owner

@nmapx commented on GitHub (May 3, 2026):

@geelenbert the issue is still there. I tried to manually disable smart multi-homed DNS resolution through Windows policies on DNS Client - without luck. I don't have any more ideas so far. Looks like, it's easier to introduce a middle device that will make sure my Windows machine is going through VPN all the way. Windows -> middle device (Linux based, eg. OPNsense) connecting to Netbird and proxying all the traffic -> Netbird server (and other peers).

<!-- gh-comment-id:4366598767 --> @nmapx commented on GitHub (May 3, 2026): @geelenbert the issue is still there. I tried to manually disable smart multi-homed DNS resolution through Windows policies on DNS Client - without luck. I don't have any more ideas so far. Looks like, it's easier to introduce a middle device that will make sure my Windows machine is going through VPN all the way. Windows -> middle device (Linux based, eg. OPNsense) connecting to Netbird and proxying all the traffic -> Netbird server (and other peers).
Author
Owner

@lixmal commented on GitHub (May 5, 2026):

Hey folks, can you test this PR/build please?

<!-- gh-comment-id:4381182418 --> @lixmal commented on GitHub (May 5, 2026): Hey folks, can you test this [PR/build](https://github.com/netbirdio/netbird/pull/6078#issuecomment-4381156609) please?
Author
Owner

@nmapx commented on GitHub (May 5, 2026):

@lixmal I tested it quickly and it's working great! Thank you for that!
Just one thing that I've noticed - DNS leak test which I'm using (https://dnscheck.tools) takes now a lot of time to identify DNS security (see attached screenshot). Without VPN connection (or on Android client) it takes 2-5 seconds max (in all cases using same DNS servers, and the latency is not an issue here). In developer console you can see some UDP stuff going on there. Worth checking if you firewall change is "not too aggresive" 😅.
Image

<!-- gh-comment-id:4383590049 --> @nmapx commented on GitHub (May 5, 2026): @lixmal I tested it quickly and it's working great! Thank you for that! Just one thing that I've noticed - DNS leak test which I'm using (https://dnscheck.tools) takes now a lot of time to identify DNS security (see attached screenshot). Without VPN connection (or on Android client) it takes 2-5 seconds max (in all cases using same DNS servers, and the latency is not an issue here). In developer console you can see some UDP stuff going on there. Worth checking if you firewall change is "not too aggresive" 😅. <img width="552" height="188" alt="Image" src="https://github.com/user-attachments/assets/67d353a8-c6e3-42fd-90ee-2a7fb3bb7758" />
Author
Owner

@lixmal commented on GitHub (May 6, 2026):

This is slow for me, even without VPN. It seems to be Windows retrying the failed bogus queries. Not sure what UDP stuff you mean

<!-- gh-comment-id:4386233659 --> @lixmal commented on GitHub (May 6, 2026): This is slow for me, even without VPN. It seems to be Windows retrying the failed bogus queries. Not sure what UDP stuff you mean
Author
Owner

@nmapx commented on GitHub (May 6, 2026):

I'm not sure how this thing works underneath 😅 just letting you know it's much slower after the change (and I mean minutes instead of seconds, which is not the case on other Netbird clients using same network, same VPN server, same setup, just different client). Anyways, it takes minutes instead of seconds now, but if that's the trade-off for non-leaking-DNS then I guess it's worth it! 😄

<!-- gh-comment-id:4387800540 --> @nmapx commented on GitHub (May 6, 2026): I'm not sure how this thing works underneath 😅 just letting you know it's much slower after the change (and I mean minutes instead of seconds, which is not the case on other Netbird clients using same network, same VPN server, same setup, just different client). Anyways, it takes minutes instead of seconds now, but if that's the trade-off for non-leaking-DNS then I guess it's worth it! 😄
Author
Owner

@nmapx commented on GitHub (May 18, 2026):

@lixmal I don't wanna rush you but any clue when the fix is gonna be released?

<!-- gh-comment-id:4483072784 --> @nmapx commented on GitHub (May 18, 2026): @lixmal I don't wanna rush you but any clue when the fix is gonna be released?
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#6520