Beyond a simple point-to-point connection, WireGuard can be configured for a hub-and-spoke topology — one central server connecting multiple remote peers, with the hub optionally routing traffic between spokes. This guide covers the configuration.
Hub-and-Spoke vs Mesh Topology
See How to Set Up a Mesh VPN with Tailscale or ZeroTier for the mesh alternative — hub-and-spoke means all spokes connect only to the central hub, not directly to each other; simpler to configure manually with plain WireGuard than a full mesh, at the cost of the hub becoming a required intermediary (and potential bottleneck) for spoke-to-spoke communication.
Step 1 — Set Up the Hub Server
[Interface]
PrivateKey = HUB_PRIVATE_KEY
Address = 10.0.0.1/24
ListenPort = 51820
See How to Set Up a VPN Server with WireGuard for base setup — the hub is configured largely like a standard WireGuard server, but will have multiple peer entries, one per spoke.
Step 2 — Add Each Spoke as a Peer on the Hub
[Peer]
PublicKey = SPOKE1_PUBLIC_KEY
AllowedIPs = 10.0.0.2/32
[Peer]
PublicKey = SPOKE2_PUBLIC_KEY
AllowedIPs = 10.0.0.3/32
Each spoke gets its own peer entry with a specific IP within the VPN subnet — scales to as many spokes as needed, each with a unique key pair and assigned address.
Step 3 — Configure Each Spoke to Connect to the Hub
[Interface]
PrivateKey = SPOKE1_PRIVATE_KEY
Address = 10.0.0.2/24
[Peer]
PublicKey = HUB_PUBLIC_KEY
Endpoint = HUB_PUBLIC_IP:51820
AllowedIPs = 10.0.0.0/24
PersistentKeepalive = 25
Each spoke's AllowedIPs includes the full VPN subnet (not just the hub's specific IP), enabling it to reach other spokes through the hub if hub-based routing is enabled.
Step 4 — Enable IP Forwarding on the Hub
sudo sysctl -w net.ipv4.ip_forward=1
echo "net.ipv4.ip_forward=1" | sudo tee -a /etc/sysctl.conf
Required for the hub to actually route traffic between spokes, rather than only handling traffic destined for itself.
Step 5 — Configure NAT/Forwarding Rules on the Hub
iptables -A FORWARD -i wg0 -o wg0 -j ACCEPT
Explicitly allow forwarding between WireGuard peers through the hub interface — without this, even with IP forwarding enabled generally, the firewall may still block spoke-to-spoke traffic passing through.
Deciding Whether Spokes Should Reach Each Other
Not every hub-and-spoke setup needs inter-spoke communication — if spokes only need to reach the hub (not each other), omit the full-subnet AllowedIPs on spokes and the forwarding rules, keeping the setup simpler and more restrictive by design.
Scaling Considerations
As spoke count grows, hub configuration management becomes more involved — consider configuration management tooling (see How to Use Ansible for Server Configuration Management) for generating/maintaining peer configurations at scale, rather than purely manual editing.
Common Errors
Spokes can reach the hub but not each other — verify IP forwarding is enabled and iptables forwarding rules are correctly configured on the hub; also confirm each spoke's AllowedIPs includes the full subnet, not just the hub's specific address.
Continue Reading
- How to Set Up a VPN Server with WireGuard
- How to Set Up a Mesh VPN with Tailscale or ZeroTier
- How to Set Up a Site-to-Site VPN Between Two VPS Servers
Browse more articles in Advanced Networking & VPN.