SVI/netbird
1
0
Fork 0
mirror of https://github.com/netbirdio/netbird.git synced 2026-05-13 11:41:58 -04:00
Code Issues 3.0k Packages Projects Releases 10 Wiki Activity

Access control policies don't work #713

New Issue
Closed
opened 2025-11-20 05:16:22 -05:00 by saavagebueno · 9 comments
saavagebueno commented 2025-11-20 05:16:22 -05:00
Owner
Copy Link

Originally created by @sisumara on GitHub (Mar 15, 2024).

Describe the problem

Today I've deployed a new setup which has separated IDP based on Zitadel and Netbird which I've configured using advanced configuration guide. I have one server in a cloud which has docker installation with couple of services and netbird agent installed in the same network with docker services. I've deleted default access policy rule and added custom one, which allows the only UDP traffic.
Screenshot 2024-03-15 at 4 54 41 PM
I've added a new route with peer and the docker network.
Screenshot 2024-03-15 at 4 56 58 PM

And traffic began to flow from User peer to OracleDC peer, but not the traffic which is limited by the access policy rule, but any traffic. So, in this case I allowed the only UDP traffic, but I can ping hosts in remote network and access to the services on 80,443/tcp ports.

To Reproduce

Steps to reproduce the behavior:

  1. Deploy a new service
  2. Add some peers to different groups.
  3. Create network route which sits behind one of the peers.
  4. Delete default access policy and create a new one which limits the access to the peers with network routes.
  5. Feel free to access to any resources in the route without limitations of created access policy.

Expected behavior

Limited traffic according to created Access Policy.

Are you using NetBird Cloud?

self-host NetBird's control plane.

NetBird version

0.26.3

Thank you

Originally created by @sisumara on GitHub (Mar 15, 2024). **Describe the problem** Today I've deployed a new setup which has separated IDP based on Zitadel and Netbird which I've configured using advanced configuration guide. I have one server in a cloud which has docker installation with couple of services and netbird agent installed in the same network with docker services. I've deleted default access policy rule and added custom one, which allows the only UDP traffic. <img width="1496" alt="Screenshot 2024-03-15 at 4 54 41 PM" src="https://github.com/netbirdio/netbird/assets/61536902/1ae572f8-dc72-4b31-af60-d7770dd0f66c"> I've added a new route with peer and the docker network. <img width="1496" alt="Screenshot 2024-03-15 at 4 56 58 PM" src="https://github.com/netbirdio/netbird/assets/61536902/0efa39b5-7852-466b-9b54-f91d4c5d05fe"> And traffic began to flow from User peer to OracleDC peer, but not the traffic which is limited by the access policy rule, but any traffic. So, in this case I allowed the only UDP traffic, but I can ping hosts in remote network and access to the services on 80,443/tcp ports. **To Reproduce** Steps to reproduce the behavior: 1. Deploy a new service 2. Add some peers to different groups. 3. Create network route which sits behind one of the peers. 4. Delete default access policy and create a new one which limits the access to the peers with network routes. 5. Feel free to access to any resources in the route without limitations of created access policy. **Expected behavior** Limited traffic according to created Access Policy. **Are you using NetBird Cloud?** self-host NetBird's control plane. **NetBird version** `0.26.3` Thank you
saavagebueno added the clientquestionroutes labels 2025-11-20 05:16:22 -05:00
saavagebueno commented 2025-11-20 05:16:22 -05:00
Author
Owner
Copy Link

@braginini commented on GitHub (Mar 16, 2024):

Hey @sisumara
This is a know limitation. The access control rule you have set up is applied to the routing peer but not the machines behind it.
We are working on enhancing the access control to apply port and protocol restrictions on the machines behind the router.

Do you want to limit ports and protocols for the whole network behind the router or individual resources?

