MikroTik WireGuard generator
Set the tunnel network and your peers, and get the RouterOS v7 WireGuard configuration plus a config file for each laptop, phone or remote site.
Keys are generated in your browser and never leave your device
Needs RouterOS v7 (WireGuard is not available on v6). Keys are generated with your browser's Web Crypto X25519; if your browser lacks it, the router generates its own key and the configs get placeholders. IPv4 tunnel addresses only. MikroTik and RouterOS are trademarks of SIA Mikrotīkls. This tool is independent and not affiliated with or endorsed by MikroTik.
How to set up WireGuard on MikroTik
- Enter the interface name, listen port, the router's tunnel address (such as
10.66.0.1/24) and the public address clients will connect to. - Add a row per peer with its tunnel address; for site-to-site links, add the networks behind it. Choose full or split tunnel.
- Paste the RouterOS script, move the firewall rule above your drop rules, and import each peer's .conf file into its WireGuard app.
WireGuard on RouterOS v7
WireGuard arrived in RouterOS 7 and is configured in two places: /interface wireguard holds the router's key pair and listen port, and /interface wireguard peers holds one entry per remote device or site, identified by its public key. The tunnel interface then gets an IP address like any other interface, and firewall rules, routes and interface lists apply to it as usual. There is no user name or password: a peer is whoever holds the private key that matches a configured public key.
Each peer's allowed-address is the heart of the setup. It lists the source addresses the router accepts from that peer and, at the same time, the destinations it sends to that peer. On the device side, AllowedIPs does the same job in reverse: 0.0.0.0/0 sends everything through the tunnel, while a list of networks keeps the tunnel to those networks only.
Before you connect
- The router must accept UDP on the listen port in its input chain, above any drop rule. The firewall generator can open it for you with
udp/13231. - If the router is behind another NAT device, forward the UDP port to it, as the port forwarding generator shows.
- Peer configs contain private keys. Move them to the devices over a trusted channel and delete stray copies.
Questions
Are the keys safe if they are made in a web page?
They are made by your browser's built-in Web Crypto X25519 implementation, the same curve WireGuard uses, and they exist only in this page's memory and in the text it shows you. Nothing is sent anywhere: the page has no server component, and its security policy blocks connections to other sites. Close the tab and they are gone, so save the configs you need first.
What if my browser can't generate X25519 keys?
The page tells you and switches to keys made elsewhere: the RouterOS script leaves out the private key, so the router generates its own when the interface is created. Run /interface wireguard print to read its public key, paste it into the peer configs, and paste each peer's public key (from its WireGuard app) into the table here.
What is allowed-address on a MikroTik peer?
It works as both an access list and a routing table: the router accepts packets from the peer only with these source addresses, and sends traffic for these destinations to that peer. For a single device it is the device's /32. For a remote site, add the site's LAN, and the script also adds a route to it.
Full tunnel or split tunnel?
Full tunnel (AllowedIPs 0.0.0.0/0 on the peer) sends all of the device's traffic through the router, useful on untrusted Wi-Fi; the router must masquerade the tunnel addresses to the internet. Split tunnel sends only the tunnel network and the networks you list, so normal browsing stays local.
Why does the peer need PersistentKeepalive?
A phone or laptop behind NAT can only receive packets while its NAT mapping is alive. A keepalive every 25 seconds keeps it open, so the router can reach the peer and the tunnel comes back quickly after a pause.
What does the preshared key add?
An extra symmetric secret mixed into the handshake, which adds a layer of protection against future quantum attacks on the public-key exchange. It is optional, and it must match on both sides.