WireGuard Config Generator

Interface name:

Use the interface name that will map to /etc/wireguard/<name>.conf.

Server tunnel addresses:

Comma or newline separated CIDRs; dual-stack addresses are allowed.

Listen port:

Use the UDP port opened on the server firewall.

UDP

Public endpoint:

Use a DNS name or public address plus port.

Client AllowedIPs default:

Comma separated route CIDRs for client configs.

Client DNS:

Optional comma separated DNS values inherited by every peer unless a row overrides them.

Peer rows:

Use pipes so route lists can contain commas; blank columns inherit sensible defaults.

Samples overwrite peer rows only; key placeholders stay visible in the generated configs.

Fix WireGuard inputs

{{ error }}

Server private key token:

The server Interface PrivateKey value.

Server public key token:

Use the real server public key when you are ready to hand configs to clients.

MTU:

Optional interface MTU in bytes.

bytes

Persistent keepalive:

Applied to every generated client Peer block.

seconds

Route table mode:

Most wg-quick deployments should keep automatic route handling.

Custom route table:

Integer route table ID to emit as Table.

Include preshared key placeholders

Adds PresharedKey fields to both server and client configs unless a peer row supplies its own value.

{{ result.serverConfig }}

{{ result.clientBundle }}

Peer	Client address	Server AllowedIPs	Client AllowedIPs	DNS	Client file	Copy
{{ row.peer }}	`{{ row.address }}`	`{{ row.serverAllowedIps }}`	`{{ row.clientAllowedIps }}`	{{ row.dns }}	`{{ row.clientFile }}`
No valid peers yet.

Severity	Check	Detail	Recommendation	Copy
{{ row.severity }}	{{ row.check }}	{{ row.detail }}	{{ row.recommendation }}

Export to PDF Fullscreen

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

A WireGuard configuration describes one tunnel interface and the peers allowed to exchange encrypted IP packets through it. The file is small compared with many VPN profiles, but every line carries routing or identity meaning. A wrong AllowedIPs value can send traffic to the wrong peer, a missing endpoint can leave a client unable to start the first handshake, and placeholder keys must never be confused with deployable credentials.

WireGuard uses public keys as peer identities. Each interface has a private key, and each peer block names the other side's public key plus the tunnel addresses or networks that belong to that peer. That makes configuration review less about long certificate chains and more about matching addresses, keys, endpoint reachability, and route intent.

The useful handoff is the config text plus the review context that explains which peer owns each address and route.

Most small deployments fit one of two patterns. A hub-and-spoke VPN gives each laptop or phone a single tunnel address and sends selected private networks through the server. A site-style peer may also advertise a routed subnet behind a gateway. The same field, AllowedIPs, is involved in both patterns, so it should be read as both a routing choice and an identity boundary.

A generated config bundle is a draft for administrator review. It can organize server and client files, show route choices, and make obvious placeholder warnings visible, but it cannot prove that firewall rules, NAT, DNS, kernel support, or peer keys are correct on the real hosts.

Technical Details:

WireGuard configuration uses two top-level sections. The single [Interface] section defines the local tunnel device, address assignment, listening port, and private key. Each [Peer] section defines one remote identity with a public key and the IP prefixes that are valid for that peer.

The central mechanism is cryptokey routing. When packets leave the tunnel interface, the destination address is compared with peer AllowedIPs to choose the peer and encryption key. When packets arrive, the source address is checked against the sending peer's allowed list. That double role is why 10.80.0.10/32 for a laptop and 10.55.0.0/16 behind a branch gateway mean very different things.

wg-quick adds practical interface behavior around the base WireGuard fields. Address, DNS, MTU, and Table are convenience settings used during interface bring-up. Automatic table handling is usually the expected mode; Table = off is mainly for designs where another network manager or policy-routing rule installs the routes.

Config Field Map:

WireGuard configuration fields and their meaning
Field	Where it appears	Meaning	Review cue
`Address`	Interface	Assigns one or more IPv4 or IPv6 CIDR addresses to the tunnel interface.	Server and client addresses should not collide, and peer host addresses are commonly `/32` for IPv4 or `/128` for IPv6.
`ListenPort`	Server interface	Chooses the UDP port the interface listens on.	The firewall and endpoint port should match this value.
`PrivateKey` and `PublicKey`	Interface and peer	Bind local identity to the interface and remote identity to each peer.	Placeholders must be replaced with keys generated for the real server and peers.
`AllowedIPs`	Peer	Names the source prefixes accepted from that peer and the destination prefixes sent to that peer.	`0.0.0.0/0` and `::/0` create full-tunnel behavior on clients.
`Endpoint`	Client peer block	Gives the initial host and port used to reach the server before roaming updates occur.	IPv6 endpoints need bracket notation such as `[2001:db8::10]:51820`.
`DNS`	Client interface	Supplies resolver addresses or search domains for clients using `wg-quick`.	DNS should match the routing plan, especially for full-tunnel profiles.
`PersistentKeepalive`	Client peer block	Sends periodic authenticated empty packets to keep stateful NAT or firewall mappings open.	`25` seconds is a common client value; `0` omits the field.

