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

How to setup multiple isolated meshs/groups #149

New Issue
Closed
opened 2025-11-20 05:07:03 -05:00 by saavagebueno · 9 comments
saavagebueno commented 2025-11-20 05:07:03 -05:00
Owner
Copy Link

Originally created by @jurgenhaas on GitHub (Jul 15, 2022).

The fact that rules are bi-directional seems to prevent multiple groups that are isolated from each other but still can be accessed from a group of admin hosts.

Use case

We are an IT company that manages hosts for a number of different customers. We would create a group for each customer and assign all their hosts to that group and define a rule so that they can communicate with each other. So far so good, that's possible.

But 2 requirements don't seem to be possible:

  • having a group of admin hosts (our own) which are allowed to communicate which each of the customer groups only
  • having customer admin groups for each customer's IT team to allow them to access their hosts too

Because the rules are bi-directional, as soon as my admin host can connect to a customer group, that customer group's hosts can connect back to my admin host and from there also connect to all other groups.

Am I missing something or is that really not possible?

Originally created by @jurgenhaas on GitHub (Jul 15, 2022). The fact that rules are bi-directional seems to prevent multiple groups that are isolated from each other but still can be accessed from a group of admin hosts. ## Use case We are an IT company that manages hosts for a number of different customers. We would create a group for each customer and assign all their hosts to that group and define a rule so that they can communicate with each other. So far so good, that's possible. But 2 requirements don't seem to be possible: - having a group of admin hosts (our own) which are allowed to communicate which each of the customer groups only - having customer admin groups for each customer's IT team to allow them to access their hosts too Because the rules are bi-directional, as soon as my admin host can connect to a customer group, that customer group's hosts can connect back to my admin host and from there also connect to all other groups. Am I missing something or is that really not possible?
saavagebueno commented 2025-11-20 05:07:04 -05:00
Author
Owner
Copy Link

@mlsmaycon commented on GitHub (Jul 15, 2022):

@jurgenhaas The two requirements you have should be possible to configure, we still have the bi-direction limitation, but that shouldn't be a reason for you to have peers from one customer to access peers from another customer. Below is an example of a configuration:

Assuming the following groups:

Group Name Description
Managers your admin group
Managers-C1 Managers from customer 1
Managers-C2 Managers from customer 2
Peers-C1 Peers from customer 1
Peers-C2 Peers from customer 2

You can set up the following rules to archive the requirements:

Rule Name Sources Destination
Managers to Customers Managers Peers-C1, Peers-C2
Customer 1 Managers Access Managers-C1 Peers-C1
Customer 2 Managers Access Managers-C2 Peers-C2
Mesh Customer 1 Peers-C1 Peers-C1
Mesh Customer 2 Peers-C2 Peers-C2
@mlsmaycon commented on GitHub (Jul 15, 2022): @jurgenhaas The two requirements you have should be possible to configure, we still have the bi-direction limitation, but that shouldn't be a reason for you to have peers from one customer to access peers from another customer. Below is an example of a configuration: Assuming the following groups: |Group Name|Description ---|--- |Managers| your admin group |Managers-C1|Managers from customer 1 |Managers-C2|Managers from customer 2 |Peers-C1|Peers from customer 1 |Peers-C2 |Peers from customer 2 You can set up the following rules to archive the requirements: |Rule Name|Sources|Destination ---|---|--- |Managers to Customers|Managers|Peers-C1, Peers-C2 |Customer 1 Managers Access|Managers-C1|Peers-C1 |Customer 2 Managers Access|Managers-C2|Peers-C2 |Mesh Customer 1|Peers-C1|Peers-C1 |Mesh Customer 2|Peers-C2|Peers-C2
saavagebueno commented 2025-11-20 05:07:04 -05:00
Author
Owner
Copy Link

@mlsmaycon commented on GitHub (Jul 15, 2022):

Forgot to mention, if you haven't yet, make sure you have removed the Default rule as it is very permissive!!

