RoMON and Out-of-Band Access: Reaching Routers You Just Broke

Everyone who manages routers for a living eventually types the command that disconnects them from the router they typed it on. A route change, a firewall rule with the interfaces backwards, an IP address moved to the wrong port — and the SSH session freezes mid-keystroke. If the box is in the next room, it’s an annoying walk. If it’s in a POP two hours away, it’s an afternoon.

Safe Mode is the first line of defense against this — press Ctrl-X, make the change, and RouterOS reverts automatically if the session dies. Use it, always. But Safe Mode only protects the change you’re currently making. It doesn’t help when a colleague renumbered the management VLAN yesterday, when DHCP on the uplink silently changed, or when the mistake was applied by an automation run that doesn’t know what Safe Mode is.

For all of those, MikroTik has something genuinely underused: RoMON. It’s a management overlay that ignores your IP configuration entirely — which means it survives exactly the class of mistakes that IP management doesn’t.

What RoMON Actually Is

RoMON — Router Management Overlay Network — builds an independent peer discovery and forwarding network at layer 2. RoMON frames use their own EtherType (0x88bf, sent to MAC 01:80:c2:00:88:bf), and each participating device gets a RoMON ID, by default derived from a port MAC address. Devices discover neighbors on RoMON-enabled ports and forward RoMON traffic for each other, hop by hop.

The two properties that make it valuable:

• It’s independent of L2 and L3 forwarding config. No IP addresses, no VLANs, no routes involved. A router with a completely destroyed IP config, an empty bridge, or a firewall dropping everything on input is still reachable over RoMON as long as a physical path of RoMON-enabled MikroTik devices exists.
• It’s multi-hop. Plain MAC-Telnet needs you on the same broadcast domain. RoMON forwards across the overlay, so one reachable device becomes your gateway to every RoMON peer in the chain — WinBox calls that device the agent.

The mental model: a control-plane mesh stitched across your MikroTik estate, alive even when the data plane is wrecked.

Enabling It — With Secrets

RoMON is off by default. Turning it on without authentication means anyone with L2 adjacency can discover and connect to your overlay, so the secret is not optional:

/tool romon set enabled=yes secrets=Str0ngRomonSecret
/tool romon print

secrets is a comma-separated list — every packet is authenticated (and its integrity protected) using the first secret, and packets from peers are accepted if they validate against any listed secret. That plural is your migration path: add the new secret alongside the old one everywhere, then remove the old one everywhere, and nothing ever agrees to disagree mid-rotation.

Note what the secret does and doesn’t do: RoMON authenticates its frames but does not encrypt the payload. Confidentiality comes from the application layer — SSH over RoMON, or WinBox’s own encrypted protocol. Fine for management traffic, but it’s another reason not to run RoMON toward networks you don’t trust.

Port policy is the other half of hygiene. By default RoMON runs on all ports; constrain it to infrastructure links:

# Forbid RoMON on customer/access-facing ports
/tool romon port add interface=ether10 forbid=yes

# Prefer the direct link over a long path (lower cost wins)
/tool romon port add interface=ether7 cost=200
/tool romon port print

Deploy RoMON like a protocol, not a toggle: same secret estate-wide, forbidden on untrusted edges, enabled everywhere else. Ansible makes this a five-line play across the fleet — the automation patterns from earlier in this series apply directly.

Using It

Discovery, reachability, and terminal access, in that order:

/tool romon discover
# lists peers: RoMON ID (a MAC), identity, version, hop cost, path

/tool romon ping id=6C:3B:6B:48:0E:8B count=5

/tool romon ssh 6C:3B:6B:48:0E:8B

The workflow that actually saves you, though, is WinBox via an agent. In WinBox, connect to any reachable RoMON-enabled device and connect in RoMON mode (the Managed/RoMON tab in current WinBox, or from a shell):

winbox.exe --romon 192.0.2.10 6C:3B:6B:48:0E:8B admin ""

WinBox logs into 192.0.2.10 as the agent, and the agent relays your session across the overlay to the target ID. You get the full GUI — not a degraded rescue console — on a box that has no working IP configuration at all.

The Day It Saves You

