How to Build a WireGuard VPN Server on Raspberry Pi

A WireGuard server on a Raspberry Pi is one of the most satisfying small network projects. For the price of a modest board, a power supply and an evening, you get a private entrance to your home: reach files on your own network from a cafe, protect your phone on hotel Wi-Fi by sending its traffic home first, or manage a device that has no public address. The protocol is lean enough that even older boards cope well with ordinary home bandwidth.

This guide builds the server from scratch. It assumes a Pi running a current Raspberry Pi OS Lite, a wired connection to your router and a basic comfort with the terminal. All addresses, keys and hostnames below are placeholders. If you are still deciding between running your own and paying a service, read self-hosted versus commercial VPN first, because the two solve different problems.

What you are building, and what you are not

Be precise about the goal, because it shapes every choice.

You get	You do not get
An encrypted path from your phone or laptop to your home network	A way to appear in another country
Access to home devices by their local addresses	Anonymity from your home internet provider
Protection on shared Wi-Fi, because the local network sees only the tunnel	Protection from phishing, weak passwords or malware
Full control of the keys and the software	A service that someone else maintains for you

The single exit point is your home connection. Websites you visit through the tunnel see your home address, and the speed is limited by your home upload rate, since all traffic from outside must come back through it. For many people that is exactly right. For others it is a reason to prefer a commercial service for travel. The WireGuard whitepaper explains the design if you want to understand why the protocol is so compact.

Check that your home can be reached

The most common failure of home servers happens before any software is installed: the outside world cannot reach your router. Check this first.

1. Find your router's WAN address in its status page.
2. Visit any page that shows your public IP address and compare. If the two match, you have a public address. If the router shows something like 100.64.x.x to 100.127.x.x, or a private range, your provider is sharing one public address between many customers, a setup called carrier-grade NAT whose reserved range is described in RFC 6598. Port forwarding will not reach you in that case.
3. If the address is public but changes every few days, use a dynamic DNS name. Many routers have this built in, and small clients exist for the Pi. You will put the name, not the number, in your client configs.
4. Check whether your router is behind another router, for example a provider box plus your own. That is double NAT, and you need to forward the port on both or put the first one into bridge mode.
5. Read what a public IP address is if these terms are new.

Many providers can give a public address on request, sometimes for a fee. If that is not possible, a self-hosted server is the wrong tool and a hosted one fits better.

Install and generate keys

Update and install the tools:

sudo apt update && sudo apt full-upgrade -y
sudo apt install -y wireguard qrencode

Create a directory for keys with strict permissions and generate the server pair:

sudo -i
umask 077
cd /etc/wireguard
wg genkey | tee server.key | wg pubkey > server.pub

The private key stays on the Pi. The public key goes into each client. Never paste the private key into chats, tickets or screenshots. Pick a private tunnel range that does not overlap your home network. If your home uses 192.168.1.0/24, choose something like 10.44.0.0/24 from the private blocks in RFC 1918. The server will be 10.44.0.1, and clients will receive .2, .3 and so on.

Write the server configuration

Create /etc/wireguard/wg0.conf:

[Interface]
Address = 10.44.0.1/24
ListenPort = 51820
PrivateKey = SERVER_PRIVATE_KEY
PostUp = nft add table ip wgnat; nft add chain ip wgnat post '{ type nat hook postrouting priority 100 ; }'; nft add rule ip wgnat post ip saddr 10.44.0.0/24 oifname "eth0" masquerade
PostDown = nft delete table ip wgnat

Replace SERVER_PRIVATE_KEY with the contents of server.key. The two hook lines add address translation only while the tunnel is up. That lets clients reach the internet and your LAN through the Pi, which will look like an ordinary computer on your network. If you want clients to reach only the Pi itself, leave these lines out.

Enable forwarding permanently:

echo 'net.ipv4.ip_forward=1' > /etc/sysctl.d/90-forward.conf
sysctl --system

Then run it as a service, using the approach from the guide on managing WireGuard with systemd:

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

At this point wg show lists the interface and no peers. That is expected.

Forward the port and open the firewall

On your router, create a port-forwarding rule that sends UDP 51820 to the Pi's fixed address. Use UDP, not TCP, since WireGuard does not use TCP. The related risks and habits are explained in VPN port forwarding explained, which is worth a skim. Give the Pi a DHCP reservation so its address never changes.

On the Pi, if you run a firewall, allow only what is needed: SSH from your local network, and UDP 51820 from anywhere. Everything else stays closed. WireGuard is deliberately quiet: it does not answer packets from a sender that has no valid key, so a port scan does not reveal a running server in the way that many other VPN services do.

Add a peer: laptop and phone

