At this point, the conversation shouldn't be about keeping your IoT devices off the internet, because the security aspects of that have been debated to bits, but about how to do so securely. The best option here is to put your smart home on its own VLAN, which solves a multitude of problems but leaves you with one glaring one. How exactly do you connect to your IoT devices to give them commands now that they're on another subnet, while keeping both networks safe? There's no one best option here, but there are several methods to connect to those untrustworthy IoT devices to make your smart home run as intended, and I'll go over them now.
Why are we putting IoT devices on their own VLAN?
Your smart home is not to be trusted
Your IoT devices deserve their own network segment. Okay, let me rephrase that. The rest of your network devices deserve for you to put IoT devices on their own VLAN or subnet. It's not just a security thing, although that's probably the primary consideration since most IoT devices have the security of an unlocked door, but there are other reasons. Think of how many IoT devices you have, then think about how much of your Wi-Fi airtime will be taken up by those chatty devices — especially security cameras, which love to send out broadcast packets to everything.
So, now we've got our IoT devices segregated on their own VLAN with an associated SSID. Now what? How do we control those from our smartphones now that they're no longer on the same network or have internet access? What things do we need to connect securely without allowing those IoT devices to communicate and cause trouble? The first thing anyone would think of is some good firewall rules, and that's as good a place to start as any.
Time for some firewall rules
The tried and tested ways never fail
I've been using OPNsense for my home lab, and the combination of quality routing and stateful firewall means it's relatively simple to put IoT devices on a VLAN and then allow careful rules to let specific devices communicate with the home network. We have a few aims in mind. The IoT VLAN should be reachable from the main VLAN so that responses can be sent back for control purposes. There should be a wireless SSID on the IoT VLAN to which only IoT devices connect. The IoT VLAN should never be able to initiate traffic to the primary VLAN or reach the internet (although that one can be allowed when you want updates).
Now, the exact wording of these rules will change depending on which firewall appliance you are using. How you approach them will change, as while most firewalls start with deny by default for inter-VLAN traffic, Unifi sets up access by default, so you'll be flipping your rules for that ecosystem. But the general ideas are the same:
- LAN IN rule from IoT if we initiate from another VLAN
- Block IoT LAN to main LAN
- Allow trusted devices like Home Assistant OS through the firewall to the main LAN
- Enable IGMP proxy
Along with those considerations, the number of open ports for hosts on the IoT VLAN should be limited. Setting static IPs for the IoT devices makes managing them easier and removes reliance on broadcast traffic. And don't forget to tag access and trunk ports as necessary for the VLANs, so they can't communicate with other network segments.
Or we could do it with a clever workaround
Home Assistant can talk over two interfaces, bridging the VLANs but not letting traffic past
There is one way of bridging those VLANs without actually bridging them, and that's using Home Assistant OS. Now there's a trick to getting this method working, and it involves running HAOS on a host that has two network interfaces to use. This could be running it in a VM with two virtual adapters, or two physical NICs if you have a suitably equipped PC or mini PC.
Then you set one interface to the IP range of the IoT VLAN, with only an IP address and no gateway set. Then you set the other network interface to the VLAN your home network uses, and set that as normal with a gateway. You might need to set the server_host variable in Home Assistant to the IP of the subnet on the user VLAN, which makes it listen for commands from that subnet and no other. Then you use Home Assistant from your phone or computer or wherever as normal.
Having one foot on each subnet, so to speak, means Home Assistant can accept commands, and then send them out over the other network interface. You might also need to set manual static IP addresses for some devices in HAOS, but that's a small amount of setup, and means you don't have to worry about firewall rules because there's no path for the IoT VLAN to get onto an internet-connected subnet.
There's an even quicker way
I've written about using an old router for a dedicated IoT network before, but that includes having that router connected to the internet through a second router, so that things can get updates and Chromecasts or other internet-greedy devices can connect. You don't need to do that. I mean, you can, but the simplest way to get your IoT network away from your main network is to grab an old router, set the SSID so the IoT devices connect, and connect it to your Home Assistant server.
And here's the trick — don't plug the WAN port in. You can happily leave that router off the internet, and the IoT devices will work as intended. Well, maybe some will throw some grumpy messages in their individual apps, but you're using Home Assistant and that app is like a honey badger, it doesn't care. Your IoT devices will be controllable, and won't be touching your network or being able to dial home.
The best way to connect your IoT device on another VLAN depends on your network needs
IoT devices are inherently untrustworthy, even if they're a lot better than they used to be. However you want to keep them off your main network is fine, but it is advisable to do so. You can use firewall rules and a VLAN to keep them separated, or straddle two VLANs with Home Assistant, or avoid having to worry by using an internal only network that doesn't have internet access at all. Either way, keeping them off your network is good for security, airtime fairness, and reducing chatter that will interfere with other networking use.