2-1: The Lighthouse

In the previous Unit, we explored the basics of connecting Wireguard nodes. However, the network we built only works when every node can directly connect to every other node. Think of this as “line of sight.” If all the nodes are in the same subnet, or accessible behind the same router, our setup works great.

flowchart
  A[Peer A] --> B[Peer B]
  B --> C[Peer C]
  A --> C

But what happens when the nodes can’t all see each other? Imagine I want to create a Wireguard network with my family to securely share photos. Nodes in my house can see one another just fine, but family members who don’t live with me can’t see those devices!

The two homes’ networks are isolated from the general internet, and therefore from each other. In order to send messages from one to another, we need a relay somewhere on the internet that’s visible from both home networks.

We’ll call that relay a “lighthouse.” Why? Mostly because it sounds cooler than relay, and it connotes visibility.

In a Lighthouse model, the lighthouse is the single [Peer] entry in every other Peer’s config. The lighthouse is then responsible for properly routing the traffic to the right connected Peer.

In essence, the lighthouse is a router, but only for Wireguard traffic.

flowchart
  subgraph internet [Internet]
  C[Peer C] <--> L[Lighthouse]
  end
  subgraph home1 [Home Network A]
  A[Peer A] <--> L
  end
  subgraph home2 [Home Network B]
  B[Peer B] <--> L
  end

  style internet fill:blue
  style home1 fill:purple
  style home2 fill:maroon

Lighthouse Configuration

There is exactly one new change for our Lighthouse Peer to serve its role: it needs IP packet forwarding enabled. There are multiple methods to enable this setting on Linux systems. However, because we are running inside of a container, we will set this configuration within the container specification in podman-compose.yml.

Peers

The Lighthouse will have listed Peers in its configuration, just as before. But the Lighthouse Peer entries will not have Endpoint directives. That’s because the Lighthouse won’t be making outgoing handshakes! It is acting as a server, receiving and routing communications rather than initiating connections.

Peer Configuration

In the last network, each Peer needed [Peer] listings for every other member of the Wireguard network. Not only does that scale very poorly (imagine adding 100+ Peer entries to every new network member), but in the case of a Lighthouse model, it’s not necessary. Because we are providing the Lighthouse, with a guaranteed (to the best of our ability) line-of-sight from all Peers, the only [Peer] entry everyone else needs is the Lighthouse itself. Only the Lighthouse needs an entry for every known Peer.

Okay, enough theory. Let’s light the beacon!

Check For Understanding

• Why can’t nodes on separate networks connect directly to each other?