Self-Hosted VPN Glossary: 34 Terms Explained (WireGuard, Headscale, DERP, NAT Traversal…)

When getting into self-hosted VPN, you quickly encounter terms that guides use without defining: AllowedIPs, DERP, NAT traversal, MTU, PersistentKeepalive, DPI obfuscation… This glossary brings together the 34 essential definitions, organized by theme, written to be understood in 30 seconds and directly quotable.

It complements the site's technical guides: for concrete configurations, see the WireGuard vs OpenVPN guide, the Tailscale vs Headscale comparison, and the Linux kill switch guide.

Table of Contents

• Protocols and Core VPN
• Mesh Network and Control Plane
• NAT, Relays and Connectivity
• Encryption and Cryptography
• Routing and Configuration
• Obfuscation and DPI Bypass
• Leaks and Operational Security
• Key Features

Protocols and Core VPN

WireGuard

WireGuard is a modern VPN protocol implemented in the Linux kernel (kernel-space). With fewer than 4,000 lines of source code (vs. 400,000 for OpenVPN), it minimizes the attack surface and delivers performance close to the raw link throughput. It uses ChaCha20-Poly1305 for encryption, Curve25519 for key exchange, and BLAKE2s for message authentication. Recommended standard for self-hosting in 2026.

OpenVPN

OpenVPN is the reference open-source VPN protocol since 2001. Unlike WireGuard, it runs in userspace, making it more portable but slower. It supports TCP and UDP, easily configures port 443 over TCP to bypass DPI firewalls, and accepts various cipher suites (AES-256-GCM by default). Still relevant for environments that block UDP or require compliance audit trails.

IPsec / IKEv2

IPsec is a set of network encryption protocols operating at the IP level (layer 3). IKEv2 is the key exchange protocol used with IPsec — native on iOS and macOS, very stable during network changes (Wi-Fi ↔ 4G/5G). Less performant than WireGuard in raw throughput, but natively integrated into Apple mobile OSes without application dependencies. Commonly used in enterprise VPN setups on routers.

VPN Tunnel (full tunnel vs split tunnel)

A VPN tunnel is an encrypted channel between two points. In full tunnel mode (AllowedIPs 0.0.0.0/0), all IP traffic transits through the VPN — including Internet traffic. In split tunnel mode (restricted AllowedIPs), only a portion of traffic passes through the tunnel, the rest exiting directly. Split tunneling reduces the load on the VPN server and improves latency for local connections.

Mesh Network and Control Plane

Mesh Network

A mesh network is a network topology where each node can communicate directly with all others, without a mandatory central node. In the VPN context, this means every device connected to the mesh can reach the others directly — unlike a hub-and-spoke topology where everything passes through a central server. Tailscale and Headscale automatically create a WireGuard mesh between all registered devices.

Tailscale

Tailscale is a WireGuard-based mesh VPN managed as SaaS. It automates key exchange, NAT traversal, ACLs, and DNS via its control plane hosted in the United States. Free for up to 100 devices for personal use. The data plane (traffic between devices) is end-to-end encrypted with WireGuard — Tailscale Inc. cannot see the content. The control plane (which orchestrates connections) remains under their control.

Headscale

Headscale is an open-source implementation of the Tailscale control plane, self-hostable on any Linux VPS. It is compatible with official Tailscale clients on all OSes. It offers the same UX (MagicDNS, ACLs, exit nodes) but without dependency on Tailscale Inc.'s servers. The control plane runs on your own VPS — see the Headscale guide for full deployment.

Control Plane vs Data Plane

The control plane is the VPN's brain: it orchestrates device registration, public key exchange, ACLs, and configuration distribution. In Tailscale, it's Tailscale Inc.'s SaaS service; in Headscale, it's your own VPS. The data plane is the actual encrypted data flow between devices — it uses WireGuard directly, independent of the control plane. Even if the control plane is compromised, the data plane traffic remains encrypted.

MagicDNS

MagicDNS is the automatic DNS feature of Tailscale and Headscale that assigns a stable domain name to each device in the mesh (machine.tailnet.ts.net). Without MagicDNS, you'd need to remember the static IP address of each device (e.g., 100.64.0.x). MagicDNS eliminates the need to maintain an /etc/hosts file or internal DNS server and simplifies automation scripts.

