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

How can I separate peers from each other? #1713

New Issue
Open
opened 2025-11-20 06:05:12 -05:00 by saavagebueno · 13 comments
saavagebueno commented 2025-11-20 06:05:12 -05:00
Owner
Copy Link

Originally created by @netandreus on GitHub (Mar 15, 2025).

I have a self-hosted NetBird installation with peers with different roles:

  • nodes, which provide routes for one or more local networks
  • server peers
  • end user peers

But the problem now is that every peer can see all other peers. What I tried to do:

  • disable default "All" Access policy
  • create Access Policies for nodes (all peers can see nodes)

But at the same time all peers can see all. How can I fix it?

Originally created by @netandreus on GitHub (Mar 15, 2025). I have a self-hosted NetBird installation with peers with different roles: - nodes, which provide routes for one or more local networks - server peers - end user peers But the problem now is that every peer can see all other peers. What I tried to do: - disable default "All" Access policy - create Access Policies for nodes (all peers can see nodes) But at the same time all peers can see all. How can I fix it?
saavagebueno added the Android label 2025-11-20 06:05:12 -05:00
saavagebueno commented 2025-11-20 06:05:13 -05:00
Author
Owner
Copy Link

@gerwim commented on GitHub (Mar 17, 2025):

If you mean the peers list should only show peers where you should have access to: I agree.

Based on the access control list, the clients should know with which peers they should be connect and don't try to make any connection to those which they are not allowed to access.

I think this will also reduce the data usage as per https://github.com/netbirdio/netbird/issues/3427.

@gerwim commented on GitHub (Mar 17, 2025): If you mean the peers list should only show peers where you should have access to: I agree. Based on the access control list, the clients should know with which peers they should be connect and don't try to make any connection to those which they are not allowed to access. I think this will also reduce the data usage as per https://github.com/netbirdio/netbird/issues/3427.
saavagebueno commented 2025-11-20 06:05:13 -05:00
Author
Owner
Copy Link

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

Is this related purely to the mobile clients?

I'm seeing the list gets filtered by ACLs properly on non-mobile devices (OpenWRT, Ubuntu etc.)

I don't think we can stop the clients from seeing all other peers (I'm pretty sure this was a design decision), but this does not mean they are accessible.

