How to Configure a WireGuard Point-to-Site VPN on Debian 12

Illustrative scenario: Maya uses a Debian 12 VPS as a personal VPN endpoint when she works from a café. Her laptop should reach the VPS over an encrypted WireGuard tunnel and send its IPv4 internet traffic through that server. This example is not a report of a live test; public IPs, keys, and terminal output shown below are placeholders or representative mockups.

This setup is a point-to-site VPN: one client connects to one server. It uses Debian’s packaged WireGuard tools, a single peer, IPv4 forwarding, and IPv4 NAT. It assumes the VPS has a public or port-forwarded IPv4 address, you can administer it with sudo, and UDP port 51820 can reach it. The walkthrough does not configure routed IPv6 or a private network behind the VPS.

Plan the addresses and access first

The example uses 10.8.0.0/24 for the VPN, with 10.8.0.1 on the server and 10.8.0.2 on Maya’s first client. Use a subnet that does not overlap the client’s Wi-Fi, office, or cloud networks. A collision can send traffic down the wrong route even when the handshake succeeds.

WireGuard uses public-key authentication. The server needs the client’s public key, and the client needs the server’s public key; each private key stays on the device that owns it. Debian’s WireGuard documentation describes the package and peer setup, while WireGuard’s quick start documents key generation and keepalive behavior. See the Debian WireGuard documentation and the WireGuard Quick Start.

Configure the Debian 12 server

1. Install the tools

Update the package index and install WireGuard plus nftables, which will provide the example IPv4 masquerade rule. Run these on the VPS:

sudo apt update
sudo apt install wireguard nftables

Debian packages WireGuard through the wireguard metapackage and its tools. If the server already uses a firewall manager such as UFW, firewalld, or provider-managed rules, identify its active ruleset before adding anything. Do not replace an existing firewall configuration with this example.

2. Find the public-facing interface and enable forwarding

Ask the routing table which interface Debian uses to reach an external IPv4 address:

ip route get 1.1.1.1

In the sample, the route uses eth0. Your VPS may show a different name such as ens3 or enp1s0; use the name from your own output in the NAT rule later. Also note the server’s public IPv4 address or DNS name. If the server sits behind a router, forward UDP 51820 from that router to the Debian host.

IPv4 forwarding is required for a full tunnel. Enable it now and persist it across reboots:

echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-wireguard.conf
sudo sysctl --system
sysctl net.ipv4.ip_forward

Het laatste commando moet rapporteren net.ipv4.ip_forward = 1. Deze instelling staat het doorsturen van pakketten toe; het opent op zichzelf de firewall niet en biedt geen NAT.

3. Maak een serversleutel en een clientsleutelpaar aan.

Maak de serversleutel aan op de Debian-host met beperkende bestandsrechten:

sudo install -d -m 700 /etc/wireguard
sudo sh -c 'umask 077; wg genkey > /etc/wireguard/server.key; wg pubkey < /etc/wireguard/server.key > /etc/wireguard/server.pub'

Genereer indien mogelijk het sleutelpaar voor de client op het clientapparaat. Op een Linux-client met de volgende wireguard-toolssoftware geïnstalleerd:

umask 077
wg genkey | tee client.key | wg pubkey > client.pub

Maak voor een telefoon een nieuwe tunnel aan in de officiële WireGuard-app en laat deze de profielsleutels genereren. Kopieer alleen de publieke sleutel van de client naar de server. Houd deze client.keyprivé; plak hem nooit in de serverconfiguratie en verstuur hem nooit via de chat. De Debian Bookworm- wg(8)handleiding beschrijft de belangrijkste commando's en interfacevelden.

4. Maak de serverinterface aan en voeg de peer toe.

Maak /etc/wireguard/wg0.confde volgende structuur. Vervang elke hoofdletter als placeholder door de bijbehorende echte sleutel. Lees de privésleutel van de server lokaal met sudo cat /etc/wireguard/server.key; plaats de publieke sleutel van de client in het peer-gedeelte.

