If you’re coming from consumer-grade routers, you might be used to «firewall» meaning just a checkbox labeled «Enable Security.» MikroTik is a whole different world.
In MikroTik, you build your firewall rules manually, from scratch. This gives you incredible power — and just as much responsibility.
Let’s break down what actually happens to a packet as it passes through the router.
🧱 The Three Chains: input, forward, output
MikroTik’s firewall is built on three main chains, each with a very specific job.
🔵 1. Input chain — protects the router itself
This chain handles packets destined for the router. For example:
- You’re logging in via Winbox or SSH
- You’re pinging the router
- You’re accessing WebFig or the DNS server on the router
🧠 Pro Tip: If you don’t protect the input chain, your MikroTik is exposed to the world.
🔷 2. Forward chain — controls traffic passing through the router
This is where you manage LAN ↔ WAN traffic, VPN clients, and even guest networks. If a packet goes through the router (from one interface to another), it hits the forward chain.
Examples:
- A computer on LAN opens a website
- A mobile device connects to VPN and accesses the internet
- A camera on VLAN 20 streams video to a remote server
🟠 3. Output chain — traffic from the router
This is not often used in most setups, but still important. It’s for traffic the router itself initiates:
- DNS queries (if using MikroTik as DNS client)
- NTP sync
- RouterOS package updates
We’ll mostly focus on input and forward, but it’s good to know this chain exists.
🧭 What Determines Which Chain Gets Hit?
Let’s say a packet arrives from the internet:
- If it’s meant for your public IP (e.g., someone scanning port 8291) → input
- If it’s meant for a device on your LAN → forward
- If it’s coming from the router itself → output
Every packet hits only one of these chains.
🔄 Connection States: new, established, related, invalid
This is one of the most important things to understand if you want to write smart firewall rules.
When MikroTik receives a packet, it checks its connection tracking table and assigns it a state:
| 🔖 State | 📋 Meaning |
|---|---|
| new | The first packet of a connection (like a TCP SYN or first UDP packet) |
| established | Part of an already approved connection (like reply packets) |
| related | Connection triggered by another one (e.g., FTP data channel, ICMP error) |
| invalid | Corrupted, expired, or unknown connection — usually garbage |
🔐 Best Practice:
Always allow established and related connections. Drop invalid. Then handle new traffic with real rules.
/ip firewall filter
add chain=input connection-state=established,related action=accept
add chain=input connection-state=invalid action=drop
You’ll repeat the same for forward chain too.
🧩 What Happens First? Firewall Rule Processing Order
MikroTik firewall goes down the list top to bottom, and stops at the first matching rule.
That means rule order matters. If your first rule says «accept everything,» nothing else will be checked. If a later rule says «drop all,» but the earlier one accepted the traffic — too late.
📌 Tip: Always put specific accept rules before broad drop rules.
Example order:
1. accept established, related
2. allow DNS from LAN
3. allow VPN traffic
4. drop invalid
5. drop everything from WAN
🧠 Thought Experiment: Which Chain?
Let’s play a quick round to see how well you understand the chains. Which chain handles these?
- You connect to MikroTik via Winbox from the internet →
input - Your laptop browses Google via NAT →
forward - MikroTik checks for a RouterOS update →
output - Remote VPN client accesses NAS on your LAN →
forward - You ping MikroTik from LAN →
input
🔎 Logging — Know What’s Hitting the Firewall
Logging helps understand what rules are matching (and what isn’t).
You can log a rule like this:
/ip firewall filter
add chain=input action=drop log=yes log-prefix="DROP-WAN: "
Log prefix helps quickly identify in logs. Use it sparingly — too much logging can crash your router under attack.
✅ Summary of Key Concepts
- MikroTik has 3 firewall chains — input, forward, output
- Every packet hits only one chain
- You should protect input to lock down the router
- Use connection states to simplify rule logic
- Rule order matters — first match wins
- Keep logs clean and informative