Build a WireGuard Site VPN on a Linux VPS

A Linux VPS is a practical place to anchor a small Site VPN. It has a stable public address, runs continuously, and can route traffic to a private web server on the same machine or to another origin reachable through a second tunnel or private network. WireGuard fits this job because its configuration is compact: each peer has a key, an address, and a set of permitted routes. The difficult part is rarely creating the interface. The real work is choosing a clean address plan, narrowing firewall rules, and maintaining keys after the first successful connection.

This guide presents a vendor-neutral blueprint rather than a copy-and-paste appliance. Commands use a Debian or Ubuntu style package manager, but the architecture applies to other Linux distributions. Replace example addresses, interface names, and ports with values from your own plan. Test from a console session that will remain available if networking changes go wrong, and make a provider snapshot or backup before altering firewall or forwarding rules.

Design the network before installing packages

Choose one private subnet for WireGuard peers and keep it separate from the VPS provider’s private network, your home LAN, and common office ranges. An example is 10.73.40.0/24, with 10.73.40.1 assigned to the gateway and one address per client. Reserve addresses in a small inventory so a peer name, public key, owner, and assigned address remain linked. Do not reuse an old address until you have confirmed the previous peer is revoked everywhere.

Decide where the protected website will listen. The simplest arrangement is a web server on the same VPS bound to 10.73.40.1 or to loopback behind a reverse proxy that listens on the WireGuard address. A separate origin can use another private route, but then the gateway needs forwarding in both directions and the origin needs a return path. Draw the packet path now; if you cannot explain the return route, the first browser request may arrive while every response disappears.

Install WireGuard and create keys safely

Install the distribution package, confirm the kernel or userspace implementation is available, and create a restrictive directory for key material. Generate a private key on each device whenever possible so the secret never travels through email or chat. The server needs its own private key and the public key derived from it. Keep private keys out of shell history, configuration repositories, backups that lack encryption, and support tickets. Public keys are identifiers and can be recorded in the peer inventory.

The official WireGuard Quick Start documents the core tools and the relationship between interfaces, keys, peers, endpoints, and allowed IPs. Read it before adding automation. Helper scripts can save time, but an operator should still know which configuration creates the interface, which rule identifies a peer, and which route is installed. That knowledge is essential when a client works from one network but not another.

sudo apt update
sudo apt install wireguard
sudo install -d -m 700 /etc/wireguard/keys
umask 077
wg genkey | sudo tee /etc/wireguard/keys/server.key | wg pubkey | sudo tee /etc/wireguard/keys/server.pub

Create a narrow server configuration

A basic server interface needs a private address, a UDP listen port, and the server private key. Each client appears as a peer with its public key and exactly the address or routes that peer is allowed to use. On the server, a phone assigned 10.73.40.10 should normally have AllowedIPs = 10.73.40.10/32, not the whole VPN subnet. WireGuard uses this field both as a routing selector and as a source-address authorization rule, so broad entries can produce confusing or unsafe behavior.

Use wg-quick for a straightforward deployment, but keep firewall policy outside the configuration once the system grows. Embedding many opaque pre-up and post-down commands makes recovery harder. Start the interface, inspect it with wg show, and confirm the UDP socket is listening. Enable the service at boot only after a manual start and stop complete successfully. Keep a second terminal open while testing so a firewall mistake does not become a locked server.

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

[Peer]
# admin-laptop
PublicKey = CLIENT_PUBLIC_KEY
AllowedIPs = 10.73.40.10/32

Open one port and close everything else by default

The public firewall needs the selected UDP port for WireGuard and only the management ports you intentionally expose. The private web service should accept traffic on the WireGuard interface or private address, not on every interface. If the reverse proxy listens on 0.0.0.0, a cloud firewall rule may hide the mistake today, but a future rule change can publish the service. Bind explicitly and verify with a socket listing tool. Defense in depth means the host and provider firewall agree.

Forwarding is required only when the gateway routes to a different host or network. Enable IPv4 or IPv6 forwarding deliberately, add rules that allow the required source and destination, and reject unrelated forwarding. Network address translation can simplify return routing for a small origin network, but it hides client addresses from the destination and can complicate logs. A routed design preserves addresses but requires the origin to know how to return traffic to the WireGuard subnet. Choose one model and document it.

Build a client profile for the protected site

The client interface receives its unique private address and the client private key. Its peer entry contains the server public key, public endpoint, and the destination routes that should use the tunnel. For a Site VPN, those routes might be only 10.73.40.1/32 or a dedicated service subnet. Avoid 0.0.0.0/0 unless the design intentionally sends all internet traffic through the VPS. A narrow route reduces bandwidth, avoids changing the user’s general egress location, and limits the effect of a gateway outage.

Mobile networks and home routers may remove idle UDP mappings. A modest persistent keepalive can help a peer that must remain reachable behind NAT, but it is not required for every device and consumes a small amount of battery and network activity. Import the profile through a secure, controlled method, label it clearly, and delete temporary QR codes or files. Confirm the device clock is accurate, then test handshake time, packet counters, DNS resolution, and the private website.

[Interface]
Address = 10.73.40.10/32
PrivateKey = CLIENT_PRIVATE_KEY

[Peer]
PublicKey = SERVER_PUBLIC_KEY
Endpoint = vpn.example.net:51820
AllowedIPs = 10.73.40.1/32
PersistentKeepalive = 25

Add DNS and TLS without exposing the origin

A memorable hostname makes the private site easier to use. You can run a DNS resolver reachable over the tunnel, distribute a static host mapping on managed devices, or use a public DNS record that points to a private address when that disclosure is acceptable. Keep the answer consistent across clients. If the same hostname serves a public landing page and a private application, use split DNS carefully and make the two destinations visually distinct so users know which environment they are operating.

Serve HTTPS inside the VPN. For a domain you control, DNS-based certificate validation can issue a publicly trusted certificate without opening the web origin. A private certificate authority is another option for managed devices, but trust installation and revocation become part of operations. Configure the reverse proxy to listen on the WireGuard address, send security headers, and reject unknown hostnames. Test that the public VPS address and alternate ports do not reveal the protected application.

Operate the VPN as a maintained service

Record the purpose, owner, and expiration review date for every peer. Remove peers when a device is replaced, a contractor leaves, or access is no longer required. Patch the operating system and WireGuard packages, monitor disk space and service health, and review authentication and web logs for unexpected activity. Back up configurations and the address inventory securely, but remember that a backup containing private keys can grant access. Protect it accordingly.

Practice recovery. Know how to rebuild the interface from a clean VPS, restore DNS, and move the public endpoint if the server is unavailable. Test configuration changes with a new peer before rotating all devices. When the number of peers grows beyond what a text file and manual process can safely support, add an auditable provisioning workflow or move to a control plane designed for identity, policy, and device lifecycle. Simplicity is a benefit only while the operator can still understand the whole system.