Lab 06-06 · Redirect: every request goes to reception¶
MTCNA
Module 6 · Firewall of the MikroTik MTCNA course, official slides p268–270 (the redirect action, transparent proxies for DNS and HTTP, and the LAB "Redirigir").
Have you ever connected to the WiFi of a hotel, an airport or a train, typed a web address, and landed on a "Welcome! Accept the terms" page instead? You never asked for that page. The network quietly took your request and answered it itself. That page is called a captive portal, and the trick behind it is the action you learn today: redirect.
In the club, it is a bouncer with a very particular instruction: "whatever room a guest asks for, walk them to reception first". The guest does not notice the detour. You will use it twice: to answer every web request with the router's own page, and to make sure every DNS question is answered by your router, even when a laptop tries to use another DNS server.
What you will learn
- Explain redirect as a special kind of dst-nat whose destination is the router itself.
- Redirect all HTTP (tcp/80) from the LAN to the router, as slide 270 asks.
- Force all DNS (udp/53) through the router's DNS cache, even if a device uses 8.8.8.8.
- Explain what a transparent proxy is and why the client "does not notice".
- Recognise the trap of forgetting to disable a lab redirect.
Redirect: dst-nat to the router itself¶
redirect is a special dst-nat action that changes a packet's destination to the router itself (the address of the interface it came in on), optionally on another port.
Slide 268 says it is used to build transparent proxy services. A proxy is a middleman that answers or fetches on your behalf; transparent means the client did not configure it and does not know it is there.
| Action | Destination becomes | Club version |
|---|---|---|
| dst-nat (lab 06-05) | another device (to-addresses, to-ports) |
the bouncer walks the visitor to a room |
| redirect | the router itself (to-ports only) |
the bouncer walks the guest to reception, whatever room they asked for |
The DNS example of slide 269: your laptop sends its question to "the configured DNS server, port 53"; the redirect rule changes the destination to "router, port 53"; the router's DNS cache answers.
flowchart LR
PC["<b>pc1</b><br>asks 8.8.8.8:53<br>'where is www.mikrotik.com?'"] -- "udp/53" --> R{"<b>r1 dstnat</b><br>redirect<br>to-ports=53"}
R -- "destination becomes<br>the router itself" --> DNS["<b>r1 DNS cache</b><br>answers 198.51.100.10"]
R -. "never reaches" .-> G["8.8.8.8"]The reply goes back from 8.8.8.8's address (the router remembers the translation and puts it back), so the laptop believes 8.8.8.8 answered.
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"] -- "LAN" --- R1["<b>r1</b> (the club)<br>bridge1: 192.168.88.1/24<br>WebFig :80 · DNS cache :53"]
R1 -- "ether2 = WAN<br>10.0.0.x" --- AP["<b>class-ap</b><br>10.0.0.1<br>DNS: www.mikrotik.com"]
AP --- NET["<b>internet</b><br>198.51.100.10<br>'Welcome to the Internet'"]| Node | Role | Address |
|---|---|---|
pc1 |
your laptop | 192.168.88.200 (DHCP) |
r1 |
your router, with WebFig on port 80 and a DNS cache on port 53 | LAN 192.168.88.1/24 · WAN ether2 10.0.0.x |
class-ap |
trainer's router; its DNS knows www.mikrotik.com |
10.0.0.1 |
internet |
"the Internet": serves "Welcome to the Internet" | 198.51.100.10 |
In this lab there is no 8.8.8.8: the classroom Internet has no route to it, so any DNS question sent there gets no answer. That makes the effect of the redirect easy to see.
Start the lab¶
Download the lab files and unzip them: 06-06-redirect.zip. Open a terminal inside the 06-06-redirect folder.
From the lab folder guions/tema-3/lab/mtcna/06-06-redirect/:
After about two minutes:
ssh admin@clab-mtcna-06-06-r1 # the router (password: admin)
docker exec -it clab-mtcna-06-06-pc1 bash # the laptop
Step 1 · Normal life, before the redirect¶
On pc1:
curl -s http://www.mikrotik.com # Welcome to the Internet
dig @8.8.8.8 www.mikrotik.com +time=2 +tries=1 # no servers could be reached
dig asks a DNS question; @8.8.8.8 chooses which server to ask. A laptop with a hand-typed DNS server (a
common trick to skip a network's filters) behaves exactly like this.
Check yourself
Why does dig @8.8.8.8 fail in this lab while curl http://www.mikrotik.com works? Which DNS server does curl use?
Done when: the web page opens and the question to 8.8.8.8 fails.
Step 2 · Redirect all web requests to the router¶
Slide 270: send every request with destination port HTTP (tcp/80) to port 80 of the router.
IP → Firewall → NAT → + · General: Chain dstnat, Protocol 6 (tcp), Dst. Port 80,
In. Interface bridge1 · Action: redirect, To Ports 80 · Comment redirect: all web traffic to the router
/ip firewall nat add chain=dstnat in-interface=bridge1 protocol=tcp dst-port=80 action=redirect to-ports=80 comment="redirect: all web traffic to the router"
in-interface=bridge1 limits the trick to your LAN guests; visitors from the WAN side are not affected.
On pc1:
curl -s http://www.mikrotik.com | grep -o '<title>.*</title>' # <title>RouterOS</title>
curl -s http://198.51.100.10 | grep -o '<title>.*</title>' # <title>RouterOS</title> too
Whatever web address you ask for, even a raw IP, reception (WebFig) answers. That is how a captive portal catches you.
Check yourself
Would this rule catch https:// pages (443/tcp)? Why do real captive portals still work when most
sites use HTTPS? (Hint: phones test a plain http:// address when they join a WiFi.)
Done when: both curls show <title>RouterOS</title>.
Step 3 · Force every DNS question through the router¶
Same idea for udp/53:
IP → Firewall → NAT → + · General: Chain dstnat, Protocol 17 (udp), Dst. Port 53,
In. Interface bridge1 · Action: redirect, To Ports 53 · Comment redirect: all DNS queries to the router
/ip firewall nat add chain=dstnat in-interface=bridge1 protocol=udp dst-port=53 action=redirect to-ports=53 comment="redirect: all DNS queries to the router"
/ip firewall nat print stats
On pc1:
Now there is an answer: www.mikrotik.com. ... A 198.51.100.10, and the line ;; SERVER: 8.8.8.8#53
claims 8.8.8.8 replied. It did not: 8.8.8.8 does not even exist in this lab. Your router answered from its
DNS cache and signed the reply with 8.8.8.8's address. Transparent.
This only works because r1 has allow-remote-requests=yes in IP → DNS: its DNS cache is willing to
answer LAN clients.
Check yourself
Give one good reason for a school or a company to force all DNS through its own router.
Done when: dig @8.8.8.8 gets 198.51.100.10 and both redirect counters are above 0.
Step 4 · Check, then put things back¶
From the lab folder on your PC:
It must end with RESULT: lab 06-06 solved.
Slide 270 ends: "when you finish, disable or delete the rule". A forgotten HTTP redirect breaks every plain web page for the whole LAN. Disable it and see the Internet come back:
IP → Firewall → NAT → select the rule → Disable (X)
The DNS redirect is harmless and useful: you may leave it on.
Check yourself
After disabling the HTTP redirect, is the DNS redirect still answering dig @8.8.8.8? Predict, then test it.
Done when: check.sh passed and, after disabling the HTTP redirect, the Internet page is back.
If something goes wrong¶
| Symptom | Likely cause | Fix |
|---|---|---|
| Web pages still come from the Internet | rule disabled, wrong chain, or src-port instead of dst-port |
/ip firewall nat print detail |
| Web pages time out instead of showing WebFig | to-ports points to a port where nothing listens, or WebFig (www service) is disabled |
to-ports=80; /ip service print |
dig @8.8.8.8 still fails |
DNS rule uses tcp instead of udp, or the router does not allow remote requests |
protocol=udp; /ip dns set allow-remote-requests=yes |
| Visitors from the Internet see WebFig | the rule has no in-interface=bridge1 |
add it |
| "The Internet is broken" the next day | the HTTP redirect is still enabled | disable or remove it |
Clean up¶
Key takeaways¶
- redirect is a dst-nat whose destination is the router itself; you only choose to-ports.
- It builds transparent proxies: the client did not configure anything and does not notice.
- Redirecting udp/53 forces every DNS question through the router's DNS cache, whatever server the client chose.
- Redirecting tcp/80 is the basis of captive portals; left on by mistake, it breaks plain web browsing.
- Limit redirects with in-interface to the LAN so the WAN side is not affected.
Quick check¶
1. What does the redirect action do?
- It sends the packet back to the sender
- It changes the destination to the router itself
- It changes the source to the router's address
- It forwards the packet to another LAN device
redirect is a special dst-nat: the new destination is the router (on the port in to-ports).
2. In which chain does a redirect rule go?
- srcnat
- forward
- dstnat
- output
Redirect changes the destination, so it belongs in the dstnat chain, like any dst-nat.
3. What is a transparent proxy?
- A proxy with an encrypted connection
- A middleman the client did not configure and does not notice
- A proxy that only works with IPv6
- A router without a firewall
A proxy answers or fetches on your behalf; transparent means it is in the way without the client knowing, thanks to rules like redirect.
4. After the DNS redirect, a laptop runs dig @8.8.8.8 and the answer says SERVER: 8.8.8.8. Who really answered?
- 8.8.8.8
- The router's DNS cache
- class-ap
- The laptop itself
The question never left the LAN: the router answered and the reply was translated back so it looks like it came from 8.8.8.8.
5. You forget the HTTP redirect enabled after the lab. What do LAN users notice?
- Nothing, redirects expire after 10 minutes
- Every plain http:// site shows the router's page
- They lose their IP addresses
- DNS stops working
Every tcp/80 request goes to the router, so every http:// page becomes WebFig. Slide 270 says to disable the rule when you finish.
6. A hotel wants every guest to see a terms page before browsing and to use the hotel's DNS. Which two rules fit?
- dstnat redirect tcp/80 from the guest LAN
- srcnat masquerade on the guest LAN
- dstnat redirect udp/53 from the guest LAN
- forward drop udp/53 from the WAN
A captive portal starts with redirecting tcp/80 to the router's page; a udp/53 redirect makes every guest use the hotel's DNS whatever they configured.
Redirect changed where packets go. In 06-07 · Source NAT and masquerade you look at the other half of NAT: changing who the packets seem to come from, the rule that lets your whole LAN share one address.