MikroTik Firewall Rule Builder
Build RouterOS firewall filter rules with the correct chain, connection-state handling and a safe default-drop baseline.
Result
/ip firewall filter
add chain=input action=accept protocol=tcp src-address=10.0.0.0/8 dst-port=8291,22 comment="management access"/ip firewall filter
add chain=input action=accept connection-state=established,related,untracked comment="accept established"
add chain=input action=drop connection-state=invalid comment="drop invalid"
add chain=input action=accept protocol=icmp limit=50/5s,10:packet comment="rate-limited ICMP"
add chain=input action=accept src-address=127.0.0.1 comment="loopback"
add chain=input action=accept protocol=tcp src-address=10.0.0.0/8 dst-port=8291,22 comment="management access"
add chain=input action=drop in-interface-list=WAN comment="drop everything else from WAN"
add chain=forward action=fasttrack-connection connection-state=established,related hw-offload=yes comment="fasttrack - bypasses queues"
add chain=forward action=accept connection-state=established,related,untracked comment="accept established"
add chain=forward action=drop connection-state=invalid comment="drop invalid"
add chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN comment="drop unsolicited inbound"/ip firewall filter print stats
/ip firewall connection print count-only
/system logging add topics=firewall action=memoryAbout MikroTik Firewall Rule Builder
RouterOS firewall rules are ordered lists in three chains: input for traffic to the router, forward for traffic through it, and output for traffic from it. Getting the chain wrong is the most common reason a rule appears to do nothing.
Interface lists instead of interface names
RouterOS v7 supports interface lists, and rules should reference in-interface-list=WAN rather than a specific port. Adding a second uplink, moving to a different physical interface or introducing a PPPoE client interface then requires editing one list rather than auditing every rule. Populate the list under /interface list member, and keep a matching LAN list so the forward chain reads in terms of trust zones rather than hardware.
Connection state does the heavy lifting
An established,related,untracked accept at the top of each chain resolves most packets immediately, so only genuinely new connections are evaluated against the rest of your rules. Dropping invalid next removes out-of-state noise. Everything after that only has to describe new connections, which makes the ruleset short enough to review.
Common use cases
- Restricting Winbox and SSH access to a management range.
- Applying a hardened baseline to a newly deployed router.
- Blocking a specific range during an incident.
Edge cases and gotchas
- Use safe mode when editing rules over a remote connection - it reverts automatically if the session drops.
- Winbox on 8291 must never be exposed to the internet.