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

Deny Rule for Specific IPs in Network Access Control #1334

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

Originally created by @marcportabellaclotet-mt on GitHub (Oct 14, 2024).

Feature Request: Deny Rule for Specific IPs in Network Access Control

Description:
We are currently using Netbird to manage network access and have a question about network access control. We would like to grant a user access to a broader network range (e.g., 10.10.0.0/16) but restrict access to a specific endpoint within that range (e.g., 10.10.3.4/32).

Currently, there doesn't seem to be an option to add a deny rule or similar mechanism that would allow us to achieve this more granular control. We believe that having the ability to define deny rules in the access control settings would be beneficial in scenarios like ours, where we need to restrict certain resources while still granting access to others within the same network range.

Proposed Solution:

  • Add the ability to create deny rules in the access control settings, allowing users to deny access to specific IP addresses or ranges even when a broader range is allowed.
  • These deny rules would take precedence over allow rules, ensuring that specific endpoints can be restricted even when a network range is permitted.

Use Case:

  • We want to grant a user access to the 10.10.0.0/16 range but restrict access to the endpoint 10.10.3.4/32.
  • With deny rules, we could grant access to the entire network range while ensuring that sensitive endpoints remain inaccessible.

Benefit:
This feature would provide more granular control over network access, helping users secure specific endpoints within broader network ranges. It would also reduce the need to create overly specific allow rules that might be cumbersome to manage in complex network setups.

Thank you for considering this feature!

Originally created by @marcportabellaclotet-mt on GitHub (Oct 14, 2024). ### Feature Request: Deny Rule for Specific IPs in Network Access Control **Description:** We are currently using Netbird to manage network access and have a question about network access control. We would like to grant a user access to a broader network range (e.g., 10.10.0.0/16) but restrict access to a specific endpoint within that range (e.g., 10.10.3.4/32). Currently, there doesn't seem to be an option to add a deny rule or similar mechanism that would allow us to achieve this more granular control. We believe that having the ability to define deny rules in the access control settings would be beneficial in scenarios like ours, where we need to restrict certain resources while still granting access to others within the same network range. **Proposed Solution:** - Add the ability to create deny rules in the access control settings, allowing users to deny access to specific IP addresses or ranges even when a broader range is allowed. - These deny rules would take precedence over allow rules, ensuring that specific endpoints can be restricted even when a network range is permitted. **Use Case:** - We want to grant a user access to the 10.10.0.0/16 range but restrict access to the endpoint 10.10.3.4/32. - With deny rules, we could grant access to the entire network range while ensuring that sensitive endpoints remain inaccessible. **Benefit:** This feature would provide more granular control over network access, helping users secure specific endpoints within broader network ranges. It would also reduce the need to create overly specific allow rules that might be cumbersome to manage in complex network setups. Thank you for considering this feature!
saavagebueno added the feature-request label 2025-11-20 05:28:39 -05:00
saavagebueno commented 2025-11-20 05:28:40 -05:00
Author
Owner
Copy Link

@bbenouarets commented on GitHub (Oct 29, 2024):

I hereby also express my interest in this function. An allow or deny list for the ports that may be used for the endpoint would also be helpful. Either you create an allow list, which would be better for the zero trust concept. However, I would favor an allow list.

@bbenouarets commented on GitHub (Oct 29, 2024): I hereby also express my interest in this function. An allow or deny list for the ports that may be used for the endpoint would also be helpful. Either you create an allow list, which would be better for the zero trust concept. However, I would favor an allow list.
saavagebueno commented 2025-11-20 05:28:40 -05:00
Author
Owner
Copy Link

@galiev commented on GitHub (Mar 7, 2025):

I understand that this isn't exactly a solution, but as a workaround, you can manually remove the address from the range:

>>> from netaddr import IPSet
>>> my_route = IPSet(['10.10.0.0/16'])
>>> my_route.remove("10.10.3.4/32")
>>> my_route
IPSet(['10.10.0.0/23', '10.10.2.0/24', '10.10.3.0/30', '10.10.3.5/32', '10.10.3.6/31', '10.10.3.8/29', '10.10.3.16/28', '10.10.3.32/27', '10.10.3.64/26', '10.10.3.128/25', '10.10.4.0/22', '10.10.8.0/21', '10.10.16.0/20', '10.10.32.0/19', '10.10.64.0/18', '10.10.128.0/17'])

However, with a large number of routes, like in my case—a default route with exceptions for reserved addresses, specific regions, etc.—I ended up with 21,221 routes, and the client gave an error:

2025-03-08T01:58:31Z WARN management/client/grpc.go:171: disconnected from the Management service but will retry silently. Reason: rpc error: code = ResourceExhausted desc = grpc: received message larger than max (11708029 vs. 4194304)
@galiev commented on GitHub (Mar 7, 2025): I understand that this isn't exactly a solution, but as a workaround, you can manually remove the address from the range: ```bash >>> from netaddr import IPSet >>> my_route = IPSet(['10.10.0.0/16']) >>> my_route.remove("10.10.3.4/32") >>> my_route IPSet(['10.10.0.0/23', '10.10.2.0/24', '10.10.3.0/30', '10.10.3.5/32', '10.10.3.6/31', '10.10.3.8/29', '10.10.3.16/28', '10.10.3.32/27', '10.10.3.64/26', '10.10.3.128/25', '10.10.4.0/22', '10.10.8.0/21', '10.10.16.0/20', '10.10.32.0/19', '10.10.64.0/18', '10.10.128.0/17']) ``` However, with a large number of routes, like in my case—a default route with exceptions for reserved addresses, specific regions, etc.—I ended up with 21,221 routes, and the client gave an error: ```bash 2025-03-08T01:58:31Z WARN management/client/grpc.go:171: disconnected from the Management service but will retry silently. Reason: rpc error: code = ResourceExhausted desc = grpc: received message larger than max (11708029 vs. 4194304) ```
saavagebueno commented 2025-11-20 05:28:41 -05:00
Author
Owner
Copy Link

@ivanky4kin commented on GitHub (Oct 8, 2025):

+1
This feature is essential for managing access inside corporate networks.
Often we have to grant users access to internal ranges (e.g., 10.0.0.0/8) but still block traffic to specific sensitive hosts or subnets.
Without deny rules, it’s impossible to properly isolate internal resources while keeping general access available.

@ivanky4kin commented on GitHub (Oct 8, 2025): +1 This feature is essential for managing access inside corporate networks. Often we have to grant users access to internal ranges (e.g., 10.0.0.0/8) but still block traffic to specific sensitive hosts or subnets. Without deny rules, it’s impossible to properly isolate internal resources while keeping general access available.
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 feature-request
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#1334
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?