MikroTik RouterOS Firewall Filter Commands

What It Does

The /ip/firewall/filter menu holds an ordered list of rules that RouterOS checks, top to bottom, against every packet passing through the router. Each rule matches on some condition (source, destination, protocol, port, interface, connection state, and more) and applies an action — most commonly accept, drop, or reject. The first matching rule wins; if nothing matches, RouterOS falls through to the chain’s default policy.

Basic Syntax

/ip/firewall/filter/print

/ip/firewall/filter/add chain=input protocol=tcp dst-port=22 action=accept comment="allow SSH"

This adds a rule to the input chain (traffic destined for the router itself) that accepts TCP port 22. New rules are appended to the end of the chain by default — use the place-before option to insert a rule at a specific position instead.

Understanding the Three Chains

• input — traffic destined for the router itself (management access, routing protocol packets, services running on the router). This is the chain that protects the router’s own control plane.
• forward — traffic passing through the router between networks (e.g. LAN clients reaching the internet). This is the chain most “firewall the network” rules belong in.
• output — traffic originating from the router itself going out (DNS queries the router makes, NTP, its own connections). Rarely restricted on a typical setup, but relevant for locking down what the router can initiate.

A very common misconfiguration is putting a rule meant to protect the network into the input chain (or vice versa) — the rule “works” in the sense that it matches nothing, and the admin assumes traffic is being filtered when it isn’t.

Practical Example: a Safe Base Ruleset

A reasonable starting input chain for a router with a public-facing WAN interface — allow established/related traffic, allow management from the LAN, drop everything else new from WAN:

/ip/firewall/filter/add chain=input connection-state=established,related action=accept comment="allow established/related"
/ip/firewall/filter/add chain=input connection-state=invalid action=drop comment="drop invalid"
/ip/firewall/filter/add chain=input in-interface=bridge action=accept comment="allow LAN management"
/ip/firewall/filter/add chain=input in-interface=ether1-wan action=drop comment="drop new from WAN"

Rule order matters here — the “allow established/related” and “drop invalid” rules need to come before the interface-specific rules so that reply traffic to connections you initiated isn’t accidentally dropped by the later WAN rule.

Troubleshooting

• A service is unreachable that should work — check rule order with /ip/firewall/filter/print; an earlier drop rule may be catching the traffic before your accept rule is reached.
• Locked out after a change — if you have physical or serial access, connect directly and review/remove the offending rule. If not, a scheduled task that reverts the firewall after a few minutes (added *before* making the risky change) is a common safety net professional engineers use.
• Rule seems to do nothing — double check the chain. A rule sitting in output when it should be in forward will never match the traffic you’re trying to control.

RouterOS v6/v7 Differences

The firewall filter’s core concepts (chains, match conditions, actions, rule order) are unchanged between v6 and v7. As with other menus, v7 accepts the slash-path form (/ip/firewall/filter/add) shown here, while v6 more commonly used space-separated navigation — both work regardless of version. IPv6 firewalling uses a separate, parallel /ipv6/firewall/filter menu in both versions; it is not merged with the IPv4 filter.