WonderLAN Architecture — Major Working Parts

A number of months ago I came across The Promised LAN, which is basically three buddies in Washington DC who decided to link their home networks together into one giant “LAN Party” via strongswan and BGP. It was a pretty cool read, even if I categorically reject their definition of what constitutes a LAN Party. My brother and I decided to do something similar, with a few key differences. Canada’s WonderLAN (a play on Canada’s Wonderland is more akin to a federated mesh of LANs rather than the centralized hub-and-spoke model that TPL adopted.

In an effort to encourage similar LAN experiments, here’s an overview of how WonderLAN works.

Addressing

We (society) aren’t quite ready yet to leave IPv4 completely behind, but we’re almost there. In the meantime, wonderlan runs on v4 and v6. Under our “federated mesh of LANs” topology, each site’s network policies can vary considerably, but for easy troubleshooting and interop we agree on a couple of conventions.

  1. WonderLAN runs in 10.0.0.0/8 with each site getting its own /16 to do with more or less as it pleases. This gives each site the freedom to have separate VLANs for IoT devices, home security, legacy hardware that doesn’t speak v6, etc.
  2. Each site runs authoritative DNS and BGP on 10.x.0.2
  3. Each site runs the wireguard tunnel on 10.x.0.3

And that’s it. The rest (default routes, recursive DNS, etc.) gets handed out via DHCP which on my network is at 10.x.0.1 but could be anywhere.

For v6 it’s even easier. We simply chose a ULA /48 prefix, and each site gets its own /56/, with the v4 site number encoded in the third hextet. So for example if my v4 /16/ was 10.10.0.0/16 then for simplicity’s sake we’d do fd42:4242:0a00:/56, since 0x0a is 10 in hex. Then the rest follows in the same way. DNS and BGP on fd42:4242:xx00::2, wg on fd42:4242:xx00::3, etc.

Split-Horizon DNS

Wonderlan is globally-routable/public and that apex zone acts as an ersatz registry for wonderlan sites, conceptually similar to the relationship between IANA and the ccTLDs. Each site gets a subdomain in *.wonderlan.ca, and operates its own resolver authoritatively for that subdomain. For example, the site located on a street beginning with the letter C gets *.c.wonderlan.ca and operates unbound on a known address, and that machine handles all DNS queries originating from *.c.wonderlan.ca, as well as being authoritative for that site, so that I can set e.g. printer.c.wonderlan.ca, jellyfin.c.wonderlan.ca, and so on and so forth, without worrying about colliding with the same services at *.r.wonderlan.ca.

Wireguard

Each wonderlan site operates a wireguard endpoint that tunnels traffic between sites. Wireguard configs are coordinated by a central server running a clean-room reimplementation of the Tailscale coordination server that I wrote, called Failscale. Wireguard gives us encrypted point-to-point links between participating sites, and it’s the transport layer for all the other services like DNS and BGP.

Inter-Site Routing via BGP

Each site operates a BGP server (typically OpenBGPD) and advertises routes to the rest of the peer sites over the wireguard link. Since each site is responsible for its own DNS, we just advertise our v4 and v6 routes over the wireguard link on the private ASN range, and DNS magically takes care of everything, and allows easy incremental growth when we add a new LAN.