Work from link to application
Record the failing source, destination, protocol and time. A router-originated test uses a different firewall chain from a client’s forwarded traffic. Start with read-only checks and change one cause at a time.
| Question | Command | Look for |
|---|---|---|
| Is the link running? | /interface/print detail | Running flag, unexpected disabled port |
| Is addressing on the right interface? | /ip/address/print | Prefix and bridge/VLAN ownership |
| Is there an active route? | /ip/route/print detail | Active flag, next hop and default route |
| Did DHCP allocate a lease? | /ip/dhcp-server/lease/print detail | Bound client and correct subnet |
| What DNS is configured? | /ip/dns/print | Actual resolver path |
| Which rule matches? | /ip/firewall/filter/print stats | Counter changes for a controlled new session |
| Is NAT being selected? | /ip/firewall/nat/print stats | First-packet matching and rule order |
| Is state retained? | /ip/firewall/connection/print detail | Existing translation/state |
| What changed recently? | /log/print | Link, DHCP and authentication events |
A short path test
/ping 10.42.50.20 count=5
/tool/traceroute 10.42.50.20
:put [:resolve "kernaali.fi"]Here .20 is a sample LAN host, not an Internet probe. Use your failing destination when checking a routed path. An unanswered hop may suppress ICMP rather than drop forwarded traffic; do not diagnose a fault from one asterisk. Successful DNS on the router does not prove that clients can reach their configured resolver.
Observe live traffic carefully
/tool/torch interface=ether1
/ip/neighbor/print detailTorch shows interface traffic; stop with Ctrl+C. Hardware-offloaded traffic may not pass the CPU, and running diagnostic tools can alter FastPath behavior. Do not run an open-ended capture or bandwidth test on a busy production router. Neighbor discovery describes visible peers on permitted links, not an inventory of every routed device.
Choose the right Wi-Fi stack
/interface/wifi/registration-table/print detail/interface/wireless/registration-table/print detailMatch the installed package. Compare signal, rates and activity during a repeatable client test. For cellular devices use LTE monitor instead: Wi-Fi RSSI and LTE RSRP are not interchangeable measurements.
Check a fix with a fresh session
Repeat the exact failing test, observe counters, then test a case that should remain blocked. Record the result before adding more changes. A working ping is not proof of a working TCP service; test the actual service with an authorized client.
Read the firewall policy · Cellular diagnostics · Wi-Fi package distinctions
Kernaali Tools is not affiliated with MikroTik.
Technical references
- RouterOS first-time configuration
- RouterOS firewall filter
- RouterOS NAT
- RouterOS Wi-Fi 6 / 7 manual
- RouterOS legacy wireless interface
- RouterOS diagnostics
- RouterOS scripting
Found an issue? Send a correction with a reproducible example.