WireGuard concepts (no vendor config)

Topic: Networking basics

WireGuard is a simple, fast VPN: each peer has a key pair and an allowed-IPs list that acts as both routing and ACL. Tunnels are stateless; crypto is modern. Use this to understand the model (peer, allowed-IPs, no central server required) before deploying. Conceptual only; no step-by-step vendor or distro-specific config.

Intent: Decision

Quick answer

  • Each peer has a public key (and optionally a preshared key); config lists peers with their public key, endpoint (IP:port for initial contact), and allowed-IPs. allowed-IPs defines which destination IPs are routed through that peer and which source IPs are accepted from that peer (routing and ACL in one).
  • No central server: any peer can initiate; NAT traversal (UDP) is built in. Tunnels are stateless (no long-lived session state); crypto is Curve25519, ChaCha20, Poly1305. Good for site-to-site, client-to-gateway, or mesh.
  • When to consider: simple config, good performance, kernel integration on Linux. When to skip: you need features WireGuard does not have (e.g. some legacy auth or complex routing); use this guide to understand the model, then refer to official or distro docs for actual config.

Prerequisites

Steps

  1. Peer and allowed-IPs

    Each interface has a private key (and public key derived from it). For each peer you set: PublicKey, Endpoint (optional, for initial contact), AllowedIPs. AllowedIPs means: send traffic to these IPs via this peer, and accept traffic from this peer with these source IPs. So it is both routing and an ACL.

  2. Stateless and modern crypto

    No long-lived session state; packets are self-contained (with replay protection). Crypto: Curve25519 for key exchange, ChaCha20-Poly1305 for encryption. Runs in kernel on Linux for performance; one UDP port per interface.

  3. Use cases and limits

    Good for site-to-site, client-to-gateway, or mesh. Simple config and good performance. Skip when you need features WireGuard does not provide (e.g. certain auth or integration requirements); understand the model here, then use official or distro docs for concrete config.

Summary

WireGuard is a simple VPN: each peer has a key pair and a list of allowed-IPs that acts as both routing and ACL. Tunnels are stateless; crypto is modern. There is no required central server. Use this to understand the model before deploying; for actual config use official or distro documentation.

Prerequisites

Steps

Step 1: Peer and allowed-IPs

Each interface has a private key (and derived public key). For each peer you configure PublicKey, optional Endpoint, and AllowedIPs. AllowedIPs means: route these destinations via this peer, and accept from this peer only with these source IPs. So it is both routing and an ACL.

Step 2: Stateless and modern crypto

No long-lived session state; packets are self-contained with replay protection. Crypto: Curve25519, ChaCha20-Poly1305. Runs in kernel on Linux; one UDP port per interface.

Step 3: Use cases and limits

Good for site-to-site, client-to-gateway, or mesh. Simple and fast. Skip when you need features WireGuard does not provide; use this guide for the model and official or distro docs for config.

Verification

You can explain what allowed-IPs does, why there is no central server requirement, and when WireGuard is a good fit vs when to use something else.

Troubleshooting

Handshake never completes — Endpoint unreachable (firewall, NAT, wrong IP/port); ensure UDP is allowed and the peer can reach the other endpoint. Traffic not routed — AllowedIPs must include the destination subnet on the peer that should receive it; check both sides.

Next steps

Continue to