Run WireGuard on a VPS with clear routing and recovery
A WireGuard VPS can provide encrypted remote access to systems you are authorized to use. Reliable deployment depends on explicit address plans, firewall and forwarding rules, protected keys, tested IPv4 and IPv6 routes, and a recovery path that does not depend on the tunnel itself. It is not a promise of anonymity or permission to bypass rules.
Key facts
- Common listener example
- `51820/udp`, configurable and not inherently required
- Identity model
- Public keys identify peers; private keys remain secret
- Routing control
- `AllowedIPs` affects peer selection and accepted source routes
- Recovery rule
- Keep console or SSH access outside the tunnel until validation
Draw the tunnel and trust boundaries first
Name the authorized users, peer devices, protected subnets, DNS resolvers, and destinations that should traverse the tunnel. Decide whether the VPS is only a remote-access endpoint, a router to another private network, or an egress gateway. Those designs require different forwarding, filtering, and logging choices. Avoid overlapping tunnel addresses with local networks used by clients.
WireGuard encrypts packets between configured peers; it does not secure a compromised endpoint, authenticate application users, or make traffic after the egress VPS invisible. The VPS public address and timing remain observable to relevant networks. Use the service for lawful private connectivity and continue to apply application authentication and data-protection controls.
- Assign a unique tunnel address and key pair to each peer.
- Document whether IPv4, IPv6, DNS, and internet egress are in scope.
- Do not route traffic you are not authorized to carry.
Verify reachability before changing the firewall
Confirm the VPS public addresses, default routes, interface names, provider firewall, guest firewall, and whether IP forwarding is enabled for the intended address family. A typical deployment permits one chosen UDP listener such as 51820/udp, preserves administrative access, and filters forwarding according to the destination rather than accepting every packet.
Use ip route, ss -lunp, and the provider console to establish a baseline. If clients will send IPv6, verify that the VPS has routed IPv6 and corresponding firewall rules; do not assume that an IPv4-only masquerade covers it. Save the current firewall configuration before applying changes and keep an automatic rollback for remote experiments.
- Open only the configured UDP port and required administration path.
- Apply forwarding and NAT rules only when the architecture requires them.
- Test from a genuinely external network, not only from the VPS itself.
Treat keys and `AllowedIPs` as security controls
Generate private keys on the device that will use them and restrict file permissions. Share only public keys. In /etc/wireguard/wg0.conf, review each peer independently: AllowedIPs influences which traffic is sent to that peer and which source addresses are accepted from it. Overly broad or overlapping entries can route traffic to the wrong peer or expand access unexpectedly.
Roaming clients behind NAT may need PersistentKeepalive, but use it only where required and choose the interval based on the network environment. A keepalive does not replace monitoring. Remove a departed or lost device's public key promptly, issue a new key pair after suspected compromise, and keep an inventory that maps keys to owners without publishing private material.
- Never send private keys through tickets or chat.
- Use the narrowest tunnel routes consistent with the task.
- Record key issuance, owner, device, rotation, and revocation.
Validate handshake, routing, DNS, MTU, and leaks
After starting the interface, inspect wg show for the expected peer, recent handshake, endpoint, and transfer counters. Test the tunnel address, each protected destination, DNS resolution, and the intended public egress for both address families. Use ip route on the client to confirm which prefixes enter the tunnel instead of inferring behavior from one successful ping.
If small packets work but larger transfers stall, investigate path MTU and encapsulation overhead before lowering MTU blindly. Test across representative mobile, office, and home networks. Confirm that tunnel failure does not expose traffic contrary to the client's intended routing policy and that administrative recovery remains available.
- Test allowed and deliberately disallowed destinations.
- Check IPv4, IPv6, and DNS separately.
- Record the validated configuration and a rollback point.
Operate the tunnel as a privileged network service
Patch the supported operating system, monitor interface availability, disk capacity, unusual transfer changes, and failed administrative access, and back up configuration without exposing private keys. Restrict who can edit peer definitions or firewall rules. Define how an authorized user requests a new device, reports a loss, and proves control of the account.
Review peers, keys, routes, DNS, forwarding, and business need on a schedule. Remove stale access and test recovery after kernel, firewall, or network changes. When retiring the server, revoke peers, erase configuration and key material, and verify that DNS or automation no longer points to the old endpoint.
- Alert on loss of reachability without collecting unnecessary browsing data.
- Keep configuration backups encrypted and access-controlled.
- Retest routes after every provider or firewall change.
Sources
Frequently asked questions
Does WireGuard make VPS traffic anonymous?
No. It encrypts traffic between configured peers. The endpoint IP, timing, VPS account, egress traffic, applications, and other records can still create links.
Must WireGuard use port 51820?
No. 51820/udp is a common example. The configured listener can use another suitable UDP port, which must match provider and guest firewall rules.
What should I check when there is no handshake?
Verify endpoint address and port, UDP firewall paths, public keys, system time, listener state with ss -lunp, and peer status with wg show. Keep console access while troubleshooting.
Should all traffic use `AllowedIPs` set to a default route?
Only if a full-tunnel design is intentional and tested. For access to specific systems, narrow prefixes reduce routing surprises and unnecessary exposure.