SVI/netbird
1
0
Fork 0
mirror of https://github.com/netbirdio/netbird.git synced 2026-08-01 10:28:39 -04:00
Code Issues 3.0k Packages Projects Releases 10 Wiki Activity

Disparity between policies, control centre view and what happens in the real world. #2382

New Issue
Open
opened 2025-11-20 07:08:59 -05:00 by saavagebueno · 1 comment
saavagebueno commented 2025-11-20 07:08:59 -05:00
Owner
Copy Link

Originally created by @NABarnes on GitHub (Oct 17, 2025).

Describe the problem

There are three areas policies are documented:
1 - The pages at https://docs.netbird.io/how-to/manage-network-access
2 - The views shown in the control centre
3 - What actually happens on a live network

The documentation states that: "For ICMP and ALL protocols, as well as for TCP and UDP protocols without specific port restrictions, communication between groups listed in the source and destination fields is bidirectional.". This is not true. ICMP and TCP/UDP without port restrictions can be configured as unidirectional and this works unidirectionally where there is not a group in common between the peers.

The documentation states that: "If you need to allow peers from the same group to communicate with each other, you can do so by adding the same group to the Source and Destination lists.". The examples below show that this is not the case.

The views shown in the control centre confirm the two points above - they show unidirectional connections and ICMP working. The view in the control centre mirrors my expectation of how the policies work and what should happen in the real world. I would say that the control centre view is 'correct' and the documentation and what actually happens is incorrect.

There are problems in implementing the policies and what you end up with is sometimes very different from what the control centre shows should happen.

To Reproduce

Create peers:

name group(s)
nbtest01 AAAA
nbtest02 AAAA
nbtest03 AAAA, BBBB
nbtest04 BBBB

Create policies:

ID Source Direction Destination Protocol Port
1 AAAA --> BBBB TCP 22
2 AAAA <--> AAAA TCP 22
3 All <--> All TCP 22
4 nbtest01 --> 1 nbtest02 TCP 22
5 AAAA --> All ALL ALL
6 nbtest01 --> BBBB TCP 22
7 nbtest01 --> BBBB ALL ALL

Then, from the terminal on nbtest01 try to SSH into the other peers:

Destination Result Expected result Policy rules that should allow
nbtest02 Fail Success 2, 3, 4, 5
nbtest03 Fail Success 1, 2, 3, 5, 6, 7
nbtest04 Success Success 1, 3, 5, 6, 7

And from the terminal on nbtest03:

Destination Result Expected result Policy rules that should allow
nbtest01 Fail Success 2, 3, 5
nbtest02 Fail Success 2, 3, 5
nbtest04 Success Success 1, 2, 3, 5

And from the terminal on nbtest04:

Destination Result Expected result Policy rules that should allow
nbtest01 Fail Success 3
nbtest02 Fail Success 3
nbtest03 Fail Success 3

The control centre indicates that the fails, above, should be successes (see screenshots below).

If I add the following policy:

ID Source Direction Destination Protocol Port
8 All <--> All ALL ALL

Then the results of nbtest01 SSHing to the other peers are:

Destination Result Expected result Policy rules that should allow
nbtest02 Success Success 2, 3, 4, 5, 8
nbtest03 Success Success 1, 2, 3, 5, 6, 7, 8
nbtest04 Success Success 1, 3, 5, 6, 7, 8

This is clearly broken!

Expected behavior

See tables above.

Are you using NetBird Cloud?

Yes

NetBird version

Client: 0.59.6

Is any other VPN software installed?

No.

Debug output

To help us resolve the problem, please attach the following anonymized status output

netbird status -dA

nb-status-01.txt
nb-status-02.txt
nb-status-03.txt
nb-status-04.txt

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

netbird debug for 1m -AS -U

Uploaded files are automatically deleted after 30 days.

f79e391890ab27fb37c88b3b4be7011e22aa2e5ca6f38ffa9c4481884941f726/599a4b23-4192-4516-b816-8b7b80e56607

f79e391890ab27fb37c88b3b4be7011e22aa2e5ca6f38ffa9c4481884941f726/e03da432-3714-466b-bd84-68bb5f355808

f79e391890ab27fb37c88b3b4be7011e22aa2e5ca6f38ffa9c4481884941f726/c6482087-0366-4780-9db5-e723477b3657

f79e391890ab27fb37c88b3b4be7011e22aa2e5ca6f38ffa9c4481884941f726/32663ace-75c1-4a48-a50d-224c14332481

Screenshots

Image Image Image Image

Additional context

Add any other context about the problem here.

Have you tried these troubleshooting steps?

  • [Y] Reviewed client troubleshooting (if applicable)
  • [Y] Checked for newer NetBird versions
  • [Y] Searched for similar issues on GitHub (including closed ones)
  • [Y] Restarted the NetBird client
  • [N/A] Disabled other VPN software
  • [N/A]2 Checked firewall settings

  1. This is shown on the dashboard as "-->" and on the policy definition window as "<-->" ↩︎

  2. No firewall installed on test machines. ↩︎

