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

Policies seem to be applied incorrectly #1421

New Issue
Closed
opened 2025-11-20 05:30:01 -05:00 by saavagebueno · 5 comments
saavagebueno commented 2025-11-20 05:30:01 -05:00
Owner
Copy Link

Originally created by @aksdb on GitHub (Nov 17, 2024).

Describe the problem

Policies seem to be applied incorrectly.

To Reproduce

  1. Add group "trusted".
  2. Add two peers.
  3. Add peer2 into group "trusted".
  4. Change default policy to allow "Source: trusted" to "Destination: all".

Expected behavior

Peer2 can ssh into Peer1, since Peer2 is "trusted".
Peer1 cannot ssh into Peer2, since Peer1 is not "trusted".

Actual behavior

Peer1 can ssh into Peer2, allowing it to evade the security policy.

Are you using NetBird Cloud?

Cloud.

NetBird version

0.32.0

Originally created by @aksdb on GitHub (Nov 17, 2024). **Describe the problem** Policies seem to be applied incorrectly. **To Reproduce** 1. Add group "trusted". 2. Add two peers. 3. Add peer2 into group "trusted". 4. Change default policy to allow "Source: trusted" to "Destination: all". **Expected behavior** Peer2 can ssh into Peer1, since Peer2 is "trusted". Peer1 cannot ssh into Peer2, since Peer1 is *not* "trusted". **Actual behavior** Peer1 can ssh into Peer2, allowing it to evade the security policy. **Are you using NetBird Cloud?** Cloud. **NetBird version** 0.32.0
saavagebueno added the peer-managementtriage-needed labels 2025-11-20 05:30:01 -05:00
saavagebueno commented 2025-11-20 05:30:02 -05:00
Author
Owner
Copy Link

@mgarces commented on GitHub (Nov 18, 2024):

Hi @aksdb ; I've tested with your exact scenario, and I can't replicate this. Can you please share all your policies?

@mgarces commented on GitHub (Nov 18, 2024): Hi @aksdb ; I've tested with your exact scenario, and I can't replicate this. Can you please share all your policies?
saavagebueno commented 2025-11-20 05:30:02 -05:00
Author
Owner
Copy Link

@aksdb commented on GitHub (Nov 18, 2024):

@mgarces It's actually just the (modified) default policy. I attached a few screenshots and commandline output:

The clients

image

Peer 1 is in groups All and Trusted
Peer 2 is in groups All and Servers

The policy

image

On Peer 1 (All, Trusted)

$ netbird status
OS: linux/amd64
Daemon version: 0.32.0
CLI version: 0.32.0
Management: Connected
Signal: Connected
Relays: 3/3 Available
Nameservers: 1/1 Available
FQDN: ******.netbird.cloud
NetBird IP: 100.93.45.255/16
Interface type: Kernel
Quantum resistance: false
Routes: -
Peers count: 1/2 Connected

$ ssh 100.93.120.99
The authenticity of host '100.93.120.99 (100.93.120.99)' can't be established.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Connection works. As expected (from Trusted to All).

On Peer 2 (All, Servers)

$ netbird status
OS: linux/amd64
Daemon version: 0.32.0
CLI version: 0.32.0
Management: Connected
Signal: Connected
Relays: 3/3 Available
Nameservers: 0/0 Available
FQDN: ******.netbird.cloud
NetBird IP: 100.93.120.99/16
Interface type: Kernel
Quantum resistance: false
Routes: -
Peers count: 1/2 Connected

$ ssh 100.93.45.255
The authenticity of host '100.93.45.255 (100.93.45.255)' can't be established.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Connection works. That is not expected, since that direction of traffic is not allowed.

With the (only) policy disabled

image

$ ssh 100.93.45.255
ssh: connect to host 100.93.45.255 port 22: Connection timed out

When turning off the default policy, traffic indeed is blocked. So there isn't any other route besides this one rule.

