2026-03-20 4 min read updated 2026-06-07 ~/blog

IoT isolation: a separate segment for smart devices without breaking smart home

IoT isolation: a separate segment for smart devices without breaking smart home

IoT devices are convenient, but they should not be trusted like a work laptop. Cameras, bulbs, plugs, TVs, and appliances are often updated rarely, actively talk to cloud services, and may have a weak security model.

The goal of IoT isolation is to separate these devices from LAN and Management without breaking required smart-home scenarios.

Where this fits in the overall architecture

Guest VLAN already gave us an “internet only” model. IoT is similar to Guest because it should not initiate access to LAN/Management, but it differs because LAN sometimes needs to access IoT: Home Assistant, printers, media devices, local APIs.

That is why IoT policy is usually not as simple as Guest policy.

Baseline policy

FlowDecision
IoT -> Internetallow or limited
IoT -> DNS/DHCPallow to approved services
IoT -> LANdeny by default
IoT -> Managementdeny
LAN -> IoTallow only required services
Home Assistant -> IoTallow by list
IoT -> Serverdeny except explicit exceptions

The main principle: IoT does not initiate access to trusted segments.

Before applying anything

Before changing VLAN/firewall/Wi-Fi:

/system backup save name=before-iot-isolation
/export file=before-iot-isolation
/system console safe-mode

First inventory devices: IP/MAC, purpose, cloud/local mode, required ports, and whether multicast/mDNS is needed.

IoT VLAN and DHCP

Example:

/interface vlan
add name=vlan40-iot interface=br-core vlan-id=40

/ip address
add address=10.10.40.1/24 interface=vlan40-iot comment="IoT gateway"

/ip pool
add name=pool-iot ranges=10.10.40.100-10.10.40.199

/ip dhcp-server
add name=dhcp-iot interface=vlan40-iot address-pool=pool-iot lease-time=1d disabled=no

/ip dhcp-server network
add address=10.10.40.0/24 gateway=10.10.40.1 dns-server=10.10.40.1

Static leases are useful for important IoT devices: firewall rules are easier to write against address-lists or stable IPs.

Wi-Fi for IoT

The IoT SSID should map to the IoT VLAN:

SSID: Home-IoT
VLAN ID: 40
Security: WPA2/WPA3 according to device compatibility
Client isolation: enable if devices should not talk to each other

Some old devices work poorly with WPA3, band steering, or modern roaming features. That is not a reason to put them in LAN; make a separate IoT SSID with compatible settings and a strict firewall policy.

Firewall

Input:

/ip firewall filter
add chain=input action=accept in-interface-list=IOT protocol=udp dst-port=53 comment="iot: allow DNS UDP"
add chain=input action=accept in-interface-list=IOT protocol=tcp dst-port=53 comment="iot: allow DNS TCP"
add chain=input action=accept in-interface-list=IOT protocol=udp dst-port=67 comment="iot: allow DHCP"
add chain=input action=drop in-interface-list=IOT comment="iot: block router management"

Forward:

/ip firewall filter
add chain=forward action=accept in-interface-list=IOT out-interface-list=WAN comment="iot: allow internet"
add chain=forward action=accept src-address=<home-assistant-ip> dst-address-list=iot-devices comment="lan: allow HA to IoT"
add chain=forward action=drop in-interface-list=IOT out-interface-list=!WAN log=yes log-prefix="drop-iot" comment="iot: block internal"

The Home Assistant rule is an example. It is better to explicitly list devices and services than to allow all LAN -> IoT without need.

Address-lists

Address-lists help maintain policy:

/ip firewall address-list
add list=iot-devices address=<iot-device-ip> comment="living room TV"
add list=iot-controllers address=<home-assistant-ip> comment="Home Assistant"

After that, the firewall can be read as policy instead of a set of random IP addresses.

mDNS and discovery

Many smart-home scenarios depend on mDNS/SSDP/broadcast discovery. This does not work automatically between VLANs. Do not try to solve it with a broad allow between LAN and IoT.

There will be a separate article about mDNS and service discovery. Here the important point is: routed access and multicast discovery are different tasks.

How to verify the result

Checks:

  • an IoT device receives an IP from the IoT subnet;
  • internet works if allowed;
  • IoT cannot open LAN/MGMT addresses;
  • LAN or Home Assistant sees only allowed IoT services;
  • DNS/DHCP work;
  • logs show blocked IoT -> internal attempts.

Commands:

/ip dhcp-server lease print where server=dhcp-iot
/ip firewall address-list print
/ip firewall filter print stats
/log print

Common mistakes

Creating an IoT VLAN but allowing IoT -> LAN fully.

Putting Home Assistant into IoT and losing control over the trust boundary.

Assuming mDNS will work between VLANs by itself.

Allowing IoT to management because “it is easier to configure”.

Security notes

The IoT segment should be untrusted. If a device requires full LAN access for basic operation, reconsider the device or scenario.

A separate VLAN does not protect anything if the firewall allows everything. A separate firewall rule does not help if all devices remain in one LAN.

Short takeaway

IoT isolation is a compromise between security and functionality. IoT should not initiate access to LAN/Management, while trusted segments receive only the required exceptions.

The next article is about mDNS and service discovery between VLANs.