Three sites in a mesh

With three locations the difference between a hub and a mesh is small: two tunnels against three. That is exactly why this shape gets chosen without much thought. At four locations it becomes six tunnels, at five it is ten, and by then the bill is visible.

When a mesh earns its complexity

A mesh is worth it when the traffic really does run between the branches. Three workshops using each other's file server, three offices with the phone system in one building and the bookkeeping in another: there, every path that goes through a third location is a detour with extra delay and one more device that can fail.

If each branch mostly talks to one central place, a hub with spokes is the calmer design. Fewer tunnels, fewer keys, one place to look when something is wrong.

The address plan

Each location gets its own rectangle on the network board with its own address range. The VLAN numbers stay the same everywhere; only the first two numbers differ.

The tunnels take their own addresses from 10.255.255.0: every new tunnel gets the next free /30, so .0, .4 and .8. Keep that block out of your own plan.

In the tool

1. Make one site with the three routers and everything hanging off them.
2. Draw three locations on the board and give each one its own address range.
3. Fill in the public address, or DNS name, on every router.
4. Right-click a router and pick Tunnel to. Do it three times: Amsterdam to Utrecht, Amsterdam to Breda, Utrecht to Breda. Each router then has wg1 and wg2.

Per tunnel the tool works out which networks sit on the other side: the VLAN subnets of the location that router stands in. Those networks land in the script as static routes and as the allowed-address of the WireGuard peer. With three tunnels, every router therefore knows both other branches directly.

That is the whole mechanism. There is no transit: a router never forwards on behalf of a third one. The mesh works because every pair has its own tunnel, not because something in the middle relays traffic.

Public addresses are the real limit

WireGuard needs at least one reachable side per tunnel. If neither router has a public address, the check reports it as an error: the tunnel does not know where to connect.

That makes the arithmetic concrete. If only Amsterdam has a fixed address and Utrecht and Breda sit behind CGNAT, then Amsterdam to Utrecht and Amsterdam to Breda are fine, but Utrecht to Breda cannot come up. What you have then is a hub, not a mesh, unless you arrange a reachable address for one of the two. The tool sets a keepalive of 25 seconds, so the side behind CGNAT keeps the connection open by itself.

If you use GRE, IPIP or EoIP instead of WireGuard the requirement is stricter: those tunnels need an IP address as their destination on both sides, not a DNS name. The check says so too.

What breaks when one link drops

This is the part that surprises people. A WireGuard interface never goes down: it exists from the moment it is created, whether or not anybody answers on the other side. The static routes the tool writes alongside it therefore stay in place.

If the line in Breda fails, Utrecht keeps handing traffic for 10.30.10.0/24 to wg2, where it disappears. Nothing reroutes via Amsterdam, even though Amsterdam is reachable and knows both networks. The tool does not generate a fallback path.

If you want one, there are two routes:

• BGP per tunnel. Give both routers an AS number on the board and switch BGP on for that tunnel. The tool then writes the BGP session over the tunnel address and leaves the static routes out; WireGuard still keeps those networks in its allowed-address, or the traffic would be dropped anyway. When the session goes away the routes go with it and the path through the third location takes over. Expect that to happen when the hold time expires, not instantly.
• Netwatch with scripts of your own. Have the router ping the tunnel address on the far side and change the route distance when it stops answering. That works, but those are rules you write, and they belong on the handover sheet.

After rolling out, check with /ip route print and /interface wireguard peers print whether the last handshake is recent; that handshake is the only real sign of life.

What the checks catch

• Two locations on the same address range, or two locations whose routers end up on the same subnets. In that second case the routes over the tunnel clash, and the tool says so.
• A location with devices but no router, or with two devices in a router role.
• A routed tunnel to a device that does not route, a switch picked as an endpoint by mistake, for example.
• Missing WireGuard keys, which happens in a browser without X25519.
• BGP switched on without an AS number on one of the two routers.

Further reading: Tunnels between locations, Two tunnels between the same locations and OSPF between locations.