WireGuardTunnel
title: WireGuard Tunnel type: technique created: 2026-05-21 last_updated: 2026-05-21 related: ["radar/techniques/K3sOracleCloud", "radar/techniques/SelfHostedSecurityReview"] sources: ["https://ryan-schachte.com/blog/boring_tunnel/"] radar_quadrant: Techniques radar_ring: Assess radar_position: inner
A technique for building private, encrypted network tunnels between machines using WireGuard, bypassing NAT without a commercial VPN service or third-party relay.
Most home and cloud machines sit behind NAT: they have no public IP and cannot accept inbound connections directly. The standard workarounds — port forwarding, dynamic DNS, or ngrok-style services — require either router access or a paid third party. A WireGuard-based "boring tunnel" uses a small VPS as a relay, routing encrypted traffic between peers without exposing services to the public internet.
A minimal WireGuard setup involves three roles:
-
Relay server — a small VPS (Oracle Free Tier, Hetzner) with a public IP. Runs
wg0with a known endpoint. - Home/origin peer — the machine with the service to expose. Initiates a persistent connection to the relay.
- Client peer — the machine that needs to reach the origin service. Connects to the relay, which routes traffic to the origin.
WireGuard configuration is static TOML-style files (wg0.conf). Each peer has a public/private key pair; the relay holds the public keys of all peers and routes packets between them.
| Alternative | Limitation |
|---|---|
| ngrok / Cloudflare Tunnel | Third-party dependency; rate limits or paid tiers for TCP |
| SSH reverse tunnel | Per-session; fragile under network changes |
| Commercial VPN | Cost; adds a trusted third party to the data path |
| Port forwarding | Requires router access; exposes service directly |
WireGuard is kernel-native on Linux (kernel 5.6+), has a small attack surface (~4,000 lines of code), and reconnects automatically after network changes.
- Accessing a home NAS or self-hosted service from anywhere without exposing it publicly
- Connecting multiple homelab nodes across different networks
- Secure access to a development machine running behind corporate NAT
- Kubernetes node networking for clusters spanning multiple cloud providers (see radar/techniques/K3sOracleCloud)
- The relay VPS must remain online; it is a single point of failure for tunnel availability
- WireGuard does not provide a management plane — key distribution and peer configuration are manual or require a tool (Netmaker, Tailscale uses WireGuard internally but adds a control plane)
- Firewall rules on the relay must permit UDP on the WireGuard port (default 51820)
- Routing and split-tunnelling require explicit
AllowedIPsconfiguration per peer
WireGuard Tunnel sits in the Assess ring of the Techniques quadrant, at inner position. First studied via Ryan Schachte's tutorial (2024-01-08). WireGuard itself is mature and kernel-native; the "boring tunnel" pattern is a well-established self-hosting technique. Inner Assess reflects clear applicability to homelab and remote-access scenarios and a realistic path to Trial on the next project requiring cross-network service access. Remaining gate: a working tunnel with at least one self-hosted service routed through it.
