NetBird

This is the first post in a series. I have been running NetBird across
my machines for a while, and it is good enough, and interesting enough,
to be worth writing about properly rather than in one post. This one
sets up the concept. Later posts go into self-hosting the control
plane, access policies, routing, and the sharper edges. Start here for
the why.

The Problem It Solves

You have machines in different places. A server in a datacenter, a box
at home behind a residential router, a laptop that moves between
networks, maybe a VPS or two. You want them to reach each other
securely, and every classic way of doing it is annoying.

Port forwarding means poking holes in firewalls and exposing services
to the internet. A VPN gateway means routing all your traffic through
one box that becomes a bottleneck and a single point of failure. Plain
WireGuard is excellent, but the moment you have more than a handful of
machines, you are hand-maintaining a full mesh of keys and peer
configs, and every new machine means editing config on all the others.
And the machine behind the home router usually cannot be reached from
outside at all without more port forwarding.

NetBird makes that whole category of hassle go away. Your machines end
up on one flat, private, encrypted network where each can reach the
others directly, and you did not open a single inbound port to make it
happen.

What It Actually Is

NetBird is an open-source overlay network built on WireGuard. Two ideas
are worth pulling apart in that sentence.

Overlay network means it creates a second, virtual network on top of
whatever physical networks your machines are already on. Every machine
that joins gets a stable private address in the 100.64.x.x range and
can talk to every other machine at that address, regardless of where it
physically sits, what it is behind, or how its real IP changes. The
overlay does not care that one peer is in a datacenter and another is
behind three layers of home NAT. On the overlay they are neighbours.

Built on WireGuard means the actual encryption and tunneling is done by
WireGuard, the same fast, modern, in-kernel VPN protocol you would
reach for anyway. NetBird does not reinvent the crypto. It uses the
best available tunnel and solves the problem WireGuard leaves to you:
the coordination.

Why Mesh, Not Gateway

The design choice that defines NetBird is that it is a mesh, not a hub.

In a traditional VPN, every machine connects to a central gateway, and
all traffic flows through that gateway. Two machines talking to each
other send their traffic to the hub and back out. The hub is a
bottleneck, a latency tax, and a single point of failure, and it sees
all your traffic.

In a mesh, machines connect directly to each other, peer to peer. When
your laptop talks to your server, the packets go straight from one to
the other over a direct WireGuard tunnel, not through any central box.
There is no bottleneck, the latency is the real network distance
between the two peers and nothing more, and no central node is in the
data path watching everything go by. NetBird establishes these direct
tunnels even between machines that are both behind NAT, using
hole-punching techniques to get them talking without either one needing
a forwarded port.

Control Plane and Data Plane

The idea that makes this work, and the one worth understanding before
the later posts, is the clean split between the control plane and the
data plane.

The control plane is the coordination. A management service holds the
network state: which peers exist, what addresses they have, which ones
are allowed to talk to which. When something changes, a new machine
joins, a policy updates, it tells the agents. A signal service helps
two peers find each other and negotiate a direct connection. This is
the brain, and it is small.

The data plane is your actual traffic, and it does not go through the
control plane at all. Once two peers have been introduced by the
control plane, they talk directly, WireGuard to WireGuard, and the
management service is not in the path. Your data never flows through
the coordinator. If a direct connection genuinely cannot be
established, traffic falls back to an encrypted relay, but the default
and the common case is straight peer-to-peer.

This separation is why the whole thing is both secure and fast. The
coordinator knows who may talk to whom but never sees the traffic. The
traffic takes the shortest path but only between parties the
coordinator authorized. Control and data, cleanly apart.

Why Self-Host It

NetBird offers a hosted cloud, and it is a fine way to try the thing.
But the reason it earns a series on this blog is that you can host the
entire control plane yourself. The management service, the signal
service, the relay, all of it runs on your own server, and the
self-hosted Community Edition is free with no cap on users or devices.

That matters because of what the control plane is. It is the thing that
holds your network's membership and decides who can reach what. Handing
that to a third party means trusting them with the map of your entire
private network and the policy over it. Self-hosting means the
coordinator is yours, the policy lives on your server, and the peer
keys never leave your machines to begin with, because WireGuard keys
are generated locally and only the public half is ever shared. You get
the convenience of a managed mesh with none of the "someone else holds
my network" tradeoff. For a homelab, or for anyone who takes
sovereignty over their own infrastructure seriously, that is the whole
point.

Where This Series Goes

This post is the concept. NetBird is a self-hosted, WireGuard-based
mesh overlay: your machines get private addresses, find each other
through a control plane you run, and then talk directly over encrypted
tunnels with no gateway in the middle and no inbound ports opened.

From here the series gets practical. Standing up the self-hosted
control plane. Joining machines and what actually happens when a peer
registers. Access policies, so the flat network is not actually flat
but governed by rules about who reaches what. Routing traffic to whole
subnets through a peer. And the sharp edges worth knowing before you
depend on it. If you have ever hand-maintained WireGuard configs across
more than three machines, the next posts are for you.