Connecting two distinct Netbird networks to each other via gateway/router?

I have an environment with several separate netbird networks and thinking about ways to interconnect those.

This is not about switching profile, but connecting two netbird networks via a gateway/router.

I wonder if somethhing like the following is possible. I have not yet tried it out, though. Just idle thinking at the momemt. Playing around with some ideas

  • Netbird network A with a routing peer (A1) on an own docker container
  • Netbird network B with a routing peer (B1) on an own docker container
  • Both routing peers (A1, B1) are connected via private docker network to a FRRouter docker container (R)
  • Once A1 connects, it gets available routes and peers based on Netbird A policies
  • Once B1 connects, it gets available routes and peers based on Netbird B policies
  • FRRouter would get the routes via OSPF and hence routes according to the configuration.
  • I believe this is something about FRR’s zebra daemon which gets the routes of the wireguard interface on A1 and B1. Using a Dockerfile that builds A1 and B1 from frrouting/frr:v9.1.0 and installs netbird should probably already make sure that the routes can be extracted via “redistribute kernel”
  • A1 and B1, as well as R should have ip forwarding allowed.
  • OSPF setup to dynamically announce the correct routes.
  • Routes to be announced to the other side are based on the routes either netbird client receives. And that is dependant of the policies set in A and B respectively.

Possible problems:

Duplicate IP Address/subnet leading to routing issues. I do not know how IP assigning to netbird clients work in detail, but since a Netbird network is usually selfcontained, there might be a chance that several instances assign the same IP address to nodes. It’s a similar issue like trying to connect two identical home subnets via VPN.

Policy rules apply to one Netbird instance only. So, the policies need to be very carefully crafted on both sides. Since I have control over both sides, that risk should be controllable.

Beside that, would something like that actually fly?

Dan

Are you running Netbird via the cloud or self-hosted instances?

With the self-hosted, you can change the Netbird network subnet to be any private address range. That way you could get around the duplicate IP address possibilities.

Good point. Currently I have a mix between selfhosted and MSP setup.

Your idea drives me a bit closer to a fully selfhosted environment. MSP is super easy to setup and maintain, but has it’s cost.

On the other hand, I am still playing with the idea on interconnecting netbird networks. It would make it easier to manage server endpoints as MSP from a central point of view.

The benefit of MSP is the multiple tenancies/customers. Self hosted is just a single customer/tenancy.

But being able to edit the subnet is definitely an advantage.

Yes, that is why we use an MSP account.
But this topic is more about the idea to interconnect separate Netbird networks.

For us this would make automated support easier.

Instead having to setup IPSec VPNs from our Routers to theirs, I could interconnect our management platforms (i.e. Zabbix, Ansible, etc) via Netbird. Much easier, especially for smaller customers.

Using one big Netbird instance is not what we look for either. Too many disadvantages…

I can see that. I have been thinking about this myself lately.

A feature similar to the Tailscale ability to share a device from one network to another would be useful. I don’t have anything yet though…