Kingsfordweg 151, 1043GR Amsterdam, The Netherlands ● 24/7 support — support@novogara.com
Knowledge base

A WireGuard VPN

WireGuard is small enough to read, fast enough to forget about, and it lets you close every administrative port on your servers.

Install and make keys

apt install wireguard

wg genkey | tee private.key | wg pubkey > public.key

The private key never leaves the machine it was made on. The public key is what you give the other side.

A working configuration

On the server, /etc/wireguard/wg0.conf:

[Interface]
Address = 10.10.0.1/24
ListenPort = 51820
PrivateKey = <server private key>
[Peer]
PublicKey = <client public key>
AllowedIPs = 10.10.0.2/32

On the client, mirrored, plus:

Endpoint = yourserver.example.com:51820
PersistentKeepalive = 25

Then systemctl enable --now wg-quick@wg0 and check with wg show. A peer with a recent handshake and non-zero transfer is working.

AllowedIPs is the thing to understand

It does double duty: on outbound traffic it is the routing table, and on inbound it is the access control list. A peer may only send you packets from addresses listed in its own AllowedIPs.

  • 10.10.0.2/32 — just that peer
  • 10.10.0.0/24, 10.20.0.0/16 — the tunnel plus a network behind that peer
  • 0.0.0.0/0, ::/0 — send everything through the tunnel

Two peers cannot both claim the same range. Overlapping AllowedIPs is the cause of most “the tunnel is up but traffic does not flow” reports.

Routing a network behind a peer

To reach machines sitting behind the server, enable forwarding:

net.ipv4.ip_forward=1 in /etc/sysctl.d/

and either route that network back to the WireGuard server, or masquerade on the way out:

PostUp = nft add rule inet nat postrouting oifname "eth0" masquerade

MTU, the classic failure

The handshake works, SSH connects, and then a large transfer hangs forever. That is MTU: the tunnel's overhead means 1500-byte packets no longer fit. Set MTU = 1420 in the [Interface] section, lower over IPv6. MTU, fragmentation and tunnels explains the whole pattern.

What it is really for

Once the tunnel exists, bind your administrative interfaces to the WireGuard address and close the public ports entirely:

  • SSH listening only on 10.10.0.1 — port 22 shut to the world
  • Your Proxmox or panel interface, same
  • Database ports, monitoring, log shipping — see connecting your own servers

Before you close SSH, make sure you can get in another way. Our remote KVM is that other way, and it is included on every machine — but confirm it works for you before you need it, not after.

Housekeeping

  • Keep /etc/wireguard/ at mode 600; the config holds a private key.
  • Give each peer its own keypair. Shared keys cannot be revoked individually.
  • Remove a peer's stanza and reload to revoke access; it takes effect at once.
  • WireGuard does not reply to unauthenticated packets at all, so a port scan sees nothing. That is a feature, not a broken firewall.

Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base