RouterOS Firewall Rules Explained: Chains, Connection State, and the Default Rule Set Line by Line

RouterOS firewall rules explained in one sentence: a packet walks a fixed path through the router, lands in one of three chains depending on where it is going, and the first rule in that chain that matches decides its fate. Connection state, interface lists, RAW and FastTrack are detail layered on that model, and most broken MikroTik firewalls are broken because someone skipped the model and pasted rules from a forum thread. What follows is the model, the default rule set line by line, and the mistakes that lock you out.

Three chains, one packet path

The filter table has three built-in chains, and the Filter documentation defines them by destination: input is for packets entering the router and addressed to it, forward is for packets passing through it, and output is for packets the router itself generates.

The routing lookup decides which chain, and it happens late. The Packet Flow in RouterOS diagram gives the order: RAW prerouting, connection tracking, mangle prerouting, dst-nat, then the routing decision. Only then does the packet reach filter input (for the router) or filter forward (for something behind it); forwarded packets continue through mangle postrouting and src-nat before leaving. Two things follow. A port forward is a dst-nat rule, so the forward chain sees the packet already rewritten to the internal host, and a forward rule must match the private address, not the public one. And RAW runs before connection tracking, which is why the default bogon drops live there.

First match wins, and the fall-through is accept

The Firewall overview states the evaluation rule plainly: rules are taken “in the order they are listed, from top to bottom”, a match performs its action “and no more rules are processed in that chain”, and “if a packet has not matched any rule within the chain, then it is accepted.” That last clause is the one people forget. A chain with no rules is an open door. A chain whose final drop got disabled during troubleshooting is an open door. Deny-by-default is something you build with an explicit drop at the bottom, not something the box gives you.

Ordering also creates shadowing. A rule below action=drop chain=input in-interface-list=!LAN never sees a WAN packet, whatever it says. When a new WireGuard listener does not answer from outside, the usual cause is not the WireGuard config but an accept that landed under the drop. New rules append to the end; use place-before= when position matters.

Actions, per the Filter page: accept, drop (silent), reject (drop plus an ICMP message back), jump and return, add-src-to-address-list, fasttrack-connection, and two that never terminate: log and passthrough, which record and then “go to next rule”. A log rule that seems to be letting traffic through is doing exactly that; it was never a terminating action.

Connection state is the whole trick

A stateful firewall does not judge every packet on its merits. It judges the first packet of a connection and rides the tracking table for the rest. The Connection tracking page defines the values you match with connection-state=: new starts a connection (a TCP SYN, or the first UDP datagram with no table entry), established belongs to an existing entry, related is tied to one (ICMP errors, the FTP data channel), invalid belongs to nothing the tracker recognises, and untracked is traffic you deliberately excluded with a RAW action=notrack rule. The table grows on demand up to a ceiling of 1,048,576 entries, and an established TCP entry lives for one day by default.

Two settings bite. With enabled=auto, tracking stays off “until at least one firewall rule is added”, which surprises scripts that add NAT before any filter rule. And setting enabled=no to chase a throughput problem makes every connection-state= matcher silently stop matching, turning “accept established, drop the rest” into “drop the rest”.

The default rule set, line by line

MikroTik’s Building Advanced Firewall page publishes the defconf rules; /system default-configuration print shows what your own unit shipped with, per the Default configurations page. The filter portion, in apply order:

/ip firewall filter
add chain=input action=accept protocol=icmp comment="defconf: accept ICMP after RAW"
add chain=input action=accept connection-state=established,related,untracked
add chain=input action=drop in-interface-list=!LAN comment="defconf: drop all not coming from LAN"
add chain=forward action=fasttrack-connection connection-state=established,related
add chain=forward action=accept connection-state=established,related,untracked
add chain=forward action=drop connection-state=invalid
add chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN
add chain=forward action=drop src-address-list=no_forward_ipv4
add chain=forward action=drop dst-address-list=no_forward_ipv4

Read the input chain as a policy: the router answers ping, continues any conversation it already has, and refuses everything else unless it arrived on an interface in the LAN list. There is no separate accept for WinBox or SSH; the LAN exception covers them. Remote management means an accept above the drop with a src-address-list on it, not deleting the drop.

In the forward chain, connection-state=new connection-nat-state=!dstnat in-interface-list=WAN drops any new inbound connection from the internet that no dst-nat rule claimed, which is what makes port forwards the only way in. drop invalid sits below the established accept because most packets are established, and the cheapest rule set matches most packets on its first line.

FastTrack is the rule that confuses people. fasttrack-connection marks an established or related connection so its later packets skip the slow path. The Packet Flow page lists what they bypass: “firewall, connection tracking, simple queues, queue tree with parent=global, ip traffic-flow, IP accounting, IPSec, hotspot universal client, VRF assignment.” That is why it sits above the ordinary accept, and why a queue or mangle mark applied to fasttracked traffic does nothing. It “works only with the main routing table”, so policy-routed multi-WAN needs a matcher excluding those connections. Disable it when you need queues rather than deleting it; the high-CPU post covers what a small board does without it.

RAW, address lists and bogons

The defconf RAW chain drops traffic that has no business on a WAN port: anything to or from bad_ipv4 (127.0.0.0/8, 192.0.0.0/24, 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24, 240.0.0.0/4) and anything arriving on the WAN list from not_global_ipv4, which holds the three RFC 1918 private blocks plus 0.0.0.0/8, 100.64.0.0/10, 169.254.0.0/16, 192.0.0.0/29 and 198.18.0.0/15. Every entry comes from the RFC 6890 special-purpose registry. Because DHCP discover is sourced from 0.0.0.0 to 255.255.255.255, both on those lists, the chain accepts UDP 68 to 67 from LAN explicitly before the drops.

One caution: 100.64.0.0/10 is the shared address space carriers use for CGNAT. If your WAN address sits in that block, so does your upstream gateway, and a blanket drop of the range on WAN can eat ICMP errors from it. Check before pasting the list.

Lists are the right tool for your own exceptions too: add-src-to-address-list with a timeout turns a log rule into a temporary block list. Interface lists do the same for ports: match in-interface-list=WAN, never ether1, so a failover WAN on ether2 inherits the policy by joining the list.

Mistakes that lock you out

Every RouterOS firewall lockout is one of three things. The new rule went below the drop. A drop was added with no established accept above it, so your own WinBox session died on its next packet. Or an interface list was edited and the bridge fell out of LAN. Safe mode exists for exactly this: enter it, make the change, and a dropped session rolls it back. The securing a new RouterOS box post covers it, and the bridge VLAN filtering post covers the Layer 2 version of the same problem.

Weighing RouterOS against OPNsense or pfSense as a firewall? The model above is the argument for it: everything is visible and ordered, nothing hides behind a wizard. The homelab firewall comparison on firewallcompare.com shows where that trades against the UI, and the UniFi VLAN segmentation guide shows the same deny-by-default inter-VLAN policy when a controller writes the rules.

Related across the network

• Best Homelab Firewall in 2026: OPNsense, pfSense, UniFi, MikroTik — firewallcompare.com
• pfSense Alternatives: 7 Platforms Compared for 2026 — firewallcompare.com
• AI Firewall and Guardrail Solutions: The 2026 Landscape — bestaisecuritytools.com
• Best Firewall for Small Business 2026: 6 Options Compared — firewallcompare.com
• Best Mini PC for OPNsense 2026: A Buyer’s Guide by Tier — firewallcompare.com