[GH-ISSUE #2698] Problems with peer-to-peer connection for name resolutions with self-hosted Netbird/DNS server #5653

Open
opened 2026-08-05 01:04:25 -04:00 by saavagebueno · 0 comments
Owner

Originally created by @joao-aveiro on GitHub (Oct 6, 2024).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/2698

Describe the problem

I have deployed a self-hosted Netbird instance alongside a CoreDNS server which I use for local/private name resolution (both in the same machine, deployed in containers). The DNS server was mapped to an interface in the localhost and access to it was achieved by installing a Netbird client in the host side of the Netbird/CoreDNS machine and creating a policy to allow clients connecting to the DNS server port on that specific peer. A custom nameserver was also configured in the dashboard.

Since the initial deployment (version 0.28.x), this has been working without a problem. However, with a recent upgrade to version 0.30.0 (both the server and the clients), the clients can no longer resolve internal domains. It seems the connection to the DNS port on the server peer is being blocked. Downgrading the client in the host of the CoreDNS server solves this issue.

To Reproduce

My setup was achieved by:

  1. Having the Netbird client installed in the server
  2. Under "Nameservers" configura a new nameserver matching my local/private domain and use the Netbird-provided IP for the Netbird/CoreDNS server
  3. Assign the Netbird/CoreDNS server peer to a group (e.g. vm-grp-dns)
  4. Create a policy allowing connecting user groups (e.g., usr-grp-xxx) to the DNS server port, i.e. usr-grp-1,usr-grp-2 -> vm-grp-dns

Running dig @100.XXX.XXX.XXX -p8053 something.internal.org (where 100.XXX.XXX.XXX is the Netbird-assigned IP of the CoreDNS/Netbird host machine peer) results in:

  • The domain being resolved if the target peer has version <0.30.0
  • Timeout if the target peer has version =0.30.0

Regardless of the client version of the origin peer (i.e., my local machine) I use.

Expected behavior

I expected that my setup would still work.
I've seen that with this release there are changes to how the network routes work, but from what I understood it shouldn't make a difference in this case, since I am not using Network Route for this purpose and instead I'm relying on direct peer connection. I can create a Network Route to solve this, but previously that wasn't needed and I don't see a point in having to create a route for a single peer which is already in the Netbird network.

I am not sure if this is a bug or intended behaviour, but in case it is the latter, I believe the details provided in the release and in the documentation regarding the changes in network routes seem insufficient.

Are you using NetBird Cloud?
No, a self-hosted instance.

NetBird version
Server: tried with 0.30.0 and 0.29.4
Clients: tried with 0.30.0 and 0.29.4 on both the origin and the target peers

Originally created by @joao-aveiro on GitHub (Oct 6, 2024). Original GitHub issue: https://github.com/netbirdio/netbird/issues/2698 **Describe the problem** I have deployed a self-hosted Netbird instance alongside a CoreDNS server which I use for local/private name resolution (both in the same machine, deployed in containers). The DNS server was mapped to an interface in the localhost and access to it was achieved by installing a Netbird client in the host side of the Netbird/CoreDNS machine and creating a policy to allow clients connecting to the DNS server port on that specific peer. A custom nameserver was also configured in the dashboard. Since the initial deployment (version 0.28.x), this has been working without a problem. However, with a recent upgrade to version 0.30.0 (both the server and the clients), the clients can no longer resolve internal domains. It seems the connection to the DNS port on the server peer is being blocked. Downgrading the client in the host of the CoreDNS server solves this issue. **To Reproduce** My setup was achieved by: 1. Having the Netbird client installed in the server 2. Under "Nameservers" configura a new nameserver matching my local/private domain and use the Netbird-provided IP for the Netbird/CoreDNS server 3. Assign the Netbird/CoreDNS server peer to a group (e.g. `vm-grp-dns`) 4. Create a policy allowing connecting user groups (e.g., `usr-grp-xxx`) to the DNS server port, i.e. `usr-grp-1,usr-grp-2 -> vm-grp-dns` Running `dig @100.XXX.XXX.XXX -p8053 something.internal.org` (where `100.XXX.XXX.XXX` is the Netbird-assigned IP of the CoreDNS/Netbird host machine peer) results in: - The domain being resolved if the target peer has version `<0.30.0` - Timeout if the target peer has version `=0.30.0` Regardless of the client version of the origin peer (i.e., my local machine) I use. **Expected behavior** I expected that my setup would still work. I've seen that with this release there are changes to how the network routes work, but from what I understood it shouldn't make a difference in this case, since I am not using Network Route for this purpose and instead I'm relying on direct peer connection. I can create a Network Route to solve this, but previously that wasn't needed and I don't see a point in having to create a route for a single peer which is already in the Netbird network. I am not sure if this is a bug or intended behaviour, but in case it is the latter, I believe the details provided in the release and in the documentation regarding the changes in network routes seem insufficient. **Are you using NetBird Cloud?** No, a self-hosted instance. **NetBird version** Server: tried with 0.30.0 and 0.29.4 Clients: tried with 0.30.0 and 0.29.4 on both the origin and the target peers
saavagebueno added the clienttriage-neededself-hosting labels 2026-08-05 01:04:25 -04:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#5653