How to Generate WireGuard Config Files the Right Way

WireGuard's simplicity is its superpower, but that simplicity means there's no hand-holding when you need to generate WireGuard config files correctly. A malformed config fails silently or, worse, connects without actually protecting you. This guide explains the moving parts (keys, addresses, AllowedIPs), walks through clean server and client templates, and covers the key-hygiene rules that keep your tunnel secure.

The Moving Parts, Explained

A WireGuard config has a small number of fields, and each one matters:

• PrivateKey: Your device's secret identity. Generated with wg genkey. Never shared, never transmitted.
• PublicKey: Derived from the private key (echo <private> | wg pubkey). This is what you give to the other side, it's safe to share.
• PresharedKey (optional): An extra symmetric key shared between two peers for post-quantum resistance. Nice to have, not required.
• Address: The device's IP inside the tunnel (e.g., 10.0.0.1/24 on the server, 10.0.0.2/32 on a client). These are private addresses you choose, they don't need to relate to your real network.
• ListenPort: The UDP port the server listens on (conventionally 51820).
• Endpoint: Where the client connects: your server's public address, ideally a DDNS hostname, plus port (e.g., myhome.example.com:51820).
• AllowedIPs: The heart of WireGuard's security model ("cryptokey routing"). It defines which IPs may arrive from / be sent to a peer.
• On the client: 0.0.0.0/0 means "send everything through the tunnel" (full tunnel). A narrower range means split tunneling.
• On the server: each peer's entry lists that peer's tunnel IP (e.g., 10.0.0.2/32), the server will only accept packets from that peer claiming that source.
• PersistentKeepalive: How often (seconds) the client pings the server to keep NAT mappings alive. 25 is the standard value for clients behind NAT.

Generating Keys Properly

On any machine with WireGuard tools installed:

# Server keys
wg genkey | tee server_private.key | wg pubkey > server_public.key

# Client keys (repeat per client - never reuse)
wg genkey | tee client1_private.key | wg pubkey > client1_public.key

Rules that matter:

1. One key pair per device. Two devices sharing a private key will fight over the tunnel IP and cause intermittent, maddening failures.
2. Private keys live in the config file with 0600 permissions (chmod 600 wg0.conf).
3. Private keys are never emailed in plaintext, pasted into chat, or stored in unencrypted notes.

Server Config Template Walkthrough

/etc/wireguard/wg0.conf on the server:

[Interface]
PrivateKey = <server private key>
Address = 10.0.0.1/24
ListenPort = 51820

# Enable forwarding + NAT so clients reach the internet
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
# Laptop
PublicKey = <client1 public key>
AllowedIPs = 10.0.0.2/32

[Peer]
# Phone
PublicKey = <client2 public key>
AllowedIPs = 10.0.0.3/32

Notes: adjust eth0 to your server's actual outbound interface. Each [Peer] section gets exactly one client's public key and that client's tunnel IP with /32. The server's Address uses /24 so it owns the whole tunnel subnet.

Client Config Template Walkthrough

On the client (laptop, phone, or travel router, the fields are identical):

[Interface]
PrivateKey = <client1 private key>
Address = 10.0.0.2/32
DNS = 10.0.0.1

[Peer]
PublicKey = <server public key>
Endpoint = myhome.example.com:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

Notes: DNS = 10.0.0.1 routes DNS through the tunnel to the server (preventing DNS leaks). AllowedIPs = 0.0.0.0/0 is the full-tunnel setting, everything goes through home. PersistentKeepalive = 25 keeps the connection alive through hotel and mobile NAT.

Key Hygiene: What to Never Share or Reuse

When a device is lost, stolen, or sold: remove its [Peer] block from the server config and restart the interface. That single action fully revokes its access, no password changes needed anywhere else.

Testing Before You Trust It

1. Bring the tunnel up: sudo wg-quick up wg0 (or import the config in your app/router).
2. Check the handshake: sudo wg show should show a recent handshake and transfer counters moving.
3. IP test: Your public IP should be your home/server IP.
4. DNS leak test: All resolvers shown should be your tunnel DNS, never the local network's.
5. Kill test: Stop the server side briefly, with a proper kill switch (or AllowedIPs full-tunnel on a router with firewall rules), traffic should stop, not leak.

Frequently Asked Questions

Need help setting this up?

Config files are unforgiving, and one wrong key means a tunnel that silently fails. If you'd rather skip the trial and error, our team will build and test the whole thing for you: https://homeipvpn.com.