Learn WireGuard - Multi-Peer & Hub Topology

#Introduction

After remote access, the question evolves: what if not only clients need to talk to the server, but clients also need to talk to each other? The answer depends on the topology. There are two main approaches — hub-and-spoke and full mesh — and they solve different problems.

Episode 11 compares both topologies practically: how to arrange the configuration, how traffic flows, and how much scaling cost each choice imposes on you.

#Hub-and-Spoke

#Everything Through the Center

In a hub-and-spoke topology, one node is the hub and all other nodes (spokes) only connect to the hub. Traffic between spokes travels two hops: from the source spoke to the hub, then from the hub to the destination spoke.

[Interface]
Address = 10.0.0.3/24
PrivateKey = <kunci privat spoke>
 
[Peer]
PublicKey = <kunci publik hub>
AllowedIPs = 10.0.0.0/24
Endpoint = 203.0.113.5:51820
PersistentKeepalive = 25

Notice the AllowedIPs = 10.0.0.0/24 value — the spoke considers the entire tunnel subnet owned by the hub, including other spokes' addresses. This is the simplest way for a spoke: one peer, one endpoint, and one route.

#The Hub Must Know All Spokes

On the hub side, each spoke is registered as a peer with its own AllowedIPs, so the hub can route traffic between spokes:

sudo wg set wg0 peer <PUBLIK_SPOKE_A> allowed-ips 10.0.0.2/32
sudo wg set wg0 peer <PUBLIK_SPOKE_B> allowed-ips 10.0.0.3/32

The hub must also forward packets between spokes. An nftables policy that accepts all wg0 traffic is sufficient for this:

table inet wg {
    chain forward {
        type filter hook forward priority 0; policy drop;
        iifname "wg0" accept
        oifname "wg0" accept
    }
}

#Full Mesh

#Everyone Connected to Everyone

In a full mesh, every node has every other node as a peer, and traffic flows directly without an intermediary. For three nodes, each node has two [Peer] sections; for five nodes, four [Peer] sections, and so on.

[Interface]
Address = 10.0.0.1/24
PrivateKey = <kunci privat A>
 
[Peer]
PublicKey = <kunci publik B>
AllowedIPs = 10.0.0.2/32
Endpoint = 203.0.113.2:51820
 
[Peer]
PublicKey = <kunci publik C>
AllowedIPs = 10.0.0.3/32
Endpoint = 203.0.113.3:51820

The advantages of full mesh are minimal latency and no single point of failure: if one node dies, the other nodes remain connected to each other.

#The O(n Squared) Scaling Cost

Full mesh's weakness shows as nodes grow. The number of connections to manage is the combination of node pairs: for n nodes you need n times n-1 divided by 2 connections. Each node stores n minus 1 peers, and every key change spreads to all nodes.

With 10 nodes there are 45 connections; with 50 nodes there are 1,225 connections. Updating a key on one node means updating it on the other 49 nodes. This is why full mesh is impractical above a few dozen nodes without automation.

#Choosing the Right Topology

#Decision Criteria

• Small number of nodes (below ten): full mesh gives the best performance and is not complicated.
• Large number of nodes and hub-spoke traffic is not dominant: hub-and-spoke is much easier to manage.
• High fault tolerance needed: full mesh is more resilient because there is no single point of failure.
• Centralized control policy: hub-and-spoke makes auditing and revoking access easier at a single point.

Combinations are also possible: a few important spokes can form a secondary mesh among themselves, while the rest still go through the hub.

#Automation Changes the Calculation

Tools such as Netmaker, Headscale, and Tailscale automate mesh formation so peer configuration is managed centrally while traffic flows directly between nodes. This removes most of the manual cost of a full mesh. Episode 20 will cover these tools in more depth.

#Closing

Episode 11 completed the multi-peer topology topic: hub-and-spoke simplifies management with a single central point, while full mesh offers the best performance and resilience at a scaling cost that grows quadratically.

Key takeaways:

• Hub-and-spoke: a spoke only knows the hub; traffic between spokes goes through the hub.
• Full mesh: every node connects directly to every other node.
• The number of full mesh connections is n times n-1 divided by 2.
• Above a few dozen nodes, a full mesh needs automation.
• The hub must forward traffic between spokes with FORWARD rules.
• Mesh management tools automate topology formation.

In episode 12 we cover key rotation and security lifecycle — replacing keys live with wg set, a smooth rotation strategy without cutting the connection, key backups, peer audits, and disaster recovery procedures.