netbird
netbird copied to clipboard
netbirdio
How to setup multiple isolated meshs/groups
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?
@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 |
Forgot to mention, if you haven't yet, make sure you have removed the Default rule as it is very permissive!!
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?
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.
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"?
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
So what's the status here? Is it already possible to allow traffic in one direction only?
@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