SVI/netbird
1
0
Fork 0
mirror of https://github.com/netbirdio/netbird.git synced 2026-07-27 16:32:34 -04:00
Code Issues 3.0k Packages Projects Releases 10 Wiki Activity

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

New Issue
Open
opened 2025-11-20 07:08:28 -05:00 by saavagebueno · 6 comments
saavagebueno commented 2025-11-20 07:08:28 -05:00
Owner
Copy Link

Originally created by @carefreecaribou on GitHub (Oct 9, 2025).

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

Image

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 @carefreecaribou on GitHub (Oct 9, 2025). **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](https://github.com/user-attachments/files/22805122/netbirdStatus_dA.txt) Create and upload a debug bundle, and share the returned file key: 9a2544acba54ee76273b90851f8577f72ebad9d0547399a91af5952a5264fafa/d80e6674-afe1-43cd-9e29-2e3882847b4a **Screenshots** <img width="1239" height="443" alt="Image" src="https://github.com/user-attachments/assets/dcf5b27a-6d60-4e5c-9e87-1d1b1812cdf6" /> **Have you tried these troubleshooting steps?** - [X] Reviewed [client troubleshooting](https://docs.netbird.io/how-to/troubleshooting-client) (if applicable) - [X] Checked for newer NetBird versions - [X] Searched for similar issues on GitHub (including closed ones) - [X] Restarted the NetBird client - [X] Disabled other VPN software - [X] Checked firewall settings
saavagebueno added the triage-needed label 2025-11-20 07:08:28 -05:00
saavagebueno commented 2025-11-20 07:08:29 -05:00
Author
Owner
Copy Link

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

@carefreecaribou what is the group membership of the peers?

@lixmal commented on GitHub (Oct 10, 2025): @carefreecaribou what is the group membership of the peers?
saavagebueno commented 2025-11-20 07:08:29 -05:00
Author
Owner
Copy Link

@Blackclaws commented on GitHub (Oct 10, 2025):

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 commented on GitHub (Oct 10, 2025): 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.
saavagebueno commented 2025-11-20 07:08:30 -05:00
Author
Owner
Copy Link

@Blackclaws commented on GitHub (Oct 10, 2025):

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.

@Blackclaws commented on GitHub (Oct 10, 2025): 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.
saavagebueno commented 2025-11-20 07:08:30 -05:00
Author
Owner
Copy Link

@carefreecaribou commented on GitHub (Oct 10, 2025):

@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:

Image

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.

Image

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.

Image

@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.

Image Image

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:

Image

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.

Image

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

@carefreecaribou commented on GitHub (Oct 10, 2025): > [@carefreecaribou](https://github.com/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: <img width="1355" height="249" alt="Image" src="https://github.com/user-attachments/assets/02b3ad87-916b-46d4-9860-2fa5c58ebe77" /> 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. <img width="1815" height="688" alt="Image" src="https://github.com/user-attachments/assets/d8d9f778-cfab-41a2-9a02-078abb021308" /> > 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. <img width="1183" height="1275" alt="Image" src="https://github.com/user-attachments/assets/cd8cbc5d-f786-4f00-aeb2-00ff9f1b75e1" /> @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. <img width="916" height="68" alt="Image" src="https://github.com/user-attachments/assets/d36ae88e-dbb2-4f47-a37d-ddb3a423c1b9" /> <img width="1957" height="71" alt="Image" src="https://github.com/user-attachments/assets/43d83f14-b304-467b-b53f-2af82ac1a4f9" /> 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: <img width="593" height="295" alt="Image" src="https://github.com/user-attachments/assets/df605978-bcc6-48d6-9779-2210adee9a72" /> >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. <img width="1163" height="1093" alt="Image" src="https://github.com/user-attachments/assets/138c8369-c2da-4697-9b4f-ba6d4ebc97f9" /> I will be testing other access methods besides just ping shortly to verify whether its "ALL" traffic or only ping traffic.
saavagebueno commented 2025-11-20 07:08:30 -05:00
Author
Owner
Copy Link

@carefreecaribou commented on GitHub (Oct 10, 2025):

@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.

Image

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 commented on GitHub (Oct 10, 2025): @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. <img width="567" height="73" alt="Image" src="https://github.com/user-attachments/assets/255a3e9a-bcb2-45a0-9047-7e9ccf362830" /> > 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
saavagebueno commented 2025-11-20 07:08:30 -05:00
Author
Owner
Copy Link

@carefreecaribou commented on GitHub (Oct 10, 2025):

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.

@carefreecaribou commented on GitHub (Oct 10, 2025): 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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
2021 Q4
2022 Q1
2022 Q1
accessibility
acl
agent
agent
Android
Android
api
authentik
automation
azure
battery-usage
bug
cache
client
client-ui
cloud
cloud-only
cloudflare
community
compatibility
config-idp
config-issue
connection
contribution
coturn
cross-vpn
dashboard
data-usage
distribution
dns
docker
documentation
duplicate
enhancement
enhancement
event-stream
feature-request
freebsd
getting-started
go
good first issue
gui
help wanted
home-assistant
idp
inconsistency
integration
integrations
ios
ipv6
jwt
k8s
keycloak
linux
login
macos
management-service
missing-docs
mobile
moved-internal
needs-review
netbird-ui
networking
new-platform
nginx
notification
okta
openwrt
packaging
peer-management
peer-management
peer-management
performance
postgres
posture-checks
psk
pull-request
Mirrored from GitHub Pull Request
 question
refactor
relay
release
rfc
routes
security
security-related
self-hosting
server
signal
sleep-issue
ssh
ssl
status
store
synology
system-compatibility-issue
test-suite
third-party-integration
triage
triage-needed
troubleshooting
UX
waiting-feedback
windows
wontfix
zitadel
No Label triage-needed
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
saavagebueno
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: SVI/netbird#2357
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?