Exit Node

An exit node is a device in the Tailscale (or Headscale) mesh configured to route all other devices' Internet traffic — like a traditional VPN. When you enable the exit node on a device, all your outgoing traffic transits through it before reaching the Internet. Useful for giving a remote machine a fixed IP or encrypting traffic from public Wi-Fi, using a VPS as an exit node. Guide: Tailscale exit node.

NAT, Relays and Connectivity

NAT (Network Address Translation)

NAT is the mechanism by which a router translates private IP addresses (192.168.x.x, 10.x.x.x) to a public address for outgoing traffic, and reverses the process for incoming traffic. Almost all residential and mobile connections are behind a NAT, making direct incoming connections impossible without manual configuration (port forwarding). This is the core problem that NAT traversal aims to solve.

NAT Traversal (Hole Punching)

NAT traversal is the set of techniques enabling two machines behind separate NATs to reach each other directly over UDP, without port forwarding. The main technique (hole punching) involves both peers simultaneously sending UDP packets to each other — both NATs then open an entry in their connection table, allowing bidirectional traffic. Tailscale uses STUN/ICE to orchestrate this process.

DERP (Designated Encrypted Relay for Packets)

DERP is Tailscale's TCP relay network activated when direct NAT traversal fails (symmetric NAT, blocked UDP port). Traffic transits through a DERP server but remains end-to-end encrypted with WireGuard — the server sees only encrypted packets. DERP is slower than a direct connection but guarantees connectivity in all network contexts. Headscale can use Tailscale's DERP servers or deploy its own.

Port Forwarding

Port forwarding consists of configuring a router or firewall to forward incoming connections on a specific port to an internal machine. For a self-hosted WireGuard VPN on a VPS, this is generally unnecessary (the VPS has a direct public IP). However, for a WireGuard server at home (behind an ISP NAT), UDP port forwarding on the WireGuard port (51820 by default) is required.

Endpoint

In WireGuard, an endpoint is the public IP address and UDP port of a peer: 203.0.113.42:51820. WireGuard memorizes the last known endpoint of each peer and automatically updates this information if the IP changes (mobile network, dynamic IP). The endpoint is not fixed on the client side (it can be 0.0.0.0:0 if the client has no fixed IP), but the server must have a stable endpoint or domain name.

Handshake

The WireGuard handshake is the initial cryptographic exchange that establishes an encrypted session between two peers. It uses Curve25519 (Diffie-Hellman key exchange) and completes in under a millisecond. WireGuard automatically renews the handshake every 3 minutes to ensure perfect forward secrecy — each session has its own ephemeral key. If no traffic is exchanged for 3 minutes, a new handshake is triggered before the next packet.

PersistentKeepalive

PersistentKeepalive is a WireGuard parameter that sends an empty UDP packet at regular intervals (in seconds) to keep the NAT entry open between the client and server. Recommended value: 25 seconds (below the standard NAT timeout of 30 seconds). Without keepalive, a client behind a NAT loses its session after a few minutes of inactivity and must restart a handshake. Essential for mobile clients.

Encryption and Cryptography

Curve25519

Curve25519 is the elliptic curve used by WireGuard for Diffie-Hellman key exchange (ECDH). It offers a security level equivalent to RSA-3072 with keys of only 32 bytes, which speeds up the handshake and reduces memory consumption. Designed to resist timing attacks. Each WireGuard peer generates a Curve25519 key pair: private key (32 bytes, secret) and public key (32 bytes, shared with peers).

ChaCha20-Poly1305

ChaCha20-Poly1305 is the AEAD (Authenticated Encryption with Associated Data) suite used by WireGuard to encrypt and authenticate packets. ChaCha20 is the stream cipher; Poly1305 is the MAC that guarantees integrity. This suite is particularly fast on processors without AES-NI acceleration (ARM on Raspberry Pi, MIPS on routers) and structurally resists timing attacks.

BLAKE2s

BLAKE2s is the cryptographic hash function used by WireGuard for message authentication and session key derivation. A variant of BLAKE2 optimized for 32-bit and embedded processors. Faster than SHA-256 on these architectures while maintaining equivalent security properties. Used in the WireGuard handshake protocol to mix ephemeral keys and session data.

