Site-to-site WireGuard for small offices: do less routing, not more

The worst site-to-site VPNs succeed technically and fail architecturally.

Packets flow. Pings work. Everyone celebrates. Six months later, every office, every VPC, and every forgotten printer can talk to everything else because "that was the easiest way to make the tunnel work."

Do not build that network.

If you are connecting small offices, cloud networks, or on-prem segments in 2026, the right question is not "how do I tunnel everything?" It is "how little routing can I get away with?"

Start with the better option: agents on the endpoints

Before you reach for site-to-site routing, ask whether the important machines can just run a client.

Tailscale's subnet router docs say this plainly: installing the client directly on each device gives you the best security and performance. Routed subnets exist for the cases where direct installation is not practical.

That is the correct default for any modern team network:

• agents on servers
• agents on laptops
• routers only for legacy devices and unmanaged subnets

If a server can run an agent, putting it behind a gateway is usually a convenience shortcut, not a security improvement.

Use site-to-site only for the parts that cannot move

Good candidates for routed connectivity:

• office printers and cameras
• NAS appliances
• old Windows boxes nobody is ready to touch
• IoT or lab gear
• whole VPCs where agent rollout is not realistic yet

Bad candidates:

• production Linux servers you fully manage
• admin laptops
• small internal tools that would be better behind an application proxy

The goal is to shrink the routed footprint over time, not make it permanent by habit.

Routes are not permissions

This is the mistake that turns a reasonable routed design into a flat private internet.

Tailscale's route injection docs are explicit: route presence and access control are different layers. A route can exist even when access is denied, and access policy can allow something that never becomes reachable because no route is present.

That is useful because it means you should think in two steps:

1. Which networks should be reachable at all?
2. Which users or groups should be allowed to talk to them?

Do not answer both questions with one giant CIDR.

A sane small-office pattern

For most small teams, this shape works:

• one gateway per office or VPC
• only the truly needed subnets advertised
• a separate route or group for infrastructure services
• clients accept only the routes they need
• no full-tunnel internet routing unless you intentionally want an exit path

If you are using a mesh overlay, this maps cleanly to subnet routers or routed networks. NetBird's Network Routes docs describe the same idea from a different angle: a routing peer forwards packets between the mesh and internal LANs, VPCs, or data centers, and high availability comes from multiple peers advertising the same route set.

That is the pattern to copy, even if you are building with raw WireGuard.

A minimal WireGuard baseline

If you are doing a traditional site-to-site tunnel between two gateways, keep it boring:

• Site A LAN: 10.20.0.0/24
• Site B LAN: 10.30.0.0/24
• Tunnel network: 10.255.0.0/30

Site A gateway:

[Interface]
Address = 10.255.0.1/30
ListenPort = 51820
PrivateKey = <site-a-private-key>

[Peer]
PublicKey = <site-b-public-key>
Endpoint = site-b.example.com:51820
AllowedIPs = 10.255.0.2/32, 10.30.0.0/24
PersistentKeepalive = 25

Site B gateway:

[Interface]
Address = 10.255.0.2/30
ListenPort = 51820
PrivateKey = <site-b-private-key>

[Peer]
PublicKey = <site-a-public-key>
Endpoint = site-a.example.com:51820
AllowedIPs = 10.255.0.1/32, 10.20.0.0/24
PersistentKeepalive = 25

Then add the real requirements around it:

• enable forwarding
• restrict firewall paths
• add only the routes you intend
• log access at the application or bastion layer where possible

The tunnel is the easy part. The route scope is the hard part.

Overlapping subnets are a tax on your future

If two sites both use 192.168.1.0/24, you can sometimes paper over it with translation tricks or overlay-specific features. Tailscale, for example, has 4via6 subnet routers for overlapping IPv4 situations.

But if you have the ability to renumber, renumber.

Overlapping subnets are one of those problems that always feel "solved for now" and never stay solved for long.

The most boring answer is usually the best one:

• office A: 10.20.0.0/24
• office B: 10.30.0.0/24
• office C: 10.40.0.0/24

Predictable addressing beats clever translation.

High availability is nice, but clarity matters first

Yes, redundant routers are useful. Both Tailscale and NetBird support high-availability routing models.

But do not start by duplicating gateways if you still have not decided which subnets should be reachable. Premature HA on top of vague routing policy only makes troubleshooting harder.

Get one clean route working first:

• one gateway
• one subnet
• one group of users
• one clear access policy

Then add redundancy.

The anti-patterns to avoid

• Advertising 10.0.0.0/8 because you were in a hurry
• Sending all internet traffic through the office tunnel by default
• Using routed subnets to avoid deploying agents to manageable servers
• Forgetting that DNS servers behind the routed subnet also need reachability
• Treating every office as equally trusted once the tunnel is up

These are not edge cases. They are how most "temporary" site-to-site designs become permanent messes.

The RouteHarden opinion

Site-to-site WireGuard is still useful. It is just not the first or best answer for every private resource.

Use agents where you can. Use routed subnets for the devices and networks that truly need them. Keep route advertisements small. Keep access policy separate from reachability. Renumber overlapping subnets if you have the chance.

Do less routing, not more.

That is how you keep a small-office network from turning into the exact flat VPN you were trying to leave behind.