WireGuard Site-to-Site vs a Mesh Overlay When Two Houses Share One Backup Target

The plan sounded adult. House A has the photos and the paperless archive. House B has a used NAS and a quieter power bill. Each night, restic or Syncthing or a Synology Hyper Backup job should land a copy across town. If one street loses a disk — or a house — the other still has last night.

Then you pick a tunnel. A mesh overlay will put an agent on the NAS, the backup box, maybe a laptop, and give you magic names that work from a cafe. A WireGuard site-to-site link will treat the two LANs as neighbors: whole subnets, stable addresses, the backup job talking to 192.168.40.10 like it lives in the other closet. Both can move bytes. They fail in different rooms.

I have run both for the same pair of houses. The overlay won the afternoon I needed to debug from a phone. The site-to-site won the month I needed a backup schedule that did not care which laptop was awake. If your product is “two households share one backup target,” the interesting question is not which logo is friendlier. For people-and-laptops across two houses, that overlay fight is Netbird versus Tailscale when the overlay fights your VLANs. It is whether the backup process should see a peer, or a network.

What the backup job actually needs

A backup is a picky guest. It wants a stable address, a predictable route, enough bandwidth that a nightly increment finishes before the next nightly increment starts, and a failure mode you can page. It does not want a node that vanishes when the “always-on” machine reboots into a Windows update. It does not want a CGNAT surprise on one side and a working public UDP port on the other. It does not want two kitchens both using 192.168.1.0/24 unless you enjoy rewriting every share path.

Mesh overlays are built for people and laptops. They shine when the set of machines changes, when you roam, when you do not want to touch the router. Site-to-site WireGuard is built for subnets. It shines when the interesting object is not a device but a prefix: the whole NAS VLAN, the IoT VLAN you should not be backing up, the lab VLAN you should.

If the backup target is one NAS, and the source is one other NAS, you can fake site-to-site with two overlay agents and a subnet router. You can also skip the overlay and put WireGuard on the two routers, or on two small boxes behind the routers. The second option has fewer moving identities. The first option has a control plane you did not write.

Site-to-site: two prefixes, one handshake

A classic WireGuard site-to-site is boring in the way plumbing is boring. Each side has a public key, an endpoint, and AllowedIPs that name the far LAN. The routers — or two Linux boxes that the routers forward to — keep a single tunnel up. Hosts on house A do not run a client. They ARP for their gateway. The gateway knows that 192.168.40.0/24 is through wg0.

That boredom is the feature for backups. The Synology job, the restic systemd timer, the rclone cron, they all keep the same destination they had when you tested on a Saturday. DNS can be a pair of split records or a static host file. You are not waiting for a coordination server to tell a subnet router that the NAS is still a peer.

The costs are real. Someone has to own the endpoint. If both houses sit behind CGNAT, neither side can be the listener unless you add a cheap VPS as a relay, at which point you have reinvented a mesh with more YAML. If one ISP blocks UDP or plays with timeouts, the tunnel flaps and the backup looks like a disk error. If you botch AllowedIPs, you blackhole a range and spend an evening blaming restic.

Overlapping RFC1918 is the amateur-hour failure that still happens to people who should know better. Two default ISP routers, two 192.168.1.0/24 LANs, one tunnel, and suddenly “the NAS” is also the other house’s TV. Site-to-site forces you to renumber one side before the first successful snapshot. A mesh overlay will let you postpone that pain until a subnet router starts leaking both kitchens into one table. Postpone is not the same as solve.

The overlay: agents, names, and a control plane

A mesh overlay — Tailscale, Headscale, Netbird, a plain WireGuard mesh you stitched yourself — puts identity on the node. The NAS is a peer. The backup box is a peer. Maybe a subnet router publishes house B’s LAN so a laptop at house A can hit a printer. The product is connectivity for whatever is running the agent, plus optional LAN extension if you turned that on and understood the ACL.

For two-house backups, the overlay is tempting because the first demo is fast. Install the agent. Tag the NAS. Copy a MagicDNS name into the backup UI. If both sides can do NAT traversal, you never open a port. If they cannot, the vendor’s relay saves the weekend and charges you in latency and policy.

The failure I keep seeing is not encryption. It is liveness. The backup target is “always on” until the Pi that runs the agent loses power, or the NAS app container restarts and comes back with a new node key you forgot to authorize, or an ACL update meant for a guest laptop also hid the NAS from the backup box. The job fails at 03:10. The overlay admin UI still shows green because some other device checked in. You have monitoring for people, not for a prefix.

Subnet routers look like site-to-site. They are not the same operational object. A site-to-site tunnel dies when the two endpoints die. A subnet router dies when that one host dies, even if the rest of the mesh is happy. If your backup path is “NAS A to NAS B via the subnet router on a used Mini PC,” that Mini PC is now more important than the pretty mesh graph. People forget and put it on Wi-Fi.

