Smart home devices are constantly targeted by attackers, and their manufacturers do not always pay enough attention to security. In this post, I will explain how to protect your home network from similar incidents and prevent a compromised IoT device from becoming an entry point into your local infrastructure.

Introduction

Smart home devices are increasingly becoming part of our daily life – thermostats, lighting, smart sockets, cameras, speakers, alarms, and more. They’re convenient, but at the same time they represent potential entry points for attackers into your local network.

To avoid unwanted consequences, it’s important to separate your core devices from IoT devices using virtual networks. Network isolation for smart home devices is no longer just a recommendation – it is a necessity.

We’ve already seen real incidents: from the Mirai botnet that turned millions of cameras and routers into tools for massive DDoS attacks, to vulnerabilities in Wi-Fi printers and Bluetooth speakers that allowed attackers to infiltrate users’ local networks. Often the real danger comes not from the device itself, but from its cloud service: if the cloud backend is compromised, an attacker can gain access to every device connected to it – and through it, to your home network.

The reason is simple: cheap or uncertified gadgets often lack proper encryption, and cloud providers don’t always follow strict security standards. As a result, a device that appears harmless can become a “bridge” between the internet and your personal data.

Determining Device Interactions

In my case, the device in question was the Terneo SX thermostat, which controls my underfloor heating system and also acts as a trigger for monitoring electrical consumption in my Telegram electricity monitoring bot – I described the thermostat’s role in detail in a previous article.

After the Terneo cloud service experienced an outage, I decided to completely isolate this device so that even if it were compromised, it would not be able to “see” any of my other devices in the network.

To better understand how virtual networks and devices inside them interact, I visualized the following scheme:

The thermostat runs on its own subnet, has access to the Internet, and communicates with my Raspberry Pi exclusively via the ICMP protocol.

Network Isolation

To implement the scheme described above, I had to complete the following steps:

• Create a firewall zone
• Create a VLAN
• Create an SSID
• Create a firewall rule

All of my network equipment belongs to the Ubiquiti UniFi ecosystem. To begin, I logged in to the UniFi Network Application, where all necessary configuration takes place in the Settings menu.

Creating a Firewall Zone

A key detail about Ubiquiti routing: all networks are assigned to the Internal zone by default. To isolate an IoT segment, you must create a dedicated zone – for example, IoT Zone – and apply inter-zone filtering policies.

To create your own zone:

1. Go to Policy Engine
2. Click Create Zone
3. Enter the zone name in the right-hand menu
4. Save the changes

Now you can create a new virtual network and assign it to the newly created zone.

Creating a VLAN

The list of existing virtual networks – and the option to create new ones – is found in the Network section. To create a new VLAN, click New Virtual Network, fill in the required fields, and adjust a few default parameters:

• Name: Thermostat
• Router / Gateway: Gateway Lite (leave unchanged)
• Zone: IoT (select the zone we created earlier)
• Host Address & Netmask: 192.168.89.30/29 in my case
• Advanced: Manual
• VLAN ID: Assigned automatically; mine was 2, but you may set your own
• Isolate Network: Enabled
• Allow Internet Access: Enabled
• DNS Server: Disable default and set public DNS (e.g., 8.8.8.8)
• Ping Conflict Detection: Optional (I enabled it)

Other parameters can remain untouched.

Visually, the basic settings look like this:

Creating an SSID

Since the thermostat works wirelessly via Wi-Fi, it is necessary to create a separate new Wi-Fi wireless network name for it. In the WiFi section, click the Create New link and fill in the appropriate fields. As in the previous example, I will skip the parameters that are displayed by default and which I will not edit.

I edited only the necessary settings:

• Name: IoT
• Password: A strong password for connecting the thermostat
• Network: Thermostat (the VLAN created earlier)
• Broadcasting APs: All (I have only one access point)
• Advanced: Manual
• Enhanced IoT Connectivity: Enabled – this optimizes settings for smart devices
• Client Device Isolation: Enabled (important – isolates IoT devices from each other)
• Multicast Enhancement: Enabled

Other parameters can stay unchanged.

Visually, the basic settings look like this:

Creating a Firewall Rule

The last and very important setting is to create a firewall rule. In the Policy Engine section at the bottom of the page, under the rules table, there will be a Create Policy link to create a new rule.

In the opened sidebar, you need to give the rule a name, define the source and recipient of traffic, specify ports, protocols. I made the following settings:

• Name: IoT access
• Source Zone: Internal (Raspberry Pi and main devices belong to this zone)
• Device: Rpi (restricting traffic origin to my Raspberry Pi)
• Action: Auto Allow Return Traffic (so the thermostat can reply to pings)
• Destination Zone: IoT (our dedicated zone)
• IP: 192.168.89.29 (the thermostat’s static IP)
• Protocol: ICMP (required for ping)
• Syslog Logging: Enabled

After creating this network and firewall rule, UniFi automatically added three related entries to the firewall table.

As a result, the thermostat works in its own VLAN, has access only to the internet, and interacts with my Raspberry Pi exclusively via ICMP.

Result Verification

As expected, after configuring the isolation, any attempt to ping the thermostat at 192.168.89.29 from the main network results in a timeout. This confirms that no direct route remains between VLANs and that the firewall blocks all traffic directed toward the IoT zone.

ping 192.168.89.29

Pinging 192.168.89.29 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 192.168.89.29:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

At the same time, the Raspberry Pi is explicitly allowed in the firewall, so it can communicate with the thermostat for energy monitoring purposes:

ping 192.168.89.29
PING 192.168.89.29 (192.168.89.29) 56(84) bytes of data.
64 bytes from 192.168.89.29: icmp_seq=1 ttl=254 time=10.3 ms
64 bytes from 192.168.89.29: icmp_seq=2 ttl=254 time=3.19 ms
64 bytes from 192.168.89.29: icmp_seq=3 ttl=254 time=7.20 ms
64 bytes from 192.168.89.29: icmp_seq=4 ttl=254 time=1.85 ms
^C
--- 192.168.89.29 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 1.848/5.629/10.281/3.330 ms

There is an important nuance regarding Ubiquiti equipment: automatically generated rules such as Isolated Networks or IoT access (Return) cannot be edited, and – most importantly – they do not support logging. This means that even though the firewall is blocking inter-VLAN traffic, these events will not appear in Flow, Events, or system logs.

In practice, the result is exactly what I intended: the thermostat is fully isolated from the main network, communicates only with the permitted device, and all other access attempts are blocked by the firewall. This ensures that even if the cloud service or the thermostat itself is compromised, only the IoT zone is exposed – not the entire home network.

Conclusion

Smart home security starts not with passwords, but with network architecture.
Use certified devices, keep firmware updated, and always isolate IoT devices into their own VLAN. For Ubiquiti users, this is straightforward: a few VLANs, a dedicated SSID, and well-structured firewall rules – and your smart devices remain safe even if their cloud services experience outages or compromises.