@mlsmaycon commented on GitHub (Jul 15, 2022): Forgot to mention, if you haven't yet, make sure you have removed the Default rule as it is very permissive!!
saavagebueno commented 2025-11-20 05:07:04 -05:00
Author
Owner
Copy Link

@jurgenhaas commented on GitHub (Jul 15, 2022):

Hmm, so far so good. But couldn't then Managers-C1 connect to Peers-C1 and from there connect to Managers? Because the first rule allows connection from Managers to Peers-C1 and also the other way round, doesn't it?

@jurgenhaas commented on GitHub (Jul 15, 2022): Hmm, so far so good. But couldn't then Managers-C1 connect to Peers-C1 and from there connect to Managers? Because the first rule allows connection from Managers to Peers-C1 and also the other way round, doesn't it?
saavagebueno commented 2025-11-20 05:07:04 -05:00
Author
Owner
Copy Link

@mlsmaycon commented on GitHub (Jul 15, 2022):

They could and if managers are more than just user machines, with services running, this would represent a risk.

In that case, unfortunately, you need some manually add/remove peers from groups on demand, at least until we don't deliver the protocol + port capabilities to AC Rules which is due in Q3/2022.

@mlsmaycon commented on GitHub (Jul 15, 2022): They could and if managers are more than just user machines, with services running, this would represent a risk. In that case, unfortunately, you need some manually add/remove peers from groups on demand, at least until we don't deliver the protocol + port capabilities to AC Rules which is due in Q3/2022.
saavagebueno commented 2025-11-20 05:07:05 -05:00
Author
Owner
Copy Link

@jurgenhaas commented on GitHub (Jul 15, 2022):

OK, makes sense.

Maybe this was asked elsewhere already: why are rules bi-directional in the first place? Wouldn't things be so much easier and still provide the same flexibility without that "feature"?

@jurgenhaas commented on GitHub (Jul 15, 2022): OK, makes sense. Maybe this was asked elsewhere already: why are rules bi-directional in the first place? Wouldn't things be so much easier and still provide the same flexibility without that "feature"?
saavagebueno commented 2025-11-20 05:07:05 -05:00
Author
Owner
Copy Link

@mlsmaycon commented on GitHub (Jul 15, 2022):

Rules are a composition of local peer Firewall management and Wireguard tunnel management. We have implemented only Wireguard tunnel management. The next step for protocol + port capabilities is basically implementation of local peer Firewall management

@mlsmaycon commented on GitHub (Jul 15, 2022): Rules are a composition of local peer Firewall management and Wireguard tunnel management. We have implemented only Wireguard tunnel management. The next step for protocol + port capabilities is basically implementation of local peer Firewall management
saavagebueno commented 2025-11-20 05:07:05 -05:00
Author
Owner
Copy Link

@boospy commented on GitHub (Apr 8, 2023):

So what's the status here? Is it already possible to allow traffic in one direction only?

@boospy commented on GitHub (Apr 8, 2023): So what's the status here? Is it already possible to allow traffic in one direction only?
saavagebueno commented 2025-11-20 05:07:05 -05:00
Author
Owner
Copy Link

@mlsmaycon commented on GitHub (Jun 16, 2023):

@jurgenhaas @boospy since v0.21.0 we are supporting direction traffic control for UDP and TCP. Please have a look at our docs: https://docs.netbird.io/how-to/manage-network-access

@mlsmaycon commented on GitHub (Jun 16, 2023): @jurgenhaas @boospy since v0.21.0 we are supporting direction traffic control for UDP and TCP. Please have a look at our docs: https://docs.netbird.io/how-to/manage-network-access
saavagebueno commented 2025-11-20 05:07:05 -05:00
Author
Owner
Copy Link

@jurgenhaas commented on GitHub (Jun 16, 2023):

Thanks @mlsmaycon for the heads-up, I'll have a look asap.

@jurgenhaas commented on GitHub (Jun 16, 2023): Thanks @mlsmaycon for the heads-up, I'll have a look asap.
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
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#149
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?