March 12, 2026 (4mo ago)
Written by Temps Team
Last updated March 12, 2026 (4mo ago)
To connect servers across multiple cloud providers with encrypted private networking, WireGuard mesh is the fastest path: generate a Curve25519 key pair on each node, assign private IPs, and add peer entries pointing to every other node's public IP and port. The result is a multi-provider private LAN with roughly 1,011 Mbps throughput and a codebase small enough to audit in an afternoon.
WireGuard is a VPN protocol built into the Linux kernel since version 5.6. A mesh network takes it one step further — every server connects directly to every other, forming a private LAN that spans cloud providers and geographies. This guide walks through the manual setup, explains the topology tradeoffs, and shows how to eliminate the N-squared configuration burden.
TL;DR: WireGuard's ~4,000-line codebase delivers roughly 3x the throughput of OpenVPN (WireGuard whitepaper). For clusters beyond 3-4 servers, automated key exchange tools eliminate the per-node configuration burden. Temps bundles userspace WireGuard (boringtun) directly in its binary — one command adds a worker node to the mesh without editing any config files.
Cloud provider VPC networks can't cross vendor boundaries — your AWS instances can't natively reach Hetzner servers. According to Flexera's 2024 State of the Cloud Report, 89% of enterprises now use a multi-cloud strategy, which means cross-provider communication is the rule, not the exception.
AWS VPC peering works great between AWS accounts. But it can't reach your Hetzner box. GCP's networking won't talk to your DigitalOcean droplet. Every provider builds walled gardens around their own infrastructure.
If your architecture spans multiple providers — and it probably should, to avoid vendor lock-in — you need a networking layer that sits above all of them.
The alternative to private networking is opening firewall ports between servers. That means your PostgreSQL instance listens on a public IP. Your Redis cache is reachable from anywhere. Bots scan all IPv4 addresses in under 45 minutes. Every open port will be found.
IP allowlisting helps, but it's fragile. Cloud IPs change. You forget to update the list. One mistake, and your database is exposed to the internet.
Traffic between servers on the public internet travels in cleartext by default. Someone on the same network path could intercept your database queries, API responses, or session tokens. TLS on every internal service is possible but adds complexity and certificate management overhead.
Istio and Linkerd solve the multi-service networking problem, but they're designed for hundreds of microservices running in Kubernetes. For 2-5 servers that just need to talk securely, a service mesh adds massive operational complexity you don't need. WireGuard handles this with a few config files.
WireGuard's entire codebase is approximately 4,000 lines of code, compared to OpenVPN's roughly 100,000 lines (WireGuard whitepaper). That smaller surface area means fewer bugs, easier auditing, and significantly better performance.
Since Linux 5.6, WireGuard runs as a kernel module. Packets don't bounce between userspace and kernel space — they're encrypted and forwarded entirely within the kernel. The WireGuard whitepaper benchmarks show throughput of 1,011 Mbps compared to OpenVPN's 258 Mbps under the same conditions.
That's not a marginal improvement. It's nearly 4x faster. For inter-server traffic like database replication or API calls, that throughput matters.
WireGuard's configuration model is refreshingly simple. Each node has a public/private key pair. You list which peers can connect and which IP ranges they're allowed to use. That's it. No certificate authorities, no TLS negotiation, no complex PKI infrastructure.
A peer is just a public key plus an allowed IP range. If the cryptographic identity doesn't match, the packet is dropped silently. There's no handshake to exploit if you're not authorized.
WireGuard uses UDP, which means it works through most NAT configurations and firewalls without special rules. It also handles roaming natively — if a server's IP changes, WireGuard re-establishes the connection automatically on the next packet.
But how does this compare to alternatives in practice? Let's break down the options.
| Feature | WireGuard | OpenVPN | IPSec/IKEv2 |
|---|---|---|---|
| Codebase size | ~4,000 lines | ~100,000 lines | ~400,000 lines |
| Kernel integration | Yes (Linux 5.6+) | No (userspace) | Yes (varies) |
| Protocol | UDP | UDP or TCP | UDP |
| Encryption | ChaCha20, Curve25519 | OpenSSL (configurable) | Configurable |
| Configuration | Simple key pairs | Complex certificates | Complex |
| Throughput | ~1,011 Mbps | ~258 Mbps | ~881 Mbps |
Throughput figures from WireGuard whitepaper benchmarks on identical hardware.
Kernel WireGuard handles packets entirely within the Linux kernel, achieving maximum throughput. Userspace implementations like boringtun — originally built by Cloudflare and open-sourced — run as regular processes, trading a small performance penalty for broader compatibility across platforms including macOS, containers, and older kernels.
The kernel module ships with Linux 5.6 and later. On older kernels, you can install it via DKMS. It processes packets at line speed with minimal CPU overhead.
Use kernel WireGuard when:
Boringtun and wireguard-go are userspace implementations. They create a TUN device and handle encryption in a regular process. Performance is still excellent — far better than OpenVPN — but slightly below the kernel module.
Use userspace WireGuard when:
Userspace WireGuard (boringtun) is well-proven for inter-node communication. The throughput penalty compared to kernel WireGuard is barely noticeable for typical API and database traffic. The real advantage is operational simplicity — no kernel modules to install, no DKMS to maintain, no compatibility issues after kernel upgrades.
In a full mesh, every node connects directly to every other node, requiring N*(N-1)/2 connections — so 3 nodes need 3 tunnels, but 10 nodes need 45. The topology you choose depends on your cluster size, traffic patterns, and tolerance for single points of failure.
Node B
|
|
Node A --Hub-- Node C
|
|
Node D
All traffic routes through a central hub. Node B can reach Node C, but the packets travel through the hub first. This is the simplest to configure — each spoke only needs one peer entry (the hub), and the hub has entries for all spokes.
Pros: Easy to set up. Adding a new node means editing only the hub's config. Cons: The hub is a single point of failure. All inter-node traffic doubles (in to hub, out from hub). The hub's bandwidth caps your cluster's throughput.
Node A ---- Node B
| \ / |
| \ / |
| \ / |
| \/ |
| /\ |
| / \ |
| / \ |
| / \ |
Node D ---- Node C
Every node connects directly to every other. Traffic takes the shortest path. No single point of failure. If Node A goes down, B, C, and D still communicate freely.
Pros: Resilient. Lowest latency. No bandwidth bottleneck. Cons: Configuration scales quadratically. Adding one node means updating every existing node's config.
Group nodes by region or function. Nodes within a group form a full mesh. Groups connect through gateway nodes. This balances resilience against configuration complexity.
For most setups with 2-5 servers, full mesh is the way to go. The configuration burden is manageable, and you get the best performance and resilience. Beyond 10 nodes, you need automation.
A 3-node WireGuard mesh requires generating key pairs on each server, assigning private IPs, and configuring peer entries — a total of 6 peer entries across 3 config files. According to the WireGuard documentation, the entire setup process per node takes just a few commands.
A manual 3-node mesh takes 12-15 minutes if you know what you're doing, and about 30 minutes the first time. Most of that time is spent copying keys between servers.
On Ubuntu/Debian:
sudo apt update && sudo apt install -y wireguard
On RHEL/Fedora:
sudo dnf install -y wireguard-tools
Verify the installation:
wg --version
Run this on each of your three servers:
wg genkey | tee /etc/wireguard/privatekey | wg pubkey > /etc/wireguard/publickey
chmod 600 /etc/wireguard/privatekey
Record the keys. You'll need the public key from every node on every other node.
cat /etc/wireguard/publickey
# Example output: aB3dE5fG7hI9jK1lM3nO5pQ7rS9tU1vW3xY5zA7bC=
Pick a private subnet. We'll use 10.0.0.0/24:
| Node | Private IP | Public IP (example) |
|---|---|---|
| Server A | 10.0.0.1 | 203.0.113.1 |
| Server B | 10.0.0.2 | 198.51.100.2 |
| Server C | 10.0.0.3 | 192.0.2.3 |
Server A (/etc/wireguard/wg0.conf):
[Interface]
PrivateKey = <Server A private key>
Address = 10.0.0.1/24
ListenPort = 51820
[Peer]
# Server B
PublicKey = <Server B public key>
Endpoint = 198.51.100.2:51820
AllowedIPs = 10.0.0.2/32
PersistentKeepalive = 25
[Peer]
# Server C
PublicKey = <Server C public key>
Endpoint = 192.0.2.3:51820
AllowedIPs = 10.0.0.3/32
PersistentKeepalive = 25
Server B (/etc/wireguard/wg0.conf):
[Interface]
PrivateKey = <Server B private key>
Address = 10.0.0.2/24
ListenPort = 51820
[Peer]
# Server A
PublicKey = <Server A public key>
Endpoint = 203.0.113.1:51820
AllowedIPs = 10.0.0.1/32
PersistentKeepalive = 25
[Peer]
# Server C
PublicKey = <Server C public key>
Endpoint = 192.0.2.3:51820
AllowedIPs = 10.0.0.3/32
PersistentKeepalive = 25
Server C (/etc/wireguard/wg0.conf):
[Interface]
PrivateKey = <Server C private key>
Address = 10.0.0.3/24
ListenPort = 51820
[Peer]
# Server A
PublicKey = <Server A public key>
Endpoint = 203.0.113.1:51820
AllowedIPs = 10.0.0.1/32
PersistentKeepalive = 25
[Peer]
# Server B
PublicKey = <Server B public key>
Endpoint = 198.51.100.2:51820
AllowedIPs = 10.0.0.2/32
PersistentKeepalive = 25
On each server:
sudo wg-quick up wg0
sudo systemctl enable wg-quick@wg0
From Server A:
ping -c 3 10.0.0.2
ping -c 3 10.0.0.3
Check the WireGuard status:
sudo wg show
You should see recent handshakes and transferred bytes for each peer. If a peer shows no handshake, double-check the endpoint IP, port, and firewall rules (UDP 51820 must be open).
Adding node #4 to a 3-node mesh means editing config files on all 3 existing servers and restarting their WireGuard interfaces. At 10 nodes, you're managing 45 individual peer entries. According to NIST SP 800-57, key management complexity is a leading cause of cryptographic implementation failures — and manual WireGuard meshes hit this wall fast.
| Nodes | Connections | Config Changes to Add 1 Node |
|---|---|---|
| 3 | 3 | Edit 3 files |
| 5 | 10 | Edit 5 files |
| 10 | 45 | Edit 10 files |
| 20 | 190 | Edit 20 files |
Every config change means restarting the WireGuard interface, which briefly drops existing connections. In a production mesh, that's downtime across your entire cluster.
Manual key distribution is error-prone. Copy a public key incorrectly, and two nodes can't establish a tunnel. Forget to add a peer to one node, and you get asymmetric connectivity — A can reach D, but D can't reach A. These bugs are maddening to debug because WireGuard silently drops packets from unknown peers.
The real scaling issue isn't the number of config files — it's the blast radius of a mistake. In a 10-node mesh, one typo in a key can break connectivity for multiple nodes, and there's no centralized view to tell you where the problem is. You end up SSH-ing into every server and running wg show one by one. That's why centralized key exchange isn't a nice-to-have. It's a necessity.
Several projects solve this problem:
Each trades some flexibility for operational sanity. The question is how much control you want to give up.
Temps embeds userspace WireGuard directly in its binary using boringtun (Cloudflare's open-source Rust implementation) via the defguard_wireguard_rs crate — no system packages, no kernel modules, no manual configuration. A single temps join command sets up an encrypted tunnel between a worker node and the control plane.
Temps is self-hostable for free (Apache 2.0) and available as a managed cloud service at approximately $6/month (Hetzner cost plus 30% margin, no per-seat fees, no bandwidth bills).
Traditional WireGuard setup requires wireguard-tools and either a kernel module or userspace daemon. Temps compiles boringtun directly into the binary. When you run temps join, it creates a TUN device and handles encryption in-process. Nothing to install. Nothing to configure.
# Direct mode: worker has a private address reachable from the control plane
temps join <control-plane-url> <join-token> --private-address <worker-ip>
# Relay mode: worker sits behind NAT, tunnel routes through api.temps.sh
temps join <control-plane-url> <join-token>
Manual WireGuard means generating keys on each server and copying public keys everywhere. Temps handles this through its API. When a worker joins, it generates a Curve25519 key pair using x25519-dalek (pure Rust, no wg genkey CLI needed) and sends its public key to the control plane. The control plane responds with its own public key and connection parameters. No SSH-ing between servers. No shared documents listing keys.
Many servers sit behind NAT — especially in cloud environments or home labs. With manual WireGuard, you need a publicly reachable endpoint on at least one side of every tunnel. Temps relay mode solves this by routing through the control plane's WireGuard endpoint, so workers behind NAT can establish tunnels without port forwarding.
| Aspect | Manual WireGuard | Tailscale | Temps |
|---|---|---|---|
| Key generation | wg genkey on each server | Automatic | Automatic (x25519-dalek) |
| Key distribution | Copy/paste between servers | SaaS-managed | API-based exchange |
| Config files | One per node, manually written | None | None (embedded) |
| Adding a node | Edit all existing configs | tailscale up | temps join |
| NAT traversal | Requires public endpoints | DERP relays (SaaS) | Relay mode (self-hosted) |
| System dependencies | wireguard-tools, kernel module | tailscaled daemon | None (single binary) |
| Self-hosted control plane | No | Headscale (separate project) | Yes (included) |
| Pricing | Free | See pricing page | Free self-host / ~$6/mo cloud |
With 5+ nodes, manual key distribution takes 15-20 minutes every time you add a server. With automated key exchange, adding a node is one command and roughly 10 seconds.
Yes, significantly. WireGuard achieves roughly 1,011 Mbps throughput compared to OpenVPN's 258 Mbps in the same benchmark environment (WireGuard whitepaper). The difference comes from WireGuard's in-kernel implementation on Linux 5.6+, which avoids the userspace-to-kernel context switching that slows OpenVPN down. For inter-server traffic, this gap translates to lower latency and less CPU overhead.
WireGuard works behind NAT in most cases, but with a catch. The node behind NAT can initiate connections to peers with public endpoints, but peers can't initiate connections back unless keepalives are enabled. Set PersistentKeepalive = 25 in your config to maintain the NAT mapping. For double-NAT situations where neither side has a public IP, you need a relay node or a coordination service that provides STUN/TURN-like functionality.
For a manual mesh, you need to generate a key pair on the new node, then edit the WireGuard config file on every existing node to add the new peer's public key and endpoint. After updating configs, restart the WireGuard interface on each server with wg-quick down wg0 && wg-quick up wg0. In a 10-node mesh, that means editing 10 files and restarting 10 tunnels — which is why automated tools like Tailscale, Netmaker, or Temps exist.
WireGuard is a VPN protocol — it handles encrypted tunnels between two endpoints. Tailscale is a management layer built on top of WireGuard that automates key distribution, NAT traversal (via DERP relay servers), and mesh topology. Think of WireGuard as the engine and Tailscale as the car. You can drive the engine directly (manual config), or let a management layer handle the operational complexity. Tailscale is SaaS-hosted by default; self-hosted alternatives include Headscale and Temps.
WireGuard fully supports IPv6. You can assign both IPv4 and IPv6 addresses to the WireGuard interface and include IPv6 ranges in AllowedIPs. This is useful for dual-stack deployments where internal services need to be reachable over both protocols. The configuration syntax is identical — just add an IPv6 address alongside the IPv4 one in your Address field.
Temps uses defguard_wireguard_rs 0.9 (which wraps boringtun, Cloudflare's open-source Rust WireGuard implementation) for the in-process tunnel, and x25519-dalek 2.0 for Curve25519 key generation. This eliminates any dependency on the wireguard-tools system package or kernel module. The temps-wireguard crate is the only consumer of this stack — the join command in temps-cli calls it directly during node registration.
WireGuard gives you encrypted private networking between any servers, anywhere. For 2-3 nodes, the manual setup takes 15 minutes and works perfectly. Beyond that, the N-squared configuration problem will push you toward automation.
The core concept stays the same regardless of tooling: Curve25519 key pairs, UDP tunnels, cryptokey routing. Understanding the manual process makes you better at debugging any WireGuard-based tool, whether that's Tailscale, Netmaker, or an embedded solution.
If you want the mesh without the configuration overhead, Temps bundles userspace WireGuard into a single binary. One temps join command on each worker, and the control plane handles key exchange and tunnel setup automatically:
curl -fsSL https://temps.sh/install.sh | bash
For the full WireGuard protocol specification, see the WireGuard whitepaper. For Temps multi-node setup, check the edge nodes documentation.