Also consumers often just use the router their ISP provided.
Suppose your router does not have VLAN support, and you do not wish to replace it. Can you add sufficient VLAN support to your network by adding switches with VLAN support?
TP-Link has a couple of switches (TL-SG105E and TL-SG108E) [1] that are not full managed switches but do more than common unmanaged switches. They are priced about the same as unmanaged switches. I got the 8 port model for $30.
These switches have some VLAN capability, although I haven't looked into what it can do. (I got it for its port mirroring ability, not its VLAN ability).
If you are using your ISP's router/WiFi access point, and your IoT devices use WiFi then I'd guess there is not much you could do with switch-based VLANs. The Hue bulbs, though, talk to a Zigbee hub that you plug into your ethernet, so you can make all the Hue traffic go through a switch.
Another problem is that nearly all the documentation I've found on using VLANs gets real "enterprisey" real fast. For even fairly sophisticated home users it is probably really confusing, and so even if they have a router with good VLAN support they might not be able to figure out how to use it.
I think the easiest -- but not the best, of course -- ro separate these for the average home user/consumer would be to just "daisy chain" two standard consumer routers.
The first plugs into your "Internet modem/router". Connect all of your "untrusted" devices to it. Your second router also connects to the first, just like the other devices do. Your "trusted" devices will connect to this second router.
Your "trusted" devices (PCs, laptops, tablets, etc.) will be subject to double NAT and, of course, NAT is not a security feature but this second router will provide a bit of separation between your trusted and untrusted devices by way of NAT and stateful firewalling, just as it would protect your internal network if it were connected directly to your upstream ISP's network.
Again, this isn't ideal but it would work for the average home user and it eliminates the need to deal with/learn about VLANs or buy special hardware that supports them.
This VM that I'm typing in is behind at least eight NAT routers. There's the pfSense perimeter router, and at least one router between that and the ISP. And then there are three pfSense VPN-gateway VMs, each with NAT by the VPN server, and local NAT to a VBox internal network.
Those switches only work with a router that actually creates the vLANs. I use one with pfSense, running on a small box with a used Intel server NIC. So I have a mix of LANs and vLANs to keep stuff more or less isolated. If I want WiFi, I just stick an Alfa AP on one.
In any case, you're counting on the router to keep one LAN/vLAN isolated from the others.
Consumer routers do have this feature, but usually it's software-limited to single additional VLAN and called "guest network". It would be trivial to add an option for dedicated "IOT network".
Even the cheapest $20 routers are actually quite capable in terms of hardware, supporting at least 16 VLANs.
Except that many IOT devices require you to be in the broadcast domain for control and discovery....
e.g. with LIFX wifi light bulbs, you can control them with low latency (and no internet connection) via ip packets; or high latency via LIFX's cloud servers if you're not in the same subnet.
Are they using broadcast packets, or is it multicast and enabling multicast routing on your home network fixes the problem (you might need a mangle rule to bump up the TTL)
Sorry - AP manufacturers are already too busy adding RGB leds, GPU vendor branding, Gaming Acceleration and other bullshit "value" adding features that can justify a three-digit price tag instead of coming up with something useful.
Industrial equipment has this idea of a “fieldbus” that you put the manufacturer’s devices on and then have some kind of hub or controller that you completely own between it and the internet (if you decide to connect it.) I spent 4 years working for a company that makes these and it’s (IMO) the correct way to do this.
X10 had this sort of architecture, maybe if everyone started using Bluetooth or USB you could do something similar.
I’ve shopped a few times for consumer computer controlled lighting and it’s all crap (just like any consumer electronics niche) that needs to be put on a WiFi network and use the manufacture’s app (and often network services.)
If you want IOT either do it yourself or get industrial stuff.
Some of the consumer stuff can be controlled with reverse engineered protocols. I've got some TP-LINK bulbs, configured and controlled entirely with Free software. They're on an isolated network with no Internet access, of course.
DIY seems eminently possible with ESP32 etc, but mains power means I'd rather buy something off the shelf from a longstanding brand.
I doubt this will move the needle for consumer manufactures to embrace it, but it works right now (and is more responsive than X10). We're all cyber-gleaners until (hopefully) the market demands open standards.
I use unifi switches, access points etc. they may be a bit higher end than the cheapest consumer gear but they are still marketed towards home use (as well as businesses).
I have four vlans - adults, kids, IOT and guests. Only the adults vlan has unfiltered access, the others are pretty heavily locked down.
The IoT stuff also needs to communicate with other trusted machines (so that they can be controlled, e.g. turning on/off the lights or watching the videos from the cameras); putting them all on a vLAN would prevent that from working, too.
Just set firewall policy to allow new / existing connections from your trusted machine to your untrusted ones and only existing connections from your untrusted machines to your trusted one.
Granted, an average user will not be able to figure out how to do this and a standard private VLAN guest network is going to prevent this from working.
yes, and it's a pain because the protocols and ports required are usually undocumented. so it's a lot of trial and error (like getting an appleTV talking to a tradfri gateway across the vlan boundary).
It's pitiful.