Why WireGuard and Why Raspberry Pi
WireGuard is a modern VPN protocol that strips away the complexity that made older solutions like OpenVPN feel like a sysadmin’s weekend project. It runs as a kernel module, uses state-of-the-art cryptography by default, and produces a configuration so minimal that you can read the entire setup file in under a minute. Where OpenVPN config files can sprawl across hundreds of lines, a WireGuard peer config often fits in ten.
Pairing WireGuard with a Raspberry Pi gives you a self-hosted VPN server that sips power, costs very little to run, and sits quietly on your home network routing encrypted traffic back from wherever you happen to be. Whether you’re connecting from a hotel Wi-Fi or locking down traffic on a mobile device, the combination handles it without the overhead of cloud-based VPN subscriptions or the trust issues that come with them.
What You Need Before Starting
The setup assumes you have a Raspberry Pi running Raspberry Pi OS Lite (any recent version), a static local IP address assigned to the Pi from your router, and SSH access already working. A Pi 3, 4, or Zero 2 W all handle WireGuard without breaking a sweat. You also need the ability to forward a UDP port on your router – this is the one step that trips people up most often, and it varies by router model, so check your router’s admin panel ahead of time.
You will need a domain name or a way to know your home IP address remotely. If your ISP assigns a dynamic IP, a free dynamic DNS service like DuckDNS solves the problem cleanly. Write down your Pi’s local IP, the UDP port you plan to use (51820 is the WireGuard default), and how many client devices you want to connect. Each device needs its own key pair and config file.
Installing and Configuring WireGuard
Start by updating the system and installing WireGuard through apt. On Raspberry Pi OS, run sudo apt update && sudo apt upgrade -y followed by sudo apt install wireguard -y. Once installed, move to the WireGuard config directory with cd /etc/wireguard. Generate the server’s private and public key pair using wg genkey | tee server_private.key | wg pubkey > server_public.key. The private key stays on the server. The public key gets shared with clients.
Create the server configuration file at /etc/wireguard/wg0.conf. The file has two main blocks: the Interface block for the server, and a Peer block for each client device. The Interface block sets the server’s VPN IP address (commonly 10.0.0.1/24), the ListenPort (51820), and the private key. It also includes two PostUp and PostDown lines that handle IP forwarding and NAT through iptables, which are what actually route client traffic through your home connection. Without those lines, clients connect but their internet traffic goes nowhere.
A basic server config looks like this: Address is 10.0.0.1/24, ListenPort is 51820, PrivateKey is the contents of server_private.key. PostUp runs iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE. PostDown reverses the same rules with -D instead of -A. If your Pi connects via Wi-Fi rather than ethernet, swap eth0 for wlan0. Then enable IP forwarding by editing /etc/sysctl.conf and uncommenting the line net.ipv4.ip_forward=1, then applying it with sudo sysctl -p.
For each client device, generate a separate key pair the same way you generated the server keys. Add a Peer block to the server config containing the client’s public key, an AllowedIPs line set to that client’s unique VPN IP (like 10.0.0.2/32), and optionally a PersistentKeepalive value of 25 if the client is behind NAT. The client’s own config file mirrors this structure in reverse: its Interface block holds its private key and VPN IP, and its Peer block points to the server’s public key, the server’s public endpoint (your domain or home IP plus the port), and AllowedIPs set to 0.0.0.0/0 if you want all traffic routed through the VPN.
Starting the Service and Connecting Clients
Bring up the WireGuard interface with sudo wg-quick up wg0 and check the status with sudo wg show. If the interface is up and listening, enable it to start automatically on boot with sudo systemctl enable wg-quick@wg0. The service will survive reboots and restart automatically without any manual intervention. At this point, port forwarding on your router is the remaining piece – create a UDP rule forwarding your chosen port to the Pi’s local IP address.
Distributing client configs can be done by copying the file manually, using SSH to transfer it, or – for mobile devices – generating a QR code. Install qrencode via apt, then run sudo cat /etc/wireguard/client1.conf | qrencode -t ansiutf8 and scan the resulting code with the WireGuard mobile app. The app is available on both iOS and Android, and scanning the QR imports the entire configuration instantly. Desktop clients for Windows and macOS import the .conf file directly through the app’s interface.
Once connected, verify the tunnel is working by checking your public IP from the client device – it should show your home IP rather than the network you are physically on. Run a ping to 10.0.0.1 (the server’s VPN IP) to confirm the tunnel is passing traffic. If the handshake in sudo wg show shows a recent timestamp and rising data transfer counts, the connection is healthy.
One detail worth keeping in mind: WireGuard does not log connection events by default, and its stateless design means a peer only appears in wg show output after it has sent at least one packet. If a client shows no handshake, the most common causes are a mismatched public key in the server’s Peer block, a firewall blocking the UDP port at the router level, or an incorrect endpoint address in the client config. Checking each of those three in order resolves the problem in almost every case. For users already running remote access tools on the same Pi, it is worth confirming that Tailscale or any other VPN layer is not conflicting with WireGuard’s routing rules before troubleshooting further.
