Two LANs on NetBird: which peers route, and who may talk

A workstation on the west LAN opens a browser, types the address of an application on the east LAN, and waits until it times out. Every NetBird screen says the peers are connected, which is true and beside the point: being in one overlay network is not the same as having the two local subnets in one network. The walk below starts at that workstation and ends with a request the design refuses on purpose, and each stop is something you can read off a device rather than infer. Expect the missing piece to be a route or a policy, not the overlay.

Read the failure from the workstation first

Before opening the management console, establish what the workstation actually sends. Its own routing table decides whether the packet goes to the site gateway, to a local interface, or nowhere, and that decision is visible without any overlay tooling. A machine with no route for the far prefix will fail however healthy the peer list looks. The overlay range and the site's own prefix are different address spaces, and enrolment configured only one of them.

Separate name resolution from reachability next, because a browser reports both as the same timeout. Repeat the request by address from a machine that runs the NetBird client, then from an ordinary workstation that does not. If the enrolled machine succeeds and the plain one fails, the gap sits in local routing; if both fail, keep reading before you change a route.

Pick one routing peer per site

A routing peer is a host that stands in for its LAN on the overlay, so choose a Linux machine with stable reachability to the subnet rather than someone's desk workstation. Enrol it through the normal process and put it in a group named for the role, because the network resource and the policy will both refer to that group. One representative per site stays legible; a fleet of volunteers advertising the same prefix turns every later question into a debugging session. The peer's address on the local segment matters as much as its overlay identity, since that address becomes the next hop every ordinary device is told to use.

Write the plan down before touching the console, because names and prefixes are where these designs drift: prefix, gateway, peer address and group, per site. West is 10.52.0.0/24 served by 10.52.0.5 and east is 10.63.0.0/24 served by 10.63.0.5, with west-routers and east-routers as the two groups, and neither prefix may overlap the other, the overlay range or another routed destination.

Create the resource, keep masquerading on

In the deployed dashboard, create one network resource per site and attach that site's routing-peer group to it. The resource is the prefix and the group is the host that answers for it, and both have to exist before anything is advertised. Confirm that the deployed self-hosted version has the Networks workflow at all, since an older interface with a similarly named route object is a different feature.

Leave masquerading enabled. The NetBird site-to-site guide requires it for this arrangement, and turning it off to keep every original address visible is not the same design with one fewer hop; it changes what the overlay's source checks and policies observe. The consequence is worth stating plainly: the receiving service records the routing peer as the source, not the individual workstation. If that service's allow list or audit expects workstation addresses, either the expectation changes or the identity has to be enforced at the site boundary before translation.

Authorise the initiators, not the prefixes

A route makes an address reachable and a policy decides who may use it; the two are separate objects with separate owners. Write the policy from the workload backwards: which group initiates, which resource it targets, and which TCP service it needs. A network that advertises both prefixes to every enrolled peer has created reachability and settled nothing.

Then read what else is already permitted, because a narrow new rule does not revoke a broad old one that sits above it. When east must also start connections to west, write that direction as its own policy; return traffic for a session west opened is a different question from allowing new sessions eastwards. If only some west workstations should reach the east application, select them at the site boundary before translation and keep the application's own authentication in place. The routing peer carries LAN traffic as the whole site rather than as a per-user overlay identity, so per-user accounting has to come from somewhere else.

Teach each gateway the next hop, then test a denial

The ordinary devices never see the overlay, so their own gateway needs a static route that points the far prefix at the routing peer's LAN address. That is the step people skip, because everything visible inside NetBird already works while plain workstations still time out. The gateway keeps its default route as it was; this prefix is an addition, not a replacement.

The two route descriptions belong in each site's own gateway configuration, not in a host override. Both are plain static routes, and neither touches the default route:

west gateway: 10.63.0.0/24 via 10.52.0.5
east gateway: 10.52.0.0/24 via 10.63.0.5

Test with the application the project actually needs, from an ordinary workstation, and record three things: the next hop chosen on the sending side, the policy that matched, and the source address the service logged. Test a refusal as well, because a design that has never denied anything has unknown edges, and the refusal is the only evidence that policy rather than routing is doing the work. When east must initiate too, start a fresh connection from that side instead of assuming the second direction follows. Plan the routing peer's restart, upgrade and replacement as well, since one host has become a site dependency.

Private names need their own resolver design, because reachability does not create DNS records and a working IP path with a broken name reads exactly like a broken path. If a routing peer runs inside a cloud network, review the provider's forwarding and firewall rules too, since enrolment does not override them. Keep the observations from the test next to the plan, because the next person to debug this will want the matched policy and the recorded source address, not a description of the topology.