{{ summaryHeading }}
{{ summaryValue }}

{{ summaryLine }}

Interface{{ resultsReady ? values.interface_name : '—' }} Client files{{ resultsReady ? values.client_count : '—' }} Review{{ resultsReady ? reviewBadgeValue : '—' }}
Topology preview unavailable
Becomes /etc/wireguard/<name>.conf with wg-quick.
Separate dual-stack addresses with commas or new lines.
Open the same UDP port on the server firewall.
UDP
Use vpn.example.com:51820 or [2001:db8::10]:51820.
Use private prefixes for split tunnel; use 0.0.0.0/0, ::/0 only for an intentional full tunnel.
Optional comma-separated values inherited by peers without an override.
Replace the placeholder only through a controlled secret-handling path.
The placeholder stays visible until you supply the public key.
Up to 12 peers; blank route/key columns inherit defaults or visible placeholders.
Samples replace peer rows only and keep key placeholders explicit.
Blank is neutral and omits MTU.
bytes
0 is neutral; 25 is the common NAT-friendly interval.
s
Automatic is neutral and leaves normal wg-quick routing enabled.
Verify the table ID in the host routing policy.
Off is neutral. Real preshared keys remain sensitive.
{{ include_preshared_key ? 'On' : 'Off' }}
{{ values.server_config }}
{{ values.peer_blocks }}
{{ values.client_bundle }}
PeerClient addressServer AllowedIPsClient AllowedIPsDNSClient fileCopy
{{ row.peer }}{{ row.address }}{{ row.serverAllowedIps }}{{ row.clientAllowedIps }}{{ row.dns }}{{ row.clientFile }}
LevelCheckFindingActionCopy
{{ row.level }}{{ row.check }}{{ row.detail }}{{ row.recommendation }}
OpenVPN Client Config Generator Generate an OpenVPN client profile with matched routing, TLS, cipher, and credential choices plus import and security review warnings.
RADIUS Client Config Generator Build FreeRADIUS client stanzas from NAS rows with device-specific secret checks, address-scope warnings, and hardened security settings.
Cisco ACL Generator Generate Cisco ACL commands from IPv4 flow rows for IOS, NX-OS, and ASA with platform-aware address conversion and safety checks before use.
Firewall Rule Matrix Generator Build a reviewable firewall rule matrix from flow rows with least-privilege findings, deterministic risk cues, and platform handoff guidance.

A WireGuard tunnel is built from peers rather than from separate server and client protocols. Each peer owns a private key, shares its public key, and lists the IP prefixes that the remote public key may represent. One machine may listen on a stable UDP port and serve as the hub, but every connection still joins two authenticated peers.

Three address concepts need to stay separate. An interface address belongs inside the tunnel. An endpoint is the public host and UDP port used to reach a peer. AllowedIPs assigns route ownership to a public key and also guides outbound routing. A tunnel can establish a handshake while application traffic still fails because one of those address roles or the return route is wrong.

Plan Typical peer prefixes Operational consequence
Single device A host route such as 10.80.0.10/32 or an IPv6 /128 The peer represents one tunnel address.
Site-to-site A tunnel address plus one or more LAN prefixes The peer acts as a gateway, so both sides need matching forward and return routes.
Split tunnel Only selected private or service networks Unlisted destinations continue to use the ordinary network path.
Full tunnel 0.0.0.0/0 and, when intended, ::/0 Default traffic moves into the tunnel, so DNS, forwarding, firewall, NAT, and recovery access must be planned together.

Keys establish identity, not reachability. The listening peer still needs an accessible endpoint and matching firewall rule, and routed networks still need forwarding policy outside WireGuard. A persistent keepalive can preserve a NAT or stateful-firewall mapping for an otherwise idle peer; 25 seconds is a common interval, while zero leaves it disabled.

wg-quick adds interface addresses and derives routes from peer AllowedIPs. Automatic table handling is convenient for ordinary layouts. Setting Table = off suppresses route creation, and a numeric table sends routes to that table instead. A full-tunnel prefix combined with disabled automatic routing therefore needs another network manager or explicit policy to install the route.

Generated configuration is a starting point for review, not proof that a VPN is secure or reachable. Real acceptance needs controlled key generation, restrictive file permissions, firewall and forwarding checks, a recent handshake, correct routes in both directions, and an application-level test through the tunnel.

How to Use This Tool:

