MikroTik WireGuard: RouterOS 7 setup + site-to-site mesh

Does MikroTik support WireGuard?

Yes, on RouterOS 7. WireGuard was added in RouterOS 7.0 (December 2021) as a first-class interface type alongside the existing IPsec, OpenVPN, L2TP, SSTP, and EoIP options. Every MikroTik board that can run RouterOS 7 supports it — that's effectively all hAP, RB, and CCR hardware from the last five years.

RouterOS 6 does not support WireGuard and will not be back-ported; this is by far the single most-requested feature that nudged operators off RouterOS 6 onto 7. If your MikroTik is still on RouterOS 6, the upgrade is the prerequisite to everything in this guide. The path is in System → Packages → Check For Updates with the upgrade channel set to stable.

WireGuard on RouterOS is the kernel-level implementation (not a userspace wrapper). The same protocol as on Linux, FreeBSD, and the official Windows/Mac/iOS/Android clients — fully interoperable.

Why RouterOS 7 is the prerequisite

This is the one point where MikroTik's situation differs from OpenWrt, OPNsense, or pfSense: RouterOS 7 is a substantial rewrite of RouterOS 6, not just a feature addition. Some configuration patterns migrated cleanly (firewall rules, interface assignments), some changed (the routing daemon was reworked), and a few RouterOS 6 features were dropped (older WiFi drivers, some legacy queuing tree behaviour).

For WireGuard specifically, the implication is simple: RouterOS 7 is required, full stop. If you're running RouterOS 6 and don't want to upgrade, your options are (a) leave WireGuard on a separate device — a small x86 mini-PC running OpenWrt is the common workaround, or (b) upgrade to RouterOS 7 and confirm any RouterOS 6-only features you depended on still work. The MikroTik docs maintain a RouterOS 7 migration guide covering the gotchas.

Setup with the RouterOS CLI

The CLI is faster than Winbox for WireGuard configuration because every field is on one line. The four commands below produce a working tunnel:

# 1. Create the WireGuard interface (generates a keypair)
/interface/wireguard
add name=wg0 listen-port=51820 private-key=auto

# 2. Print the public key (capture for the remote peer)
/interface/wireguard/print

# 3. Assign the tunnel address
/ip/address
add address=10.100.0.2/16 interface=wg0

# 4. Open the firewall (place above the default drop rule)
/ip/firewall/filter
add chain=input action=accept protocol=udp dst-port=51820 \
    comment="WireGuard handshake" place-before=0

# 5. Add the remote peer
/interface/wireguard/peers
add interface=wg0 \
    public-key="REMOTE_PUBLIC_KEY" \
    endpoint-address=peer.example.com \
    endpoint-port=51820 \
    allowed-address=10.100.0.0/16,192.168.20.0/24 \
    persistent-keepalive=21s

That's the entire configuration. private-key=auto generates a key on the router — no need to paste one. place-before=0 on the firewall rule is the small detail that catches most operators: without it, the rule ends up after the default drop all not from connection-state=established and the tunnel never handshakes.

For automation across many routers, MikroTik's .rsc script format is just the same CLI commands in a file — drop the snippet above into tunnel-setup.rsc and run /import file-name=tunnel-setup.rsc on each board.

Setup with Winbox / WebFig

For operators who prefer the GUI, the same setup in Winbox lives in four places:

1. Interfaces → + → WireGuard. Name the interface (wg0), set Listen Port (51820). Save. The public key field auto-populates after save.
2. Interfaces → wg0 → Peers tab → Add. Paste the remote public key. Set Endpoint (host) and Endpoint Port if the remote has a stable public address. Set Allowed Addresses (comma-separated CIDRs). Set Persistent Keepalive to 00:00:21 if behind NAT.
3. IP → Addresses → Add. Address: 10.100.0.2/16, Interface: wg0.
4. IP → Firewall → Filter Rules → Add. Chain: input, Action: accept, Protocol: udp, Dst. Port: 51820. Drag the new rule above the default drop rule.

