Site-to-site networking

The whole site, one command

Any always-on box at each site becomes a subnet router: a mini PC in the closet, a VM on the hypervisor, a container on the firewall. One command advertises the LAN; one approval in the console makes it reachable by every node on the mesh.

✓No phase-1 proposals, no matching lifetimes, no MTU roulette
✓Dynamic IPs and NAT at the branch are simply irrelevant
✓Add site number ten: one more router, zero new tunnels

sites — advertised routes

hqoffice · 192.168.1.0/242 routesUP

dc-eastdata center · 10.10.0.0/164 routesUP

branch-chidynamic IP · 172.16.8.0/221 routeUP

lab-2campus · 10.44.0.0/161 routeUP

Roaming users ride the same network

There's no separate remote-access VPN to maintain alongside the site-to-site mesh. The laptop in the airport and the printer at the branch are on one network with one ACL file — site-to-site and remote access stopped being different projects.

# at the branch — advertise the LAN, done

$ openvlan up --advertise-routes=192.168.8.0/24

# admin approves once; everyone (and every site) can reach it

$ ping 192.168.8.14 # branch printer, from hq laptop

$ ssh 10.10.2.55 # dc server, from branch desktop

How sites join

Run a subnet router at each site

Any always-on box — a mini PC, a VM, the existing firewall if it supports containers. One command advertises the site's LAN.

Approve the routes

The tailnet admin approves each advertised range once. Every node — laptop or server — can now reach that LAN.

Route site-to-site

With multiple subnet routers, sites reach each other through the mesh: office A's clients can talk to data center B's servers directly.

Compared to classic site-to-site

	IPsec site-to-site	OpenVLAN subnet routers
Setup per site	Phase 1/2 config, matching proposals, MTU tuning	One command + one approval
New site	Mesh topology: N×(N−1)/2 tunnels or hub design	One more router — topology free
Behind NAT / dynamic IP	Often painful	Irrelevant — outbound only
Roaming users	Separate remote-access VPN	Same network, same ACLs
Crypto agility	Vendor-dependent proposals	AmneziaWG everywhere

Field-tested topologies

HQ + branches

Branch LANs advertised into the tailnet; staff at HQ reach branch printers and NAS boxes like local devices.

Office + data center

The classic pair — plus multi-cloud ranges on the same mesh when you're ready.

Lab + campus

Research networks spanning buildings without rewiring or dedicated circuits.

Retail chains

Every store's POS and back-office systems on one network; new locations join the day they open.

Manufacturing plants

Plant-floor networks reachable by engineering and MES systems — without punching the OT network onto the internet.

MSP multi-client

Agencies run each customer's sites as tagged, isolated tailnets — one tooling stack, zero cross-client leakage.

Site-to-site FAQs

What bandwidth can a subnet router handle?

A modest VM routes multi-gigabit traffic comfortably — it's AmneziaWG at kernel speed, not a userspace proxy. Most teams size for redundancy rather than throughput.

What if a site's router dies?

Run a second router at any site that matters; routes fail over automatically. Sites with a single router degrade to local-only until it's back — same as any network's single point of failure.

Do branch devices need the client installed?

No — regular devices at the branch keep working exactly as before. The router advertises their subnet; nothing changes on the endpoints unless you want them on the mesh individually.

Can we control which sites talk to each other?

Yes — ACLs apply to routed traffic too. "Branches may reach HQ and the data center, but not each other" is a two-line policy, not a re-architecture.

How does this handle sites with the same LAN range?

Identical ranges on two sites conflict like they always have — but unlike IPsec, you can resolve it with a NAT rule on one router or a small renumber of one site, without touching the other.

Site-to-site without the IPsec ceremony