NetBird Part 4 - Reaching the Things That Cannot Run the Agent

The series so far built a governed mesh: peers find each other, a control
plane you run coordinates them, and access policies decide who reaches
what. But everything so far assumes the thing you want to reach is a peer,
a machine running the NetBird agent. Plenty of what you actually need to
reach cannot run an agent at all. A network printer. A NAS. A managed
database. An IoT device. A legacy appliance whose vendor vanished. An
entire subnet in a datacenter or cloud VPC full of resources you are not
going to install anything on.

This post is about reaching those. The mechanism is a routing peer, and
the 2026 version of it is cleaner than what older guides describe, because
NetBird changed how this works in a way that happens to fix the sharp edge
I flagged at the end of part three.

The Routing Peer

The idea is simple. You cannot put the agent on the printer, but you can
put it on a machine that sits on the same network as the printer. That
machine becomes a routing peer: a normal NetBird peer that also forwards
traffic between the mesh and the local network behind it. A Raspberry Pi on
your home LAN, a small VM in your datacenter, a pod in your Kubernetes
cluster. It runs the agent, it joins the mesh like any peer, and it
advertises "I can reach the 192.168.1.0/24 network behind me."

Once that route exists and is distributed to the right peers, those peers
can address anything in that subnet directly, as if they were on the local
network, and the routing peer forwards the packets. Your laptop, from a
cafe, reaches the NAS at its home LAN address, and the traffic goes
encrypted over the mesh to the routing peer at home, which hands it to the
NAS on the local network. The NAS has no idea NetBird exists. It just sees
a connection from the routing peer.

One thing to keep straight from the start: a route grants access to the
network behind the routing peer, not to the routing peer machine itself.
If you also want to reach a service running on the routing peer, that is a
normal peer-to-peer policy to the routing peer's own group, separate from
the route.

Networks Replaced Routes, and That Matters

Here is the important 2026 change, and it is the reason to not just copy an
older tutorial. NetBird used to call this feature Network Routes, and
Network Routes had exactly the trap I warned about in part three: unless
you explicitly attached ACL groups, a route ignored access control and
granted every peer that received it unrestricted access to the whole
destination subnet. The secure thing required an extra manual step, which
meant the insecure thing was the default, which is backwards.

NetBird fixed this by introducing Networks as the successor. A Network
models the thing properly: it is a private environment, with resources
inside it, reached through one or more routing peers, and governed by the
same per-resource access policies as everything else. Access control is not
a bolt-on you might forget; it is how a Network works. You say which groups
may reach which resources, in the same policy model from part three, and
the routing peer just carries the traffic that policy already permits.

The practical consequence: the old caveat is gone if you use Networks.
Network Routes still exist and still work, they are deprecated and kept for
exit nodes and a couple of niche cases, but for reaching internal resources
you use Networks, and access control comes for free and by default instead
of as a step you have to remember. If you read a guide that walks you
through Network Routes and ACL groups for internal access, it is describing
the old way. Use Networks.

High Availability Is Just More Routing Peers

The routing peer is a single point of failure by nature: if the Pi at home
reboots, the route through it dies and the NAS becomes unreachable. The fix
is built in and worth using for anything you depend on. Assign more than
one routing peer, or a whole group of them, to the same network. NetBird
sees multiple paths to the same subnet and makes them highly available
automatically.

Each client connects through its lowest-metric, best-connection routing
peer, and if that peer goes offline, traffic fails over to another one
without you doing anything. In a Kubernetes cluster you run a pool of
routing-peer replicas spread across nodes, and a node failure takes out one
and the clients move to the rest. For a home or small setup, two cheap
boxes advertising the same network is enough to turn "the route dies when I
reboot the Pi" into "nobody notices." High availability here is not a
separate feature to configure, it is a consequence of having more than one
routing peer, which is the right way for it to work.

Masquerade, or Who the Remote Network Thinks You Are

One detail that matters more in some environments than people expect:
masquerade. By default, the routing peer NATs the forwarded traffic, so the
subnet behind it sees connections coming from the routing peer's own IP,
not from the original mesh client. This is the convenient default, because
the remote network does not need any routes back toward your mesh for
return traffic to work, it just replies to the routing peer, which it
already knows how to reach.

The cost is that the original source is hidden. From the perspective of the
NAS, or the audit log of the thing being accessed, every connection appears
to come from the routing peer, regardless of which of your twenty peers
actually made it. If you need accurate source-IP visibility, which in a
regulated or security-audited environment you often do, you disable
masquerade and preserve the original source IPs, at the cost of having to
ensure the remote network has return routes back to the NetBird range.
Convenience by default, source accuracy when you need it and are willing to
handle the return routing. Knowing the trade exists is the point; the wrong
default here quietly destroys your ability to tell who did what.

Exit Nodes: Routing All Traffic, Not Just a Subnet

The same routing machinery, pointed at the whole internet instead of one
subnet, gives you an exit node. Instead of advertising 192.168.1.0/24, a
peer advertises the default route, 0.0.0.0/0, and the peers distributed to
it send all their internet traffic out through that machine. Your laptop in
a cafe routes its entire internet connection through your box at home, and
the world sees your home IP, not the cafe's.

This is the one case that still uses the older Routes mechanism rather than
Networks. The uses are the obvious ones: own your egress instead of trusting
a commercial VPN, appear to be in a specific location, or force
remote-worker traffic through corporate egress for compliance. Two honest
cautions. An exit node can reach any network the exit machine can reach,
including its local LAN, so enable Block LAN access unless you specifically
want exit-node users touching the exit's home network. And an exit node
carries all of someone's traffic, so it is a position of real trust and a
real bandwidth load on that one machine; scope which peers use it
deliberately.

The Point

The mesh covers machines running the agent, but the routing peer extends it
to everything that cannot: a peer that sits on a local network and forwards
traffic into it, so the printer, the NAS, the legacy box, and the whole
cloud subnet become reachable over the mesh without installing anything on
them. In 2026 you do this with Networks, not the old Network Routes, and
that is the upgrade that matters, because access control is now built into
the model instead of a step you can forget, which closes the one real sharp
edge the earlier approach had.