To set up a VPN, create a key pair on each machine, give each a tunnel interface with a private address, tell each side the other's public key and endpoint, and bring the interface up. WireGuard's official quick start shows this with a few commands. The rest is deciding what traffic goes through.
What do you need before you begin?
Two machines, one reachable from the other on a UDP port, and administrator rights. WireGuard sends all its packets over UDP, so the server's firewall must allow the port you pick. The project's example uses 51820. Install WireGuard first, using your operating system's package instructions, and read the project's conceptual overview.
Step 1: How do you generate keys?
WireGuard uses base64-encoded public and private keys. The quick start generates them with the wg utility. Set a restrictive file mask first so the private key is not readable by others, then run wg genkey to create a private key and wg pubkey to derive the public key from it. The documentation shows doing both at once by piping through tee.
Keep the private key on its own machine. Never email it or commit it to a repository. Share only the public key.
Step 2: How do you create the interface?
On Linux, add an interface of type wireguard with ip link add dev wg0 type wireguard. On other systems the project says to run the userspace implementation, wireguard-go. Then assign an address inside a private range that you choose for the tunnel, for example 192.168.2.1/24 on the server and a different address on the client.
Step 3: How do you configure the peer?
Use the wg tool to set a listening port, the private key file, and a peer. A peer entry holds the other side's public key, the allowed IPs, and, for the side that initiates, the endpoint address and port. The allowed IPs list does two jobs: it is the set of addresses you will send to that peer, and the set of source addresses you will accept from it. Keep it tight. Do not set it to everything unless you intend to route all traffic through the peer.
Step 4: How do you bring it up?
Run ip link set up dev wg0, then check with wg show. The wg-quick tool can automate the routine bring-up and tear-down from a configuration file, which is the usual way to make a setup repeatable.
What about NAT and firewalls?
WireGuard is quiet when idle and only sends when it has something to say. A peer behind NAT may stop receiving once the NAT mapping expires. The quick start describes a persistent keepalive option. It suggests an interval of 25 seconds as one that works with many firewalls, and recommends leaving it off if you do not need it.
A constructed example
A two-person team wants to reach a small office server from home. The server has a public address and UDP port 51820 open. The server gets tunnel address 10.8.0.1, the laptop gets 10.8.0.2. On the server, the laptop's peer entry allows only 10.8.0.2. On the laptop, the server's peer entry allows only 10.8.0.1 and the office subnet. Because the laptop sits behind home NAT, it sets a keepalive of 25 seconds. Traffic to anything else, such as video streaming, bypasses the tunnel.
How to check or apply this
- Generate keys on each machine and keep private keys private.
- Choose a tunnel address range that does not clash with your home or office networks.
- Open the UDP port on the server firewall and nothing else.
- Restrict allowed IPs to what each peer really needs.
- Test with a ping across the tunnel, then check
wg showfor a recent handshake. - Back up the configuration without private keys, and record who holds each key.
Quick check
Does WireGuard use TCP or UDP?
UDP. All WireGuard packets are sent over UDP, so open the chosen UDP port in the firewall.
Should I enable persistent keepalive everywhere?
No. The project says to leave it off unless a peer is behind NAT or a firewall and needs to receive connections while idle.
Sources
Last reviewed: 18 October 2026.
