[GH-ISSUE #4473] Networks: DNS resources with same IP bypass access control policies #9197

Open
opened 2026-08-05 01:21:14 -04:00 by saavagebueno · 3 comments
Owner

Originally created by @joao-aveiro on GitHub (Sep 10, 2025).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/4473

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). Original GitHub issue: https://github.com/netbirdio/netbird/issues/4473 > 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 2026-08-05 01:21:14 -04:00
Author
Owner

@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.

<!-- gh-comment-id:3275034620 --> @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.
Author
Owner

@Takalele commented on GitHub (Jan 23, 2026):

@joao-aveiro there is a "sloppy workaround", but it is not fully secure, as users can still manually add the FQDN to /etc/hosts or fake the http header.

Enable the nameserver distribution groups and the nameserver resource groups only for users who require full access to the dns servers.

for all other users (without the “former nameservers”), the routing node will handle dns resolution according to the defined policies, so the client can only resolve FQDNs that are explicitly allowed by those policies.

<!-- gh-comment-id:3790123027 --> @Takalele commented on GitHub (Jan 23, 2026): @joao-aveiro there is a "sloppy workaround", but it is not fully secure, as users can still manually add the FQDN to /etc/hosts or fake the http header. Enable the nameserver distribution groups and the nameserver resource groups only for users who require full access to the dns servers. for all other users (without the “former nameservers”), the routing node will handle dns resolution according to the defined policies, so the client can only resolve FQDNs that are explicitly allowed by those policies.
Author
Owner

@SpoopyTim commented on GitHub (Feb 8, 2026):

Looks like this is (at least in part) related to: https://github.com/netbirdio/netbird/issues/2790

Came across this limitation recently when getting into a test migration from my existing vpn stack to NetBird. Currently considering using the peer's IP to restrict access which is going to be tedious to setup and probably prone to failure.

A fully managed reverse proxy might work for some but grouped subnets would probably work for the larger majority as you would be able to handle IP restriction externally and without having to add each peer's IP manually.

Perhaps there's some middle-ground solution where NetBird could communicate access control changes with an reverse proxy like envoyproxy or traefik while also restricting peers to certain subnets for nonstandard traffic that does not have a well defined proxy system.

<!-- gh-comment-id:3868278058 --> @SpoopyTim commented on GitHub (Feb 8, 2026): Looks like this is (at least in part) related to: https://github.com/netbirdio/netbird/issues/2790 Came across this limitation recently when getting into a test migration from my existing vpn stack to NetBird. Currently considering using the peer's IP to restrict access which is going to be tedious to setup and probably prone to failure. A fully managed reverse proxy might work for some but grouped subnets would probably work for the larger majority as you would be able to handle IP restriction externally and without having to add each peer's IP manually. Perhaps there's some middle-ground solution where NetBird could communicate access control changes with an reverse proxy like envoyproxy or traefik while also restricting peers to certain subnets for nonstandard traffic that does not have a well defined proxy system.
Sign in to join this conversation.
No Label dns
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#9197