Separating IoT and Smart-Home Devices with Sophos XG

“Put IoT devices in their own VLAN” is good advice, but it is only the beginning. A smart home is a distributed system: sensors, gateways, brokers, controllers, user interfaces, DNS, and mobile clients still need carefully selected communication.

Split by behavior, not by marketing label

I distinguished several roles:

• untrusted or cloud-oriented IoT appliances;
• home-automation field devices and gateways;
• central services such as MQTT and Zigbee2MQTT;
• HomeMatic control components;
• trusted clients used to administer or operate the system;
• media devices with their own discovery requirements.

Not every “smart” device belongs in the same trust domain. A television that needs streaming services behaves differently from a sensor that publishes to a local MQTT broker.

Place central services deliberately

The MQTT broker is a useful example. If devices across several networks connect to it, its location affects many rules.

Putting it in a core-services network provides a clear pattern:

• IoT or home-automation devices may initiate MQTT to the broker;
• Zigbee2MQTT may reach the broker and its adapter as required;
• administration clients may reach the broker’s management interface;
• the broker does not receive broad access back into every client VLAN.

The same principle applies to DNS, HomeMatic services, and automation platforms: centrality should not imply unrestricted reachability.

Write a flow matrix

Before creating rules, I list the required flows:

The actual MQTT ports and TLS policy depend on the installation. The important point is to use a named service object that reflects the deployed configuration.

Default deny between device networks

IoT devices normally do not need to initiate connections to Office, management, hypervisor, or NAS networks. Begin with no cross-VLAN permission and add only observed, documented requirements.

Internet access can also be narrower than Any. Some devices need vendor clouds; others operate locally and only require DNS and NTP. Logging an initial restricted rule can show what a device attempts before broadening access.

Discovery is the awkward part

Many consumer ecosystems assume a flat LAN and use multicast or broadcast discovery. Routed VLAN boundaries intentionally stop ordinary broadcasts. Symptoms include an app failing to discover a device even though direct unicast access works.

Possible responses are:

• configure the application with a fixed device address;
• use supported DNS-based discovery;
• deploy an appropriate multicast reflector or relay;
• place tightly coupled components in the same VLAN;
• decide that the convenience is not worth weakening the boundary.

Do not immediately add a broad inter-VLAN allow rule. First identify whether the failure is discovery, name resolution, routing, or application traffic.

Wi-Fi SSIDs must complete the path

An IoT SSID mapped to VLAN 30 works only if:

1. the access point tags the client traffic with VLAN 30;
2. the AP’s switch port carries VLAN 30;
3. the switch trunk to Sophos carries VLAN 30;
4. Sophos has the VLAN 30 interface and DHCP configuration;
5. firewall and NAT rules permit the intended flows.

The AP management traffic may belong to a different VLAN. That separation is desirable and must also be configured end to end.

Stable addresses for service endpoints

Controllers, brokers, and gateways benefit from stable addresses through static configuration or DHCP reservations. Firewall objects should point to stable destinations, and DNS names should resolve consistently from the client networks that use them.

Avoid embedding a large number of raw addresses in rules. Named objects such as HOST_MQTT or HOST_HOMEMATIC make future changes safer.

Test from the device’s perspective

For each class, verify:

• it receives the intended DHCP configuration;
• it resolves required names;
• it reaches only the required broker or controller services;
• cloud connectivity works only if intended;
• it cannot open management interfaces;
• user applications can operate devices through the intended path;
• discovery behavior is understood rather than accidental.

The result is not absolute isolation. It is constrained, explainable communication—the practical goal of segmentation.