Plan the tunnel addresses and route ownership first. Keep placeholders in place until the route design is reviewed.

  1. Enter an interface name, one or more server tunnel CIDRs, the UDP listen port, and the public endpoint clients can reach. Bracket an IPv6 endpoint, as in [2001:db8::10]:51820.
  2. Set the default client AllowedIPs. Use only the intended private prefixes for a split tunnel, or add IPv4 and IPv6 default routes only when all traffic should traverse the server.
  3. Add one pipe-delimited peer per line. Supply the peer name and tunnel CIDR first; optional columns can override server-side routes, client-side routes, DNS, public key, private key, and preshared key. The limit is 12 peers.
  4. Open Advanced only when the deployment needs a fixed MTU, persistent keepalive, non-default route-table handling, or preshared-key placeholders. Leave MTU blank for automatic discovery and keepalive at zero unless idle NAT traversal needs it.
  5. Read Config review before copying anything. Replace every placeholder through a controlled key-handling path, resolve subnet and route warnings, then test the configuration on a recoverable host.

Interpreting Results:

A generated server or client block is syntactically useful only after its placeholders and routes have been reviewed. A Pass row confirms that peer rows were parsed into artifacts; it does not confirm a handshake, firewall path, forwarding, DNS resolution, NAT, or access to the target service.

  • Treat any placeholder-key warning as a stop condition. A configuration containing placeholders cannot authenticate a real tunnel.
  • A default-route note means the client may send ordinary internet traffic through the VPN. Confirm DNS and an out-of-band recovery path before applying it remotely.
  • A peer address outside the entered server IPv4 networks may be intentional, but it needs an explicit route design. Verify it rather than clearing the warning reflexively.
  • After installation, check wg show, operating-system routes, recent handshake time, transfer counters, and traffic to a real destination inside AllowedIPs.

Technical Details:

A wg-quick configuration has one [Interface] section for local state and one [Peer] section for each remote identity. The meaning of a field depends on which side reads the file. For example, the server assigns a peer’s public key to the prefixes that peer may originate, while the client assigns the server’s public key to the destination prefixes that should use the tunnel.

Rule Core

Input meaning Server configuration Client configuration
Local tunnel address Server tunnel CIDR becomes Address. Peer tunnel CIDR becomes Address.
Local private key Server private key becomes PrivateKey. Peer private key becomes PrivateKey.
Remote public key Each peer public key starts its [Peer] block. The server public key starts the client’s [Peer] block.
Route ownership The peer’s server-side prefixes become AllowedIPs. The peer override or client default becomes AllowedIPs.
First contact ListenPort is emitted for the server. The public host and port become Endpoint.
Optional policy A fixed MTU and non-automatic table value are emitted on both interfaces. DNS and positive keepalive values are client-side settings.

Peer rows use the order name | peer CIDR | server AllowedIPs | client AllowedIPs | DNS | public key | private key | preshared key. A blank server-route cell inherits the peer CIDR. A blank client-route cell inherits the global client default. Blank DNS inherits the global DNS value, while blank key cells remain visible placeholders.

Validation and review rules

Value Accepted boundary or review behavior
Interface name 1 to 15 characters from letters, digits, underscore, equals, plus, dot, and dash.
CIDR prefixes IPv4 uses 0 to 32; IPv6 uses 0 to 128. A prefix is required.
Endpoint and listen port The endpoint must contain a valid host and port; both endpoint and listen ports use 1 to 65,535.
MTU Blank omits the field. An explicit value must be from 576 to 9,000 bytes.
Persistent keepalive 0 disables it. Positive whole seconds up to 65,535 are accepted; values other than 25 receive an informational note.
Peer uniqueness Normalized peer names and exact peer CIDR strings must not repeat.
Route breadth /32 and /128 count as host routes, prefix zero counts as a default route, and every other valid prefix counts as a network route.

The review detects private IPv4 endpoints, exact duplicate addresses, placeholder keys, IPv4 peer addresses outside the entered server networks, default client routes, and the combination of Table = off with a default route. It does not calculate IPv6 subnet containment, detect every overlapping prefix, validate real key material, contact the endpoint, or inspect the host firewall.

Privacy and Security Notes:

Configuration generation runs in the browser, but these settings are synchronized into the page URL. Real private keys or preshared keys could therefore appear in browser history, copied links, logs, screenshots, or monitoring systems.

  • Plan with placeholders. Generate private keys under restrictive permissions and insert them only in a controlled local workflow.
  • Never send a private key to another peer. Share only the corresponding public key.
  • Store finished configuration files as secrets and restrict access before bringing an interface up.
  • Apply route or firewall changes from a console or another recovery path when a mistake could cut off remote access.

Worked Examples:

Remote laptop with split routing

Give the laptop a host address such as 10.80.0.10/32. Keep the server-side route at that host prefix, then set the client side to only the tunnel and office networks it should reach. The route profile should show host and network routes but no default route.

Phone using a full tunnel

Use 0.0.0.0/0, ::/0 on the client side only when both address families should use the VPN. A default-route note is expected. Before distribution, confirm server forwarding, firewall and NAT policy, tunnel DNS, IPv6 support, and a recovery path if the new route breaks connectivity.

References: