Lab 05-05 · Snooper, registration table and access list¶
MTCNA
Module 5 · Wireless. Official course slides 223–232: Snooper, registration table, access list, Default Authenticate and Default Forward. The official course has no LAB slide for this part; this lab turns those slides into practice (slide 233 is the module summary).
Real hardware in class
This lab is config-only: it is done on the real MikroTik router on your desk (a virtual CHR has no radio). It starts where Lab 05-03 ended: your AP 13_JohnDoe on the 5 GHz radio.
Your little brother found out your WiFi password. Now his tablet, his console and two of his friends' phones are on your network every afternoon, and your online match lags. Changing the password means re-typing it on every device you own. Is there a better way?
Yes: tell the access point exactly which devices may connect, and when. Everybody else is refused, even with the right password. Today you will survey the air, pick your own devices from the registration table, and build that guest list.
What you will learn
- Survey the radio environment with the Snooper / flat-snoop and choose a quiet channel
- Read the registration table and copy a client to the access list
- Write access list rules by MAC address, time of day and signal, and know they are evaluated top-down
- Explain Default Authenticate and Default Forward, and their equivalents in the new WiFi menu (a final reject rule and client isolation)
- Explain why a MAC-based list is a convenience, not real security (MAC spoofing, private MAC addresses)
The bouncer and the guest list¶
Our analogy for this lab: a party with a bouncer at the door.
| Party | Access point |
|---|---|
| Looking out of the window to see who is around | Snooper: every AP and station on every channel |
| The list of people already inside | Registration table |
| The bouncer's guest list | Access list |
| "If you're not on the list, you're not coming in" | Default Authenticate = off |
| "Guests may not talk to each other" (a strange party) | Default Forward = off (client isolation) |
The access list is an ordered list of rules that an access point checks for every station that tries to connect. Each rule matches a station (by MAC address, interface, signal range, time and days) and decides whether it may connect (authentication) and whether it may talk to other WiFi clients (forwarding).
Rules are checked from the top, and the first matching rule decides, as in the connect list (Lab 05-02) and the firewall. If no rule matches, the interface defaults apply (slide 228).
flowchart LR
ST["<b>Station</b> tries to join<br>(correct password)"] --> AL{"<b>Access list</b><br>first matching rule?"}
AL -- "accept / authentication=yes" --> IN["<b>Connected</b><br>forwarding from the rule"]
AL -- "reject / authentication=no" --> OUT["<b>Refused</b>"]
AL -- "no rule matches" --> DA{"<b>Default Authenticate</b><br>(legacy)"}
DA -- "yes" --> IN2["<b>Connected</b><br>Default Forward decides"]
DA -- "no" --> OUTDefault Authenticate and Default Forward (slides 230–232)¶
| Legacy interface setting | Meaning | New WiFi menu equivalent |
|---|---|---|
| Default Authenticate on (default) | stations that no rule mentions may connect | nothing to do: there is no implicit reject rule |
| Default Authenticate off | only stations allowed by a rule may connect | add a last rule action=reject with no MAC (matches everybody) |
| Default Forward on (default) | WiFi clients can talk to each other | datapath.client-isolation=no (default) |
| Default Forward off | WiFi clients can only talk to the router and beyond, not to each other | datapath.client-isolation=yes |
| per-client override | access-list forwarding=yes/no |
access-list client-isolation=yes/no |
Client isolation (Default Forward off) is what hotel and café WiFi does: your laptop reaches the Internet, but not the laptop of the stranger at the next table.
A MAC list is a guest list, not a lock
The MAC address is sent in clear in every WiFi frame. Anybody with a sniffer can read an allowed MAC and copy it onto their own device (MAC spoofing). An access list keeps out the honest and the lazy (your brother's friends); real security is still the WPA2/WPA3 passphrase.
Private MAC addresses
Modern phones and laptops use a private (random) MAC address per network by default. Your phone's MAC in the registration table is not the one in its settings' "About" page, and it can change if you "forget" the network. Copy the MAC from the registration table, never from the device box.
The scenario¶
| Node | Role | Address |
|---|---|---|
class-ap |
teacher's router, AP ClassAP (2.4 GHz) | 10.0.0.1/24 |
r1 2.4 GHz radio (wifi2 / wlan1) |
station of ClassAP (Internet) | 10.0.0.x (DHCP) |
r1 5 GHz radio (wifi1 / wlan2) |
your AP 13_JohnDoe, port of bridge1 |
— |
| your laptop | allowed always, may talk to other WiFi clients | 192.168.88.x |
| your phone | allowed school days 07:00–22:00, isolated from other WiFi clients | 192.168.88.x |
| a classmate's phone | not on the list: must be refused | — |
flowchart LR
subgraph R1["<b>r1</b> · AP <b>13_JohnDoe</b> (5 GHz)"]
AL["<b>Access list</b><br>1. laptop: accept<br>2. phone: accept 07-22h, isolated<br>3. everybody else: reject"]
end
L["<b>Your laptop</b>"] -- "allowed" --> AL
P["<b>Your phone</b>"] -- "allowed in hours" --> AL
X["<b>Classmate's phone</b>"] -. "refused" .-> ALWhere is ether1?
On a real hAP the Internet port is ether1; in the virtual labs ether1 is reserved for the lab itself, so the Internet port is ether2 and the LAN ports start at ether3. Here, on real hardware, the Internet arrives over WiFi and ether1 stays unused; the LAN is ether2–ether5.
Start the lab¶
Download the lab files and unzip them: 05-05-access-list.zip. Open a terminal inside the 05-05-access-list folder.
The starting point is the solution of Lab 05-03 (your AP is already running). Upload initial/r1.rsc (hAP ax²) or initial/r1-legacy-wireless.rsc (hAP ac²) to Files, then:
Reconnect WinBox to 192.168.88.1 by cable (ether2). Stay on the cable for the whole lab: you are about to build rules that can lock WiFi devices out, including your laptop.
Step 1 · Survey the air with the Snooper¶
Why: before choosing who may enter, look at who is around. The Snooper lists every AP and every station on every channel, with how busy each channel is (slides 223–224). It is the tool for choosing a quiet channel.
WinBox: WiFi → WiFi Interfaces, select wifi1 and use its Flat Snoop tool (button names vary a little between WinBox versions; the CLI below is the reference):
(/interface wifi frequency-scan wifi1 shows only the channel load.)
Expected: a list of channels with the networks and devices heard on each, their signal and the share of air time and traffic they use. Your classmates' APs on 5180–5240 MHz will show up.
The interface disconnects while it snoops
To listen on every channel the radio must leave its own (slide 223). All clients of your AP are disconnected during the snoop. Do it before connecting your devices, or accept the interruption.
Check yourself
Which of the 5 GHz channels 36, 40, 44, 48 is the busiest in your classroom? Which would you choose for your AP, and why?
Done when: you have identified the busiest and the quietest channel near you.
Step 2 · Connect your devices and read the registration table¶
Why: you need the real MAC addresses of your laptop's WiFi card and your phone (remember: private MACs).
- Connect your phone and your laptop (its WiFi, while the cable stays in ether2) to
13_JohnDoe. - Open the registration table.
WinBox: WiFi → Registration (legacy: Wireless → Registration).
Expected: two entries. The DHCP leases tell you which MAC is which device (the host name column says e.g. Pixel-7 or DESKTOP-4F2K).
Check yourself
Write down both MAC addresses. Look at the second hexadecimal digit of your phone's MAC: if it is 2, 6, A or E, the address is locally administered, a sign of a private (random) MAC. Is yours?
Done when: you know which MAC is your laptop and which is your phone.
Step 3 · Build the guest list¶
Why: this is the access list itself (slides 226–229). Rule 1: the laptop, always. Rule 2: the phone, only on school days from 07:00 to 22:00, and isolated from other WiFi clients.
WinBox: WiFi → Access List → +. Replace the MACs with yours:
/interface wifi access-list add interface=wifi1 mac-address=AA:BB:CC:DD:EE:01 action=accept client-isolation=no comment="my laptop"
/interface wifi access-list add interface=wifi1 mac-address=AA:BB:CC:DD:EE:02 action=accept time=7h-22h days=mon,tue,wed,thu,fri comment="my phone, school days 07:00-22:00"
/interface wifi access-list print
WinBox shortcut (slide 229): Wireless → Registration, double-click a client → Copy to Access List, then edit the rule. Or by CLI, replacing the MACs with yours:
/interface wireless access-list add interface=wlan2 mac-address=AA:BB:CC:DD:EE:01 authentication=yes forwarding=yes comment="my laptop"
/interface wireless access-list add interface=wlan2 mac-address=AA:BB:CC:DD:EE:02 authentication=yes forwarding=no time=7h-22h,mon,tue,wed,thu,fri comment="my phone, school days 07:00-22:00"
/interface wireless access-list print
Expected: two rules, in this order. Nothing changes yet for your devices: they match an "accept" rule. A classmate's phone with your password would still get in, because no rule refuses it yet.
More things a rule can match
Signal range (e.g. signal-range=-70..0: only devices close enough; far, weak clients slow everybody down), and in the legacy menu AP Tx Limit / Client Tx Limit to cap a client's speed. Look at the access-list window in WinBox (slide 227).
Check yourself
The router's clock decides the time and days rules. Run /system clock print: is the time and time zone correct? What would happen to your phone at 22:01?
Done when: both rules are in the access list, laptop first.
Step 4 · Refuse everybody else (Default Authenticate)¶
Why: a guest list is useless if the bouncer lets in people who are not on it.
The new WiFi menu has no implicit reject: add a last rule that matches everybody.
Now ask a classmate to join 13_JohnDoe with your passphrase. Watch the log (/log print follow) while they try.
Expected: your two devices stay connected; the classmate's phone is refused although the password is right. Look for its MAC address in the log lines of the attempt.
Check yourself
WiFi menu: what would happen if the reject rule were the first rule of the list? Legacy: what would happen if you unchecked Default Authenticate before adding any rule?
Done when: an unknown device cannot connect, and your two devices can.
Step 5 · Stop WiFi clients talking to each other (Default Forward)¶
Why: in a café you want guests to reach the Internet but not each other's laptops. Your phone should not be reachable from other WiFi devices.
First, the "before" picture. Unplug the laptop's cable for this test (it is allowed by rule 1, so WinBox keeps working over WiFi): if the cable stays in, the ping would travel through ether2 and isolation would not apply. From the laptop, ping your phone's IP from the DHCP leases. (If your phone never answers pings, use a classmate's laptop on your WiFi as the second device.)
WinBox: WiFi → Configurations → cfg-ap → Datapath → Client Isolation checked.
The laptop's rule has client-isolation=no: it overrides the default for that client (slide 232: "forwarding can be overridden for specific clients in the access list"). The phone's rule says nothing, so it inherits isolation.
Ping the phone from the laptop again.
Expected: before, the ping worked; now it fails, while both devices still browse the Internet and can reach the router at 192.168.88.1. Plug the cable back in when you are done.
Check yourself
The laptop is allowed to forward and the phone is not. Why does a ping from the laptop to the phone still fail? (Hint: think about the reply.)
Done when: your phone has Internet but no other WiFi client can reach it.
Step 6 · Restore¶
Why: so the next lab, or your next class, starts from a working AP.
Reload this lab's initial/ file with the reset command, or remove what you added:
The final/ files keep the whole solution (with placeholder MACs AA:BB:CC:DD:EE:01 and :02).
If something goes wrong¶
| Symptom | Likely cause | Fix |
|---|---|---|
| Your own phone is refused | its MAC in the rule is not the one it uses (private MAC), or a typo | copy the MAC from the registration table or the DHCP leases, not from the phone's "About" page |
| The phone is refused although the MAC is right | the time/days rule does not match now (wrong clock or time zone) |
/system clock print; set time-zone-name=Europe/Madrid |
| Everybody, including you, is refused | WiFi: the reject rule is above the accept rules; legacy: Default Authenticate off with no accept rules | reorder (drag in WinBox, or place-before=0); add the accept rules |
| Unknown devices still connect | WiFi: no final reject rule; legacy: Default Authenticate still on | Step 4 |
| Clients can still ping each other after Step 5 | the client's own rule overrides (forwarding=yes / client-isolation=no) |
that is per-client by design; check which rule matched |
| Lost WinBox during the snoop | you were managing the router over WiFi | always manage by cable during this lab |
Clean up¶
Step 6 restores the router. Unplug nothing: the next module starts from its own configuration.
Key takeaways¶
- The Snooper (legacy) / flat-snoop (WiFi) shows every AP and station per channel; it disconnects the interface while it runs.
- The registration table lists connected clients; in the legacy menu Copy to Access List turns one into a rule.
- The access list is checked top-down, first match; rules match by MAC, interface, signal range and time/days.
- Default Authenticate off = only listed stations; the WiFi menu has no implicit reject, so you add a final reject rule.
- Default Forward off = client isolation: clients reach the router and the Internet but not each other; per-client override in the access list.
- MAC filtering is a convenience: MACs can be spoofed and phones use private MACs; the passphrase is the real lock.
Quick check¶
1. In which order does an access point evaluate its access-list rules?
- From the top, and the first matching rule decides
- From the bottom, and the last matching rule decides
- All rules are combined, and the strictest one wins
- In order of MAC address, from lowest to highest
Like the connect list and the firewall, the access list is read top-down and the first match decides. If no rule matches, the interface defaults apply.
2. A legacy AP has Default Authenticate unchecked and one rule allowing your laptop. Your friend types the correct password on her phone. What happens?
- Her phone is refused, because no rule allows it
- Her phone connects, because the password is correct
- Her phone connects but cannot reach the Internet
- Her phone replaces your laptop in the list
With Default Authenticate off, a station that matches no rule is refused, even with the right passphrase. Only listed stations get in.
3. How do you get the effect of Default Authenticate = off in the new WiFi menu?
- Add a last access-list rule with action=reject that matches everybody
- Set datapath.client-isolation=yes on the configuration
- Set the SSID to hidden in the configuration
- Remove the passphrase from the security object
The WiFi menu has no implicit reject rule: a station that matches nothing is accepted. A final rule with action=reject and no MAC address matches every remaining station.
4. What does turning off Default Forward (client isolation) do?
- WiFi clients can reach the router and the Internet but not each other
- WiFi clients cannot reach the Internet any more
- The AP stops forwarding beacons, so its SSID is hidden
- Only one client at a time may be connected
Client isolation blocks traffic between stations of the AP. Traffic to the router (and through it, to the Internet) still works. Hotels and cafés use it.
5. Why should you copy a phone's MAC address from the registration table and not from the phone's 'About' screen?
- Phones use a private, random MAC for each WiFi network
- The registration table shows the MAC in a shorter format
- The 'About' screen shows the Bluetooth address, never the WiFi one
- The access list only accepts MAC addresses that start with AA
Modern phones use a private MAC address per network by default. The AP only ever sees that one, so that is the one the rule must contain.
6. Why is a MAC-based access list not enough to protect a WiFi network?
- Allowed MAC addresses travel in clear and can be copied by an attacker
- Access lists are deleted every time the router reboots
- MAC addresses are encrypted, so the AP cannot read them reliably
- Access lists only work on the 2.4 GHz band
Every WiFi frame carries the MAC in clear text. An attacker can read an allowed MAC and set it on their own card (MAC spoofing). The real protection is WPA2/WPA3 with a strong passphrase.
7. Why does the Snooper disconnect the clients of your AP while it runs?
- The radio must leave its channel to listen on all the others
- The Snooper changes the passphrase while it runs
- The Snooper turns the AP into a station of ClassAP
- The clients are moved to the 2.4 GHz radio automatically
One radio listens on one channel at a time. To survey every channel it leaves the AP's channel, so its clients lose the link until it comes back.
8. A small shop's staff WiFi must admit only the three staff tablets and the card terminal, and a stolen tablet must not be able to reach the card terminal over WiFi. Pick the two settings that are part of the solution.
- A final reject rule (or Default Authenticate off) after the four allowed devices
- Client isolation (Default Forward off) so WiFi clients cannot reach each other
- A connect-list rule with connect=no for every unknown device
- WPS push-button enabled so new staff can join easily
Unknown devices are stopped by the final reject (WiFi) or Default Authenticate off (legacy); the tablets and the terminal are kept apart by client isolation. The connect list is for stations, not APs, and WPS would let anyone near the button in.
You have finished Module 5: your router can be a WiFi client, an access point, and a strict bouncer. Next module: the firewall, the bouncer for every packet, not just for WiFi devices.