Lab 06-01 · The input chain: a bouncer for your router¶
MTCNA
Module 6 · Firewall of the MikroTik MTCNA course, official slides p234–247 (what a firewall is, chains, actions, and the LAB "Cadena: input").
Last weekend you probably queued outside somewhere: a concert, a club, a stadium. At the door stood a bouncer with a list. Some people walked straight in, some were sent home, and the bouncer never had to think twice: he just followed his instructions, from the top, until one matched.
Your router needs exactly that person. Right now anybody plugged into your network can open the router's login page, try passwords on it, or ask it anything. In this lab you hire the bouncer, tell him that only your laptop may talk to the router, and then pretend to be a stranger to see the door close in your face.
What you will learn
- Explain what a firewall is and why it reads its rules from top to bottom, first match wins.
- Tell apart the three built-in chains:
input,forwardandoutput. - Choose between the actions accept, drop and reject.
- Write
inputrules on RouterOS that let only one address manage the router. - Lock yourself out on purpose, understand why the web stopped working (the DNS trap), and fix it.
- Prove that a rule works by watching its counters climb.
What is a firewall?¶
A firewall is a set of rules that decides, packet by packet, which network traffic may pass and which may not.
Every message on a network travels in small pieces called packets (you met them in the IP labs). Each packet carries labels: where it comes from (source address), where it goes (destination address), which kind of service it wants (protocol and port). The firewall is the bouncer who reads those labels.
A RouterOS firewall rule works on the principle if... then...:
- If the packet matches these conditions (comes in through this interface, from this address, to this port...)
- then do this action (let it in, throw it away...).
The bouncer reads his instructions in order, from the top. The first instruction that matches the packet decides its fate, and he stops reading. A packet that matches no rule at all is accepted: the RouterOS firewall is open by default, so an empty list means "everybody in".
Order is everything
"Let my laptop in" followed by "throw everybody out" protects the router. The same two rules in the opposite order lock you out too, because the bouncer reaches "throw everybody out" first. Most firewall bugs are rules in the wrong order.
Three doors: the chains¶
Rules are grouped into chains. Imagine the router as a club building with a small staff office inside:
| Chain | Who it checks | In the club |
|---|---|---|
| input | packets addressed to the router itself (WebFig, WinBox, ping to 192.168.88.1, DNS questions) | people trying to get into the staff office |
| forward | packets that pass through the router (your laptop talking to a web server on the Internet) | people walking through the building from one street to the other |
| output | packets created by the router (the router asking a DNS server, sending a ping) | staff leaving the office |
flowchart LR
LAN["<b>LAN</b><br>your laptop"] -- "forward<br>(through the club)" --> NET["<b>Internet</b>"]
LAN -- "input<br>(into the office)" --> R["<b>the router itself</b><br>WebFig, WinBox, DNS"]
R -- "output<br>(staff going out)" --> NETThis lab only touches input: it protects the router itself. The next lab is about forward.
You can create your own chains
Besides the three built-in chains you can invent new ones (for example ssh-checks) and send packets
there with the action jump; return sends them back. Large firewalls use this to stay readable.
You will not need it in the MTCNA labs.
What the bouncer can do: actions¶
Every rule has an action: what to do when a packet matches.
| Action | What happens | At the club door |
|---|---|---|
| accept | the packet is let in; no more rules are read | "Come in." |
| drop | the packet is silently thrown away; the sender gets no answer | the bouncer looks straight through you and says nothing |
| reject | the packet is thrown away and an ICMP error is sent back ("go away") | "You are not coming in, sorry." |
| jump / return | continue in another chain / come back | "Ask my colleague at the side door." |
| log | write a line in the log, then keep reading | the bouncer writes in his notebook |
Why would anybody choose drop instead of the more polite reject? Because silence gives an attacker nothing: no answer, no hint that a router is even there, and he has to wait for his own timeout every time.
The scenario¶
You are the student with r1, a home router configured like a MikroTik out of the box. Your laptop pc1 sits on its LAN. class-ap is the trainer's router, which connects the whole class to "the Internet", here played by a small server called internet.
On a real hAP the Internet port is ether1; in the virtual lab ether1 is reserved for the lab itself, so the Internet port is ether2 and the LAN ports start at ether3.
flowchart LR
PC1["<b>pc1</b> (your laptop)<br>192.168.88.200<br>eth1"] -- "LAN" --- R1["<b>r1</b> (your router = the club)<br>bridge1 = ether3: 192.168.88.1/24<br>ether2 = WAN: 10.0.0.x by DHCP"]
R1 -- "class network<br>10.0.0.0/24" --- AP["<b>class-ap</b> (trainer's router)<br>10.0.0.1 · 198.51.100.1<br>DNS: www.mikrotik.com"]
AP --- NET["<b>internet</b><br>198.51.100.10<br>web server :80"]| Node | Role | Address |
|---|---|---|
pc1 |
your laptop (Linux) | 192.168.88.200 (r1 always gives it this address by DHCP) |
r1 |
your router: the club and its bouncer | LAN bridge1 192.168.88.1/24 · WAN ether2 10.0.0.x (DHCP) |
class-ap |
the trainer's router, class gateway and DNS | 10.0.0.1 and 198.51.100.1 |
internet |
"the Internet": answers ping and serves a web page | 198.51.100.10 (www.mikrotik.com points here) |
r1 starts with no firewall rules at all: the bouncer has not been hired yet.
Start the lab¶
Download the lab files and unzip them: 06-01-input-chain.zip. Open a terminal inside the 06-01-input-chain folder.
From the lab folder guions/tema-3/lab/mtcna/06-01-input-chain/:
The two RouterOS routers need about two minutes to boot. Then open two terminals:
ssh admin@clab-mtcna-06-01-r1 # the router (password: admin)
docker exec -it clab-mtcna-06-01-pc1 bash # the laptop
If you prefer WinBox, connect it to the router's management address shown by containerlab inspect.
Every step below gives the WinBox path and the CLI command; use either.
Step 1 · Look at the empty rule list¶
Before changing anything, see what the bouncer has today: nothing.
IP → Firewall → Filter Rules
Expected output: only the header (Flags: X - DISABLED...), no rules. Now prove that the router's door is
wide open. On pc1:
ip -4 addr show eth1 # you are 192.168.88.200
ping -c2 192.168.88.1 # the router answers
curl -s http://192.168.88.1 | grep -o '<title>.*</title>' # WebFig's login page: <title>RouterOS</title>
Check yourself
Which chain would a packet from pc1 to 192.168.88.1 go through: input, forward or output? Why?
Done when: you have seen an empty filter list and pc1 reaches the router by ping and by web.
Step 2 · Put your laptop on the guest list¶
The first instruction for the bouncer: "if a packet comes in through the LAN (bridge1) from my laptop
(192.168.88.200), let it in". This is the rule on slide 243.
IP → Firewall → Filter Rules → + · General: Chain input, Src. Address 192.168.88.200,
In. Interface bridge1 · Action: accept · Comment: accept the laptop
/ip firewall filter add chain=input in-interface=bridge1 src-address=192.168.88.200 action=accept comment="accept the laptop"
Nothing changes yet: everybody was already allowed. That is fine: this rule only matters once we add the "everybody else out" rule below it.
Check yourself
Right now the accept rule changes nothing at all. Why? What has to exist below it for it to matter?
Done when: /ip firewall filter print shows rule 0 with the comment accept the laptop.
Step 3 · Turn everybody else away¶
Now the second instruction: "anything else coming in through the LAN to the router: drop".
IP → Firewall → Filter Rules → + · General: Chain input, In. Interface bridge1 ·
Action: drop · Comment: drop everything else from the LAN
/ip firewall filter add chain=input in-interface=bridge1 action=drop comment="drop everything else from the LAN"
/ip firewall filter print
Expected: rule 0 accept, rule 1 drop. A new rule is always added at the bottom, which is exactly
where a "catch-all" drop belongs.
Your laptop is on the list, so on pc1 everything still works:
Check yourself
Why did we write in-interface=bridge1 in the drop rule? What would happen to traffic arriving from
the Internet side (ether2) if we had left it out?
Done when: two rules, accept above drop, and pc1 still pings the router.
Step 4 · Become a stranger and get locked out¶
Time to test the bouncer. Slide 244 asks you to change the laptop to a fixed address that is not on the list: 192.168.88.199. On pc1:
dhclient -r eth1 # give back the DHCP address (.200)
ip addr add 192.168.88.199/24 dev eth1 # now you are the stranger .199
ip route add default via 192.168.88.1 # gateway: r1
echo "nameserver 192.168.88.1" > /etc/resolv.conf # DNS: r1 (as on slide 244)
Now try:
ping -c2 192.168.88.1 # 100% packet loss: the bouncer ignores you
curl -s --max-time 4 http://192.168.88.1; echo "exit $?" # exit 28 = timeout, no WebFig
curl -s --max-time 4 http://www.mikrotik.com; echo "exit $?" # the web is broken too!?
ping -c2 198.51.100.10 # ...and yet this works
Look at the counters on the router (you are still connected through the lab's management port, which is
not bridge1, so the rule does not affect you there):
IP → Firewall → Filter Rules (columns Bytes / Packets)
The packets counter of the drop rule has grown: those are your rejected attempts.
How do you get back in on a real router?
On slide 246 the course reconnects with MAC WinBox. MAC WinBox talks to the router using the laptop's MAC address (layer 2), not its IP address, so the IP firewall never sees it. That is your back door when you lock yourself out of a real hAP. In this lab the back door is the management port ether1.
Check yourself
The web page http://www.mikrotik.com does not open, but ping 198.51.100.10 (the same server!) works.
Before reading the next step, write down your theory: what does the browser need before it can
connect to www.mikrotik.com, and who gives it that?
Done when: as .199 you cannot ping or open the router, you cannot open www.mikrotik.com, but you can
ping 198.51.100.10.
Step 5 · Solve the mystery: the DNS trap¶
Web traffic to the Internet goes through the router (forward chain), and we did not touch forward. So why
did it break? Because before connecting, your laptop has to turn the name www.mikrotik.com into an
IP address. That job is called DNS (Domain Name System), and your laptop asks the router to do it
(nameserver 192.168.88.1). A DNS question is a packet to the router: input chain, and the bouncer drops it.
The fix (slide 246): add an accept rule for DNS questions, udp port 53, and place it above the drop.
IP → Firewall → Filter Rules → + · General: Chain input, Protocol udp, Dst. Port 53,
In. Interface bridge1 · Action: accept · Comment: accept DNS from the LAN · then drag the rule
above the drop rule in the list.
/ip firewall filter add chain=input in-interface=bridge1 protocol=udp dst-port=53 action=accept comment="accept DNS from the LAN" place-before=[find comment="drop everything else from the LAN"]
/ip firewall filter print
place-before= puts the new rule just above the rule you name; [find comment="..."] looks that rule up by
its comment, so you do not depend on rule numbers. Expected order: accept the laptop, accept DNS, drop.
On pc1 (still .199):
curl -s --max-time 4 http://www.mikrotik.com # Welcome to the Internet
ping -c2 192.168.88.1 # still dropped: only DNS was opened
Check yourself
Why does the new rule have to be above the drop rule? Predict what would happen if it stayed at the bottom, then explain using "first match wins".
Done when: as .199 the web works again but the router still ignores your ping.
Step 6 · Go back to being yourself¶
Slide 247: return the laptop to DHCP. On pc1:
ip addr flush dev eth1 # forget .199
dhclient eth1 # ask r1 for an address again
ip -4 addr show eth1 # 192.168.88.200 is back
ping -c2 192.168.88.1 # the router answers you again
Notice something interesting: the DHCP conversation worked even though .199-style strangers are dropped. The RouterOS DHCP server picks up its packets before the IP firewall looks at them, so it keeps working. Do not count on that for any other service.
The course ends the lab by disabling these rules (IP → Firewall, select, Disable, or
/ip firewall filter disable [find]). Leave them enabled here for now: the checker needs them. When you
have run it, you may disable them to see the door open again.
Run the automated check from the lab folder on your PC:
It plays the stranger .199 for you and must end with RESULT: lab 06-01 solved.
Check yourself
In one or two sentences, explain to a classmate why disabling the rules at the end of a course lab is a good habit on a shared classroom router.
Done when: pc1 is back at 192.168.88.200 and check.sh passes.
If something goes wrong¶
| Symptom | Likely cause | Fix |
|---|---|---|
| Even your laptop (.200) cannot reach the router | the drop rule is above the accept rule | /ip firewall filter print, then move the accept rule up (or drag it in WinBox) |
| You lost your own SSH/WinBox session to the router | you wrote the drop rule without in-interface=bridge1 and connected through the LAN |
on real hardware use MAC WinBox; in the lab connect through the management address and fix the rule |
| As .199 the web still works before step 5 | /etc/resolv.conf points to another DNS server, or the drop rule is disabled (X flag) |
write nameserver 192.168.88.1; enable the rule |
| After step 5 the web still fails | the DNS rule is below the drop, or you typed tcp instead of udp |
check order and protocol with /ip firewall filter print |
dhclient eth1 hangs |
r1 is still booting | wait a minute and try again |
| Counters stay at 0 | the rule never matched: wrong interface (ether3 instead of bridge1) |
ether3 is a bridge port; IP traffic arrives on bridge1 |
Clean up¶
Key takeaways¶
- A firewall checks every packet against a list of if-then rules, from the top; the first match wins, and an empty list lets everything through.
- RouterOS has three built-in chains: input (to the router), forward (through the router) and output (from the router).
- accept lets a packet in, drop ignores it silently, reject refuses it and tells the sender.
- Protecting the router means input rules: accept what you trust, then a final drop for the rest of the LAN.
- Clients use the router for DNS (udp/53): block input without an exception and "the Internet stops working".
- Rule counters (packets/bytes) prove whether a rule really matched.
Quick check¶
1. Your router's filter list is completely empty. What happens to a packet that arrives?
- It is dropped, because no rule allows it
- It is accepted, because no rule matched it
- It is rejected with an ICMP message
- It waits until an administrator adds a rule
The RouterOS firewall is open by default: a packet that matches no rule is accepted. That is why a router without rules lets anybody on the LAN reach its login page.
2. You open WebFig at http://192.168.88.1 from your laptop. Which chain checks those packets?
- input
- forward
- output
- srcnat
WebFig runs on the router itself, so the packets are addressed to the router: the input chain. Forward is only for traffic that passes through the router to somewhere else.
3. A rule list has: rule 0 drop everything on bridge1, rule 1 accept 192.168.88.200 on bridge1. What happens to your laptop .200?
- It is accepted, because accept rules always win
- It is dropped, because rule 0 matches first
- It is accepted, because rule 1 is more specific
- It is dropped only if it uses udp
Rules are read from the top and the first match wins. Rule 0 matches every packet from the LAN, so the bouncer never even reads rule 1. Order is everything.
4. What is the difference between drop and reject?
- drop logs the packet, reject does not
- drop works on input only, reject on forward only
- drop discards silently, reject discards and sends an ICMP error back
- drop is temporary, reject is permanent
drop throws the packet away and says nothing, so the sender just waits for a timeout. reject also throws it away but answers with an ICMP error. Drop gives an attacker less information.
5. After blocking input from the LAN (except your laptop), a classmate on the LAN cannot open any web page, yet can ping 198.51.100.10. What is the most likely reason?
- The forward chain is blocking port 80
- The classmate's cable is faulty
- Their DNS questions to the router (udp/53) are dropped in input
- The masquerade rule was deleted
Ping by IP works, so the path through the router is fine. What fails is turning names into addresses: the classmate asks the router for DNS, which is input traffic. Accept udp/53 above the drop rule.
6. How can you prove a firewall rule is really doing its job, not just sitting in the list?
- By checking that it has a comment
- By generating matching traffic and watching its packet counter grow
- By rebooting the router
- By checking that its number is 0
Every rule counts the packets and bytes it matched (/ip firewall filter print stats). If you
send the traffic the rule is meant to catch and the counter does not move, the rule is not matching.
7. While you sleep, a smart TV on your LAN gets an address that is not on the guest list. Which two still work for it with this lab's rules?
- Asking the router to resolve names (DNS)
- Opening the router's WebFig page
- Streaming video from a server on the Internet
- Pinging the router
The TV is a stranger for the input chain: only DNS (udp/53) is accepted for it. Traffic through the router, like streaming from the Internet, goes through forward, which this lab never touched.
The router now has a bouncer at its office door. In the next lab, 06-02 · The forward chain, you put one in the corridor too and decide which traffic may pass through the router.