Your guest Wi-Fi probably isn't isolated

You set up guest Wi-Fi. Separate network name, separate password, and somewhere in the interface a box labeled "guest network" or "client isolation" that you ticked. Visitors get internet, and you assume that's all they get.

Three different mechanisms hide behind that assumption. Most small networks have exactly one of them.

What "client isolation" actually stops

Client isolation is a rule inside the access point: frames arriving from one associated station are not forwarded back out to another associated station on the same radio. It stops the laptop in your waiting room from seeing the phone sitting next to it.

On RouterOS's current wifi package it lives on the datapath:

/interface/wifi/datapath
add name=guest-dp bridge=bridge-guest client-isolation=yes

On the older wireless package the equivalent is default-forwarding=no on the interface. Either way, notice what it says nothing about: traffic that leaves the AP. Isolation is per-radio. Bridge two access points together on the same guest SSID and a client on one can reach a client on the other, because those frames never needed station-to-station forwarding — they went up the wire and back down. If guest coverage spans more than one AP, you also want split horizon on the bridge ports:

/interface bridge port
set [find bridge=bridge-guest] horizon=1

Ports sharing a horizon value won't forward to each other, which closes the AP-to-AP path.

A separate SSID is not a separate network

This is the one that catches people. An SSID is a name. If the guest SSID is bridged into the same bridge as everything else, guests land in the same subnet, the same broadcast domain and the same DHCP pool as your point-of-sale. Different password, identical network. They can see every device on it, and client isolation doesn't help, because the printer and the file server aren't wireless stations.

Real separation means the guest SSID lands on its own VLAN and its own subnet, and anything crossing between that subnet and the rest of the building has to pass through the router where you can drop it. I've written about zone-based segmentation already and won't repeat it — the short version is that a guest VLAN with no forward rules is just a tidier flat network.

The part everyone forgets: the router is a device too

Here's what I find on networks that did all of the above correctly. The guest VLAN exists. The subnet is separate. The forward chain drops guest-to-LAN. And a guest can still open the router's admin page.

Rules governing traffic between networks live in the forward chain. Traffic addressed to the router itself — its web interface, its API, its resolver, its SSH — goes to the input chain, which is a different list, usually written once years ago and never revisited since. It needs its own rules:

/ip firewall filter
add chain=input in-interface-list=GUEST protocol=udp dst-port=67 action=accept \
    comment="DHCP"
add chain=input in-interface-list=GUEST protocol=udp dst-port=53 action=accept
add chain=input in-interface-list=GUEST protocol=tcp dst-port=53 action=accept
add chain=input in-interface-list=GUEST action=drop \
    comment="addresses and name resolution, nothing else"

Order matters. The drop sits below those accepts and above any broad accept already in the chain.

Then there's the one that isn't an IP problem at all. RouterOS can be discovered and managed over layer 2, by MAC address, with no IP configuration whatsoever. A guest running Winbox on an isolated, firewalled guest VLAN can still see and connect to your router, because MAC-Winbox never touches the IP firewall — every rule you wrote is correct and irrelevant. Confine it, along with neighbor discovery:

/ip neighbor discovery-settings set discover-interface-list=MGMT
/tool mac-server set allowed-interface-list=MGMT
/tool mac-server mac-winbox set allowed-interface-list=MGMT

Those three lines are missing on most of the networks I'm asked to clean up.

Verify from the guest side

Configuration screens lie by omission. Join the guest SSID with a laptop and check the result:

Read your address and mask. If it's the same subnet as the office, stop — nothing else matters until that's fixed.
Ping the office printer and the point-of-sale by address. Both should time out.
Scan your own subnet. You should find the gateway and nothing else.
Open the router's LAN address and each access point's management address in a browser. Both should refuse.
Open Winbox and use the neighbor tab, not the address field. If your router appears there, fix the mac-server settings.

One honest side effect: proper isolation breaks casting. Guests can't AirPlay to the lobby TV, because that is precisely the traffic being blocked. If that matters to you, put the TV on a deliberate path rather than reopening the network to get it back.

Want someone to run those five checks against your network and tell you what turned up? Start here.