@braginini commented on GitHub (Mar 16, 2024): Hey @sisumara This is a know limitation. The access control rule you have set up is applied to the routing peer but not the machines behind it. We are working on enhancing the access control to apply port and protocol restrictions on the machines behind the router. Do you want to limit ports and protocols for the whole network behind the router or individual resources?
saavagebueno commented 2025-11-20 05:16:23 -05:00
Author
Owner
Copy Link

@sisumara commented on GitHub (Mar 17, 2024):

Hey @sisumara This is a know limitation. The access control rule you have set up is applied to the routing peer but not the machines behind it. We are working on enhancing the access control to apply port and protocol restrictions on the machines behind the router.

So, I can limit traffic flow with access policies the only to the peers, right?

Do you want to limit ports and protocols for the whole network behind the router or individual resources?

I have couple of cases and in some of them it needs to limit the whole network in some of them just certain hosts in the network.

@sisumara commented on GitHub (Mar 17, 2024): > Hey @sisumara This is a know limitation. The access control rule you have set up is applied to the routing peer but not the machines behind it. We are working on enhancing the access control to apply port and protocol restrictions on the machines behind the router. > So, I can limit traffic flow with access policies the only to the peers, right? > Do you want to limit ports and protocols for the whole network behind the router or individual resources? I have couple of cases and in some of them it needs to limit the whole network in some of them just certain hosts in the network.
saavagebueno commented 2025-11-20 05:16:23 -05:00
Author
Owner
Copy Link

@barto95100 commented on GitHub (Mar 22, 2024):

YEs the same, test to accept juste in TCP port 32400 (plex) and the host with netbird agent havec access to connecte on SSH :
explain flow

host peer agent ----> host routing peer -----> server plex

I want to block the host peer agent just right access on port 32400 and not all port in host beinhind routing peer

@barto95100 commented on GitHub (Mar 22, 2024): YEs the same, test to accept juste in TCP port 32400 (plex) and the host with netbird agent havec access to connecte on SSH : explain flow host peer agent ----> host routing peer -----> server plex I want to block the host peer agent just right access on port 32400 and not all port in host beinhind routing peer
saavagebueno commented 2025-11-20 05:16:23 -05:00
Author
Owner
Copy Link

@Cheekie25 commented on GitHub (Apr 16, 2025):

I have the same need: I would like to limit ports and protocols for the whole network behind the router.
Do you any ETA for this feature ?
Do you know any workaround ?
Thank you

@Cheekie25 commented on GitHub (Apr 16, 2025): I have the same need: I would like to limit ports and protocols for the whole network behind the router. Do you any ETA for this feature ? Do you know any workaround ? Thank you
saavagebueno commented 2025-11-20 05:16:23 -05:00
Author
Owner
Copy Link

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

I have the same need: I would like to limit ports and protocols for the whole network behind the router. Do you any ETA for this feature ? Do you know any workaround ? Thank you

I am pretty sure it's perfectly achievable and working with:

  • introduction of protocols and ports on access policies
  • the new Networks feature (made of Resources and Routing Peers) on the current version.

I am closing this because I believe this is fully addressed, but feel free to comment and we'll reopen.

@nazarewk commented on GitHub (Apr 17, 2025): > I have the same need: I would like to limit ports and protocols for the whole network behind the router. Do you any ETA for this feature ? Do you know any workaround ? Thank you I am pretty sure it's perfectly achievable and working with: - introduction of protocols and ports on access policies - the new Networks feature (made of Resources and Routing Peers) on the current version. I am closing this because I believe this is fully addressed, but feel free to comment and we'll reopen.
saavagebueno commented 2025-11-20 05:16:23 -05:00
Author
Owner
Copy Link

@Cheekie25 commented on GitHub (Apr 17, 2025):

Thank you for your answer.

My goal is to be able to reach some web service on a specific port of a resource but that the other web services on the same resource do not be accessible.

I just tried the following setup without success:

  • One docker peer "NAS" with network mode host (v0.41.3).
    Groups "All" and "Secret".
  • One iPhone (v0.36.4-dev according to the the UI and 0.0.9 in the app. No update is available in the App Store).
    Group "All".
  • One network named "Private" with one resource "MY NAS" with 192.168.1.50/32 for the address.
    Group "Secret".
    Routing peer: "NAS" (Masquerade activated).

