A practical way to isolate cameras, lights, irrigation controllers and other IoT devices from laptops, NAS shares and admin interfaces, without inventing a vendor-specific firewall recipe. It sits alongside the existing camera and VLAN discussion in t=154.
Complexity
Moderate if your router already supports VLANs. Advanced if you are introducing a managed switch for the first time.
1. Why a separate network
Many IoT devices receive infrequent firmware updates, run services you did not ask for, and do not need to see your files or your workstation. The Australian Signals Directorate / Australian Cyber Security Centre publishes guidance on network segmentation and segregation and on limiting what a compromised device can reach. That publication is written for organisations, not a home lab, but the same idea — separate trust zones, control the flows between them, and reduce how far a compromise can travel — scales down to a home or small commercial site: put untrusted or purpose-built devices on their own VLAN, and only allow the flows you can name.
2. A simple three-bucket design
Exact subnet numbers are yours to choose. The buckets matter more than the addresses:
- Trusted / workstations. Laptops, phones you use for admin, and maybe a Home Assistant or NVR host if you treat that host as trusted. This is where you SSH, open router UI, and browse file shares.
- IoT / controllers. Lights, IR blasters, irrigation, HVAC Wi-Fi adapters, voice speakers if you use them, and similar. Default: they can reach the internet only if they must, and they cannot initiate connections into the trusted VLAN.
- Cameras / security. Often a third VLAN, because camera firmware and ONVIF/RTSP exposure deserve tighter treatment (see the camera / VLAN thread and the ONVIF 2026 refresh in CCTV).
3. Firewall policy in words, not a vendor CLI
Write the policy first, then implement it on whatever router or firewall you actually own. A cautious default:
- IoT cannot initiate to trusted (no SMB, no SSH, no router admin, no NAS).
- Trusted can initiate to IoT for administration (Home Assistant talking to a light, a browser talking to an inverter on a reserved IP).
- IoT can use DNS and NTP, preferably to resolvers you control.
- Internet access from IoT is an allow-list or a temporary permit, not "any any". Vendor cloud dependencies (Hydrawise, MELCloud, some camera apps) may force a hole — document it.
- Modbus TCP, installer web UIs and similar unauthenticated services must not be port-forwarded. Official Home Assistant Modbus docs are explicit that Modbus TCP has no authentication or encryption.
- Management of the firewall itself only from the trusted network, preferably not from the IoT SSID.
4. Home Assistant placement
Home Assistant needs to reach devices on the IoT and camera VLANs (discovery, MQTT, ONVIF, vendor APIs). That usually means the HA host is either trunked to those VLANs, or the firewall allows the HA host to initiate into them. It does not mean every IoT device should be able to reach the HA supervisor, add-on ports or backups. Pair this with the Home Assistant day-two thread in Getting Started with Home Assistant.
5. Wireless notes
- Separate SSIDs (or one SSID with VLAN assignment) for trusted and IoT.
- Do not share the IoT PSK on a sticker on the router.
- Isolating clients from each other on the IoT SSID can help, but it also breaks device-to-device features — test Matter/Thread, Cast and similar before you lock it down.
ASD/ACSC: network segmentation and segregation (overview, 17 September 2026)
Home Assistant Modbus (unauthenticated TCP warning)
Existing VLAN / camera discussion
Researched from official documentation on 15 November 2026 (Australia/Sydney). This is a planning and how-to guide, not a claim that the exact hardware combination was assembled and tested on a live site. Please correct anything that has moved on.