WireGuard config generator
Create WireGuard keys and configuration files for a server and its clients. Keys are generated in this tab, in your browser; nothing is sent to a server. Hub-and-spoke and site-to-site templates cover access to field SCADA/PLC networks.
Keys are generated in the browser; nothing is sent to a server or stored.
Addresses inside the tunnel are assigned from here automatically; the server takes the first address. Choose a private block that does not clash with your existing networks.
Domain name or IP, optional :port. Without a port, 51820 is used.
A separate key and .conf is generated for each client. The name is also used for the file name.
With a split tunnel, the networks the client routes through the tunnel (CIDRs, spaces/commas). Not used with a full tunnel.
Written to the clients; separate addresses with commas.
You may leave it empty. If you see fragmentation problems, try 1380–1420.
25 is common for peers behind NAT or a firewall; empty or 0 = off.
Adds an extra symmetric-key layer for each pair of peers.
The egress interface for NAT (e.g. eth0, ens3). Letters, digits, dot, hyphen and underscore.
Common for remote access so clients can reach the server's network; usually not needed for site-to-site and hub-and-spoke, where routing is enough.
These are examples: adapt them to your distribution, existing firewall policy and interface names. The nftables example covers NAT only.
Configuration files
Generating keys…
This tool produces a starting configuration; it does not replace a security review. Verify firewall rules, key distribution and access rights for your own environment. In production you may prefer to generate keys with a trusted tool (wg genkey) in your production environment.
Would you like to design remote access or site connections (including SCADA/PLC) securely and traceably?
Request a meeting01
How to use
A
Choose the topology: remote access, site-to-site or hub and spoke. Enter the tunnel network, the public endpoint and the names of the peers (and the sites' LANs).
B
Choose full or split tunnel; set DNS, MTU, keepalive, PSK and the iptables/nftables examples for the server if needed.
C
Copy or download the generated .conf for each peer and pass it to the device over a secure channel; save it before leaving the page.
02
How a WireGuard configuration works
In WireGuard each peer is identified by a key pair: the private key stays on the device and the public key is given to the other side. Authentication uses these keys, not user names or passwords. The public key is derived from the private key with Curve25519; the tool does this in your browser by clamping 32 random bytes, multiplying with the base point and writing the result as base64.
The AllowedIPs line of each [Peer] section does two jobs: it is the routing table for outgoing packets and a source-address filter for incoming ones (cryptokey routing). It decides which networks belong to a peer. Endpoint is the other side's address; PersistentKeepalive sends periodic packets so that a peer behind NAT keeps the connection open. WireGuard uses UDP; 51820 is only a common default.
03
Topologies and AllowedIPs
In remote access all clients connect to one server, which gives each client a /32 address from the tunnel network. With a full tunnel the client gets 0.0.0.0/0 and ::/0 as AllowedIPs and sends all its traffic through the server; with a split tunnel only the tunnel network and the networks you list enter the tunnel. If the server does not forward IPv6, the ::/0 entry drops IPv6 traffic inside the tunnel, which prevents leaks.
In site-to-site two gateways are joined and each adds the other side's LANs to AllowedIPs; devices on both LANs must route to the gateway, and the LAN blocks must not overlap (the tool checks this). In hub and spoke, field sites connect to a central hub, which keeps each site's LAN in its AllowedIPs. By default sites only see the networks on the hub side; letting them see each other's LANs must be enabled separately. The PostUp/PostDown lines for routing and NAT are examples; adapt the interface name and firewall policy to your environment.
04
Security and remote access to OT networks
A generated private key is the only proof of access for a device: pass the file over a secure channel rather than chat or email, and if it is compromised, close access by removing that peer's public key from the server. WireGuard has no user authentication or second factor; a device whose key is stolen reaches everywhere the key allows. Disk encryption and fewer keys therefore matter against device loss.
General principles for remote access to an OT/SCADA network are: least privilege (each peer gets only the networks, ideally only the addresses and ports, it needs), landing the tunnel in a separate zone (DMZ) rather than directly on the field network, reaching the network from there through a jump host with multi-factor authentication, recording sessions and limiting access in time. This tool only generates tunnel configuration; zone design, firewall rules and logging must be planned separately.
FAQ
- Are my keys sent anywhere?
- No. Keys are generated in your browser from bytes of the secure random number generator and are not sent to or stored on any server. They are lost when you leave or reload the page, so save the files first.
- Are these keys the same as ones from wg genkey?
- The format is the same: 32 bytes, base64. The private key is clamped and the public key derived with Curve25519, so wg pubkey gives the same public key from the same private key. In critical environments you can generate keys on your own system with wg genkey.
- Should I choose a full or split tunnel?
- To reach specific resources on a network, a split tunnel is enough and does not send unnecessary traffic through the server. Choose full tunnel if all traffic must be inspected or the egress address must be fixed; the server must then route and NAT.
- When is PersistentKeepalive needed?
- When a peer behind NAT or a stateful firewall initiates the connection and the other side must also be able to send packets to it. 25 seconds is a common value. It is usually not needed on a peer with a public address.
- Why is there no QR code?
- Because the configuration contains a private key, this tool uses no external component or extra code. You can pass the file to mobile devices over a secure channel or import it from a file in the WireGuard app.
Set up remote access securely and traceably
We support VPN design, segmentation and access models for your server, network and OT/SCADA infrastructure. In a free discovery call we discuss your current need.