[GH-ISSUE #5862] Reverse Proxy: OR logic for access control rules and reusable auth/policy profiles #11198

Open
opened 2026-08-05 01:28:51 -04:00 by saavagebueno · 11 comments
Owner

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

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

I'm self-hosting NetBird as a replacement for Cloudflare's tunnels and security features. When configuring access control on exposed services, I need to allow traffic from specific countries (e.g. France, Belgium) OR from trusted internal CIDR ranges (e.g. the IP of an exit node).

From what I experienced, access control rules of different types (Country and CIDR Block) are evaluated with AND logic: a connection must satisfy all configured "Allow Only" rules to be permitted. This makes it impossible to express "allow if from France OR Belgium OR from my VPN range" — adding a CIDR allowlist silently overrides country rules blocking all IPs outside that CIDR regardless of their country.

Cloudflare achieves this through Security Rules with explicit boolean operators ((ip.geoip.country eq "FR") or
(ip.geoip.country eq "BE") or (ip.src in {100.64.0.0/10})).

Describe the solution you'd like

Two related improvements:

  1. OR logic between access control rules
    Allow rules of different types (Country, CIDR Block) to be combined with OR logic, not just AND. A possible UI approach would be to group rules into logical blocks where conditions within a group are OR-evaluated, and groups themselves can be AND-evaluated. At minimum, a simple "match any / match all" toggle at the rule set level would be
    sufficient.
    Expected behavior example:
  • Allow if country = FR OR country = BE OR IP in 100.64.0.0/10
  • Currently this requires three separate "Allow Only" entries but behaves as AND across types.
  1. Reusable access control policies and authentication methods

Currently, access control rules and authentication methods (SSO config, password, headers) must be configured individually per service. When managing many exposed services, this creates significant maintenance overhead: updating a shared policy (e.g. adding a new allowed country or rotating a shared secret) requires editing every service one by one.
The solution would be to introduce named, reusable Access Control Policies and Authentication Profiles that can be created once and assigned to multiple services. Changes to a shared policy would propagate automatically to all services using it.

Describe alternatives you've considered

  • Removing CIDR rules entirely and relying only on country rules: loses the ability to grant access to trusted peers regardless of geographic location.
  • Handling OR logic at the Traefik layer (custom middleware): possible but requires manually injecting configuration outside of NetBird's management plane, breaking the unified management model.
  • Staying on Cloudflare: defeats the purpose of self-hosting with NetBird as the single access layer.

Additional context
This is particularly relevant for self-hosters who want to use NetBird's reverse proxy as a full Cloudflare replacement with geo-blocking. The current AND-only evaluation model is not documented explicitly, making the behavior surprising: adding a CIDR allowlist silently breaks previously working country-based rules.
The reusable policies request is similar to how Cloudflare handles WAF Custom Rulesets or how Traefik handles reusable middleware — define once, reference many times.

Originally created by @matlantin on GitHub (Apr 12, 2026). Original GitHub issue: https://github.com/netbirdio/netbird/issues/5862 **Is your feature request related to a problem? Please describe.** I'm self-hosting NetBird as a replacement for Cloudflare's tunnels and security features. When configuring access control on exposed services, I need to allow traffic from specific countries (e.g. France, Belgium) OR from trusted internal CIDR ranges (e.g. the IP of an exit node). From what I experienced, access control rules of different types (Country and CIDR Block) are evaluated with AND logic: a connection must satisfy all configured "Allow Only" rules to be permitted. This makes it impossible to express "allow if from France OR Belgium OR from my VPN range" — adding a CIDR allowlist silently overrides country rules blocking all IPs outside that CIDR regardless of their country. Cloudflare achieves this through Security Rules with explicit boolean operators ((ip.geoip.country eq "FR") or (ip.geoip.country eq "BE") or (ip.src in {100.64.0.0/10})). **Describe the solution you'd like** Two related improvements: 1. OR logic between access control rules Allow rules of different types (Country, CIDR Block) to be combined with OR logic, not just AND. A possible UI approach would be to group rules into logical blocks where conditions within a group are OR-evaluated, and groups themselves can be AND-evaluated. At minimum, a simple "match any / match all" toggle at the rule set level would be sufficient. Expected behavior example: - Allow if country = FR OR country = BE OR IP in 100.64.0.0/10 - Currently this requires three separate "Allow Only" entries but behaves as AND across types. 2. Reusable access control policies and authentication methods Currently, access control rules and authentication methods (SSO config, password, headers) must be configured individually per service. When managing many exposed services, this creates significant maintenance overhead: updating a shared policy (e.g. adding a new allowed country or rotating a shared secret) requires editing every service one by one. The solution would be to introduce named, reusable Access Control Policies and Authentication Profiles that can be created once and assigned to multiple services. Changes to a shared policy would propagate automatically to all services using it. **Describe alternatives you've considered** - Removing CIDR rules entirely and relying only on country rules: loses the ability to grant access to trusted peers regardless of geographic location. - Handling OR logic at the Traefik layer (custom middleware): possible but requires manually injecting configuration outside of NetBird's management plane, breaking the unified management model. - Staying on Cloudflare: defeats the purpose of self-hosting with NetBird as the single access layer. **Additional context** This is particularly relevant for self-hosters who want to use NetBird's reverse proxy as a full Cloudflare replacement with geo-blocking. The current AND-only evaluation model is not documented explicitly, making the behavior surprising: adding a CIDR allowlist silently breaks previously working country-based rules. The reusable policies request is similar to how Cloudflare handles WAF Custom Rulesets or how Traefik handles reusable middleware — define once, reference many times.
saavagebueno added the feature-request label 2026-08-05 01:28:51 -04:00
Author
Owner

@wtrucci commented on GitHub (May 2, 2026):

+1
AND logic isn't very convenient or useful. In the case of a self-hosted setup, if I want to restrict access from a specific country and a specific CIRD, I need to use OR logic; otherwise, no connections will be allowed.
The documentation doesn't clearly specify which logic is used, but I believe OR should be used instead of AND in the proxy service under the “Allow Only” rules.

<!-- gh-comment-id:4363351026 --> @wtrucci commented on GitHub (May 2, 2026): +1 AND logic isn't very convenient or useful. In the case of a self-hosted setup, if I want to restrict access from a specific country and a specific CIRD, I need to use OR logic; otherwise, no connections will be allowed. The documentation doesn't clearly specify which logic is used, but I believe OR should be used instead of AND in the proxy service under the “Allow Only” rules.
Author
Owner

@michelkroon commented on GitHub (May 16, 2026):

+1
I'm experiencing the same issue. Nowhere in the documentation can ben found what logic is used when evaluating the rules. Would really love the option to choose between AND/OR logic based on my needs.

<!-- gh-comment-id:4466285644 --> @michelkroon commented on GitHub (May 16, 2026): +1 I'm experiencing the same issue. Nowhere in the documentation can ben found what logic is used when evaluating the rules. Would really love the option to choose between AND/OR logic based on my needs.
Author
Owner

@baldygeraldy commented on GitHub (May 21, 2026):

Following as i have the same. These requests would make the product much much better

<!-- gh-comment-id:4505196990 --> @baldygeraldy commented on GitHub (May 21, 2026): Following as i have the same. These requests would make the product much much better
Author
Owner

@stephen-cornwell commented on GitHub (May 29, 2026):

+1 from me too.

OR logic would be the best win, though I'd settle for either:

  • Allow / Deny rules which short circuit the flow.
  • A "bypass rules for CIDR" option in the Access Controls form.
<!-- gh-comment-id:4581028203 --> @stephen-cornwell commented on GitHub (May 29, 2026): +1 from me too. OR logic would be the best win, though I'd settle for either: - Allow / Deny rules which short circuit the flow. - A "bypass rules for CIDR" option in the Access Controls form.
Author
Owner

@Xandar31 commented on GitHub (Jun 7, 2026):

+1
I'm also looking for some way to group the Access Control.
In general for my services it's always the same, like enforce crowdsec, restrict the countrys to a few one and CIDRs.
It would be nice to create like a "Posture Checks" and add this to the reverse proxy service as access control

<!-- gh-comment-id:4642083038 --> @Xandar31 commented on GitHub (Jun 7, 2026): +1 I'm also looking for some way to group the Access Control. In general for my services it's always the same, like enforce crowdsec, restrict the countrys to a few one and CIDRs. It would be nice to create like a "Posture Checks" and add this to the reverse proxy service as access control
Author
Owner

@wtrucci commented on GitHub (Jun 8, 2026):

+1 from me too.

OR logic would be the best win, though I'd settle for either:

  • Allow / Deny rules which short circuit the flow.
  • A "bypass rules for CIDR" option in the Access Controls form.

Exactly, OR logic is right not AND...

<!-- gh-comment-id:4648458125 --> @wtrucci commented on GitHub (Jun 8, 2026): > +1 from me too. > > OR logic would be the best win, though I'd settle for either: > > * Allow / Deny rules which short circuit the flow. > * A "bypass rules for CIDR" option in the Access Controls form. Exactly, OR logic is right not AND...
Author
Owner

@GrapeFruitStudioUK commented on GitHub (Jun 9, 2026):

+1 This has just bitten me that this is AND only which is counter intuitive. For self hosting I believe OR as the default would be more useful as like others I am trying to restrict by country and internal IP scope.

<!-- gh-comment-id:4662581900 --> @GrapeFruitStudioUK commented on GitHub (Jun 9, 2026): +1 This has just bitten me that this is AND only which is counter intuitive. For self hosting I believe OR as the default would be more useful as like others I am trying to restrict by country and internal IP scope.
Author
Owner

@azerioxal commented on GitHub (Jun 12, 2026):

I would like to add that this would also be something I would love to have work with the new 'NetBird-Only Access' feature. Restricting something to NetBird only when not coming from a list of allowed subnets.

<!-- gh-comment-id:4691115443 --> @azerioxal commented on GitHub (Jun 12, 2026): I would like to add that this would also be something I would love to have work with the new 'NetBird-Only Access' feature. Restricting something to NetBird only when not coming from a list of allowed subnets.
Author
Owner

@m1g0r3ng commented on GitHub (Jun 13, 2026):

+1 Services are accessible with one rule or the other, but not both, and echoing NetBird-Only access as an option would be great too for robustness

<!-- gh-comment-id:4700621925 --> @m1g0r3ng commented on GitHub (Jun 13, 2026): +1 Services are accessible with one rule or the other, but not both, and echoing NetBird-Only access as an option would be great too for robustness
Author
Owner

@drake5000 commented on GitHub (Jul 16, 2026):

I would like to join the feature request as well

<!-- gh-comment-id:4989043657 --> @drake5000 commented on GitHub (Jul 16, 2026): I would like to join the feature request as well
Author
Owner

@krahlos commented on GitHub (Jul 23, 2026):

+1 for reusable Access Control Policies (part 2). I often set the same country blocklist per service by hand and every list change means editing every exposed service. Something like a named policy defined once and referenced by many services (like Traefik's GeoBlock plugin) would be nice.

<!-- gh-comment-id:5058967855 --> @krahlos commented on GitHub (Jul 23, 2026): +1 for reusable Access Control Policies (part 2). I often set the same country blocklist per service by hand and every list change means editing every exposed service. Something like a named policy defined once and referenced by many services (like Traefik's [GeoBlock](https://plugins.traefik.io/plugins/62947313ffc0cd18356a97ca/geo-block) plugin) would be nice.
Sign in to join this conversation.
No Label feature-request
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#11198