Each device gets its own key pair and its own tunnel address. On the Pi, create the keys for a phone:

cd /etc/wireguard
wg genkey | tee phone.key | wg pubkey > phone.pub

Register the peer on the server by appending this to wg0.conf:

[Peer]
PublicKey = PHONE_PUBLIC_KEY
AllowedIPs = 10.44.0.2/32

Apply it without dropping existing connections:

wg syncconf wg0 <(wg-quick strip wg0)

Now write the client file phone.conf:

[Interface]
PrivateKey = PHONE_PRIVATE_KEY
Address = 10.44.0.2/32
DNS = 10.44.0.1

[Peer]
PublicKey = SERVER_PUBLIC_KEY
Endpoint = myhome.example.net:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

The AllowedIPs line is the key decision. With 0.0.0.0/0 all of the phone's traffic goes home, which suits public Wi-Fi. With 10.44.0.0/24, 192.168.1.0/24 only tunnel and home addresses go through, and everything else uses the phone's own connection. For the DNS line you need a resolver reachable at that address, such as a small resolver running on the Pi; otherwise point it at your router's address. Display the config as a QR code and scan it in the official WireGuard app:

qrencode -t ansiutf8 < phone.conf

Delete phone.conf and the private key from the Pi when you are done if you do not need a backup. A laptop works the same way, importing the file instead of scanning.

Test and troubleshoot

Turn the tunnel on from the phone while it is on mobile data, not your home Wi-Fi, since only then does the test cross the internet. Then check:

Symptom	Likely cause	What to do
No handshake on wg show	Port not reaching the Pi, wrong endpoint or CGNAT	Recheck forward rule, name and public address
Handshake, but no internet through the tunnel	Forwarding or NAT missing	Confirm ip_forward is 1 and the nft table exists
Handshake, home devices unreachable	AllowedIPs lacks the home range, or devices block the tunnel range	Add the range, check device firewalls
Some sites hang while others load	MTU too high for your line	Add MTU = 1380 on the client and test
Works for days, then fails	Dynamic address changed	Check the dynamic DNS update
Works on mobile data, fails at one cafe	That network restricts UDP	Try mobile data or another network

Use wg show on the Pi to see the last handshake and the data counters per peer. They make it clear at a glance which device is working. The speed article WireGuard speed test explains how to measure throughput without fooling yourself.

Harden and maintain it

A server on the internet is a responsibility, however small.

• Keep the Pi updated. Run updates monthly and enable automatic security updates if you prefer.
• Use SSH keys and disable password login. Do not forward SSH to the internet unless you really need to.
• Give each device its own peer entry and remove entries for devices you sell or lose, then apply the change.
• Back up the server private key and the config somewhere offline and encrypted. Without them you must reissue every client.
• Rotate keys if you ever suspect a leak. Generate new pairs, update both sides and delete the old ones.
• Watch your power and storage. A failing card takes the server and your remote access with it.
• Remember that you are the operator. If other people use your server, you are responsible for what they do through your home connection, so keep the peer list short and trusted.

Three ways people use it

A concrete picture helps you decide whether the project is worth an evening.

• The remote worker. Aroon keeps a network drive and a small development server at home. From a co-working space she connects to the Pi, uses the internal addresses and never exposes those services to the internet. Her split AllowedIPs sends only home traffic through the tunnel, so video calls stay on the local connection.
• The traveller on hotel Wi-Fi. Ben sets AllowedIPs = 0.0.0.0/0 on his phone before a trip. On a shared hotel network, everything he sends is encrypted to his house first. He accepts that his speed depends on his home upload rate and that the sites he visits see his home address.
• The family helper. Mali manages her parents' printer and media box from another city. A second peer on her laptop lets her reach their LAN addresses without any software on the parents' side beyond the Pi.

In all three cases the Pi is a doorway to your own network. If your main goal is something else, such as choosing between exit locations, a self-hosted server will disappoint you.

Common mistakes

• Skipping the reachability check, then debugging software for hours.
• Forwarding TCP instead of UDP.
• Reusing one client key on several devices, which makes them fight over the same session.
• Choosing a tunnel range that overlaps the home or cafe network.
• Putting the private key into a chat message.
• Expecting the server to hide your activity from your own internet provider.
• Forgetting that the speed is capped by your home upload rate.

Summary

Building a WireGuard server on a Raspberry Pi comes down to five steps: confirm your home can be reached, generate keys, write a small server config with forwarding and address translation, forward one UDP port, and add each device as its own peer. Test from mobile data, keep the Pi updated, and treat the key files as secrets. The result is a private, fully controlled way back to your own network.

If you would rather not run the other end yourself, the pricing page shows prepaid passes that work with the free VPNclient app, as described in the Linux setup guide.