I have two http web services running on "MY NAS".
One on port 9000 and one on port 82.

Now if I don't set any policy to the "Private" network, I can't reach any service of my "MY NAS" resource from the iPhone.
But if I add a policy that links the groups, "All" to "Secrets", I can reach all of the service.

The issue is that even if the policy has the only direction "All" to "Secrets" and that the port 9000 and TCP protocol are specified, I can still reach the web service on the port 82 that is running on the same resource.

I'm I missing something ?

@Cheekie25 commented on GitHub (Apr 17, 2025): Thank you for your answer. My goal is to be able to reach some web service on a specific port of a resource but that the other web services on the same resource do not be accessible. I just tried the following setup without success: - One docker peer "NAS" with network mode host (v0.41.3). Groups "All" and "Secret". - One iPhone (v0.36.4-dev according to the the UI and 0.0.9 in the app. No update is available in the App Store). Group "All". - One network named "Private" with one resource "MY NAS" with 192.168.1.50/32 for the address. Group "Secret". Routing peer: "NAS" (Masquerade activated). I have two http web services running on "MY NAS". One on port 9000 and one on port 82. Now if I don't set any policy to the "Private" network, I can't reach any service of my "MY NAS" resource from the iPhone. But if I add a policy that links the groups, "All" to "Secrets", I can reach all of the service. The issue is that even if the policy has the only direction "All" to "Secrets" and that the port 9000 and TCP protocol are specified, I can still reach the web service on the port 82 that is running on the same resource. I'm I missing something ?
saavagebueno commented 2025-11-20 05:16:23 -05:00
Author
Owner
Copy Link

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

I'm I missing something ?

  1. You should use a dedicated group (let's call it X) for your client devices instead of All.
  2. Then create Access Control policy allowing access from Group X to Group Secret
  3. limit the policy to ports 9000 & 82. Note you need to select either TCP or UDP to do that
  4. (optionally) duplicate the rule if you need access to both TCP and UDP on those ports

There is one caveat: if you were to separate Resource's Group from Routing Peer's Group and the 192.168.1.50 belonged to the Peer doing the routing (NetBird was installed on the same NAS) you would need to allow access to both Groups to be able to access NAS's LAN IP over NetBird.

@nazarewk commented on GitHub (Apr 18, 2025): > I'm I missing something ? 1. You should use a dedicated group (let's call it `X`) for your client devices instead of `All`. 2. Then create Access Control policy allowing access from Group `X` to Group `Secret` 3. limit the policy to ports 9000 & 82. Note you need to select either `TCP` or `UDP` to do that 4. (optionally) duplicate the rule if you need access to both TCP and UDP on those ports There is one caveat: if you were to separate Resource's Group from Routing Peer's Group and the `192.168.1.50` belonged to the Peer doing the routing (NetBird was installed on the same NAS) you would need to allow access to **both** Groups to be able to access NAS's LAN IP over NetBird.
saavagebueno commented 2025-11-20 05:16:23 -05:00
Author
Owner
Copy Link

@Cheekie25 commented on GitHub (Apr 21, 2025):

I tried several setups, here are 3 but I tried others. In each case: either nothing can be reached, or everything can.
I haven't found any case where only the 9000 port of the resource would be reachable (and the 82 port wouldn't).