Peer Row Translation:

Each peer row is read as a pipe-separated record: peer name, peer tunnel CIDR, server-side AllowedIPs, client-side AllowedIPs, DNS override, peer public key, peer private key, and optional preshared key. Blank route columns inherit defaults where the generator can do so safely. Blank key columns become visible placeholders rather than silent omissions.

WireGuard peer row translation and validation boundaries
Check	Boundary	Why it matters
Interface name	One to fifteen characters from letters, numbers, underscore, equals, plus, dot, and dash.	The name maps to the expected `wg-quick` interface file name.
CIDR values	IPv4 prefixes must be `0` to `32`; IPv6 prefixes must be `0` to `128`.	Missing prefixes make tunnel addresses and route ownership ambiguous.
Endpoint	Host and port are required; ports must be `1` to `65535`.	A client needs an initial server address before it can learn any roaming update.
Duplicate peers	Peer names are normalized for filenames, and duplicate normalized names are errors.	Two peers should not export to the same client config filename.
Duplicate addresses	The same peer tunnel CIDR repeated across rows is an error.	One tunnel address should identify one peer.
Server subnet fit	IPv4 peer addresses are compared with entered IPv4 server tunnel networks.	A peer outside the server network may be intentional routing, but it deserves review before handoff.

An optional preshared key adds another symmetric secret to the WireGuard key exchange. It is useful only when both sides receive the same value for that peer. Placeholder preshared keys can be included for planning, but they should be generated, distributed, and stored with the same care as other VPN secrets before the configuration is used.

Everyday Use & Decision Guide:

Start with wg0, one server tunnel address, the UDP listen port opened on the server firewall, and the public endpoint clients can reach. Add peers with one row per device. For a laptop profile, use a single tunnel address such as 10.80.0.10/32 and client AllowedIPs that match the networks the laptop should route through the VPN.

Use Hub sample when the goal is remote access for individual devices. Use Site sample when one peer represents a routed network behind a branch gateway. Those samples replace only the peer rows, so server keys, endpoint, keepalive, route table mode, and other settings stay under your control.

Keep Client AllowedIPs default narrow for split-tunnel access, such as private server networks. Use 0.0.0.0/0, ::/0 only when the client should send default traffic through the tunnel.
Set Client DNS when clients need internal names or when full-tunnel routing should use a trusted resolver reachable through the VPN.
Leave MTU blank unless the target path needs a known value. A custom MTU should match the real underlay and encapsulation path.
Keep Persistent keepalive at 25 for roaming clients behind NAT unless the deployment has a different interval policy.
Use Route table mode Auto for ordinary wg-quick clients. Choose Off or a custom table only when another routing layer is planned.
Turn on preshared key placeholders only when you intend to use a real per-peer preshared key during final handoff.

The most common wrong assumption is that a clean generated file is already secure. The output can still contain server, peer, or preshared key placeholders. It can also describe a full-tunnel client without the DNS, firewall, NAT, or policy rules needed to make that choice safe.

Before copying, read Config Review and Peer Ledger. The review explains errors, warnings, placeholder keys, private endpoint values, full-tunnel routing, and table-mode risks. The ledger is the quickest way to confirm each peer address, server-side route list, client-side route list, DNS value, and exported filename.

Step-by-Step Guide:

Enter Interface name, Server tunnel addresses, Listen port, and Public endpoint. The summary should show the interface, UDP port, and endpoint once the values validate.
Set the default client route list in Client AllowedIPs default. Use private CIDRs for split tunnel or default routes only when all client traffic should use WireGuard.
Add optional Client DNS values that match the routing plan. Internal resolvers are useful only if clients can reach them through the tunnel.
Write one Peer rows line per client or site peer. Use pipe separators when route lists contain commas.
Open Advanced and replace server key placeholders when real keys are ready. Add MTU, keepalive, table mode, custom table, and preshared-key placeholders only when they match the deployment plan.
Fix every red validation message before using the generated files. Invalid CIDR notation, bad endpoint syntax, duplicate peer names, and duplicate peer addresses are blocking issues.
Review Server Config and Client Configs. Confirm each client contains its own private key, the server public key, the intended endpoint, and the intended AllowedIPs.
Use the copy, download, CSV, DOCX, or JSON exports only after the review rows explain every remaining warning.