[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = SERVER_PRIVATE_KEY

[Peer]
PublicKey = CLIENT_PUBLIC_KEY
AllowedIPs = 10.8.0.2/32

Bescherm het bestand, want het bevat een privésleutel:

sudo chown root:root /etc/wireguard/wg0.conf
sudo chmod 600 /etc/wireguard/wg0.conf

AllowedIPs = 10.8.0.2/32Hiermee wordt aan deze peer één VPN-adres toegewezen en wordt voorkomen dat een andere peer dit adres claimt. Geef elk extra apparaat een eigen sleutelpaar en een uniek adres, bijvoorbeeld 10.8.0.3/32. Gebruik niet hetzelfde clientprofiel opnieuw voor meerdere apparaten als u aparte intrekking of identiteit nodig hebt.

5. Voeg IPv4 NAT toe en sta de WireGuard-poort toe.

Voor de volledige IPv4-tunnel in het voorbeeld moeten uitgaande pakketten 10.8.0.0/24via de publieke interface met source NAT vertrekken. Voeg een equivalente regel toe aan de bestaande nftables-configuratie of firewallmanager van de server. Deze zelfstandige nftables-tabel illustreert de regel; vervang deze eth0door de interface die in stap 2 is gevonden:

table ip wg_nat {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    ip saddr 10.8.0.0/24 oifname "eth0" masquerade
  }
}

Als je Debian gebruikt nftables.service, voeg dan de tabel samen met de configuratie die de service bij het opstarten laadt en valideer het volledige bestand sudo nft -c -f /etc/nftables.confvoordat je het opnieuw laadt. Controleer of je huidige configuratie bestaande regels wist of vervangt voordat je deze toepast. NAT alleen heft geen forward-chain beleid op dat verkeer blokkeert: sta doorsturen van wg0naar de WAN-interface en het retourverkeer toe in je actieve firewall. nft(8)De handleiding van Debian beschrijft het laden van nftables-regels en NAT-instructies.

Sta inkomend UDP-verkeer op poort 51820 toe in zowel de firewall van de VPS-provider als de firewall van de host. Open poort 51820 niet voor TCP-verkeer via deze WireGuard-tunnel. Houd uw SSH-toegangsregel van kracht tijdens het wijzigen van het firewallbeleid en gebruik een console van de provider of een andere herstelprocedure als een herstart van de firewall de verbinding zou kunnen verbreken.

Configureer en verbind de client.

6. Stel het klantprofiel op

Maak een nieuwe tunnel aan in de WireGuard-clientapp of sla een configuratie zoals deze op een Linux-client op. Vervang de privésleutel, de openbare sleutel van de server en het eindpunt door de werkelijke waarden. Het onderstaande TEST-NET-adres is slechts een voorbeeld en zal geen echte server bereiken.

[Interface]
Address = 10.8.0.2/32
PrivateKey = CLIENT_PRIVATE_KEY
DNS = 1.1.1.1

[Peer]
PublicKey = SERVER_PUBLIC_KEY
Endpoint = 203.0.113.10:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

AllowedIPs = 0.0.0.0/0De route van IPv4-bestemmingen via de tunnel is dus de optie voor een volledige IPv4-tunnel. Voor een smalle split-tunnel die alleen het WireGuard-serveradres bereikt, gebruikt u 10.8.0.0/24in plaats daarvan. Om een ​​LAN achter de server te bereiken, moet u het daadwerkelijke subnet van dat LAN opnemen in het configuratiebestand van de client AllowedIPs, een retourroute of geschikte NAT toevoegen en het verkeer door de serverfirewall toestaan; deze stappen zijn afhankelijk van de LAN-router en vallen buiten dit voorbeeld.

