A private tunnel with a clear purpose.

Define the route

Decide whether the tunnel carries only private service traffic or all internet traffic. Configure allowed routes intentionally and account for both IPv4 and IPv6. A split-tunnel and a full-tunnel setup have different leak and reachability considerations.

Keep one key per device

Generate private keys on the device where practical and never publish them. Use separate peer identities so a lost device can be revoked without replacing every client. Store server configuration with protected permissions.

Configure forwarding and DNS

Set forwarding and firewall rules deliberately. Check name resolution, MTU and the return path. Test the effective public address and DNS behaviour from the client instead of assuming a successful handshake means all traffic uses the intended route.

Understand the trust shift

A self-hosted VPN can protect traffic on the local network, but the VPS and upstream still see metadata and any unencrypted traffic. It does not make a browser session anonymous or override the policies of services you access.

Use an explicit listener and inspect the handshake

UDP 51820 is a common WireGuard configuration choice, not a mandatory or guaranteed host policy. Open only the chosen UDP port and keep administration separately restricted. The wg show command can report peer handshake and transfer information without requiring you to publish private keys.

• Verify a recent handshake
• Test the intended private service
• Test internet and DNS routes only if a full tunnel is intended

wg show

Official documentation: WireGuard quick start

Use keepalives only when the network needs them

A peer behind NAT may need periodic keepalive traffic to preserve a mapping for inbound packets. The appropriate setting depends on the network. Keep the configuration intentional; do not copy a full-tunnel recipe if the goal is only access to one private application.

Choose split tunnelling or a full-tunnel design

Start with the actual goal. A split tunnel can carry only a private subnet or administrative service; a full tunnel also needs internet forwarding, egress rules and a DNS plan. Choose non-overlapping tunnel addresses and decide how IPv6 is handled. UDP51820 is a common port, not a required one. Confirm the selected host’s policy and keep console/administrator access available while changing routes or firewall rules.

• Give each device a unique key pair and a narrow peer identity.
• Keep private keys on their intended devices and off public files or QR sharing.
• Treat public endpoints and client roaming as part of the network design.

Official documentation: WireGuard quick start

Bring up a small tunnel before adding internet routing

Follow the supported OS installation and generate keys with restrictive file permissions. Configure the server interface, one peer and the chosen UDP listener. A server-side peer should normally have its own tunnel address in AllowedIPs rather than an overlapping catch-all assigned to multiple clients. Start with access to the tunnel address, then add approved forwarding and destination routes. A successful handshake proves peer contact, not that DNS or internet egress is correct.

# Inspection examples; these do not reveal a private key:
wg show
ip address show dev wg0
ip route get 10.44.0.1

Official documentation: WireGuard interface and peer configuration

Test the expected path and a forbidden path

From the client, verify a recent handshake and a permitted private service. Try a destination that should be denied. If using a full tunnel, check the effective public route, DNS resolver and IPv6 behaviour from that client; split-tunnel traffic should retain the intended local path. Repeat after a client network change. Use a NAT keepalive only when the peer’s network needs it, and keep the interval consistent with the documented design.

• No handshake: inspect endpoint DNS, UDP reachability, keys and peer mapping.
• Handshake but no service: inspect AllowedIPs, firewall, forwarding and the return route.
• Some sites stall: investigate path MTU before applying a random permanent value.

Make revocation and reboot behaviour repeatable

Remove a lost device’s peer key and confirm it can no longer establish the intended access. Keep encrypted configuration backups and an inventory of which public key belongs to which device. Test whether the interface and required routing rules return after a normal reboot. A VPN shifts trust toward the VPS and its upstream; it does not remove application identifiers, account cookies or the need for HTTPS to the final destination.

Official documentation: WireGuard wg-quick manual