Lab 06-02 · The forward chain: guarding the corridor¶

MTCNA

Module 6 · Firewall of the MikroTik MTCNA course, official slides p248–252 (chain forward, the LAB "Cadena: forward" and the table of common ports).

Your school blocks some websites. Your phone at home does not. Same phone, same apps: the difference is a rule in the router those packets pass through. Somebody told the router "this kind of traffic may not cross".

In the previous lab the bouncer guarded the router's office (the input chain). Today he moves to the corridor: the traffic that walks through the club from the LAN street to the Internet street. You will stop your laptop from opening web pages, and discover that the router's own page still opens. Why? Because that page lives in the office, not across the corridor.

What you will learn

Explain what the forward chain controls and how it differs from input.
Recognise the most common ports (80, 443, 22, 23, 20/21, 8291...).
Write a forward rule that blocks one protocol and port (HTTP, tcp/80).
Remember the trap: a port only means something once you choose the protocol (tcp or udp).
Show, by traffic and by counters, that WebFig survives a forward block.

The forward chain¶

The forward chain checks the packets that pass through the router: from the LAN to the Internet, from the Internet to the LAN, and between devices on different LAN networks.

Picture the club again. The input door leads into the staff office: the router itself. The forward corridor crosses the building from one street to the other. A packet from your laptop to a web server on the Internet never visits the office; it only walks the corridor.

By default, slide 249 reminds us, the corridor is completely open:

devices on your LAN can talk to each other freely;
traffic between your LAN and the Internet is not restricted.

flowchart LR
    PC["<b>pc1</b><br>your laptop"] -- "http://www.mikrotik.com<br><b>forward</b> (through the corridor)" --> R1["<b>r1</b><br>the club"]
    R1 -- "forward" --> NET["<b>internet</b><br>198.51.100.10:80"]
    PC -. "http://192.168.88.1<br><b>input</b> (into the office)" .-> R1

Ports: which door of the server?¶

An IP address takes a packet to the right computer. A port number takes it to the right program on that computer: the web server, the SSH server, WinBox... Ports belong to a protocol: TCP (a conversation with delivery checks, used by the web) or UDP (quick messages without checks, used by DNS).

Port	Service
80/tcp	HTTP (web pages, unencrypted)
443/tcp	HTTPS (web pages, encrypted)
22/tcp	SSH (secure remote terminal)
23/tcp	Telnet (old, unencrypted remote terminal)
20, 21/tcp	FTP (file transfer)
8291/tcp	WinBox
5678/udp	MikroTik Neighbor Discovery
20561/udp	MAC WinBox

A port needs a protocol

"Port 80" alone is ambiguous: tcp/80 and udp/80 are different doors. RouterOS will not let you fill Dst. Port until you choose a Protocol (slide 250). Always pick the protocol first.

The scenario¶

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 (DHCP from r1)
`r1`	your router	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, serves `http://www.mikrotik.com`	198.51.100.10

r1 starts with an empty firewall filter: the corridor is unguarded.

Start the lab¶

Download the lab files and unzip them: 06-02-forward-chain.zip. Open a terminal inside the 06-02-forward-chain folder.

From the lab folder guions/tema-3/lab/mtcna/06-02-forward-chain/:

sudo containerlab deploy -t topology.clab.yml

Wait about two minutes for the routers to boot, then:

ssh admin@clab-mtcna-06-02-r1                   # the router (password: admin)
docker exec -it clab-mtcna-06-02-pc1 bash       # the laptop

Step 1 · Walk the corridor before the bouncer arrives¶

On pc1:

curl -s http://www.mikrotik.com                                 # Welcome to the Internet
curl -s http://192.168.88.1 | grep -o '<title>.*</title>'       # <title>RouterOS</title> (WebFig)
ping -c2 www.mikrotik.com                                       # answers from 198.51.100.10

Three requests, two different chains. The first and the last cross the router (forward); the second stops at the router (input).

Check yourself

For each of the three commands, write the chain that checks it (input or forward) and why.

Done when: the three commands work.

Step 2 · Block web traffic in the corridor¶

Slide 250: add a drop rule in forward for tcp port 80 (HTTP).

IP → Firewall → Filter Rules → + · General: Chain forward, Protocol 6 (tcp), Dst. Port 80 · Action: drop · Comment: forward: no web browsing (HTTP, 80/tcp)

/ip firewall filter add chain=forward protocol=tcp dst-port=80 action=drop comment="forward: no web browsing (HTTP, 80/tcp)"
/ip firewall filter print

Why dst-port (destination port)? Because the web server is the one listening on port 80: packets from your laptop go to port 80. Your laptop's own port (the source port) is a random high number that changes every time.

Check yourself

The rule has no source or destination address. Which packets does it catch? Would it also stop a classmate's laptop on the same LAN?

Done when: the rule appears in the list without the X (disabled) or I (invalid) flag.