PersistentKeepalive = 25Dit kan ervoor zorgen dat een client achter NAT bereikbaar blijft na perioden van inactiviteit. Het is optioneel; de documentatie van WireGuard geeft aan dat de meeste gebruikers het niet nodig hebben, maar noemt 25 seconden als een algemeen bruikbaar interval waarin een NAT-mapping open moet blijven. Het DNSveld wordt ondersteund door sommige clients en clients die gebaseerd zijn op wg-quick; als uw app het negeert, stelt u DNS in via de eigen instellingen van die app.

7. Start de tunnel en controleer de handdruk.

Op Debian activeer je de interface tijdens het opstarten met:

sudo systemctl enable --now wg-quick@wg0
sudo wg show

Importeer of activeer het clientprofiel nadat UDP-poort 51820 bereikbaar is. wg showControleer in of de verwachte peer verschijnt en of deze latest handshakewordt bijgewerkt nadat de client verkeer heeft verzonden. De wg-quick(8)handleiding voor Debian Bookworm beschrijft de interface-configuratiehelper die door de systemd-eenheid wordt gebruikt.

Een ontbrekende handshake wijst in de eerste plaats op problemen met de bereikbaarheid of sleutelovereenkomsten: controleer het eindpuntadres en de poort, de UDP-firewallregels, de openbare sleutel van de server in het clientprofiel, de openbare sleutel van de client wg0.confen de juiste systeemtijd. Een handshake zonder werkend verkeer wijst meestal op doorsturen, NAT, overlapping van routes of een firewallregel in de doorstuurketen.

8. Controleer het verkeer en begrijp de IPv6-limiet.

Nadat de client is verbonden, test u eerst het tunneladres van de server en controleert u vervolgens het openbare IPv4-adres dat wordt gezien door een externe IPv4-adrescontroleservice:

ping -c 3 10.8.0.1
curl -4 https://ifconfig.me

De ping zou de server moeten bereiken als ICMP is toegestaan. De externe IPv4-controle zou het openbare uitgaande adres van de VPS moeten tonen voor deze full-tunnelconfiguratie. Als het openbare adres niet verandert, inspecteer dan AllowedIPsde forwarding-instellingen, de naam van de NAT-interface en het forwardbeleid van de firewall.

This example is IPv4-only. AllowedIPs = 0.0.0.0/0 does not route IPv6, so a client with IPv6 connectivity may still send IPv6 traffic outside the tunnel. Do not describe this configuration as a complete dual-stack privacy tunnel. To carry IPv6 through WireGuard, allocate and route IPv6 addresses for the tunnel, enable IPv6 forwarding, configure appropriate firewall and routing rules, and add ::/0 on the client only after that path works end to end. Provider support varies. Otherwise, choose a split-tunnel policy knowingly and check the client’s IPv6 behavior.

Common problems and a quick final check

• No handshake: confirm inbound UDP 51820 at both provider and host firewalls, the endpoint’s public IP or DNS, and each side’s peer public key.
• Handshake works, but websites do not load: confirm net.ipv4.ip_forward=1, the NAT rule uses the actual egress interface, and the firewall permits forwarded traffic.
• Only some networks fail: check whether 10.8.0.0/24 overlaps a local or remote network. Renumber the tunnel if needed, updating both peers and the firewall rule together.
• It works until reboot: confirm wg-quick@wg0 is enabled and that the firewall and sysctl settings are persisted through the system’s normal configuration.
• IPv6 still uses the local connection: that is expected with this IPv4-only example. Configure and test an IPv6 tunnel route before relying on a full-tunnel privacy claim.

Before calling the setup complete, verify that the server service is active, wg show reports a recent handshake and increasing transfer counters, the client can reach 10.8.0.1, and an IPv4 egress check reports the server’s public address. Reboot only after persistent firewall and forwarding settings are in place, then repeat those checks. For additional peers, issue separate key pairs and unique tunnel IPs, then remove a device by deleting its peer entry and reloading the interface.