Segmenting the Home Network: A Budget Mikrotik Build with VLANs, IoT Isolation, and (Eventually) Real Fast Roaming

The problem

Two-storey house, roughly 160m² per floor, single ISP router (Vodafone) sitting at one end of the building. WiFi at the far end, on either floor, was barely usable. The obvious fix – a mesh kit – didn’t sit well with me for two reasons: no VLAN support on consumer mesh gear, and I wanted actual control over the network, not a black box that “just works” until it doesn’t.

Budget was a real constraint too. This wasn’t a “buy whatever’s best” project, it was “what’s the most capable setup I can build for not much money.”

Requirements

• Full WiFi coverage across both floors, no dead zones
• Proper network segmentation: a trusted LAN, an isolated IoT VLAN (home automation is a notoriously soft attack surface), a fully sandboxed guest network, and a separate management plane for administering the infrastructure itself
• Everything routed through a firewall I actually control, not the ISP’s black-box router
• Internal DNS resolution for my own domain, plus ad-blocking via AdGuard Home
• All of it needed to survive and cooperate with an existing Proxmox cluster, Home Assistant, and a growing pile of IoT devices from at least four different ecosystems (Tuya, Sonoff/eWeLink, Tapo, and a solar/heat-pump vendor or two)

Hardware

• 2x Mikrotik hAP ac2 (RBD52G-5HacD2HnD-TC) – one at each end of the house
• 1x TP-Link TL-SG108E – cheap 8-port “Easy Smart” switch with 802.1Q support

Total spend: well under €250. The hAP ac2 was chosen specifically because it’s a full RouterOS device – router, firewall, VLAN-aware bridge, and dual-band AP in one box – rather than a dumb access point that would’ve needed a separate router behind it.

Network design

Four VLANs, each carved out of a /23 instead of the usual /24, mostly so I’d never have to think about address exhaustion again:

VLAN	Purpose	Subnet
10	Management / link network	10.10.10.0/23
20	Trusted LAN	10.10.20.0/23
30	IoT	10.10.30.0/23
40	Guest	10.10.40.0/23

Topology:

Vodafone router (192.168.1.0/24)
        │
     ether1
   [AP01 — hAP ac2]  ── gateway, firewall, NAT, DHCP, DNS
   ether2 │      │ ether3
          │      └── trunk (native VLAN10) ── TL-SG108E switch
       trunk
          │ ether1
   [AP02 — hAP ac2]  ── pure access point, no routing
   ether2 └── wired IoT device (camera)

The Vodafone router can’t be bridged, so this runs as double NAT: the hAP ac2 gets a DHCP lease from the ISP router on its WAN port and NATs everything behind it again. Not elegant, but invisible in practice, and it means I never have to touch the ISP’s configuration at all.

Firewall logic

The segmentation only matters if it’s actually enforced:

• Management VLAN: full admin access, reachable from the trusted LAN too (no reason to lock myself out of Winbox/SSH from my own laptop)
• LAN → IoT: allowed (Home Assistant needs to reach devices)
• IoT → LAN / management: blocked outright
• Guest: isolated from everything except the internet, with client-to-client isolation enabled on the wireless interface itself so two guest devices can’t see each other either

One non-obvious wrinkle: the switch’s own management interface doesn’t tag its traffic, even with 802.1Q active on its other ports. So the uplink port between AP01 and the switch is a hybrid trunk: VLANs 20/30/40 tagged, VLAN 10 native/untagged, purely so the switch itself can have a management IP on the same VLAN as everything else.

DNS

Rather than pointing every VLAN’s DHCP scope directly at an internal DNS server (which would’ve meant punching new firewall holes across VLAN boundaries), every VLAN’s DHCP hands out the router itself as the DNS server, and the router does the indirection:

/ip dns static add type=FWD forward-to=10.10.20.53 match-subdomain=yes name=hferreira.loc

Anything under my internal domain gets forwarded to a local DNS container; everything else goes upstream. Guest bypasses the router’s resolver entirely and points straight at public DNS, so it never even sees internal names. AdGuard Home (running as a Home Assistant add-on) sits in the same chain as the upstream resolver for everyone except guest, which turned out to be the cleanest way to get ad-blocking network-wide without touching every device’s DNS settings individually.

Things that didn’t go as planned

Worth writing down, mostly for my future self:

• WPA3 isn’t supported by the hAP ac2’s default driver. The legacy wireless package on this chipset (IPQ4019) simply doesn’t implement it, trying to create a WPA2/WPA3 mixed security profile fails silently on that specific line, with everything else in the script still applying.
• RouterOS 7’s device-mode blocks the scheduler by default on consumer-oriented boards. Needed an explicit mode=advanced switch, confirmed physically (button press or power cycle) by design, specifically so this can’t be done remotely by an attacker.
• /interface wireless print‘s R flag lied to me for the better part of an afternoon. A radio that was, in fact, running perfectly fine as an AP showed up without the “running” flag, which sent me down a multi-hour rabbit hole of firmware upgrades and factory resets chasing a hardware fault that didn’t exist. /interface wireless monitor turned out to be the only reliable source of truth. Lesson: don’t trust a summary flag when a detailed status command is one call away.
• Sticky client roaming is real, and it’s not a config bug, it’s a driver limitation. Standalone AP mode without 802.11k/v/r means the client decides when to switch access points, and most devices are lazy about it. There’s no software fix for this on the legacy wireless stack.

What’s next

That last point is the interesting one. Since RouterOS 7.13, the hAP ac2 can actually run an alternative driver package, wifi-qcom-ac, that brings it up to feature parity with newer WiFi 6 hardware in terms of protocol support: WPA3, OWE, 802.11w, and, critically, 802.11r/k/v fast roaming, managed centrally via the new CAPsMAN.

It’s not a toggle, it’s a full package swap (uninstall wireless, install wifi-qcom-ac, reboot) followed by rebuilding the wireless configuration from scratch in a new syntax, with one router acting as the CAPsMAN controller and the other joining as a managed CAP. VLAN assignment on this older chipset still has to be done by hand at the bridge level rather than automatically via the controller, which is the one place the “AC” driver falls short of its WiFi 6 sibling.

Same hardware, no new spend, genuinely better roaming behaviour. Write-up on that migration once it’s done and I’ve had a chance to break it a few more times first.