[GH-ISSUE #5861] Reverse Proxy: Add Netbird Networks as access restriction source #11855

Open
opened 2026-08-05 01:31:20 -04:00 by saavagebueno · 0 comments
Owner

Originally created by @renne on GitHub (Apr 12, 2026).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/5861

Is your feature request related to a problem? Please describe.

The Reverse Proxy supports access restrictions based on Country, IP Address, or CIDR Block. However, there is no way to restrict access to clients that are part of a specific Netbird Network — i.e. Netbird overlay peers (100.x.x.x) and LAN hosts whose subnets are defined as Network resources.

The primary use case is a combined private and public proxy cluster: most services are public, but certain services must be exclusively accessible to internal hosts with no public access. Today this requires manually enumerating all overlay IPs and LAN subnets as individual CIDR rules — a list that silently goes stale when peers or resources change.

Describe the solution you'd like

Add "Netbird Network" as a new rule type in the Reverse Proxy → Services → Access Rules section, alongside the existing "Country", "IP Address", and "CIDR Block" options.

When a Network-based rule is configured, the management server resolves the effective set of allowed/blocked source IPs for that Network:

  • Overlay IPs of all Netbird peers belonging to the network
  • Resource CIDRs defined in the network (e.g. 192.168.1.0/24) — LAN hosts that reach the proxy directly over the local network, not through the overlay

These form the effective CIDR set and are kept in sync automatically as peer membership and network resources change.

Implementation sketch:

  • New proto fields in AccessRestrictions: allowed_networks / blocked_networks (Network IDs)
  • Management server: resolve effective IP set (peer overlay IPs + resource CIDRs) per network at mapping generation time; push updates on membership/resource changes
  • UI: "Netbird Network" option in the access rule type dropdown with a network picker

Use case example:

A Netbird reverse proxy cluster serves both public internet clients and internal clients. A Netbird Network is defined with:

  • Netbird peers enrolled on internal devices (overlay IPs 100.x.x.x)
  • LAN subnets (e.g. 10.0.0.0/24) as network resources — these hosts hit the proxy directly via the local network, not through the Netbird overlay

The admin configures certain proxy services with an "Allow: Netbird Network — " rule. All other source IPs are denied. No manual CIDR maintenance is needed; the list updates automatically as the network evolves.

Describe alternatives you've considered

  • Manual CIDR rules: Requires tracking all overlay IPs and LAN subnets manually. Silently breaks when peers join/leave or subnets change.
  • Separate proxy instance for internal traffic: Operational overhead; defeats the purpose of a unified proxy cluster.
  • Netbird access policies alone: These control overlay-to-overlay traffic, not inbound connections from LAN hosts or public clients to the proxy.

Additional context

The access restriction engine was introduced in PR #5587. The AccessRestrictions proto message currently carries allowed_cidrs, blocked_cidrs, allowed_countries, blocked_countries. Adding allowed_networks / blocked_networks extends this naturally.

Netbird Networks already carry full membership data (peers, resource CIDRs), so the management server has all the information needed to resolve the effective IP set dynamically without any new data collection.

Originally created by @renne on GitHub (Apr 12, 2026). Original GitHub issue: https://github.com/netbirdio/netbird/issues/5861 **Is your feature request related to a problem? Please describe.** The Reverse Proxy supports access restrictions based on Country, IP Address, or CIDR Block. However, there is no way to restrict access to clients that are part of a specific **Netbird Network** — i.e. Netbird overlay peers (100.x.x.x) and LAN hosts whose subnets are defined as Network resources. The primary use case is a **combined private and public proxy cluster**: most services are public, but certain services must be exclusively accessible to internal hosts with no public access. Today this requires manually enumerating all overlay IPs and LAN subnets as individual CIDR rules — a list that silently goes stale when peers or resources change. **Describe the solution you'd like** Add **"Netbird Network"** as a new rule type in the Reverse Proxy → Services → Access Rules section, alongside the existing "Country", "IP Address", and "CIDR Block" options. When a Network-based rule is configured, the management server resolves the effective set of allowed/blocked source IPs for that Network: - **Overlay IPs** of all Netbird peers belonging to the network - **Resource CIDRs** defined in the network (e.g. `192.168.1.0/24`) — LAN hosts that reach the proxy directly over the local network, not through the overlay These form the effective CIDR set and are kept in sync automatically as peer membership and network resources change. Implementation sketch: - New proto fields in `AccessRestrictions`: `allowed_networks` / `blocked_networks` (Network IDs) - Management server: resolve effective IP set (peer overlay IPs + resource CIDRs) per network at mapping generation time; push updates on membership/resource changes - UI: "Netbird Network" option in the access rule type dropdown with a network picker **Use case example:** A Netbird reverse proxy cluster serves both public internet clients and internal clients. A Netbird Network is defined with: - Netbird peers enrolled on internal devices (overlay IPs `100.x.x.x`) - LAN subnets (e.g. `10.0.0.0/24`) as network resources — these hosts hit the proxy directly via the local network, not through the Netbird overlay The admin configures certain proxy services with an "Allow: Netbird Network — <name>" rule. All other source IPs are denied. No manual CIDR maintenance is needed; the list updates automatically as the network evolves. **Describe alternatives you've considered** - **Manual CIDR rules:** Requires tracking all overlay IPs and LAN subnets manually. Silently breaks when peers join/leave or subnets change. - **Separate proxy instance for internal traffic:** Operational overhead; defeats the purpose of a unified proxy cluster. - **Netbird access policies alone:** These control overlay-to-overlay traffic, not inbound connections from LAN hosts or public clients to the proxy. **Additional context** The access restriction engine was introduced in PR #5587. The `AccessRestrictions` proto message currently carries `allowed_cidrs`, `blocked_cidrs`, `allowed_countries`, `blocked_countries`. Adding `allowed_networks` / `blocked_networks` extends this naturally. Netbird Networks already carry full membership data (peers, resource CIDRs), so the management server has all the information needed to resolve the effective IP set dynamically without any new data collection.
Sign in to join this conversation.
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#11855