@aksdb commented on GitHub (Nov 18, 2024): @mgarces It's actually just the (modified) default policy. I attached a few screenshots and commandline output: ## The clients ![image](https://github.com/user-attachments/assets/58f815de-e9cd-4373-a1df-15baab5c7630) Peer 1 is in groups All and Trusted Peer 2 is in groups All and Servers ## The policy ![image](https://github.com/user-attachments/assets/54726a96-cf90-4228-a545-fcc6edd1c22f) ## On Peer 1 (All, Trusted) ``` $ netbird status OS: linux/amd64 Daemon version: 0.32.0 CLI version: 0.32.0 Management: Connected Signal: Connected Relays: 3/3 Available Nameservers: 1/1 Available FQDN: ******.netbird.cloud NetBird IP: 100.93.45.255/16 Interface type: Kernel Quantum resistance: false Routes: - Peers count: 1/2 Connected $ ssh 100.93.120.99 The authenticity of host '100.93.120.99 (100.93.120.99)' can't be established. Are you sure you want to continue connecting (yes/no/[fingerprint])? ``` Connection works. As expected (from Trusted to All). ## On Peer 2 (All, Servers) ``` $ netbird status OS: linux/amd64 Daemon version: 0.32.0 CLI version: 0.32.0 Management: Connected Signal: Connected Relays: 3/3 Available Nameservers: 0/0 Available FQDN: ******.netbird.cloud NetBird IP: 100.93.120.99/16 Interface type: Kernel Quantum resistance: false Routes: - Peers count: 1/2 Connected $ ssh 100.93.45.255 The authenticity of host '100.93.45.255 (100.93.45.255)' can't be established. Are you sure you want to continue connecting (yes/no/[fingerprint])? ``` Connection works. That is **not** expected, since that direction of traffic is not allowed. ## With the (only) policy disabled ![image](https://github.com/user-attachments/assets/e4ef07d1-5754-4791-b520-217873035962) ``` $ ssh 100.93.45.255 ssh: connect to host 100.93.45.255 port 22: Connection timed out ``` When turning off the default policy, traffic indeed is blocked. So there isn't any other route besides this one rule.
saavagebueno commented 2025-11-20 05:30:02 -05:00
Author
Owner
Copy Link

@lixmal commented on GitHub (Nov 18, 2024):

Hi @aksdb,

the policy is bidirectional as indicated by the arrows. If you want unidirectional access, you must select tcp/udp and specific ports.

@lixmal commented on GitHub (Nov 18, 2024): Hi @aksdb, the policy is bidirectional as indicated by the arrows. If you want unidirectional access, you must select tcp/udp and specific ports.
saavagebueno commented 2025-11-20 05:30:03 -05:00
Author
Owner
Copy Link

@aksdb commented on GitHub (Nov 18, 2024):

@lixmal I'll give that a shot. I interpreted the directions as to allow the destination to respond. My expectation was, that "source" specifies who initiates a connection and "destination" who you can connect to.

@aksdb commented on GitHub (Nov 18, 2024): @lixmal I'll give that a shot. I interpreted the directions as to allow the destination to respond. My expectation was, that "source" specifies who initiates a connection and "destination" who you can connect to.
saavagebueno commented 2025-11-20 05:30:03 -05:00
Author
Owner
Copy Link

@aksdb commented on GitHub (Nov 18, 2024):

Yup, that was it. Unfortunately now I need to specify all ports I am interested in vs. saying "trusted devices can access everything (without being exposed themselves)". But I guess that's rather a feature request now and not a bug. Thanks for clarifying!

@aksdb commented on GitHub (Nov 18, 2024): Yup, that was it. Unfortunately now I need to specify all ports I am interested in vs. saying "trusted devices can access everything (without being exposed themselves)". But I guess that's rather a feature request now and not a bug. Thanks for clarifying!
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 peer-management 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#1421
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?