A VLAN keeps guests off the servers; it does nothing to stop one guest attacking another on the same segment, or a rogue DHCP server handing out a poisoned gateway. This is the Layer-2 hardening pass on RouterOS — port isolation, DHCP snooping, ARP discipline — and the one caveat that decides whether any of it runs on the switch chip or the CPU.
The threats are the same ones the Cisco Switch Security post defends against: guest-to-guest attacks inside a shared segment, rogue DHCP servers, and ARP spoofing. RouterOS answers them through the bridge — horizon for port isolation, dhcp-snooping with trusted ports, and ARP reply-only for a static-ARP lockdown. The building blocks map cleanly to Cisco's protected ports, DHCP snooping, and Dynamic ARP Inspection.
The RouterOS-specific catch runs through everything: many of these features disable hardware offload, moving the bridge from the switch chip to the CPU. On a small hEX that's fine; on a router pushing gigabits it matters. Knowing which feature costs offload is the difference between a secure segment and an accidental bottleneck.
01
Guest Wi-Fi's real security boundary isn't the password — it's stopping guests from seeing each other. On RouterOS, bridge horizon is the tool: ports sharing a horizon value can't forward to each other, only to the uplink.
# Give every guest-facing port the same horizon. Same number = can't # talk to each other; they can still reach a DIFFERENT-horizon uplink. > /interface bridge port set [find interface=ether3] horizon=10 > /interface bridge port set [find interface=ether4] horizon=10 # The uplink/gateway port keeps the default (no horizon), so guests # reach the internet but not one another. Same idea as Cisco protected-port.
Horizon covers wired ports and traffic crossing the bridge. Wireless clients on the same AP and SSID can still talk directly through the radio unless you enable client isolation there (CAPsMAN/wifiwave2: the datapath client-isolation option). Guest isolation is a wired and wireless setting — see CAPsMAN and the plain-language Why Guest Wi-Fi Needs Its Own Network.
02
A rogue DHCP server — a guest's mis-set travel router, or an attacker — can hand the whole segment a malicious gateway and MITM everyone. Snooping drops DHCP offers from any port you haven't blessed.
> /interface bridge set bridge dhcp-snooping=yes add-dhcp-option82=yes # Trust ONLY the port toward the legitimate DHCP server (here the uplink). # All other ports may REQUEST but their OFFERS/ACKs are dropped. > /interface bridge port set [find interface=ether1] trusted=yes # A guest plugging in a DHCP-serving router now poisons nobody.
Enabling dhcp-snooping (and option-82) moves affected bridge processing to the CPU on most models — the switch chip can't do it. On a CRS switching at line rate this can be a real throughput hit. Decide per box: on an access switch for a guest VLAN it's usually worth it; on a core doing 10G it may not be. Check /interface bridge port print for the H (hardware-offloaded) flag before and after.
03
ARP spoofing lets one host impersonate the gateway. RouterOS counters it by refusing to learn ARP dynamically on a locked-down interface and pairing that with static entries — the equivalent of Cisco's DAI plus IP Source Guard for the high-value segments.
# The interface answers ARP but won't LEARN it — so a spoofed # gratuitous ARP can't poison the table. Pair with static entries. > /interface vlan set [find name=vlan30-pms] arp=reply-only > /ip arp add address=10.10.30.10 mac-address=DC:2C:6E:00:11:22 interface=vlan30-pms # Optional belt-and-braces: cap how many MACs a guest port may learn, # and stop unknown-unicast flooding leaking frames across the segment. > /interface bridge port set [find interface=ether3] unknown-unicast-flood=no
Takeaways
H flag and decide per device.NOCTIS builds isolated, snooped, ARP-disciplined Layer-2 designs on MikroTik and Cisco for hospitality and business in Crete — so one compromised guest laptop stays exactly that.
Book a Discovery Call →