[Bug] [Access Control] Peers Within the Same Group Are Reachable

[carefreecaribou]

Describe the problem

peers within the same group can always reach each other directly. Access control policies only control traffic between different groups, not within a group. When you configure policies allowing Group1 to communicate with Group2 and Group1 to communicate with Group3, and remove the default policy, Group1 members can still ping, scan, and SSH to each other. We do not have peers within the same group advertised. So peers in Group1 cannot see each-other (not including administrator privileged users), but can perform network discovery to determine which peers exist.

To Reproduce

1. Create two groups in NetBird: Group1, Group2
2. Add 2-3 peers to Group1
3. Add 1-2 peers to Group2
4. Create an access control policy: Allow Group1 → Group2
5. Remove the default access control policy
6. Confirm no other policies exist that would allow Group1 → Group1
7. Test from a regular user peer in Group1: Ping another peer in Group1
8. All connections within Group1 succeed

Expected behavior

With the default Access Control Policy removed, it is expected that only rules explicitly defined should grant access to groups, peers, and resources.

Are you using NetBird Cloud?

No, Selfhosted.

NetBird version

Netbird Client: v0.59.5
Netbird Server: v0.59.5

Is any other VPN software installed?

Yes. Wireguard, ProtonVPN, but these are disabled during testing.

Debug output

netbirdStatus_dA.txt

Create and upload a debug bundle, and share the returned file key:

9a2544acba54ee76273b90851f8577f72ebad9d0547399a91af5952a5264fafa/d80e6674-afe1-43cd-9e29-2e3882847b4a

Screenshots

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

[lixmal]

@carefreecaribou what is the group membership of the peers?

[Blackclaws]

If you check with the new dashboard and select one of your peers it should show you which other peers it is connected to by which policies. We cannot reproduce this with our setups. I'd usually also say that bidirectional policies are mostly a trap because there is seldom a need for the target to contact back, only exceptions are when you want to build a full mesh between nodes.

[Blackclaws]

I think ping could also be a somewhat special case, I'd have to check but you shouldn't even be peering with those from your own group unless there was an access policy governing that or the node was also part of one of the other groups that you have access to.

[carefreecaribou]

@carefreecaribou what is the group membership of the peers?

@lixmal Both peers during testing are a part of the same group "Tester Group" and the default "All" group:

For testing each user in this group gets access to two other groups "VPN" and "INT". For the initial testing, bidirectional access policies from "Tester" to each of these other two groups were created (But tested with one way policies later on in this post). The VPN group gives you access to network routes. Each "VPN" node is on a certain exit route and is of the type routing Peers. When we disable each of these exit routes, pings are still possible to the peers within my same group. There are currently no other rules affecting INT or any online peers in this group to affect meshing.

If you check with the new dashboard and select one of your peers it should show you which other peers it is connected to by which policies. We cannot reproduce this with our setups.

@Blackclaws The peers within the same group are not showing up as an accessible peer

I think ping could also be a somewhat special case, I'd have to check but you shouldn't even be peering with those from your own group unless there was an access policy governing that or the node was also part of one of the other groups that you have access to.

When we create an explicit one way policy between users within the same group allowing only doom on udp.

Connections are restricted as expected. I cannot reach the host except on the explicitly defined policy, even with ping; however, ping still discloses the presence of this host:

I'd usually also say that bidirectional policies are mostly a trap because there is seldom a need for the target to contact back, only exceptions are when you want to build a full mesh between nodes.

Finally, changing the existing routes to one way policies as you hinted at and disabling the "doom" rule for now, still allows that ping connection (will be checking other access methods soon). (see posts below for correction). We do have a use case for these nodes to have bidirectional communications though, which is why we initially had it as such.

I will be testing other access methods besides just ping shortly to verify whether its "ALL" traffic or only ping traffic.

[carefreecaribou]

@Blackclaws

I'd usually also say that bidirectional policies are mostly a trap because there is seldom a need for the target to contact back, only exceptions are when you want to build a full mesh between nodes.

You might be right here. I failed to relaunch my netbird client after attempting one way traffic policies only. After changing the VPN policy to one way, and rebringing netbird down/up, I can no longer seem to access the peers. I will try to look into this further, but it now seems that testers within a group can reach one another if there is a bidirectional policy in place to routing peers /exit nodes.

This issue is only caused when using a bidirectional (or two unidirectional policies) to a Routing Peer Exit node and not bidirectional policies to other groups that are not exit nodes. Here is a trace route showing my connection to the second node is going through an exit node (Routing Peer) we had configured.

The routing peer functions as the exit node for the Internet traffic. Once configured, it automatically handles traffic it receives from connected peers, applying masquerading to ensure traffic appears to originate from the routing peer's public IP address.

Acting as a router seems to make Routing Peers ignore not-explicitly defined access control policies if some other limiting policy does not exist for peers within a group.

So
GroupA <-> Exit(routing Peer)

Will allow GroupA->Exit(routing Peer)->GroupA
for all traffic without the default rule unless a specific policy exists for GroupA->GroupA

[carefreecaribou]

For now, I don't think this is a bug, rather just unexpected behavior caused by the routing function of the routing peers.
We were intending on having outside traffic being able to communicate with nodes in this test group (the second direction) and were not expecting the test group intra-communication to succeed due to the routing peer directing the traffic back since we did not explicitly allow a test->test policy. It could be good to list this on the Exit Node/Routing Peer documentation if that's the case. Creating an explicit intra-peer rule restricting everything (but a single port such as our doom rule above) restricts this routing unless its the explicitly allowed traffic, but still discloses the presence of the host due to the differing returned responses.

I would expect this traffic to be blocked since it's not explicitly allowed in the access control policy (with the "default" rule removed). Routing peers should respect access control policies and not facilitate intra- and inter-network communications solely based on their own connectivity—an explicit rule should be required to allow traffic within and between the networks.

Feel free to close this if you also believe this is bug, but part of the Exit Node/Routing peer mesh design. Still might be useful to have a note about this either on the Exit Node/Routing Peer page, or within the Access control Page about bidirectional policies and routing peers.