mikrotik

The rule that comes before every other rule

You are administering the device you are connected through. A firewall rule, an interface change or an address change can drop your own session, and on a router in another building that means somebody drives there.

RouterOS has the answer built in and you should use it by default:

ssh_exec   /system scheduler add name=undo interval=5m on-event="/system reboot"

…or, better and simpler, the safe-mode idea: make the risky change, verify you still have the session, then remove the undo. On the console it is ctrl-X; over SSH the scheduler above is the equivalent — if you lose the session and cannot cancel it, the router reboots into the last saved config.

Always take a backup first, and take both kinds:

ssh_exec   /system backup save name=before-change
ssh_exec   /export file=before-change          (readable text, diffable)
ssh_download the .rsc so it lives off the device

The binary backup restores exactly; the .rsc export is the one you can read and diff, which is what tells you what you changed.

Reaching it

ssh_connect then ssh_exec, per the ssh-ops skill — the connection stays open so a session of twenty commands does not pay twenty handshakes. RouterOS accepts full commands non-interactively, which is exactly what ssh_exec wants:

ssh_exec   /interface print
ssh_exec   /ip address print
ssh_exec   /ip firewall filter print

Webfig over browser_goto is there when a person needs to see it, but the CLI is what you should drive: it returns text you can act on rather than a page you have to read.

Reading before changing

/export on its own prints the whole configuration as commands — that is the single best "what is this router doing" call, and it is one round trip. For narrower questions: /ip route print, /ip dhcp-server lease print, /system resource print (CPU, memory, RouterOS version), /log print for what it has been complaining about.

/tool torch interface=<if> is live traffic and never returns — a job, and abort it when done. Same for /tool sniffer.

Firewall and NAT, in the order that does not lock you out

Rules are evaluated in order, and add appends to the end. That is the trap: a drop rule added to the end of a chain whose earlier rule already accepts your traffic does nothing, and one added before it kills your session.

• place-before= puts a rule where you mean it.
• Add the accept for your own management access first, verify, then add the drop.
• /ip firewall filter print after every change, and read the order.
• disabled=yes on a new rule, then enable it once you have looked at it, is cheaper than being wrong.

For NAT, srcnat/masquerade on the out interface and dstnat for port-forwards; /ip firewall nat print shows both.

Upgrades

/system package update check-for-updates then download, and the install reboots — so it is a decision, not a step. Say what will be interrupted and let a person pick the moment. RouterOS v6→v7 is a major migration that changes syntax; do not treat it as a routine upgrade.

/system routerboard print shows whether the bootloader (current-firmware) also needs /system routerboard upgrade — people forget this half and then wonder why a feature is missing.

Credentials

A RouterOS password does not go in a tool argument. Use a key: /user ssh-keys import on the device with a public key you uploaded, and connect with the key from here. If the only way in is a password, that is an ask_human — see the rule in your system prompt.

A router reachable from the internet with admin and a weak password is a finding to report before you do anything else on it.