WireGuard Site VPN Blueprint

Why WireGuard fits a focused private website

WireGuard gives each peer a public key, private address, and set of allowed destinations. That compact model is well suited to a small hub-and-spoke Site VPN: a Linux VPS provides a stable public endpoint, and phones, laptops, servers, or routers initiate encrypted UDP sessions to it. The software is open source and available on major platforms, but the full deployment still needs hosting, DNS, monitoring, backups, and an operator.

The protocol intentionally does not provide a user directory, certificate authority, web dashboard, billing system, or automated mesh control plane. Those omissions keep the tunnel layer small. They also mean a team must create an inventory and provisioning workflow. For a handful of stable devices, a reviewed configuration file can be enough. For a dynamic fleet, a control plane or managed service may be safer.

Use a gateway topology unless the requirement is truly a mesh

A private website has a natural center: the gateway next to the service. Each client needs only one public endpoint, and the server holds one peer entry per device. The website can run on the same VPS, listen on the WireGuard address, or live on another private host with an explicit route. This avoids the NAT traversal and relay problem that appears when arbitrary peers must connect directly to each other.

The configuration model

The gateway interface has a private address, listen port, and private key. Each client peer entry contains that client’s public key and the exact address the peer is allowed to use. On the client, the gateway peer contains the server public key, endpoint, and destinations that should traverse the tunnel. For a Site VPN, the client route is normally a host or service subnet rather than a default route.

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

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

The client profile mirrors the relationship:

[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

Values are examples, not a drop-in production configuration. Generate private keys on their devices where possible, choose your own addresses and endpoint, and decide whether keepalive is necessary for roaming or NAT behavior. The complete Linux VPS build guide explains installation, forwarding, DNS, TLS, and recovery in context.

The firewall and web origin should reinforce the route

Expose the selected UDP port publicly and only the management paths the server requires. The private web service should listen on the WireGuard address or loopback, not on 0.0.0.0 or an IPv6 wildcard. Provider firewall rules are helpful, but host binding and host firewall policy should remain safe if the provider rule changes later.

Enable forwarding only when the gateway routes to another host. Allow the exact source subnet, destination, and protocol; reject unrelated forwarding. Decide between routed return traffic and address translation. Then test public IPv4, public IPv6, alternate ports, direct IP access, and unexpected hostnames. The tunnel is not the boundary if the application can still be reached around it.

Unique keys make revocation possible

One device should have one key pair. Copying a shared configuration to every phone and laptop makes a lost device impossible to revoke without interrupting everyone. Record the peer name, owner, platform, assigned address, public key, creation date, and access review date. Remove peers when a device is replaced or a person leaves, and verify the old key no longer handshakes.

Protect private keys in backups and support workflows. A screenshot, QR code, downloaded configuration, or CI artifact can grant access. Delete temporary transfer files and avoid placing secrets in repositories. When peer count or policy complexity grows beyond what a human can audit, add a provisioning system or adopt a coordination layer rather than pretending the text file remains simple.

Troubleshoot from the outside inward

1. Confirm the client has general connectivity and resolves the gateway endpoint.
2. Confirm the UDP port reaches the server and the peer shows a recent handshake.
3. Inspect packet counters and verify the client installed the intended route.
4. Resolve the private hostname and compare its answer with the address plan.
5. Check the host firewall and the web server’s listening address.
6. Verify the TLS certificate and application logs.
7. Test the return route from the origin to the client subnet.

This order prevents DNS changes from hiding a missing handshake and prevents application debugging from consuming time when the origin is not listening privately. Keep a known-good pilot peer and a console recovery path for the gateway.