Perfect Forward Secrecy (PFS)

Perfect forward secrecy guarantees that compromising a session key does not allow decryption of past or future sessions. WireGuard implements this natively: at each handshake (every 3 minutes), new ephemeral Curve25519 keys are generated and destroyed after use. Even if an attacker records encrypted traffic and later compromises a peer's static private key, they cannot recover previous sessions.

WireGuard Public / Private Key

WireGuard uses asymmetric cryptography for authentication. The private key (32 bytes, base64 format) never leaves the device and signs handshakes. The public key is derived from the private key and shared with peers — it's a peer's identifier in WireGuard. Each peer in a WireGuard config is identified by its public key in the [Peer] section. The command wg genkey | tee private.key | wg pubkey > public.key generates a key pair.

Routing and Configuration

AllowedIPs

AllowedIPs is the most important WireGuard configuration parameter on the peer side. It simultaneously defines the routes sent into the tunnel (any packet destined for these ranges goes through this peer) and the whitelist of accepted source IPs from this peer. 0.0.0.0/0, ::/0 = full tunnel (all traffic). 10.0.0.0/24 = only that subnet. A peer's AllowedIPs on the server side defines which internal IP is allocated to that client.

MTU (Maximum Transmission Unit)

MTU is the maximum size of a network packet in bytes. For WireGuard over Ethernet (MTU 1500), the tunnel MTU must be reduced by 60 bytes for WireGuard/UDP/IP overhead: standard recommendation of 1420 bytes. A misconfigured MTU causes silent fragmentation or connections that "hang" on certain sites (especially TLS). Set in the [Interface] section of the WireGuard config. Test with ping -M do -s 1400 8.8.8.8.

DNS Leak

A DNS leak occurs when DNS queries (domain name resolution) exit outside the VPN tunnel and go through the ISP or OS resolver. Result: your ISP sees which domains you visit despite the active VPN. In WireGuard, configuring DNS = 1.1.1.1 in the [Interface] section forces all DNS queries into the tunnel. Full prevention guide: WireGuard DNS leak prevention.

PostUp / PostDown

PostUp and PostDown are WireGuard configuration hooks that execute shell commands when the interface starts and stops. Used to configure iptables rules (NAT masquerade, kill switch), enable IP forwarding (sysctl net.ipv4.ip_forward=1), or launch monitoring scripts. The PostUp command runs after wg-quick up; PostDown after wg-quick down. Essential for masquerading and systemd kill switch.

wg-quick

wg-quick is the high-level configuration tool shipped with WireGuard that simplifies interface management. It reads .conf files from /etc/wireguard/, creates the network interface, configures routes, DNS, and runs PostUp/PostDown hooks. Main commands: wg-quick up wg0, wg-quick down wg0. It automatically creates routes for AllowedIPs and manages default routing in full tunnel mode. Different from wg (the low-level command).

Obfuscation and DPI Bypass

DPI (Deep Packet Inspection)

DPI is a network analysis technique that examines packet content (not just headers) to identify protocols, filter traffic, or detect VPNs. Corporate firewalls, governments (Chinese Great Firewall), and some ISPs use DPI to block WireGuard or OpenVPN. WireGuard is detectable by DPI because it has a distinctive UDP signature. Obfuscation aims to disguise this traffic as normal HTTPS.

Obfuscation

VPN obfuscation disguises encrypted traffic to resemble ordinary HTTPS traffic, making detection by DPI difficult. Common techniques: wstunnel (tunneling WireGuard in WebSocket on port 443), Cloak (obfsproxy plugin for OpenVPN), Shadowsocks (encrypted SOCKS5 proxy), V2Ray VMess/VLESS. Obfuscation is necessary in networks with aggressive DPI (China, Iran, corporate networks). Guide: anti-DPI bypass 2026.

wstunnel

wstunnel is a tool that encapsulates UDP traffic (especially WireGuard) in a WebSocket connection on port 443 (HTTPS). On the client side, wstunnel listens on a local UDP port and forwards to the remote wstunnel server via WebSocket. On the server side, wstunnel decapsulates and forwards to the local WireGuard port. Result: everything looks like HTTPS traffic from the outside. Detailed guide: wstunnel TCP over WebSocket.

