The RouterOS firewall filter is the primary security control on every MikroTik router. For ISP deployments, the filter has to achieve three things simultaneously: protect the router's own management plane from unauthorised access, enforce subscriber access controls and anti-spoofing, and do both efficiently enough that packet processing overhead does not become a bottleneck at high throughput. Default RouterOS firewall rules are designed for general use, not ISP operation: building an ISP-appropriate ruleset from first principles is what this guide covers.
Chain Architecture
RouterOS firewall filter has three chains relevant to ISP operation. The input chain processes packets destined for the router itself, management access attempts, pings to the router's own IP, and routing protocol traffic. This is where you protect the management plane. The forward chain processes packets transiting the router from one interface to another, subscriber traffic, and is where you enforce subscriber-facing policy. The output chain processes packets originating from the router itself and is rarely modified for ISP deployments.
Rules are evaluated in order within each chain. The first matching rule wins. Place the most specific rules first and the most general last. The most common performance mistake is placing the connection state accept rule too far down the chain, causing established connections to be evaluated against many rules on every packet before reaching the accept.
Input Chain: Protecting the Management Plane
The correct structure for the input chain is: first accept established and related connections, then accept traffic from trusted management sources, then drop everything else that hits management protocols, then accept necessary operational traffic (BGP, OSPF, ICMP with rate limiting).
/ip firewall filter
# Accept established and related first - this must be early
add chain=input action=accept connection-state=established,related \
comment="Accept established/related"
# Drop invalid connections
add chain=input action=drop connection-state=invalid \
comment="Drop invalid"
# Accept management only from management subnet
add chain=input action=accept protocol=tcp dst-port=22,8291 \
src-address=<management-subnet> comment="SSH and Winbox from management"
add chain=input action=accept protocol=tcp dst-port=80,443 \
src-address=<management-subnet> comment="HTTP/HTTPS from management"
# Drop management protocols from everywhere else
add chain=input action=drop protocol=tcp dst-port=22,23,80,443,8291 \
comment="Drop management from non-management sources"
# Accept BGP from upstream peers
add chain=input action=accept protocol=tcp dst-port=179 \
src-address-list=bgp-peers comment="Accept BGP from peers"
# Accept ICMP with rate limiting
add chain=input action=accept protocol=icmp \
limit=50,20:packet comment="ICMP rate limited"
# Accept SNMP from NMS
add chain=input action=accept protocol=udp dst-port=161 \
src-address=<nms-server-ip> comment="SNMP from NMS"
# Drop everything else to input
add chain=input action=drop comment="Drop all other input"Forward Chain: Subscriber Traffic Control
The forward chain for an ISP router handles all transit traffic. The primary rules enforce connection state, anti-spoofing, and any protocol-specific blocking. Bandwidth limiting and QoS are handled in the queue and mangle layers, not in the forward chain filter.
# Accept established/related first for performance
add chain=forward action=accept connection-state=established,related \
comment="Accept established/related forward"
# Drop invalid
add chain=forward action=drop connection-state=invalid \
comment="Drop invalid forward"
# Anti-spoofing: drop subscriber traffic with non-subscriber source
add chain=forward action=drop in-interface=<subscriber-interface> \
src-address=!100.64.0.0/10 comment="Anti-spoofing subscriber"
# Drop RFC 1918 from subscriber to management
add chain=forward action=drop src-address=100.64.0.0/10 \
dst-address=<management-subnet> \
comment="Block subscriber to management network"
# Accept subscriber to internet (new connections)
add chain=forward action=accept connection-state=new \
src-address=100.64.0.0/10 comment="New subscriber connections"
# Drop everything else
add chain=forward action=drop comment="Drop all other forward"Logging Rules for Security Events
Add logging before drop rules for events that warrant NOC attention: management access attempts from unauthorised sources and anti-spoofing hits are the highest priority:
# Log before dropping unauthorised management attempts
add chain=input action=log protocol=tcp dst-port=22,8291 \
src-address=!<management-subnet> log-prefix="MGMT-ATTEMPT:" \
comment="Log unauthorised management attempts"
# Log anti-spoofing hits
add chain=forward action=log in-interface=<subscriber-interface> \
src-address=!100.64.0.0/10 log-prefix="ANTISPOOFING:" \
comment="Log anti-spoofing hits"These log entries, forwarded to your centralised syslog infrastructure, provide the security event data that CTDISR-2025 Section 9 and Section 6 (nTSOC) require. Management access attempts from non-management sources are exactly the kind of event that should reach your NOC and potentially your SIEM for correlation.
Connection Tracking Performance
Place the connection state accept rule as the first rule in every chain. Established and related connections make up the vast majority of traffic on a running network: getting them to an accept as quickly as possible reduces firewall processing load dramatically.
For high-throughput routers, enable FastTrack for established connections in the forward chain. FastTrack bypasses the full filter and mangle processing for marked connections, reducing CPU load at the cost of some visibility:
add chain=forward action=fasttrack-connection connection-state=established,related \
comment="FastTrack established/related - place before filter rules"Note that FastTrack bypasses mangle rules, so if you're using mangle for QoS marking, FastTrack connections will not be shaped. Use FastTrack selectively for traffic categories that don't need mangle processing.
For a comprehensive review of your MikroTik firewall configuration against CTDISR-2025 Section 9 hardening requirements, ISP Audit scores your network security posture across all 104 controls. For hands-on firewall review and ruleset design, our Cybersecurity for ISPs service covers MikroTik-specific configuration as part of the broader security engagement.