/interface wireguard → secure tunnel planner

MikroTik WireGuard Config Generator

Build a reviewable RouterOS v7 tunnel for a VPS, site-to-site link, or remote technician. The generator explains every address and keeps any key you enter in this browser.

Written by Diaa · Last reviewed 21 September 2026 · RouterOS v7 focus

What this tool does: it generates the RouterOS interface, address, peer, and firewall commands plus a client profile. It does not connect to your router, upload keys, or prove that the tunnel works. Test the output on one reachable device first.

1. Tunnel inputs

Deployment mode

For a router behind CGNAT, choose client mode and keep the outbound peer alive.

WireGuard interface name

Letters, numbers, hyphen, or underscore.

UDP listen port

Open this only on the intended WAN interface.

Router tunnel address

The router's address inside the WireGuard tunnel.

Peer tunnel address

Use a unique address for each peer.

Peer endpoint

Leave empty for a roaming client that discovers the server.

Peer allowed addresses

Comma-separated routes that belong to this peer. Do not overlap peers on the same interface.

Persistent keepalive (seconds)

Useful when the peer is behind NAT.

Client DNS

Used only in the client profile.

Remote peer public key

Paste the remote public key. Never paste a private key into a support ticket.

Router private key optional

Blank output lets RouterOS generate the interface key. Retrieve the public key from the router and place it in the peer configuration.

Client private key optional

Blank output keeps a visible placeholder instead of inventing an unsafe key.

Router public key for client profile

After the interface exists, read its public key and replace this placeholder.

Add a narrow input rule allowing the WireGuard UDP port from the WAN.

wireguard-routeros.txt

Change an input to rebuild the commands.

How to use the generated configuration

WireGuard has one interface key pair and one public key per peer. The router can generate its own private key automatically when the interface is created. The peer still needs a key pair, and the peer's public key must be entered on the opposite side. A public key can be shared; a private key must remain on the device that owns it.

Address planning

Use a dedicated tunnel subnet such as 10.77.0.0/24. Give the RouterOS interface one address, then give each peer a distinct address or prefix. In allowed-address, place the peer's tunnel address and any private networks that should be routed through that peer. Two peers on one WireGuard interface must not claim the same allowed range.

When the router is behind CGNAT

A router behind provider CGNAT cannot receive an unsolicited inbound connection. Make it the initiating peer, set persistent-keepalive=25, and place the public endpoint on a VPS or another reachable router. The keepalive maintains the NAT mapping; it does not create a public IP or replace firewall policy.

Verification sequence

Import on a test router with local or out-of-band access.
Read the generated public key and put it into the opposite peer configuration.
Confirm the peer shows a recent handshake and increasing receive/transmit counters.
Ping the tunnel address, then test one routed private subnet.
Only after the route and firewall behavior are correct should you add more peers.

Do not skip this: the output intentionally leaves key placeholders when a key is not supplied. Replace them with keys generated on the actual devices; never use an example key in production.

References and related tools

The fields follow MikroTik's RouterOS WireGuard model for interface keys, peer public keys, allowed addresses, endpoints, and persistent keepalive. Read the official WireGuard documentation for release-specific behavior. For safe rollout, use the deployment checklist and for a CGNAT scenario read the backhaul guide.