Step 3 · Test both doors¶

Give the router a second to apply the rule, then on pc1:

curl -s --max-time 4 http://www.mikrotik.com; echo "exit $?"     # nothing, exit 28 (timeout)
curl -s http://192.168.88.1 | grep -o '<title>.*</title>'       # still <title>RouterOS</title>
ping -c2 www.mikrotik.com                                       # still answers

Slide 251 explains the second result: the router's web page works because that traffic goes to the router (input), not through it (forward). And ping still works because ping is not tcp/80: the bouncer only stops the people who match the description.

Now read the counters:

IP → Firewall → Filter Rules (Packets column)

/ip firewall filter print stats

The drop rule shows a few packets: your browser kept retrying the connection (TCP sends the first packet several times before giving up), and each attempt was dropped.

Check yourself

Most real websites use HTTPS (443/tcp), not HTTP. Would this rule stop a student from opening https://... pages? What would you add?

Done when: the Internet web page times out, WebFig still opens, ping still works, and the counter is above 0.

Step 4 · Run the checker¶

From the lab folder on your PC:

CLAB_EXEC="sudo docker exec" ./check.sh

It must end with RESULT: lab 06-02 solved.

Blocking one website, not all of them

The slide says "block the laptop from www.mikrotik.com". This lab blocks port 80 for every site. To block one site, add dst-address=198.51.100.10 to the rule (the address www.mikrotik.com resolves to here). Real sites have many addresses that change; the next lab's address lists help.

Check yourself

The checker proves the rule works with traffic and with a counter. Why is looking at /ip firewall filter print alone not enough proof?

Done when: check.sh passes.

If something goes wrong¶

Symptom	Likely cause	Fix
WinBox refuses the Dst. Port field	no Protocol chosen	choose `6 (tcp)` first
The Internet page still opens	rule disabled, or in the input chain, or `src-port=80` instead of `dst-port=80`	`/ip firewall filter print detail` and correct it
WebFig (192.168.88.1) stopped opening	you put the rule in input	delete it and add it in forward
Ping stopped working too	you left Protocol and Dst. Port empty: the rule drops everything	set `protocol=tcp dst-port=80`
The page opens once and then fails	the first curl ran before the rule was applied	wait a second and retry

Clean up¶

sudo containerlab destroy -t topology.clab.yml --cleanup

Key takeaways¶

The forward chain checks traffic through the router; input checks traffic to the router.
By default forward is wide open: LAN-to-LAN and LAN-to-Internet traffic is not restricted.
A port picks the program on a computer; it only makes sense together with a protocol (tcp or udp).
To block a service, match its destination port (the server's port), e.g. tcp/80 for HTTP.
A forward block on tcp/80 stops Internet web pages but not WebFig, which is input traffic.

Quick check¶

1. Which traffic does the forward chain check?

Packets addressed to the router itself
Packets that pass through the router
Packets created by the router
Only packets coming from the Internet

forward is the corridor: anything that crosses the router between interfaces, in either direction. Packets to the router are input; packets from the router are output.

2. You add chain=forward protocol=tcp dst-port=80 action=drop. Why does http://192.168.88.1 still open?

Because WebFig uses port 8291
Because that traffic goes to the router, so it is checked by input
Because the router always trusts its own LAN
Because WebFig uses udp

WebFig runs on the router: those packets end at the router and are checked by input. The forward rule only sees traffic passing through.

3. Why does WinBox ask for a protocol before letting you type a port?

Because ports only exist for icmp
Because the protocol decides the rule's chain
Because the same port number means different things in tcp and udp
Because ports are only allowed in the input chain

Ports belong to a protocol: tcp/53 and udp/53 are two different doors. A port without a protocol would be ambiguous.

4. Which port and protocol does HTTPS use?

80/tcp
443/tcp
8291/tcp
53/udp

HTTPS (encrypted web) listens on 443/tcp. HTTP is 80/tcp, WinBox 8291/tcp, DNS 53/udp.

5. Why do we match dst-port=80 and not src-port=80 to block web browsing?

Because src-port only works with udp
Because the router cannot read source ports
Because the web server listens on 80; the laptop's own port is random
Because dst-port is faster to evaluate

The server listens on port 80, so the laptop's packets travel to port 80: the destination port. The laptop picks a random high source port for each connection.

6. After this lab's rule, a student watches a video on a site served over HTTPS. Which two statements are true?

The video plays, because 443/tcp is not blocked
The video stops, because all web traffic is blocked
The drop rule's counter does not grow while the video plays
The router's input chain blocks the video

The rule only matches tcp/80. HTTPS uses 443, so the packets do not match, they are accepted by default and the counter stays still. Input is not involved: the video crosses the router.

Now the bouncer guards both the office and the corridor, but every rule names addresses one by one. Next, in 06-03 · Address lists, you give him a proper guest list.