NAT, hairpin, and who can initiate

House A has a real public IPv4 and a router that will forward UDP 51820. House B has CGNAT. Site-to-site still works if B is the client and A is the listener. The backup can still run in both directions once the tunnel is up; initiation is not the same as data flow. This is the case where plain WireGuard is enough and an overlay is luxury.

Both sides on CGNAT is the case where the overlay’s relay — or your own VPS — stops being optional. You can build a WireGuard hub on a five-dollar VM and treat both houses as clients. That hub is a site-to-site with an extra hop. It is also a mesh with a node you control. Call it whatever you want. Budget the VPS as part of the backup, not as a clever trick.

Hairpin and NAT reflection bite when someone at house A tries to reach house A’s NAS using the house-B-facing name, or when a job runs on the NAS and tries to talk to itself through the tunnel. Overlays with MagicDNS make this easier to stumble into because names are global. Site-to-site with unique prefixes makes it rarer. Neither is immune if you reuse hostnames.

Bandwidth, encryption, and the nightly window

Two houses on ordinary fiber can saturate a tunnel with a first-year full backup. Incremental nights are fine until someone dumps a raw photo library or a Proxmox backup onto the same link. WireGuard on a router ASIC or a small x86 box will usually not be the bottleneck. The ISP uplink will. The overlay relay will, if you are on the relay.

I measure the path I will actually use at 02:00, not the iperf I ran from the couch. If the overlay falls back to a relay when NAT traversal fails, the nightly job inherits that path. Site-to-site either has a direct UDP path or it is down. Down is ugly. A silent relay is uglier, because the job “succeeds” at 400 kbps and is still running when the next job starts.

Wake-on-LAN across a mesh is a party trick. Wake-on-LAN across a site-to-site can work if you routed the right broadcast domain, which you probably should not. For backups, keep the target powered. If the target sleeps, neither tunnel design will save the schedule.

Security is not the slogan on the box

A site-to-site link is a trust decision about two prefixes. If house B’s IoT VLAN is in AllowedIPs, house A can now scan cheap cameras. If you only need the NAS, only route the NAS address or a storage VLAN. That discipline is available in both designs. Overlays make it an ACL tag. WireGuard makes it a prefix list. The failure is the same: people route 0.0.0.0/0 because a blog used it in a laptop-exit-node example.

I do not put backup credentials in a mesh identity and call that a backup policy. The NAS still needs its own user, its own snapshot permissions, its own “this key can write to /backups/house-a and nowhere else.” The tunnel is a pipe. The share ACL is the lock.

Guest Wi-Fi at either house should not inherit the tunnel. That sentence has ended more Thanksgiving visits than I will admit. Site-to-site on the main LAN without VLANs is how a visiting phone becomes a path to the other family’s disks. Fix the LAN first. Then pick a tunnel.

When I still use a mesh for the same two houses

I keep an overlay for humans: the laptop that needs to check a restore, the phone that needs to approve a 2FA prompt on the NAS UI, the week someone is in a hotel and the backup failed. I do not point the scheduled job at a MagicDNS name if I can point it at a stable prefix over a router tunnel. Humans roam. Cron does not.

If I cannot get a listener anywhere — two CGNATs, no VPS budget, no friend with a spare IP — the overlay’s relay is the product. I would rather a slow, understood relay than a WireGuard config that never completes a handshake. I would also rather add the five-dollar VPS. That is usually cheaper than a year of “why is the snapshot 12 hours late.”

If one house is a short-term rental or a family member who will not touch a router, the overlay wins because you can install an agent on the NAS and leave the ISP box alone. Site-to-site that requires admin on both routers is a political problem, not a crypto problem.

When site-to-site is the backup

I use WireGuard site-to-site when both houses have a box I can treat as infrastructure: a router that will keep a peer, or a fanless PC on ethernet that I will notice when it dies. I renumber one LAN if I have to. I route only the storage VLAN. I monitor the handshake age, not a mesh membership list. The backup software keeps numeric addresses or local DNS names that I control.

I test a restore across the tunnel on purpose. A green snapshot list on the source is not a restore. The first time you need house B, you will discover an MTU problem, a firewall that allowed ping and not the backup port, or a time zone that started the job during the other house’s upload-heavy window.

Two houses sharing one backup target is not a laptop problem. It is a prefix problem with a schedule. A mesh overlay will get you connected. A site-to-site link will get you a network you can point a timer at. Use the overlay for the people. Use the tunnel for the disks. If you can only afford one, pick the one the cron job can still see after a phone goes to sleep.