Devices
and IPs
iPhone
100.75.71.147
- 		NAS (Routing peer)
100.75.15.109
192.168.1.50		 MY NAS (Resource)
-
192.168.1.50/32
Groups X Secret Secret
Policies Result
X --> Secret (TCP port 9000) iPhone can connect to 192.168.1.50:9000 and 192.168.1.50:82
Devices
and IPs
iPhone
100.75.71.147
- 		NAS (Routing peer)
100.75.15.109
192.168.1.50		 MY NAS (Resource)
-
192.168.1.50/32
Groups X Secret Res
Policies Result
X --> Secret (TCP port 9000) iPhone can't connect to 192.168.1.50
Secret --> Res (TCP port 9000)
Devices
and IPs
iPhone
100.75.71.147
- 		NAS (Routing peer)
100.75.15.109
192.168.1.50		 MY NAS (Resource)
-
192.168.1.50/32
Groups X Secret Res
Policies Result
X --> Res (TCP port 9000) iPhone can connect to 192.168.1.50:9000 and 192.168.1.50:82
@Cheekie25 commented on GitHub (Apr 21, 2025): I tried several setups, here are 3 but I tried others. In each case: either nothing can be reached, or everything can. I haven't found any case where only the 9000 port of the resource would be reachable (and the 82 port wouldn't). 1) <table><thead> <tr> <th rowspan="2">Devices <br>and IPs</th> </tr> <tr> <th>iPhone <br>100.75.71.147<br>- </th> <th>NAS (Routing peer)<br>100.75.15.109<br>192.168.1.50</th> <th>MY NAS (Resource)<br>- <br>192.168.1.50/32</th> </tr></thead> <tbody> <tr> <td>Groups</td> <td>X</td> <td>Secret</td> <td>Secret</td> </tr> </tbody> </table> <table><thead> <tr> <th>Policies</th> <th>Result</th> </tr></thead> <tbody> <tr> <td>X --&gt; Secret (TCP port 9000)</td> <td>iPhone can connect to 192.168.1.50:9000 and 192.168.1.50:82</td> </tr> </tbody> </table> 2. <table><thead> <tr> <th rowspan="2">Devices <br>and IPs</th> </tr> <tr> <th>iPhone <br>100.75.71.147<br>- </th> <th>NAS (Routing peer)<br>100.75.15.109<br>192.168.1.50</th> <th>MY NAS (Resource)<br>- <br>192.168.1.50/32</th> </tr></thead> <tbody> <tr> <td>Groups</td> <td>X</td> <td>Secret</td> <td>Res</td> </tr> </tbody> </table> <table><thead> <tr> <th>Policies</th> <th>Result</th> </tr></thead> <tbody> <tr> <td>X --&gt; Secret (TCP port 9000)</td> <th rowspan="2">iPhone can't connect to 192.168.1.50</th> </tr> <tr> <td>Secret --&gt; Res (TCP port 9000)</td> </tr> </tbody> </table> 3. <table><thead> <tr> <th rowspan="2">Devices <br>and IPs</th> </tr> <tr> <th>iPhone <br>100.75.71.147<br>- </th> <th>NAS (Routing peer)<br>100.75.15.109<br>192.168.1.50</th> <th>MY NAS (Resource)<br>- <br>192.168.1.50/32</th> </tr></thead> <tbody> <tr> <td>Groups</td> <td>X</td> <td>Secret</td> <td>Res</td> </tr> </tbody> </table> <table><thead> <tr> <th>Policies</th> <th>Result</th> </tr></thead> <tbody> <tr> <td>X --&gt; Res (TCP port 9000)</td> <td>iPhone can connect to 192.168.1.50:9000 and 192.168.1.50:82</td> </tr> </tbody> </table>
saavagebueno commented 2025-11-20 05:16:24 -05:00
Author
Owner
Copy Link

@Cheekie25 commented on GitHub (Apr 23, 2025):

I tried with a Routing peer on another device than the Resource one (but on the same local network so it could reach the Resource).
In this configuration, the policies behave as expected 👍 .
Any way to make that work when the Routing Peer and the Resource are on the same device ?

@Cheekie25 commented on GitHub (Apr 23, 2025): I tried with a Routing peer on another device than the Resource one (but on the same local network so it could reach the Resource). In this configuration, the policies behave as expected 👍 . Any way to make that work when the Routing Peer and the Resource are on the same device ?
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 client question routes
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#713
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?