@nazarewk commented on GitHub (Mar 17, 2025): Is this related purely to the mobile clients? I'm seeing the list gets filtered by ACLs properly on non-mobile devices (OpenWRT, Ubuntu etc.) I don't think we can stop the clients from seeing all other peers (I'm pretty sure this was a design decision), but this does not mean they are accessible.
saavagebueno commented 2025-11-20 06:05:13 -05:00
Author
Owner
Copy Link

@gerwim commented on GitHub (Mar 17, 2025):

I have just checked: this seems to be only happening on Android. On my iPhone, the peers get correctly filtered out. On my Mac, the same. On Android however, I can see all peers.

@gerwim commented on GitHub (Mar 17, 2025): I have just checked: this seems to be only happening on Android. On my iPhone, the peers get correctly filtered out. On my Mac, the same. On Android however, I can see all peers.
saavagebueno commented 2025-11-20 06:05:13 -05:00
Author
Owner
Copy Link

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

@gerwim I just checked in MacOS.

Image

I disabled ALL <-> Rules but all my nodes still can see all nodes. But only Elk, NS1 and GitLab should be visible by All nodes. It doesn't working as it should be.

@netandreus commented on GitHub (Mar 18, 2025): @gerwim I just checked in MacOS. <img width="1412" alt="Image" src="https://github.com/user-attachments/assets/b5dceea1-b691-443f-b132-19ea21db0234" /> I disabled ```ALL <-> Rules``` but all my nodes still can see all nodes. But only Elk, NS1 and GitLab should be visible by All nodes. It doesn't working as it should be.
saavagebueno commented 2025-11-20 06:05:14 -05:00
Author
Owner
Copy Link

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

@pappz may be you can suggest something? Or I'm doing something wrong?

@netandreus commented on GitHub (Mar 18, 2025): @pappz may be you can suggest something? Or I'm doing something wrong?
saavagebueno commented 2025-11-20 06:05:14 -05:00
Author
Owner
Copy Link

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

@netandreus
Could you prepare a group policy setup with three peers (just for testing to easier to understand the network map)? Configure it so two peers can see each other, while the third peer cannot see the others. Please run the netbird debug bundle -S command on the peer that should not see the other peers."
And please create screenshots about the relevant settings just like in your previous comment.

@pappz commented on GitHub (Mar 18, 2025): @netandreus Could you prepare a group policy setup with three peers (just for testing to easier to understand the network map)? Configure it so two peers can see each other, while the third peer cannot see the others. Please run the `netbird debug bundle -S` command on the peer that should not see the other peers." And please create screenshots about the relevant settings just like in your previous comment.
saavagebueno commented 2025-11-20 06:05:14 -05:00
Author
Owner
Copy Link

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

@pappz What does "can still see all nodes" mean?

Your output for netbird status -d should also show the nodes allowed (atleast, this happens on MacOS). I'm running selfhosted version 0.38.2 and use the same version for my clients.

When I disable all access policies, there are 0 nodes to connect to (see last line):

➜  ~ netbird status -d
Peers detail:
Events:
  [INFO] SYSTEM (0d12a93d-fc69-4472-a361-1fe7bef1098a)
    Message: Network map updated
    Time: 31 minutes, 53 seconds ago
  [INFO] SYSTEM (fee74587-5c64-406a-8834-1ff61bd9ff23)
    Message: Network map updated
    Time: 31 minutes, 9 seconds ago
  [INFO] SYSTEM (97c1cf09-2a91-4c53-ae8d-cffcc24c314a)
    Message: Network map updated
    Time: 31 minutes, 7 seconds ago
  [INFO] SYSTEM (4013dfd8-e611-4f03-84f0-092b8d99cdbf)
    Message: Network map updated
    Time: 30 minutes, 56 seconds ago
  [INFO] SYSTEM (64d785b6-7e29-41e8-a0ff-4a4c8cc6e065)
    Message: Network map updated
    Time: 3 minutes, 48 seconds ago
  [INFO] SYSTEM (be7d5dd8-3604-4771-8cab-1d51252fcfbb)
    Message: Network map updated
    Time: 3 minutes, 37 seconds ago
  [INFO] SYSTEM (6d3c05ef-3d15-4369-90e3-0464207e75c1)
    Message: Network map updated
    Time: 3 minutes, 36 seconds ago
  [INFO] SYSTEM (e688a579-52f5-44de-81db-e7530ec594ec)
    Message: Network map updated
    Time: 1 minute, 43 seconds ago
  [INFO] SYSTEM (3451daab-3236-4344-925c-15a03cf9466c)
    Message: Network map updated
    Time: 1 minute, 30 seconds ago
  [INFO] SYSTEM (c22f9215-675c-4084-bfb0-fd596ddaafb2)
    Message: Network map updated
    Time: Now
OS: darwin/arm64
Daemon version: 0.38.2
CLI version: 0.38.2
Management: Connected to https://xxxxxx:443
Signal: Connected to https://xxxxxxx:443
Relays:
  [stun:xxxxxl:3478] is Available
  [turn:xxxxxx:3478?transport=udp] is Available
  [rels://xxxxx:443] is Available
Nameservers:
FQDN: yyyyy
NetBird IP: 100.99.6.71/16
Interface type: Userspace
Quantum resistance: false
Networks: -
Forwarding rules: 0
Peers count: 0/0 Connected <---- no peers
@gerwim commented on GitHub (Mar 18, 2025): @pappz What does "can still see all nodes" mean? Your output for `netbird status -d` should also show the nodes allowed (atleast, this happens on MacOS). I'm running selfhosted version 0.38.2 and use the same version for my clients. When I disable all access policies, there are 0 nodes to connect to (see last line): ``` ➜ ~ netbird status -d Peers detail: Events: [INFO] SYSTEM (0d12a93d-fc69-4472-a361-1fe7bef1098a) Message: Network map updated Time: 31 minutes, 53 seconds ago [INFO] SYSTEM (fee74587-5c64-406a-8834-1ff61bd9ff23) Message: Network map updated Time: 31 minutes, 9 seconds ago [INFO] SYSTEM (97c1cf09-2a91-4c53-ae8d-cffcc24c314a) Message: Network map updated Time: 31 minutes, 7 seconds ago [INFO] SYSTEM (4013dfd8-e611-4f03-84f0-092b8d99cdbf) Message: Network map updated Time: 30 minutes, 56 seconds ago [INFO] SYSTEM (64d785b6-7e29-41e8-a0ff-4a4c8cc6e065) Message: Network map updated Time: 3 minutes, 48 seconds ago [INFO] SYSTEM (be7d5dd8-3604-4771-8cab-1d51252fcfbb) Message: Network map updated Time: 3 minutes, 37 seconds ago [INFO] SYSTEM (6d3c05ef-3d15-4369-90e3-0464207e75c1) Message: Network map updated Time: 3 minutes, 36 seconds ago [INFO] SYSTEM (e688a579-52f5-44de-81db-e7530ec594ec) Message: Network map updated Time: 1 minute, 43 seconds ago [INFO] SYSTEM (3451daab-3236-4344-925c-15a03cf9466c) Message: Network map updated Time: 1 minute, 30 seconds ago [INFO] SYSTEM (c22f9215-675c-4084-bfb0-fd596ddaafb2) Message: Network map updated Time: Now OS: darwin/arm64 Daemon version: 0.38.2 CLI version: 0.38.2 Management: Connected to https://xxxxxx:443 Signal: Connected to https://xxxxxxx:443 Relays: [stun:xxxxxl:3478] is Available [turn:xxxxxx:3478?transport=udp] is Available [rels://xxxxx:443] is Available Nameservers: FQDN: yyyyy NetBird IP: 100.99.6.71/16 Interface type: Userspace Quantum resistance: false Networks: - Forwarding rules: 0 Peers count: 0/0 Connected <---- no peers ```
saavagebueno commented 2025-11-20 06:05:14 -05:00
Author
Owner
Copy Link

@netandreus commented on GitHub (Mar 21, 2025):

I think problem can be using All group at the one side of relation. I will try to make separated groups and avoid using All group.

@netandreus commented on GitHub (Mar 21, 2025): I think problem can be using ```All``` group at the one side of relation. I will try to make separated groups and avoid using ```All``` group.
saavagebueno commented 2025-11-20 06:05:14 -05:00
Author
Owner
Copy Link

@netandreus commented on GitHub (Mar 26, 2025):

Yes, I can confirm the problem.

Problem:
If there is at least one Policy where group All is in the one side of relation, all nodes can see all nodes.
This error occurs not only in Android. I can confirm it in MacOS at NetBird 0.37.1

Workaround:
Workaround is to avoid to use All in any network policy.

But I think, it should be fixed generally.

@netandreus commented on GitHub (Mar 26, 2025): Yes, I can confirm the problem. **Problem:** If there is at least one Policy where group ```All``` is in the one side of relation, all nodes can see all nodes. This error occurs not only in Android. I can confirm it in MacOS at NetBird 0.37.1 **Workaround:** Workaround is to avoid to use ```All``` in any network policy. But I think, it should be fixed generally.
saavagebueno commented 2025-11-20 06:05:14 -05:00
Author
Owner
Copy Link

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

Problem: If there is at least one Policy where group All is in the one side of relation, all nodes can see all nodes. This error occurs not only in Android. I can confirm it in MacOS at NetBird 0.37.1

This is working exactly as designed, Peers will establish internal communication as soon as it is allowed by ACLs. Having a bidirectional rule with All participating will make every peer try to connect to every other peer.

Note this is just an internal connectivity estabilshment and completely independent of accepting (or denying) traffic to flow between peers.

@nazarewk commented on GitHub (Mar 27, 2025): > **Problem:** If there is at least one Policy where group `All` is in the one side of relation, all nodes can see all nodes. This error occurs not only in Android. I can confirm it in MacOS at NetBird 0.37.1 This is working *exactly* as designed, Peers will establish internal communication as soon as it is allowed by ACLs. Having a bidirectional rule with `All` participating will make every peer try to connect to every other peer. Note this is just an internal connectivity estabilshment and completely independent of accepting (or denying) traffic to flow between peers.
saavagebueno commented 2025-11-20 06:05:15 -05:00
Author
Owner
Copy Link

@netandreus commented on GitHub (Mar 30, 2025):

Having a bidirectional rule with All participating will make every peer try to connect to every other peer.

@nazarewk Even if "All" is mentioned only on one side? Not on both sides.

Note this is just an internal connectivity estabilshment and completely independent of accepting (or denying) traffic to flow between peers.

Ok, but I don't want all the peers to see each other.

@netandreus commented on GitHub (Mar 30, 2025): > Having a bidirectional rule with All participating will make every peer try to connect to every other peer. @nazarewk Even if "All" is mentioned only on one side? Not on both sides. > Note this is just an internal connectivity estabilshment and completely independent of accepting (or denying) traffic to flow between peers. Ok, but I don't want all the peers to see each other.
saavagebueno commented 2025-11-20 06:05:15 -05:00
Author
Owner
Copy Link

@nazarewk commented on GitHub (Apr 1, 2025):

Even if "All" is mentioned only on one side? Not on both sides.

I did not test, but you should be able to create uni-directional rule from X to All on specific TCP/UDP ports, then everything would be connected to X, but not to Y & Z.

As soon as you create a bidirectional rule with All, it will not be able to distinguish who exactly you mean (you have chosen All) to connect with and will establish a full mesh.

@nazarewk commented on GitHub (Apr 1, 2025): > Even if "All" is mentioned only on one side? Not on both sides. I did not test, but you should be able to create uni-directional rule from `X` to `All` on specific TCP/UDP ports, then everything would be connected to `X`, but not to `Y` & `Z`. As soon as you create a bidirectional rule with `All`, it will not be able to distinguish who exactly you mean (you have chosen `All`) to connect with and will establish a full mesh.
saavagebueno commented 2025-11-20 06:05:15 -05:00
Author
Owner
Copy Link

@nazarewk commented on GitHub (Apr 1, 2025):

FYI: adding a Network Resource access without granting explicit access to the Routing Peer also makes the client establish internal connectivity to the Routing Peer even though it's not explicitly mentioned in any ACLrule.

@nazarewk commented on GitHub (Apr 1, 2025): FYI: adding a Network Resource access without granting explicit access to the Routing Peer also makes the client establish internal connectivity to the Routing Peer even though it's not explicitly mentioned in any ACLrule.
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 Android
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#1713
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?