Originally created by @NABarnes on GitHub (Oct 17, 2025). **Describe the problem** There are three areas policies are documented: 1 - The pages at https://docs.netbird.io/how-to/manage-network-access 2 - The views shown in the control centre 3 - What actually happens on a live network The documentation states that: "For ICMP and ALL protocols, as well as for TCP and UDP protocols without specific port restrictions, communication between groups listed in the source and destination fields is bidirectional.". This is not true. ICMP and TCP/UDP without port restrictions can be configured as unidirectional and this works unidirectionally where there is not a group in common between the peers. The documentation states that: "If you need to allow peers from the same group to communicate with each other, you can do so by adding the same group to the Source and Destination lists.". The examples below show that this is not the case. The views shown in the control centre confirm the two points above - they show unidirectional connections and ICMP working. The view in the control centre mirrors my expectation of how the policies work and what should happen in the real world. I would say that the control centre view is 'correct' and the documentation and what actually happens is incorrect. There are problems in implementing the policies and what you end up with is sometimes very different from what the control centre shows should happen. **To Reproduce** Create peers: | name | group(s) | |-|-| | nbtest01 | AAAA | | nbtest02 | AAAA | | nbtest03 | AAAA, BBBB | | nbtest04 | BBBB | Create policies: | ID | Source | Direction | Destination | Protocol | Port | | - | - | - | - | - | - | | 1 | AAAA | --> | BBBB | TCP | 22 | | 2 | AAAA | <--> | AAAA | TCP | 22 | | 3 | All | <--> | All | TCP | 22 | | 4 | nbtest01 | --> [^1] | nbtest02 | TCP | 22 | | 5 | AAAA | --> | All | ALL | ALL | | 6 | nbtest01 | --> | BBBB | TCP | 22 | | 7 | nbtest01 | --> | BBBB | ALL | ALL | [^1]: This is shown on the dashboard as "-->" and on the policy definition window as "<-->" Then, from the terminal on nbtest01 try to SSH into the other peers: | Destination | Result | Expected result | Policy rules that should allow | | - | - | - | - | | nbtest02 | Fail | Success | 2, 3, 4, 5 | | nbtest03 | Fail | Success | 1, 2, 3, 5, 6, 7 | | nbtest04 | Success | Success | 1, 3, 5, 6, 7 | And from the terminal on nbtest03: | Destination | Result | Expected result | Policy rules that should allow | | - | - | - | - | | nbtest01 | Fail | Success | 2, 3, 5 | | nbtest02 | Fail | Success | 2, 3, 5 | | nbtest04 | Success | Success | 1, 2, 3, 5 | And from the terminal on nbtest04: | Destination | Result | Expected result | Policy rules that should allow | | - | - | - | - | | nbtest01 | Fail | Success | 3 | | nbtest02 | Fail | Success | 3 | | nbtest03 | Fail | Success | 3 | The control centre indicates that the fails, above, should be successes (see screenshots below). If I add the following policy: | ID | Source | Direction | Destination | Protocol | Port | | - | - | - | - | - | - | | 8 | All | <--> | All | ALL | ALL | Then the results of nbtest01 SSHing to the other peers are: | Destination | Result | Expected result | Policy rules that should allow | | - | - | - | - | | nbtest02 | Success | Success | 2, 3, 4, 5, 8 | | nbtest03 | Success | Success | 1, 2, 3, 5, 6, 7, 8 | | nbtest04 | Success | Success | 1, 3, 5, 6, 7, 8 | This is clearly broken! **Expected behavior** See tables above. **Are you using NetBird Cloud?** Yes **NetBird version** Client: 0.59.6 **Is any other VPN software installed?** No. **Debug output** To help us resolve the problem, please attach the following anonymized status output netbird status -dA [nb-status-01.txt](https://github.com/user-attachments/files/22966377/nb-status-01.txt) [nb-status-02.txt](https://github.com/user-attachments/files/22966379/nb-status-02.txt) [nb-status-03.txt](https://github.com/user-attachments/files/22966376/nb-status-03.txt) [nb-status-04.txt](https://github.com/user-attachments/files/22966378/nb-status-04.txt) Create and upload a debug bundle, and share the returned file key: netbird debug for 1m -AS -U *Uploaded files are automatically deleted after 30 days.* f79e391890ab27fb37c88b3b4be7011e22aa2e5ca6f38ffa9c4481884941f726/599a4b23-4192-4516-b816-8b7b80e56607 f79e391890ab27fb37c88b3b4be7011e22aa2e5ca6f38ffa9c4481884941f726/e03da432-3714-466b-bd84-68bb5f355808 f79e391890ab27fb37c88b3b4be7011e22aa2e5ca6f38ffa9c4481884941f726/c6482087-0366-4780-9db5-e723477b3657 f79e391890ab27fb37c88b3b4be7011e22aa2e5ca6f38ffa9c4481884941f726/32663ace-75c1-4a48-a50d-224c14332481 **Screenshots** <img width="1385" height="402" alt="Image" src="https://github.com/user-attachments/assets/eb88f0fb-98c1-488a-8a76-16180281f7d6" /> <img width="1061" height="588" alt="Image" src="https://github.com/user-attachments/assets/7fd3108b-784a-423f-81a7-39eb44236928" /> <img width="979" height="278" alt="Image" src="https://github.com/user-attachments/assets/db3bc36f-e264-476d-8b72-87ed48b541bd" /> <img width="973" height="117" alt="Image" src="https://github.com/user-attachments/assets/86735686-7123-4290-92ee-ce12e2926792" /> **Additional context** Add any other context about the problem here. **Have you tried these troubleshooting steps?** - [Y] Reviewed [client troubleshooting](https://docs.netbird.io/how-to/troubleshooting-client) (if applicable) - [Y] Checked for newer NetBird versions - [Y] Searched for similar issues on GitHub (including closed ones) - [Y] Restarted the NetBird client - [N/A] Disabled other VPN software - [N/A][^2] Checked firewall settings [^2]: No firewall installed on test machines.
saavagebueno added the triage-needed label 2025-11-20 07:08:59 -05:00
saavagebueno commented 2025-11-20 07:09:00 -05:00
Author
Owner
Copy Link

@NABarnes commented on GitHub (Oct 17, 2025):

I should add that the same problem exists in the self-hosted version.

@NABarnes commented on GitHub (Oct 17, 2025): I should add that the same problem exists in the self-hosted version.
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#2382
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?