WireGuard Config Generator

WireGuard setup is mostly a question of identity and routes. A private key belongs to one local interface, a public key identifies one remote peer, and AllowedIPs names the IP prefixes that peer is allowed to use inside the tunnel. Once those three pieces are wrong, the configuration may still look tidy while traffic goes to the wrong device, disappears into the wrong route, or never reaches the endpoint that should answer the first packet.

Small remote-access VPNs often start with a hub-and-spoke shape: one server listens on a UDP port, and each laptop or phone receives a single tunnel address such as 10.80.0.10/32. Site-to-site designs add another choice because a peer can represent a router rather than a single device. In that case, the peer's allowed prefixes may include a whole office network such as 10.55.0.0/16, and the server must know that the branch router owns that route.

The endpoint is only the first place a peer tries to send encrypted UDP traffic. After a valid packet arrives, WireGuard can remember the latest authenticated source address for roaming. That is helpful for mobile clients, but it does not remove the need for a reachable public host and port when off-network clients start a connection.

wg-quick adds practical interface settings around the core WireGuard peer model. Address assigns tunnel IPs, DNS can set resolvers or search domains, MTU can override automatic sizing, and Table controls route installation. Those conveniences make short files useful, but they also make intent easy to overread. A configuration draft cannot prove that keys were exchanged safely, a firewall is open, network address translation is ready, or the selected route table matches the rest of the host.

The safest review habit is to treat every peer as a route owner. Confirm who owns each tunnel address, whether the advertised prefixes are host routes or networks, whether default routes are intentional, and whether secret key material is still a placeholder. That review matters before the file reaches a server, a laptop, a phone, or a branch gateway.

How to Use This Tool:

Start with the server listener, add one peer row per client or site, then use the generated review and ledger to catch route or key problems before copying configs.

1. Set Interface name, Server tunnel addresses, Listen port, and Public endpoint. The summary should show the interface, UDP port, and endpoint in one line when those values are usable.
2. Choose Client AllowedIPs default for the routes ordinary client profiles should send through the server. Use private network CIDRs for split tunnel, or use 0.0.0.0/0, ::/0 only when client default traffic should enter WireGuard.
3. Add Client DNS when client profiles should receive resolver addresses or search domains. Internal DNS values only help when clients can reach the resolver through the tunnel.
4. Enter Peer rows with one line per peer. Pipe-separated rows can include name, tunnel CIDR, server-side AllowedIPs, client-side AllowedIPs, DNS override, public key, private key, and preshared key.
5. Use Hub sample for individual remote-access peers or Site sample for a branch-style peer that advertises an extra LAN. The sample buttons replace peer rows only, so server fields and advanced settings remain under your control.
6. Open Advanced when you need real server key tokens, an explicit MTU, a non-default Persistent keepalive, a Route table mode, or preshared-key placeholders in generated profiles.
7. Fix every Error in Config Review before using Server Config, Peer Blocks, or Client Configs. Then read the warnings and compare Peer Ledger against your intended address plan.

Interpreting Results:

The strongest signal is the Config Review severity, not the fact that text was generated. Error rows mean a value breaks the page's structural checks, such as bad CIDR notation, a missing peer address, an invalid endpoint, a port outside range, duplicate normalized peer names, or duplicate peer tunnel addresses. Generated config text is still shown so the broken area is easier to inspect, but it should not be applied.

Warning rows call out choices that might be intentional but need human review. Placeholder keys are warnings because planning with placeholders is useful, but real configs need keys generated and distributed through a controlled path. Private IPv4 endpoints may work for peers already on the same network, but off-network clients usually need a public DNS name or public address. A peer address outside the server's IPv4 tunnel network may be valid in an advanced routing plan, but it deserves a second look.

• Peer Ledger is the route-ownership view. Check each peer's Client address, Server AllowedIPs, Client AllowedIPs, DNS value, and generated client filename before distributing profiles.
• Server Config gives a complete server-side file with an [Interface] section and all generated peer blocks. Use it when building a new server file or replacing a reviewed draft.
• Peer Blocks omits the server interface and gives append-only peer sections for adding clients to an existing server file.
• Client Configs gives one client profile per valid peer address. A peer with an invalid tunnel CIDR appears in review but does not produce a usable client config.
• JSON, CSV, and DOCX exports are review artifacts. They help hand off the route plan, but they should be treated as sensitive if real private keys or preshared keys were entered.

