Technical guide
MikroTik multi-site: reach remote RouterOS without opening the network
A MikroTik multi-site rollout is not “several Winbox windows”. It is a management-path, visibility and recovery problem: how to reach each router behind NAT, know which site is down, and restore without being on-site. This guide covers the architecture before the product pitch.
What multi-site actually means on MikroTik
Multi-site is not “several routers”. Three hAPs in one building are still one site. Multi-site starts when each location has its own Internet egress, its own NAT, often a different ISP, and no shared LAN between devices.
The search intent is operational: how an integrator or MSP sees every RouterOS box at once, without drawing a mesh VPN between every pair of sites, and without publishing port 8291 on every public IP.
In the field the pattern that lasts is almost always the same: each site initiates an outbound session to a hub (cloud or CHR), regular keepalive, then management (API, SSH, backup) rides that tunnel. The inverse — the hub pushing to the customer WAN IP — breaks on CGNAT and consumer CPE.
Real constraints of a multi-site fleet
Failed multi-site adoptions rarely come from RouterOS itself. They come from the path to the router.
- Carrier CGNAT: no dedicated public IP, no Winbox DNAT
- ISP CPE that changes IP or drops inbound UDP
- Sites with no DNS on the router (hostname endpoints never resolve)
- Short outages treated as “customer down”
- No off-flash backup: a brick means the site is gone
NAT and handshake
WireGuard or IPsec only come up if at least one packet reaches the peer. Site-side persistent-keepalive fixes most NATs, provided the hub endpoint is an IP or a resolved hostname and UDP to the listen-port actually arrives.
DNS optional, IP mandatory
A lab or bare router often has no DNS servers. A FQDN endpoint then stays at empty current-endpoint and tx=0. For multi-site management the hub must accept a stable public IP as endpoint.
Recommended management architecture
Three families exist. They are not equal once site count leaves the single digits.
Site-to-site mesh
Every pair of sites has a tunnel. Count grows as n². Useful for business traffic (stretched VLANs), heavy for management only. Miss a keepalive and a site disappears.
Hub-and-spoke to a CHR / VPS
One concentrator terminates tunnels. Each site has a single peer. Clearest pattern for MikroTik multi-site management: one listen-port, one ACL, an allowed-address inventory.
Cloud controller + outbound tunnel
The site opens nothing. It builds the tunnel; the controller speaks API/SSH inside it. Backups and alerts live off-site. Same network principle without each integrator babysitting a homemade CHR.
Day-to-day ops: what one screen must show
Once tunnels are up the question is no longer “how do I reach it” but “which site drifted”. A multi-site operator must answer in seconds: how many routers are offline, since when, is it a maintenance window, is there a fresh backup.
Without that aggregate view you reopen Winbox site by site — the opposite of why you built multi-site. Short history (last-seen, handshake, CPU) is enough; a data lake is not the job.
- Online / pending / offline per site, not only per WAN IP
- Grace window on reboot to cut false alerts
- Timestamped cloud backup tied to router identity
- Time-boxed access session instead of port 8291 left open
Security: do not turn the hub into an attack surface
The multi-site concentrator sees every management plane. Treat it as a least-privilege zone: dedicated accounts, API limited to the tunnel prefix, no customer-WAN Winbox.
On the site, the tooling account does not need full design rights if the platform only reads resources, pushes a backup and opens a bounded session. Keep ops identity separate from local admin so an adoption script never becomes a forgotten super-user.
Classic multi-site MikroTik mistakes
The same failures show up project after project.
- Hostname endpoint on a router with no DNS
- No persistent-keepalive behind NAT
- Broken hub UDP forward: old tunnels stay up, new ones never handshake
- Excel inventory out of sync with WireGuard allowed-address
- Local-only backup: a bricked site has no config
Routiv for a multi-site MikroTik fleet
Routiv industrialises hub-and-spoke: each router opens an outbound tunnel, lands in one fleet, stores off-site backups and can be reached in a controlled session — without opening Winbox at the customer.
Pilot: one lab site, confirm handshake and first backup, then enrol a second remote site. The 30-day trial on routiv.net lets you validate the management path before you scale.
FAQ
How do I attach many MikroTik sites to one controller?+
One outbound tunnel per site (WireGuard in practice) to a hub. The controller talks to the tunnel IP, not the customer WAN IP.
Does every site need a public IP?+
No. The site initiates the tunnel. Only the hub needs a reachable endpoint (IP or DNS plus UDP forward).
WireGuard or IPsec for multi-site management?+
WireGuard is easier to industrialise (keys, keepalive, allowed-address). IPsec still fits existing business site-to-site traffic.
Why are new sites offline while old ones stay up?+
Often the hub UDP port no longer accepts new sessions, or the script endpoint (hostname) does not resolve on a bare router.
Can The Dude replace a multi-site controller?+
Not once sites are isolated behind NAT. The Dude assumes an IP path to every device.
What should I monitor first?+
Handshake / last-seen, then a successful off-site backup. CPU and WAN come next for diagnosis.
How do I avoid reboot false alerts?+
A few minutes of grace and a pending (never seen) vs offline (seen then lost) distinction.
Where should multi-site backups live?+
Off each router, centralised, tied to device identity, with occasional restore tests.
Related guides
30-day trial — no credit card
30-day free trial