Shadowsocks

Shadowsocks is an encrypted SOCKS5 proxy protocol originally designed to bypass the Chinese Great Firewall. It encrypts traffic with AES-256-GCM or ChaCha20-Poly1305 and disguises it as HTTPS traffic. Different from a VPN: Shadowsocks is an application proxy, not a complete network tunnel. Can be combined with WireGuard (Shadowsocks as transport) for a double layer of obfuscation. See Shadowsocks vs VPN.

V2Ray / VMess / VLESS

V2Ray is a multi-protocol proxy and tunneling framework. VMess is its proprietary protocol (authentication, encryption, HTTPS camouflage); VLESS is its lightweight version without embedded encryption (delegates to TLS). Both support multiple transports (WebSocket, gRPC, HTTP/2) to bypass DPI. V2Ray is more complex to configure than WireGuard or Shadowsocks but offers the best camouflage capabilities in environments with advanced DPI.

Leaks and Operational Security

WebRTC Leak

WebRTC is a browser API for peer-to-peer communication. To function, it queries all network interfaces on the machine — including the real IP before VPN masking. A site can thus retrieve the real IP via JavaScript despite the active tunnel. Solution for self-hosting: configure the WireGuard client at the OS level (not just browser) and enable WebRTC protection in the browser (Firefox: media.peerconnection.enabled = false).

IPv6 Leak

If your VPS or network supports IPv6 and your WireGuard config only tunnels IPv4, IPv6 connections exit in plaintext and expose your real identity. Solution: add ::/0 to AllowedIPs (full IPv6 tunnel), or disable IPv6 at the OS interface level if your setup doesn't handle it. WireGuard natively supports IPv6 — just include it in the [Interface] config (Address) and [Peer] (AllowedIPs).

Key Features

Kill Switch

The kill switch cuts all network connections if the VPN tunnel drops, preventing real IP exposure. On Linux with WireGuard, it's implemented via iptables/nftables rules in the PostUp hook: block all traffic outside the wg0 interface except traffic to the WireGuard endpoint. Complete guide with systemd and iptables: VPN kill switch Linux.

Split Tunneling

Split tunneling routes only a portion of traffic through the VPN, the rest exiting directly. In WireGuard, it's configured via AllowedIPs: by listing only the target subnets (e.g., 10.8.0.0/24), the rest of the traffic exits through the normal interface. Useful for accessing VPN network resources (NAS, internal services) while maintaining optimal latency for Internet traffic.

ACLs (Access Control Lists)

ACLs in Tailscale and Headscale define which machines can communicate with each other in the mesh. Configured in JSON (HuJSON format in Tailscale), they allow access segmentation: for example, allowing prod servers to talk to each other but preventing personal machines from accessing them directly. Without ACLs, all mesh devices can see and communicate with each other — convenient but not suitable for multi-team professional use.

Subnet Router

A subnet router is a Tailscale/Headscale device configured to advertise a private subnet to the rest of the mesh. Example: a NAS on 192.168.1.0/24 can be made accessible from the Internet if a machine on that network acts as a subnet router and announces that range. This way, other mesh devices can reach all LAN machines without each being individually registered in Tailscale.

Peer-to-Peer (Direct P2P)

In the Tailscale/Headscale context, P2P refers to direct connections between two devices without passing through an intermediary server. Tailscale always attempts to establish a direct P2P connection via NAT traversal before falling back to DERP. A P2P connection offers minimum latency (direct UDP between the two endpoints). The tailscale status interface indicates whether a connection is direct (Direct) or relayed (Relay).

What This Glossary Doesn't Replace

These definitions provide the basic vocabulary, but real understanding comes from practice. To go further: the WireGuard vs OpenVPN comparison details concrete choices by use case, the Tailscale vs Headscale guide compares the two control plane approaches, and the anti-DPI guide covers obfuscation from A to Z.

Published June 12, 2026. Definitions established from official WireGuard specifications (Jason A. Donenfeld, whitepapers.wireguard.com), Tailscale documentation (tailscale.com/kb), Headscale source code (github.com/juanfont/headscale), and relevant IETF RFCs. Updated continuously.