Technical Details:

WireGuard configuration has two main levels. The local [Interface] section gives the interface private key and, on a listening server, the UDP port. Each [Peer] section names a remote public key and the prefixes associated with that peer. The public key authenticates the peer; AllowedIPs tells WireGuard which decrypted source addresses are accepted from that peer and which outgoing destination addresses should be encrypted to that peer.

wg-quick extends the core peer format with convenience fields that affect the host operating system. Address assigns tunnel addresses, DNS can configure resolvers or search domains, MTU can override automatic sizing, and Table decides whether routes are installed automatically, disabled, or placed into a numeric routing table. Full-tunnel routes plus Table = off require a separate routing plan because wg-quick will not create the default route for that file.

Rule Core:

Formula Core:

IPv4 subnet review uses a masked network comparison. A peer IPv4 address fits a server IPv4 tunnel network when both addresses match after applying the server network mask.

A is the peer IPv4 address, N is the server network address, and M is the mask produced by the server prefix length. IPv6 CIDRs are checked for notation and prefix range, but the subnet-fit warning is limited to comparable IPv4 values.

Field Map:

Peer Row Translation:

A peer row can supply up to eight values in order: peer name, peer tunnel CIDR, server-side AllowedIPs, client-side AllowedIPs, DNS override, peer public key, peer private key, and preshared key. Blank route fields inherit defaults where available. Blank key fields become visible placeholders so missing secrets remain obvious during review.

Privacy Notes:

WireGuard private keys and preshared keys are secrets. If you enter real key material, generated configs, copied rows, downloads, JSON, CSV, DOCX exports, and screenshots can all contain sensitive VPN credentials.

• Use placeholders while discussing topology or collecting review feedback.
• Replace placeholders only in a controlled handoff path for the intended server or peer.
• Do not send one peer's client profile to another peer because the profile can contain that peer's private key.
• Keep the final peer ledger with the deployed configs so route ownership can be checked later.

Worked Examples:

Remote-access laptop. A server uses wg0, 10.80.0.1/24, UDP 51820, and vpn.example.com:51820. The peer row laptop-01 | 10.80.0.10/32 | 10.80.0.10/32 | 10.80.0.0/24, 10.44.0.0/16 should produce one Client Configs profile and one Peer Ledger row. The ledger should show the laptop address, the server-side host route, and the private networks the laptop will route through WireGuard.

Full-tunnel phone. A phone row with client AllowedIPs set to 0.0.0.0/0, ::/0 creates a client profile that routes default IPv4 and IPv6 traffic through the server. Config Review adds an Info row for default routing. Before sharing that profile, confirm DNS, firewall forwarding, and NAT behavior on the server because the generated text cannot verify those host settings.

Branch route. A site peer such as branch-gw | 10.80.0.20/32 | 10.80.0.20/32, 10.55.0.0/16 | 10.80.0.0/24, 10.44.0.0/16 tells the server that the branch gateway owns both its tunnel address and the 10.55.0.0/16 LAN. Peer Ledger should make that route visible under the branch peer, not under a laptop or phone peer.

Duplicate peer names. Rows named Ops Laptop and ops-laptop normalize to the same client filename. Config Review reports Duplicate peer names. Rename one row, such as ops-laptop-backup, then confirm the filenames in Peer Ledger are distinct.

FAQ:

Glossary:

AllowedIPs

The peer prefix list used for cryptokey routing and accepted decrypted source addresses.

CIDR

Address notation that combines an IP address with a prefix length, such as 10.80.0.10/32.

Endpoint

The host and UDP port a peer uses for first contact before roaming updates occur.

Persistent keepalive

A periodic authenticated empty packet used to keep a NAT or stateful firewall mapping open.

Preshared key

An optional symmetric secret mixed into WireGuard's public-key cryptography.

Peer ledger

The generated table that records peer address, route, DNS, and client filename choices.

References:

• WireGuard conceptual overview, WireGuard project.
• WireGuard quick start, WireGuard project.
• Protocol & Cryptography, WireGuard project.
• wg(8) manual page, Linux man-pages project.
• wg-quick(8) manual page, Linux man-pages project.
• How to configure WireGuard VPN in openSUSE and SLES, simplified.guide.