MikroTik Router Troubleshooting: How to Diagnose and Fix Common RouterOS Issues

The most common complaint is “nothing works,” and more often than not, that isn’t true. If the boss can’t open an email attachment titled “you’ve won a million” because the antivirus blocked it, chances are you won’t be configuring the router that day. That’s why one of the key skills for an admin is being able to talk to users and figure out exactly what isn’t working and how. Unfortunately, I can’t teach that in an article, so let’s jump straight to the technical part.

Resource Usage

The first thing any sysadmin checks is resource usage. Fortunately, WinBox shows these metrics right in the main window. If you don’t see them yet, add them now—it’ll save you time later. Go to Dashboard → Add. And by the way, the green square in the top-right corner isn’t CPU load. Just ignore it.

If the CPU is consistently over 80% utilization (the exact threshold varies by context, but 80% is a reasonable baseline), something’s off. First, open the built-in task manager via Tools → Profile. There you’ll see what’s driving the CPU load and can decide on next steps.

You’ll find the field explanations on the wiki. The most common ones you’ll see are DNS, Encrypting, and Firewall.

• Encrypting — your router is burning a lot of CPU on encryption. You probably have a bunch of VPN tunnels and no hardware crypto accelerator. Either switch to an appliance with a dedicated crypto chip, or use lighter-weight algorithms.
• Firewall — a pretty strong hint you didn’t read my previous articles 🙂 Your firewall is configured suboptimally.
• DNS — and this is where it gets interesting.

A standalone DNS server barely loads a router in small and medium-sized networks (up to a few thousand hosts). Using RouterOS as a DNS server in large networks, however, isn’t a great idea. So where does the load come from? Let’s dig in. If there’s load, something is generating it. Most likely, the DNS server is handling a high volume of queries. Let’s verify that. We’ll create a firewall rule.

Now check the logs. If our hunch is right, you’ll see lots of entries with a DNS prefix. You’ll be able to tell which source addresses and which interfaces the queries are hitting—most likely the WAN. We don’t want to process DNS queries coming in from the internet, so block UDP port 53 on the WAN interface, place the firewall rule in the right position, and enjoy the reduced load. Congratulations! We just discovered we were part of a botnet, closed that hole, and made the internet a little cleaner. Attacks like this often leverage UDP-based protocols.

Firewall

In general, knowing how to work with a firewall gives you tremendous power. A well-crafted rule shows how a packet moves through the system—which interface it enters, which one it exits—and whether a response packet comes back. Even the counters alone can tell you a lot about your network.

The Bytes and Packets columns show the number of bytes and packets processed by the rule. The Reset Counters buttons clear these counters. This lets you see whether traffic is hitting the intended rule or not.

The Firewall’s Connections tab is often very handy. It shows all flows passing through the router: their state, bytes transferred, and flow flags (hover over a value in the column to see a tooltip). For better clarity, add the Reply Dst. Address and Reply Src. Address columns. These fields show which destination and source addresses NAT translated to and from.

The firewall, with all its features, lets you inspect and debug all traffic passing through the router. To make sense of what you see across all those tabs, you should understand how packets traverse the router. The image shows a simplified version of the flow. A more detailed one is available in the documentation.

Other ways to analyze traffic

Being able to see a connection’s state, addresses, byte counters, and so on is great. But the firewall doesn’t provide a convenient, single place to verify that routing is correct. To find out which interface a packet is leaving through, just use the Torch tool.

You can think of Torch as a tcpdump-like tool. It shows VLAN IDs, source/destination addresses and ports, DSCP, and both bit rate and packet rate. It has convenient filters for precise queries. If the view changes too quickly, increase the Entry Timeout value. The catch is that each window can display traffic for only one interface—but you can hit New Window to watch multiple interfaces simultaneously. If Torch isn’t showing the expected traffic on the expected interface, you’re likely dealing with a routing issue.

Torch provides real-time visibility into traffic flows. However, sometimes you need more granular traffic data. The IP Sniffer tool lets you capture it.

It lets you see traffic metadata and even inspect packet payloads.

But sometimes you need a deeper look—for example, to verify that the TCP handshake completed successfully and data is actually flowing. In that case, you should see the ACK flag in the packets. However, hunting for packets in Winbox’s minimal interface is inconvenient.

This is where everyone’s favorite Wireshark comes to the rescue—a powerful tool for analyzing network traffic. In the Filter field, set the parameters you need so you’re not capturing everything indiscriminately; in General, choose Filename, then click Apply and Start. You can then find the resulting capture file under Files on the router, copy it to your computer, and open it in Wireshark. There are plenty of articles about it, so I won’t even try to explain how to use it here.

But that’s just the beginning. You can watch the traffic live in Wireshark—no file operations needed. Open Wireshark, set the filter to udp.port == 37008. In the RouterOS packet sniffer, go to the Streaming tab, check Streaming Enabled, and enter the IP address of the machine running Wireshark. You can also enable Filter Stream to feed only the selected traffic into Wireshark instead of everything.

You can mirror traffic to a sniffer right from the firewall. The Mangle table has the sniff TZSP action for that. It works similarly to Sniffer Streaming, but using the firewall lets you select packets for the sniffer much more precisely.

Wireless

The hardest part of troubleshooting is Wi‑Fi. It’s a complex technology to begin with, and the medium is shared: all the neighbors’ routers interfere with yours—and vice versa. Entire books have been written about 802.11; I’m not going to summarize them here. Let’s just look at the tools that can help with troubleshooting.

There aren’t many of them in RouterOS. The most important one is the Registration tab under Wireless. It shows all information about connected clients: MAC address, signal level, and signal quality.

Key fields:

• CCQ — Client Connection Quality. The closer to 100%, the better. Below 60% indicates a poor link.
• TX/RX Signal Strength — signal level. Excellent: 0 to −45 dBm; acceptable: −55 to −75 dBm. Anything in between is good. Below −75 dBm can be treated as no link. That’s the rule of thumb I use.
• Signal to Noise — signal-to-noise ratio (SNR). The higher, the better.

The second tool is logs. In fact, you should be using them actively not just for Wi‑Fi troubleshooting. If the standard logs aren’t enough, just enable extended logging.

Ping, Traceroute

Ping has always been a sysadmin’s go-to tool for troubleshooting. But few people realize just how many capabilities it packs.

Many have seen this: the text on a site loads, but images don’t. Or scripts fail to load and the layout breaks. These are early signs of an MTU mismatch. You can check this with ping. Enable the “Don’t Fragment” flag, set the desired packet size, and look at the result. If you see packet too large, the MTU on the path is lower than the size you set. Reduce it and test again. This way you find the largest packet that traverses the network without fragmentation.

By default, the router sends a packet with the Src. Address of the egress interface. Sometimes you need to change it—for example, when troubleshooting routing inside a VPN or verifying that the firewall is working correctly. To do this, set the Src. Address field. Remember, the address must be one that actually exists on the router so the reply can make it back.

For complex routing, you need to select the appropriate Routing Table. That said, anyone who works with multiple routing tables already knows this.

You can’t cover every possible issue and how to diagnose and fix it in a single article—or even a few books. Effective debugging requires understanding how the network works at every layer and the quirks of its specific implementation—no two networks are identical, and playbooks that work in one environment may be useless in another.

For effective debugging, you need to understand how a packet flows through RouterOS, and in especially complex cases, you also need to know the vendor’s quirks. This applies not only to MikroTik. The best debugging tool is knowledge and experience!