Interpreting Results:

WireGuard config bundle ready means the current fields produced server and client config text without blocking errors. It does not mean the VPN has been deployed, that keys are real, that the endpoint is reachable, or that operating-system routes and firewall rules already exist.

WireGuard config generator result cues and follow-up checks
Visible cue	Best reading	What to check next
`fix required`	At least one input error is active.	Read the red alert and the matching `Config Review` row before copying any config text.
`validated`	No errors or warnings are active in the current parsed state.	Still replace placeholders, install files on the correct hosts, and test the real tunnel.
`warnings`	The bundle was generated, but one or more choices deserve human review.	Look for placeholder keys, private endpoint addresses, full-tunnel routing, subnet mismatch, or unusual keepalive values.
`PSK placeholders`	PresharedKey lines will appear unless a peer row supplies real values.	Generate real preshared keys per peer or disable the placeholder option before handoff.
`Client files`	Valid peer rows produced named client config blocks.	Confirm normalized filenames do not hide naming mistakes and that each file goes to the right device.

The JSON view is a structured snapshot of the same settings, generated artifacts, peer ledger, and review rows. It is useful for tickets and audits, but the .conf text is what gets installed. If the ledger, JSON, and visible configs disagree with the planned topology, fix the inputs rather than editing exported text by hand.

Worked Examples:

Split-tunnel laptop and phone

A small remote-access setup can use server address 10.80.0.1/24, endpoint vpn.example.com:51820, and two peer rows such as laptop-01 | 10.80.0.10/32 | 10.80.0.10/32 | 10.80.0.0/24, 10.44.0.0/16 and phone-01 | 10.80.0.11/32 | 10.80.0.11/32 | 10.80.0.0/24. The server config should show two peer blocks, while each client config should route only the listed private networks.

Full-tunnel roaming client

A phone that should send all traffic through the VPN can use client AllowedIPs 0.0.0.0/0, ::/0. The review adds an informational routing note because default routes change more than private-network reachability. Confirm DNS, firewall forwarding, NAT, and any kill-switch policy before distributing that client file.

Branch gateway peer

A branch gateway can have peer address 10.80.0.20/32 and server-side AllowedIPs 10.80.0.20/32, 10.55.0.0/16. That tells the server that the gateway owns both its tunnel address and the branch subnet. The client-side route list should name the networks the branch gateway should send back through the server.

Endpoint and table warning

If the endpoint is entered as 192.168.1.10:51820, the review warns that the address is private or local. That may be fine in a lab, but off-network clients normally need a public DNS name or public address. If the same profile also uses default routes with Table = off, the review warns because wg-quick will not create those routes automatically.

FAQ:

Does this generate real WireGuard keys?

No. Blank key fields become visible placeholders. Generate real server and peer keys with trusted WireGuard tooling, then replace the placeholders before deployment.

Why do peer rows need both server and client AllowedIPs?

The server-side value describes what the server accepts from and routes to that peer. The client-side value describes what the client sends through its server peer. They are often different in split-tunnel and site-to-site designs.

When should I use a preshared key?

Use a preshared key only when your deployment process can create, protect, and install a matching per-peer value on both sides. Placeholder preshared keys are planning markers, not secrets.

Can one client route both IPv4 and IPv6?

Yes. The fields accept IPv4 and IPv6 CIDR values. Use ::/0 only when IPv6 default traffic should go through the tunnel, and confirm the server side can route and filter IPv6 correctly.

Does entered config data get sent somewhere for generation?

The values are parsed in the page to build the config text, ledger rows, review rows, and JSON. Copy and download actions use the visible generated output.

Glossary:

WireGuard: A VPN protocol and interface model that encrypts IP packets between peers identified by public keys.
Peer: A remote WireGuard identity with a public key and allowed tunnel addresses or routed prefixes.
AllowedIPs: The CIDR list used to choose outbound peer routing and check inbound source addresses for that peer.
Endpoint: The host and port used to reach a peer before WireGuard learns a newer authenticated source address.
PersistentKeepalive: An optional interval for sending empty authenticated packets so NAT or firewall state does not expire silently.
PresharedKey: An optional per-peer symmetric key mixed into the WireGuard key exchange in addition to public-key cryptography.

References:

WireGuard conceptual overview, WireGuard project.
WireGuard quick start, WireGuard project.
wg(8) manual page, Linux man-pages project.
wg-quick(8) manual page, Linux man-pages project.