The series finale: every MikroTik post assembled into the network we actually build for a living — a small hotel. One RB5009 gateway, one CRS326 core switch, two ceiling APs, four VLANs, guest isolation that's tested rather than assumed, per-guest bandwidth fairness, and a CCTV segment the guests can never find. Build it on real gear or entirely in CHR — then break it like we do before handover.
This is the MikroTik twin of the Cisco campus lab, tuned for the deployment we do most: a 10–40 room property where the network must keep guests, staff, cameras, and management provably separate on hardware that costs less than one night's revenue. It composes the VLAN post, the firewall post, and the QoS post into one coherent build — with the integration gotchas that only appear when the pieces meet.
No hardware? No problem. Everything except the Wi-Fi radios runs identically on free CHR images in GNS3/EVE-NG — build the GW and SW as CHRs, hang test VMs off the VLANs, and substitute the AP section with tagged virtual NICs. The verification and failure drills at the end work either way — and they, not the config, are the actual lesson.
01
Four VLANs, four subnets, one table. As always: the plan is the design, the config is typing.
| VLAN / subnet | Who lives here — and the rule that governs them |
|---|---|
| 10 STAFF — 10.10.10.0/24 | Reception PCs, office Wi-Fi. Reaches internet + CCTV viewing; not mgmt. |
| 20 GUEST — 10.10.20.0/24 | Guest SSID + room ethernet. Internet only. Nothing internal, ever. |
| 30 CCTV — 10.10.30.0/24 | NVR + cameras. No internet at all (remote viewing comes via WireGuard). |
| 99 MGMT — 10.10.99.0/24 | Router, switch, APs. Reachable only from MGMT itself (+ VPN). |
| Gateways | GW owns .1 of every subnet on VLAN interfaces over the trunk. |
| Uplinks | GW ether1 = fibre, ether2 = Starlink (failover per the Starlink post). |
Cheap cameras phone home to clouds you don't control, run firmware nobody patches, and are the most-compromised device class we see. The design answer is structural, not hopeful: VLAN 30 has no route to the internet at all — a camera that can't reach its botnet C2 is a camera whose vulnerabilities mostly don't matter. The owner watches the NVR remotely through WireGuard into VLAN 30, which needs no camera to ever send a packet outward.
02
One bridge, vlan-filtering, hardware offload. Trunks to GW and both APs; access ports for reception and cameras. Order matters — build the VLAN table before enabling filtering.
[admin@SW] > /interface/bridge add name=bridge1 vlan-filtering=no ← ON later, LAST # Ports: trunk to GW (ether1), trunks to APs (ether2-3), # access for reception (ether10-12, V10) and NVR/cameras (ether20-24, V30) [admin@SW] > /interface/bridge/port add bridge=bridge1 interface=ether1 hw=yes [admin@SW] > /interface/bridge/port add bridge=bridge1 interface=ether2 hw=yes [admin@SW] > /interface/bridge/port add bridge=bridge1 interface=ether3 hw=yes [admin@SW] > /interface/bridge/port add bridge=bridge1 interface=ether10 pvid=10 frame-types=admit-only-untagged hw=yes [admin@SW] > /interface/bridge/port add bridge=bridge1 interface=ether20 pvid=30 frame-types=admit-only-untagged hw=yes # …repeat for the rest of each range # VLAN table: trunks tagged for everything; APs only need guest+staff+mgmt [admin@SW] > /interface/bridge/vlan add bridge=bridge1 vlan-ids=10 tagged=bridge1,ether1,ether2,ether3 untagged=ether10,ether11,ether12 [admin@SW] > /interface/bridge/vlan add bridge=bridge1 vlan-ids=20 tagged=bridge1,ether1,ether2,ether3 [admin@SW] > /interface/bridge/vlan add bridge=bridge1 vlan-ids=30 tagged=bridge1,ether1 untagged=ether20,ether21,ether22,ether23,ether24 [admin@SW] > /interface/bridge/vlan add bridge=bridge1 vlan-ids=99 tagged=bridge1,ether1,ether2,ether3 # Switch's own mgmt IP rides VLAN 99 [admin@SW] > /interface/vlan add name=vlan99-mgmt interface=bridge1 vlan-id=99 [admin@SW] > /ip/address add address=10.10.99.2/24 interface=vlan99-mgmt [admin@SW] > /ip/route add dst-address=0.0.0.0/0 gateway=10.10.99.1 # Everything above verified? NOW flip the big switch (from mgmt VLAN or console): [admin@SW] > /interface/bridge set bridge1 vlan-filtering=yes
Notice VLAN 30's tagged list: bridge1,ether1 only. The APs have no business carrying camera traffic, so the trunk definition simply doesn't extend VLAN 30 to them — segmentation by omission, enforced in hardware. This is the same "allowed VLAN list" idea as Cisco's switchport trunk allowed vlan, and the same audit point: a VLAN reaches exactly where its tagged/untagged lists say, no further. Review those lists whenever a new drop is cabled; they are the map of what can ever leak where.
03
GW terminates all four VLANs on one trunk port, serves DHCP to three of them, and NATs two of them to the internet. CCTV gets DHCP but no NAT — that's the no-internet rule, implemented.
# ether3 is the trunk to SW — VLAN interfaces ride directly on it [admin@GW] > /interface/vlan add name=vlan10-staff interface=ether3 vlan-id=10 [admin@GW] > /interface/vlan add name=vlan20-guest interface=ether3 vlan-id=20 [admin@GW] > /interface/vlan add name=vlan30-cctv interface=ether3 vlan-id=30 [admin@GW] > /interface/vlan add name=vlan99-mgmt interface=ether3 vlan-id=99 [admin@GW] > /ip/address add address=10.10.10.1/24 interface=vlan10-staff # …same for .20/.30/.99 # Interface lists — the firewall below matches these, not raw interfaces [admin@GW] > /interface/list add name=WAN [admin@GW] > /interface/list add name=LAN [admin@GW] > /interface/list/member add list=WAN interface=ether1 [admin@GW] > /interface/list/member add list=WAN interface=ether2 [admin@GW] > /interface/list/member add list=LAN interface=vlan10-staff # …and the other three VLANs into LAN # DHCP per VLAN (guest shown; staff/cctv identical pattern, mgmt static-only) [admin@GW] > /ip/pool add name=pool-guest ranges=10.10.20.50-10.10.20.250 [admin@GW] > /ip/dhcp-server add name=dhcp-guest interface=vlan20-guest address-pool=pool-guest [admin@GW] > /ip/dhcp-server/network add address=10.10.20.0/24 gateway=10.10.20.1 dns-server=10.10.20.1 # NAT: staff and guest get out; CCTV is conspicuously absent [admin@GW] > /ip/firewall/nat add chain=srcnat action=masquerade src-address=10.10.10.0/24 out-interface-list=WAN [admin@GW] > /ip/firewall/nat add chain=srcnat action=masquerade src-address=10.10.20.0/24 out-interface-list=WAN
The two WAN ports are exactly the Starlink failover writeup: recursive default routes with check-gateway=ping probing a real internet target, distances 1 and 10. Because the NAT rules above masquerade on out-interface-list=WAN rather than a specific port, translations follow whichever uplink is active with zero extra config — the trap the Cisco version needs route-maps for is simply absent here.
04
Section 01's table, translated mechanically into the forward chain. Every sentence in the plan becomes one or two rules — that traceability is what makes the firewall auditable.
# State first, as always [admin@GW] > /ip/firewall/filter add chain=forward action=fasttrack-connection hw-offload=yes connection-state=established,related comment="fasttrack" [admin@GW] > /ip/firewall/filter add chain=forward action=accept connection-state=established,related [admin@GW] > /ip/firewall/filter add chain=forward action=drop connection-state=invalid # "Guests reach the internet and absolutely nothing else" [admin@GW] > /ip/firewall/filter add chain=forward action=accept in-interface=vlan20-guest out-interface-list=WAN comment="guest to internet" [admin@GW] > /ip/firewall/filter add chain=forward action=drop in-interface=vlan20-guest comment="guest to anywhere else: NO" # "Staff reach internet + CCTV viewing" (NVR web/rtsp only, not the cameras) [admin@GW] > /ip/firewall/filter add chain=forward action=accept in-interface=vlan10-staff out-interface-list=WAN [admin@GW] > /ip/firewall/filter add chain=forward action=accept in-interface=vlan10-staff dst-address=10.10.30.10 protocol=tcp dst-port=80,443,554 comment="staff to NVR" # "CCTV: no internet" needs no rule — no NAT + final drop does it. Belt AND braces: [admin@GW] > /ip/firewall/filter add chain=forward action=drop in-interface=vlan30-cctv out-interface-list=WAN comment="cctv never phones home" # The wall [admin@GW] > /ip/firewall/filter add chain=forward action=drop comment="drop all else"
The guest drop rule blocks guest→LAN traffic, but the router itself is reached via the input chain — a guest can still hit 10.10.10.1 (staff gateway = same router!) for DNS or WinBox unless input is scoped too. In the input chain, accept DNS only in-interface=vlan20-guest dst-address=10.10.20.1, and management only from MGMT. A guest VLAN that can WinBox the router through the staff-side address is the most common hole we find in "segmented" hotel networks — the forward chain was perfect and nobody thought about input.
05
Two SSIDs on every AP: Hotel-Guest lands in VLAN 20, Hotel-Staff in VLAN 10, over the same trunk cable. Then PCQ makes forty guests share the uplink like adults.
# The AP's bridge is VLAN-aware like the switch; its uplink is a trunk. # Each SSID gets a vlan-id — frames are tagged before they hit the wire: [admin@AP-1] > /interface/wifi add name=wifi-guest master-interface=wifi1 configuration.ssid="Hotel-Guest" security.passphrase="summer-in-crete" datapath.bridge=bridge1 datapath.vlan-id=20 disabled=no [admin@AP-1] > /interface/wifi add name=wifi-staff master-interface=wifi1 configuration.ssid="Hotel-Staff" security.passphrase="********" datapath.bridge=bridge1 datapath.vlan-id=10 disabled=no # AP mgmt IP on vlan99, same pattern as the switch. Repeat on AP-2 — # same SSIDs, same passphrases, so devices roam between wings.
# Every guest gets an equal share; one torrenter can no longer eat the hotel [admin@GW] > /queue/type add name=pcq-down kind=pcq pcq-classifier=dst-address pcq-rate=20M [admin@GW] > /queue/type add name=pcq-up kind=pcq pcq-classifier=src-address pcq-rate=10M [admin@GW] > /queue/simple add name=guest-fairness target=10.10.20.0/24 max-limit=300M/300M queue=pcq-up/pcq-down # CRITICAL: exempt guests from fasttrack or this queue sees nothing — # scope the fasttrack rule exactly as the firewall post's Option B.
06
This checklist is literally what we run before a property goes live. A network that hasn't failed in front of you will fail in front of guests.
| Test | Pass condition |
|---|---|
| Guest SSID → DHCP | Address from 10.10.20.x, internet works, speedtest shaped by PCQ. |
| Guest → 10.10.10.0/24, .30.x, .99.x | All dead; guest-drop counters increment while you try. |
| Guest → 10.10.10.1 (WinBox/DNS) | Dead — the input-chain hole from section 04 is closed. |
| Staff → NVR :443/:554 | Works; staff → a camera IP directly does not. |
| Camera → 8.8.8.8 | Dead. /ip/firewall/filter print stats shows "cctv never phones home" counting. |
| Two laptops on guest, both speedtesting | Each gets ~half the guest pool — PCQ fairness visible. |
Drill 1 — pull the fibre. Continuous ping from a guest device; the recursive routes fail over to Starlink within seconds, and because NAT masquerades on the WAN list, established connections re-form without touching config. Plug back in, watch it fail back.
Drill 2 — reboot the switch. Everything drops (single core — that's the honest trade-off of this design tier), and everything must return by itself within two minutes: DHCP leases renew, APs re-tag SSIDs, cameras reconnect to the NVR. Anything that needs a human after a power blip is a configuration bug — find it now, not after the next island brownout.
Drill 3 — evil guest. From the guest VLAN run an aggressive scan (nmap -A 10.10.0.0/16 from your laptop). Watch it find nothing but the guest gateway IP, and watch the drop counters climb. Save that scan output — it's the segmentation evidence for the owner, in a form even a non-technical client understands.
Takeaways
NOCTIS builds exactly this network for hotels and villas across Crete — segmentation with evidence, guest Wi-Fi that stays fair in high season, cameras that can't phone home, and failover we prove by pulling the fibre in front of you.
Book a Discovery Call →