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

Networks: DNS resources with same IP bypass access control policies #2262

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

Originally created by @joao-aveiro on GitHub (Sep 10, 2025).

Note: This might be related to a known limitation mentioned in NetBird's documentation: "Policies for domains or wildcard domains applied to peers with IP ranges might influence access control for those peers, as their destination ranges include any IPs. Therefore, we recommend creating networks with routing peers dedicated to domain and wildcard domains to prevent unwanted access. In upcoming releases, we will provide a fix for this behavior." I searched through existing GitHub issues (including closed ones) but could not find a specific issue tracking this limitation, despite it being acknowledged in the documentation. Creating this issue to provide a concrete use case and allow the community to track progress on this fix.

Describe the problem
When using the Networks feature with DNS-based resources that resolve to the same IP address (e.g., multiple applications behind a reverse proxy/load balancer), access control policies grant access to all applications on that IP rather than just the specific FQDN resource defined in the policy.

To Reproduce
Steps to reproduce the behavior:

  1. Create a new Network in NetBird dashboard
  2. Add a routing peer to the network
  3. Add two DNS-based resources with different FQDNs that resolve to the same IP address (e.g., app1.company.org and app2.company.org both resolving to 10.32.0.101)
  4. Create separate groups for each resource (e.g., app1-group, app2-group)
  5. Create separate access control policies: usr-app1-access -> app1-group and usr-app2-access -> app2-group
  6. Add a user only to the usr-app1-access group
  7. Test access to both applications

Expected behavior
Users should only be able to access the specific application they have been granted access to through the Networks resource and access policy. In this case, a user with only usr-app1-access should be able to access app1.company.org but not app2.company.org.

Are you using NetBird Cloud?
Self-hosted

NetBird version
netbird version 0.56.1

Is any other VPN software installed?
WireGuard (disabled during testing)

Debug output
N/A

Screenshots
N/A

Additional context
This appears to be related to a known limitation mentioned in NetBird's documentation: "Policies for domains or wildcard domains applied to peers with IP ranges might influence access control for those peers, as their destination ranges include any IPs. Therefore, we recommend creating networks with routing peers dedicated to domain and wildcard domains to prevent unwanted access. In upcoming releases, we will provide a fix for this behavior."

However, this specific scenario (multiple applications behind reverse proxies/load balancers with the same IP) is a common enterprise architecture pattern that would benefit from more granular FQDN-based access control rather than IP-based routing.

The DNS records are only available on our internal network, and the DNS server is properly configured and reachable by all NetBird peers.

Have you tried these troubleshooting steps?

  • Reviewed client troubleshooting (if applicable)
  • Checked for newer NetBird versions
  • Searched for similar issues on GitHub (including closed ones)
  • Restarted the NetBird client
  • Disabled other VPN software
  • Checked firewall settings
Originally created by @joao-aveiro on GitHub (Sep 10, 2025). > Note: This might be related to a known limitation mentioned in NetBird's documentation: "Policies for domains or wildcard domains applied to peers with IP ranges might influence access control for those peers, as their destination ranges include any IPs. Therefore, we recommend creating networks with routing peers dedicated to domain and wildcard domains to prevent unwanted access. In upcoming releases, we will provide a fix for this behavior." I searched through existing GitHub issues (including closed ones) but could not find a specific issue tracking this limitation, despite it being acknowledged in the documentation. Creating this issue to provide a concrete use case and allow the community to track progress on this fix. **Describe the problem** When using the Networks feature with DNS-based resources that resolve to the same IP address (e.g., multiple applications behind a reverse proxy/load balancer), access control policies grant access to all applications on that IP rather than just the specific FQDN resource defined in the policy. **To Reproduce** Steps to reproduce the behavior: 1. Create a new Network in NetBird dashboard 2. Add a routing peer to the network 3. Add two DNS-based resources with different FQDNs that resolve to the same IP address (e.g., `app1.company.org` and `app2.company.org` both resolving to `10.32.0.101`) 4. Create separate groups for each resource (e.g., `app1-group`, `app2-group`) 5. Create separate access control policies: `usr-app1-access -> app1-group` and `usr-app2-access -> app2-group` 6. Add a user only to the `usr-app1-access` group 7. Test access to both applications **Expected behavior** Users should only be able to access the specific application they have been granted access to through the Networks resource and access policy. In this case, a user with only `usr-app1-access` should be able to access `app1.company.org` but not `app2.company.org`. **Are you using NetBird Cloud?** Self-hosted **NetBird version** `netbird version 0.56.1` **Is any other VPN software installed?** WireGuard (disabled during testing) **Debug output** N/A **Screenshots** N/A **Additional context** This appears to be related to a known limitation mentioned in NetBird's documentation: "Policies for domains or wildcard domains applied to peers with IP ranges might influence access control for those peers, as their destination ranges include any IPs. Therefore, we recommend creating networks with routing peers dedicated to domain and wildcard domains to prevent unwanted access. In upcoming releases, we will provide a fix for this behavior." However, this specific scenario (multiple applications behind reverse proxies/load balancers with the same IP) is a common enterprise architecture pattern that would benefit from more granular FQDN-based access control rather than IP-based routing. The DNS records are only available on our internal network, and the DNS server is properly configured and reachable by all NetBird peers. **Have you tried these troubleshooting steps?** - [x] Reviewed [client troubleshooting](https://docs.netbird.io/how-to/troubleshooting-client) (if applicable) - [x] Checked for newer NetBird versions - [x] Searched for similar issues on GitHub (including closed ones) - [x] Restarted the NetBird client - [x] Disabled other VPN software - [ ] Checked firewall settings
saavagebueno added the dns label 2025-11-20 07:06:43 -05:00
saavagebueno commented 2025-11-20 07:06:44 -05:00
Author
Owner
Copy Link

@nazarewk commented on GitHub (Sep 10, 2025):

this is unfortunately working as designed, there is no way to tell multiple services using the same IP address apart from each other without running a reverse proxy for the very specific protocol

I am not sure if there is a feature request for it yet, but we are aware of this and plan to address this in the future.

@nazarewk commented on GitHub (Sep 10, 2025): this is unfortunately working as designed, there is no way to tell multiple services using the same IP address apart from each other without running a reverse proxy for the very specific protocol I am not sure if there is a feature request for it yet, but we are aware of this and plan to address this in the future.
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 dns
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#2262
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?