Netbird vs Tailscale for Two Households: When the Overlay Fights Your VLANs

Two households on one overlay sounds like a weekend. Each house already has a LAN, an IoT VLAN, and a guest SSID that is not supposed to see the NAS. Then someone advertises “the home prefixes” into Tailscale or Netbird so a travel laptop can print and check cameras. The overlay does what it was told. It also punches a hole through the isolation you spent a Saturday drawing on a napkin. The fight is not WireGuard versus WireGuard. It is an overlay that does not know your VLANs are a security boundary. If you have not yet decided whether a mesh belongs in the house at all, Tailscale versus a traditional VPN is the earlier fork.

Netbird versus Tailscale for this job is a control-plane and policy story. Both will move packets. Both will happily route 192.168.10.0/24 from house A into house B if you advertise it. Both will look “down” when those prefixes already exist on the cafe LAN. I have done this with both products. The second house is where the diagram goes from cute to hostile.

What two households actually need

A shared set of humans. A few servers that should be reachable: a NAS, maybe Home Assistant, maybe a jump host. Not a full merge of two broadcast domains. Not IoT cameras from the in-laws appearing on your phone’s “local network” tab. Not guests at house B reaching your VLAN 20 because a subnet router was generous.

Site-to-site VPN people already know this. They route specific prefixes and they put ACLs on the interesting ports. Overlay fans skip that because the admin UI makes “add route” a checkbox. The checkbox is how isolation dies.

Where Tailscale is easier, and where it is sloppy

Tailscale’s enrollment is still the household winner. Relatives install an app. You tag devices. ACLs can say house-A-admin can reach house-B-nas. Subnet routers advertise prefixes you accept. MagicDNS names are familiar.

Sloppy is the default grant that lets every node see every node, plus a subnet router that advertises the whole RFC1918 soup because both houses used 10.0.0.0/24 internally for “IoT” and you thought a bigger prefix was simpler. Clients pick a route. The wrong 10.0.0.50 answers, or nothing does. You debug firewalls. The overlay is doing longest-prefix and your identity plan did not include “two sites, same numbers.”

Renumber one house before you overlay them. I said this about cafe collisions. Two houses are a permanent cafe collision. House A keeps 10.40.0.0/16. House B keeps 10.50.0.0/16. Advertise only the server VLAN from each, not IoT, not guest. If a camera must be reached, put a client on a jump box in that VLAN or publish a reverse proxy you intend to publish. Do not advertise 10.40.20.0/24 to the other family because a dashboard was pretty.

Tailscale ACLs can express “tag:house-b cannot initiate to tag:house-a-iot” only if you did not flatten those networks into one advertised blob. Tags on subnet routers are not a substitute for prefixes you never should have shared.

Where Netbird is the better control freak

Netbird is the overlay people pick when they want WireGuard, an open management plane, and policies that feel like a tiny corporate mesh. You can self-host the management and signal. You can also use their cloud. For two households that already dislike a single vendor seeing both site graphs, self-hosted Netbird is the consistent choice — with the same control-plane tax I wrote about for Headscale. If nobody at house B can revive the management VM, you did not build independence. You built a bus factor of one.

Policies in Netbird are groups and rules. Used well, they are clearer than a Tailscale ACL file you are afraid to touch. Used poorly, they are a default allow plus a route to 0.0.0.0-adjacent thinking. The product will not stop you from bridging IoT to IoT across town.

DNS is the other fight. Each house has Pi-hole or AdGuard on a VLAN-only address. The overlay wants its own names. Split DNS that works on a travel laptop is a project: resolve ha.house-a.internal through the mesh without sending house-B IoT queries to house-A’s filter, and without leaking guest names. If you point all clients at one Pi-hole across the overlay, you just made that Pi-hole a cross-site dependency and a privacy mash-up of two families’ query logs. Two resolvers, two suffixes, no shared “just use 10.40.1.53 for everything.”

The overlay-versus-VLAN failures

Multicast and “local” apps. Chromecast, AirPlay, printer discovery, and a lot of camera apps assume L2. The overlay is L3. People enable a subnet route and then say Netbird or Tailscale “broke VLANs” because the living-room TV does not appear. It never would. Use a client on-site, a dedicated reflector you understand, or give up discovery and use names. Do not stretch IoT L2 across cities. That sentence is the article.

Return path and firewalls. A packet from house-B laptop to house-A NAS arrives via the subnet router. The NAS sees a source in 100.x or in house-B’s server VLAN. IoT VLAN ACLs on the switch never saw this flow when everything was local. You add a messy allow. Two months later the allow is how a compromised travel laptop talks to a camera you thought was isolated. Log the exception. Prefer a jump host in the server VLAN to a general route into IoT.

Asymmetric routing. Both houses run subnet routers. A third node has its own client. Packets leave one path and try to return another. Stateful firewalls drop the return. This looks like VLAN isolation “working” when it is just conntrack being confused. Draw the path. One designated router per prefix.

Guest networks. Never advertise them. If you need to admin a guest AP, use the AP’s cloud or a management VLAN you intended to expose. Guests plus a second household is how you get a story you do not want to tell.

A two-house layout I will defend

Unique prefixes. Server VLAN only on the overlay. IoT stays local. Guests stay local. One subnet router per house, always-on, not a desktop. ACLs default deny between sites except tagged humans to tagged servers on specific ports. DNS suffixes per house. No shared Pi-hole. Monitoring on the subnet routers from the other site so a dead router is a page, not a mysterious VLAN.

Pick Tailscale if the humans need an app store install and you accept their control plane. Pick Netbird if you will staff a management plane and you want the policy UI. Do not pick both and dual-home the same phone. Do not pick either as an excuse to flatten VLANs you already isolated.

If the real need is two or three named services, install the overlay client on those hosts and skip subnet routes. The VLAN fight often starts because someone wanted “the whole house” in a mesh. The whole house is the thing you isolated.

When a boring site-to-site still wins

If both houses have a router that can do WireGuard with static prefixes and you will not add casual devices, a pair of tunnels without a mesh control plane can be less surprising. No MagicDNS. No accidental node-to-node. You route 10.40.10.0/24 to 10.50.10.0/24 and you stop. Overlays shine when laptops appear and disappear. They shine less when you needed a /24 and a firewall rule.

I use an overlay for people. I use a tight prefix list for sites. When those two are the same config screen, I slow down.

Exit nodes make this worse. A laptop at house B that “uses house A as exit” sends all internet via house A and can, depending on LAN access checkboxes, also see house A the way a resident would. That is a different product than “I need the NAS.” If you enable it, write down that house B traffic now egresses on house A’s ISP bill and house A’s threat model. Two households rarely want that. One traveler sometimes does. Do not leave it on as a default for tagged family phones.

Key expiry and offboarding are the last VLAN-adjacent mess. A cousin’s laptop stays in the ACL group after the visit. The subnet route is still there. You isolated IoT from guests on the switch and then left a mesh identity that bypasses the switch. Review nodes when people leave the holiday. Tailscale and Netbird both make this a calendar problem, not a packet problem.

The close

Netbird and Tailscale will both connect two households. They will both fight your VLANs if you advertise isolation away. Renumber, route only the server nets, keep IoT local, and write ACLs as if the other house is a friendly but untrusted ISP.

The overlay is a WAN you own. VLANs are still the LAN policy. When those layers disagree, the living room will blame the mesh, and the cameras will be reachable from a train in a way you cannot honestly call a feature. If you cannot draw the prefixes on paper without overlapping crayons, do not click advertise yet. Renumber first. The overlay will wait. The collision will not.