pjhtech Tools
MikroTik · RouterOS v7

MikroTik Firewall Commands: Counters and Connections

Quick answer #

Use rule counters to see which rules match, and connection tracking to inspect the state of a flow. Neither view alone proves that an application works. The useful question is whether one controlled connection reaches the expected rule and receives return traffic.

Scope: RouterOS v7 on RouterBOARD, CCR, CRS running RouterOS, or CHR where the relevant feature exists. Not SwOS. Output fields depend on release and hardware. IPv4 examples; IPv6 uses its own firewall menus and policy.

Commands #

These commands read the existing rules and state. On a busy router, narrow the connection-table query further in your own environment rather than repeatedly printing the entire table.

Commands
RouterOS v7 · RouterOS v7 terminal; absolute menu paths

Read-only
/ip/firewall/filter/print stats
Read-only
/ip/firewall/filter/print detail where chain=forward
Read-only
/ip/firewall/raw/print stats
Read-only
/ip/firewall/mangle/print stats
Read-only
/ip/firewall/nat/print stats
Read-only
/ip/firewall/connection/tracking/print
Read-only
/ip/firewall/connection/print detail where tcp-state="syn-sent"
Read-only
/ip/firewall/connection/print detail where dstnat
Read-only
/ipv6/firewall/filter/print stats

Read the result #

Firewall byte and packet counters are cumulative matching statistics. Compare two snapshots around a fresh test. A rule with millions of packets may be irrelevant to the current failure. Read its chain, action and match conditions alongside the counter increase; the label in a comment is not executable policy.

Connection tracking identifies original and reply directions, NAT status and protocol state. A TCP entry remaining in syn-sent is a reason to investigate the response path. It is not enough to identify a particular downstream firewall as the culprit. Replies might never be sent, might take another route, or might be lost before they return to this router.

Also inspect RAW rules: a packet dropped before connection tracking will not produce the normal tracked session you expect. FastTracked traffic complicates comparisons between interface totals and ordinary rule counters, because not every packet follows the same processing path.

Follow one application attempt #

Record the client address, destination, protocol, port and test time. Save the relevant counters, open a new connection from the client, and save them again. Find the associated connection entry and compare its original and reply information. Then inspect the first rule whose behaviour contradicts the intended policy.

If no expected counter moves, verify that you are looking at the correct address family and chain. Traffic to the router is a different case from traffic forwarded through it. If a rule matches but no reply returns, use a short capture at the appropriate interface to establish the next observation point.

Pitfalls #

Do not flush the connection table to make a diagnostic screenshot look clean. That interrupts unrelated sessions and destroys useful evidence. A NAT configuration change may also require a genuinely new application connection before the test represents the new policy; coordinate any targeted state removal separately.

Counters and session tuples can contain customer addresses and usage metadata. Keep the incident extract scoped to the affected flow when sharing it outside the operations team.

Sources

Documentation reviewed: 8 October 2026