[GH-ISSUE #5593] Losing access to a local network when apply access rule to a peer in another local network #10821

Open
opened 2026-08-05 01:27:23 -04:00 by saavagebueno · 2 comments
Owner

Originally created by @avina8i on GitHub (Mar 12, 2026).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/5593

the problem

I've spent many hours trying to fix different parts of my network because of losing access from one network resource to another. I've blamed my firewall, routing settings, DNS and etc and when I've checked everything I accidentally discovered that Netbird peer causes that issue.

So the problem:
I have some internal networks separated with VLANs and firewall rules between them on site A, let's call the networks - A and B. For simplicity and debugging purposes I've allowed to move all the traffic between those networks in both directions without any restrictions, so services in network A can reach services in network B and vice versa. On networks A and B I have docker servers (Debian 13) and I installed a Netbird client on each of the docker server - DKR-A in network A and DKR-B in network B. In Netbird management console I've configured two networks - A and B and added to them resources - DKR-A in network A and DKR-B in network - B respectively. I've assigned to the resource DKR-A an ip address 10.0.0.1/32 and distribution group - A-DKR-A and to the resource DKR-B an ip address 10.0.10.1/32 and distribution group - B-DKR-B. Next I've added an access rule which allows all peers (source) to access my network resources through groups A-DKR-A and B-DKR-B respectively with any protocol. When I enable the access rule I can't ping the DKR-B server from DKR-A and in the opposite direction, so literally I can't reach any network resource in network A from DKR-B in network B and vice versa. It looks strange and I don't know how to solve it properly or maybe it is just a bug?

To Reproduce

I've described everything in a problem section.

Expected behavior

The resources in local networks should be reachable in described scenario.

Are you using NetBird Cloud?

self-host NetBird's control plane

NetBird version

66.4

Is any other VPN software installed?

no

Add any other context about the problem here.

Have you tried these troubleshooting steps?

  • Reviewed client troubleshooting (if applicable)
  • Checked for newer NetBird versions
  • Searched for similar issues on GitHub (including closed ones)
  • Restarted the NetBird client
  • Disabled other VPN software
  • Checked firewall settings
Originally created by @avina8i on GitHub (Mar 12, 2026). Original GitHub issue: https://github.com/netbirdio/netbird/issues/5593 **the problem** I've spent many hours trying to fix different parts of my network because of losing access from one network resource to another. I've blamed my firewall, routing settings, DNS and etc and when I've checked everything I accidentally discovered that Netbird peer causes that issue. So the problem: I have some internal networks separated with VLANs and firewall rules between them on site A, let's call the networks - A and B. For simplicity and debugging purposes I've allowed to move all the traffic between those networks in both directions without any restrictions, so services in network A can reach services in network B and vice versa. On networks A and B I have docker servers (Debian 13) and I installed a Netbird client on each of the docker server - **DKR-A in network A** and **DKR-B in network B**. In Netbird management console I've configured **two networks - A and B** and added to them resources - **DKR-A in network A** and **DKR-B in network - B** respectively. I've assigned to the resource DKR-A an ip address 10.0.0.1/32 and **distribution group - A-DKR-A** and to the resource DKR-B an ip address 10.0.10.1/32 and **distribution group - B-DKR-B**. Next I've added an access rule which allows all peers (source) to access my network resources through groups A-DKR-A and B-DKR-B respectively with any protocol. When I enable the access rule I can't ping the DKR-B server from DKR-A and in the opposite direction, so literally I can't reach any network resource in network A from DKR-B in network B and vice versa. It looks strange and I don't know how to solve it properly or maybe it is just a bug? **To Reproduce** I've described everything in a problem section. **Expected behavior** The resources in local networks should be reachable in described scenario. **Are you using NetBird Cloud?** self-host NetBird's control plane **NetBird version** 66.4 **Is any other VPN software installed?** no Add any other context about the problem here. **Have you tried these troubleshooting steps?** - [x] Reviewed [client troubleshooting](https://docs.netbird.io/how-to/troubleshooting-client) (if applicable) - [ ] Checked for newer NetBird versions - [ ] Searched for similar issues on GitHub (including closed ones) - [ ] Restarted the NetBird client - [ ] Disabled other VPN software - [ ] Checked firewall settings
saavagebueno added the triage-needed label 2026-08-05 01:27:23 -04:00
Author
Owner

@svenkispert commented on GitHub (Mar 21, 2026):

Hi,

I hope I'm understanding you correctly, but I think you've misunderstood how networks and resources work. Networks and their resources are used when you have servers or IP networks you want to access but on which no Netbird client is installed. The server running the Netbird client then functions as a router (so called routing peer). The addresses in the resources must be real IP addresses; you don't assign addresses that way! Take a look at this page in the documentation: https://docs.netbird.io/manage/networks

From what I understand, you have installed Netbird clients on your destination servers. You can use them as destinations (Tab: peers) in the access policies, or you can group them together and use the groups as destinations/sources if the same rules are to apply. In that case, no "networks" are necessary.

That's how it should work. At least for relayed connections; for P2P, the servers must, of course, be allowed to use high UDP ports for outbound traffic and will then be managed via the management server using Signal and STUN.

I hope that helps.
Give it a try and have a great weekend! If you have any questions, feel free to reach out again.

Best!
Sven

<!-- gh-comment-id:4103065469 --> @svenkispert commented on GitHub (Mar 21, 2026): Hi, I hope I'm understanding you correctly, but I think you've misunderstood how networks and resources work. Networks and their resources are used when you have servers or IP networks you want to access but on which no Netbird client is installed. The server running the Netbird client then functions as a router (so called routing peer). The addresses in the resources must be real IP addresses; you don't assign addresses that way! Take a look at this page in the documentation: https://docs.netbird.io/manage/networks From what I understand, you have installed Netbird clients on your destination servers. You can use them as destinations (Tab: peers) in the access policies, or you can group them together and use the groups as destinations/sources if the same rules are to apply. In that case, no "networks" are necessary. That's how it should work. At least for relayed connections; for P2P, the servers must, of course, be allowed to use high UDP ports for outbound traffic and will then be managed via the management server using Signal and STUN. I hope that helps. Give it a try and have a great weekend! If you have any questions, feel free to reach out again. Best! Sven
Author
Owner

@avina8i commented on GitHub (Apr 3, 2026):

It look like you haven't red my post, as I've described my scenario ;) Netbird is blocking traffic which comes to the host with installed netbird client from the others hosts in the same network and it is strange as it should behave like that...

<!-- gh-comment-id:4182613531 --> @avina8i commented on GitHub (Apr 3, 2026): It look like you haven't red my post, as I've described my scenario ;) Netbird is blocking traffic which comes to the host with installed netbird client from the others hosts in the same network and it is strange as it should behave like that...
Sign in to join this conversation.
No Label triage-needed
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#10821