Concrete scenario. Three sites in a chain: core, aggregation, remote. You’re changing the routing on the remote router, skip Safe Mode because it’s “a one-liner,” and the one-liner replaces the route your session depends on. Without RoMON: truck roll, or talking someone’s hands through a serial cable by phone.

With RoMON: WinBox to the aggregation router as agent, discover, connect to the remote router’s RoMON ID, fix the route, done in ninety seconds. The remote box was never IP-reachable during any of it — and it didn’t matter, because the physical Ethernet path was intact and every hop spoke RoMON.

Verify your coverage before you need it:

/tool romon discover
# every infrastructure device should appear; if one is missing,
# find out today whether it's the secret, a forbidden port,
# or a non-MikroTik switch in the path eating the frames

That last one is the common gap: RoMON is MikroTik-proprietary, and the overlay is only as connected as the chain of MikroTik devices forwarding it. A third-party switch between two routers may or may not pass the frames — test it, don’t assume.

What RoMON Is Not

RoMON is not a console cable. Know the failure classes it doesn’t cover:

• The box must be running RouterOS. Boot loops, failed upgrades, corrupted storage — no RoMON.
• The physical path must exist. If the link itself is down, there’s nothing to overlay.
• Disabled interface, dead port, or a RoMON misconfig (wrong secret, forbidden port) takes the device off the overlay along with everything behind it.
• You can lock yourself out of RoMON too — /tool romon set enabled=no pushed by careless automation removes your safety net silently. Monitor RoMON peer counts like any other protocol.

For the failures RoMON can’t reach, you fall back to the real out-of-band layer.

Serial Console

Most rack-mount MikroTik gear (CCRs, most CRS switches, RB1100/RB5009-class boxes) has a serial port — RJ45 or USB — and it’s the only interface that works when networking doesn’t exist. Parameters live under:

/port print
/port set serial0 baud-rate=115200 data-bits=8 parity=none stop-bits=1

115200 8N1 is the default on current hardware. From a laptop: screen /dev/ttyUSB0 115200 or PuTTY, and you have a login prompt that survives any routing or firewall catastrophe — plus visibility into RouterBOOT during boot, which no network method gives you. If a site hosts gear you can’t afford to visit, a console server (or even a Raspberry Pi with a USB-serial adapter on the OOB LTE router) next to the rack is cheap insurance. I covered the same OOB philosophy from the hypervisor side in the Proxmox Guide — the principle is identical: the management path must not depend on the thing being managed.

Note the flip side: an exposed serial port is a local-attack surface. Physical rack security and a strong admin password matter here; the console does not care how good your firewall is.

Reset Button Recovery

Last resort before Netinstall: the hardware reset button, which acts on hold duration during power-on. The sequence on current RouterBOARD hardware:

• Hold the button before applying power and keep holding: after ~5 seconds the user LED starts flashing. Release while flashing → RouterOS configuration is reset to defaults on boot.
• Keep holding ~5 more seconds until the LED goes solid (on CAP-capable devices) → boots into CAPs mode, looking for a CAPsMAN controller.
• Keep holding ~5 more seconds until the LED turns off, then release → the board enters Netinstall mode, waiting for a Netinstall server on ether1.

Configuration reset wipes your config (protect secrets accordingly — an attacker with physical access and thirty seconds gets a default-credentials router; /system routerboard settings set protected-routerboot=enabled exists exactly for that threat model, at the cost of making recovery harder for you too). Netinstall is the full reimage path — it rewrites RouterOS from a PC on the same segment and rescues boxes that no longer boot. Practice it once on a bench router; like restoring from backup, it’s a skill you want rehearsed before it’s urgent.

Closing Thoughts

Layer your access like you layer your defenses. Safe Mode for the change you’re making right now. RoMON — with secrets, forbidden on untrusted ports, verified by periodic discovery — for reaching any box whose IP plane is broken but whose wires aren’t. Serial console for the boxes RoMON can’t see, and the reset button plus Netinstall for the ones nothing can see. The pattern across this whole series holds here too: the recovery path you haven’t tested doesn’t exist. Run /tool romon discover this week and see whether your safety net actually covers the fleet you think it does.