The same configuration applies in WebFig (RouterOS's web admin); menu structure is identical to Winbox.

Site-to-site between two MikroTiks

For two-branch deployment, run the setup symmetrically. Conventional addressing:

For routing LAN traffic across the tunnel, the kernel will automatically install routes for the allowed-address CIDRs — no manual /ip/route needed. If the side behind NAT has a dynamic public IP, omit endpoint-address on the static-IP side's peer record; the dynamic side dials out and the static side accepts the connection.

The firewall input-chain rule everyone forgets

The most common reason a freshly-configured MikroTik WireGuard tunnel never handshakes: the firewall input chain blocks UDP 51820 by default. RouterOS ships with a sensible default ruleset that drops everything not from connection-state=established,related. The WireGuard handshake is the new connection, so it gets dropped.

The fix is one line:

/ip/firewall/filter
add chain=input action=accept protocol=udp dst-port=51820 \
    comment="WireGuard handshake" place-before=0

The place-before=0 matters: it inserts the rule at the top of the list, above the default drop. Without that flag, the rule lands at the bottom (after the drop) and has no effect. After running, /ip/firewall/filter/print should show the new rule as rule 0.

If you have other VPNs running, also confirm the input chain accepts the listen-ports for those (IPsec uses UDP 500 / 4500, OpenVPN typically TCP/UDP 1194). MikroTik's default ruleset assumes you've added these explicitly.

Throughput per MikroTik board

WireGuard throughput on MikroTik is bound by the CPU's symmetric-crypto performance — none of the hardware acceleration that helps IPsec on MikroTik applies to WireGuard. The realistic numbers:

For most Indian SMB branch deployments the local internet uplink (50–300 Mbps) is the binding constraint on anything from hAP ax² upwards. The exception worth noting: on the older hAP ac² and RB750Gr3, a 1 Gbps fibre uplink will saturate the WireGuard CPU before the link, so plan an RB5009 or better if your fibre is fast.

From two routers to ten branches

MikroTik WireGuard handles two-site tunnels cleanly. The shape changes when the operator needs more:

• Five sites in a full mesh = ten peer relationships. Each must be configured on both ends, so twenty entries to manage. Ten sites = forty-five relationships, ninety entries.
• Key rotation. WireGuard hygiene rotates keys periodically. With ten MikroTiks in a mesh, rotating one router's key means editing the peer entry on every other router — manually, by SSH or Winbox, on each board.
• Per-peer access policy. WireGuard's allowed-address covers route+encryption but not L4 access policy. Restricting "branch A can talk to branch B but not branch C" means firewall rules per board.
• Branches behind CGNAT. Two MikroTiks both behind CGNAT (common on cellular failover or rural fibre) can't directly handshake. They need an intermediary listener; MikroTik doesn't ship a relay layer, so you'd run one on a cloud VM with the operational cost that implies.
• Cross-router visibility. /interface/wireguard/peers/print stats shows one router's view. Ten branches means ten SSH sessions or ten Winbox tabs.

How MeshWG fits with MikroTik

MeshWG layers above the RouterOS-native WireGuard. Your MikroTik keeps using its kernel WireGuard module exactly as it does today; MeshWG provides the orchestration:

• Generated RouterOS scripts. For each MikroTik you add, MeshWG produces a paste-ready .rsc script with every peer pre-populated. New branch joins the mesh, MeshWG regenerates everyone's allowed-address so you don't visit each router.
• Central policy. Allow / deny rules between any two devices are configured once in the dashboard. The rules apply before traffic reaches the destination — no per-router firewall edits across ten boards.
• Relay layer for double-NAT. Two MikroTiks both behind CGNAT use a MeshWG relay automatically; no extra configuration.
• Single dashboard. Every router's last handshake, transferred bytes, and live state in one view. Replaces SSH-ing into each board.
• Honest billing. First two routers free forever. After that, ₹349/router/month annual or ₹499/router/month monthly in INR via Razorpay.

The MikroTik + MeshWG combination is what most ISP-class and MSP buyers actually want: keep the RouterOS expertise, keep the existing hardware investment, add a mesh layer on top that handles the parts that don't scale.

Frequently asked questions