How to put IoT devices on a separate VLAN at home or in a small office

Every article about securing connected devices, including the device security basics on this site, ends with the same advice: put them on their own network. This one is about doing it. The mechanism is a VLAN, the equipment is a router and an access point that support them, and the work is an evening with a laptop and a notebook for writing down what each device needs.

What a VLAN does for IoT devices

A VLAN, a virtual LAN (standardized by the IEEE as 802.1Q), is a way of running several separate networks over one set of switches and cables. Each VLAN has a number. Traffic on one VLAN cannot reach another except by going through a router, and the router can apply firewall rules at that crossing. That is the property you want: IoT devices on one VLAN, everything else on another, and a set of rules at the router that decides who may talk to whom.

Compared with a guest network, a VLAN gives you control over the rules. Most guest networks are all-or-nothing: the guest devices are isolated from each other and from the main network, full stop. That breaks the thing you want, which is for your phone to reach the devices while the devices cannot reach your phone. A VLAN with one-way firewall rules gives exactly that.

What you need

Three pieces of equipment have to understand VLANs.

A router that can create VLAN interfaces and apply firewall rules between them. Many consumer routers cannot. Small-business routers, most open-source router firmware, and the prosumer brands can. If your internet provider’s box cannot, the usual answer is to put it in bridge or modem mode and place a capable router behind it.

An access point that can broadcast more than one Wi-Fi network and tag each one to a VLAN; most smart devices join only the 2.4 GHz band, so the IoT network needs it switched on. Again, many all-in-one consumer units cannot; most standalone access points can. If your router and access point are one unit, it needs to do both jobs.

A managed switch, if you have wired devices that need to be on different VLANs. A managed switch lets you say which VLAN each port belongs to, and which ports carry several VLANs at once (a trunk). If all your wired devices are on the main network and all your IoT devices are wireless, an unmanaged switch on the main VLAN is enough.

You also need an hour to write down every device, which network it should be on, and what it needs to reach. That list is what the firewall rules are built from.

Set up the IoT VLAN and its Wi-Fi network

The order that avoids locking yourself out is: build the new VLAN alongside the old network, move devices across one at a time, and tighten the rules last.

1. Create the VLAN on the router. Give it a number (20 is a common choice, with the main network as 1 or 10), its own subnet, and a DHCP server so devices on it receive addresses. Leave the firewall open between VLANs for now.
2. Carry the VLAN to the access point. The cable between router and access point becomes a trunk that carries both VLANs, tagged. On a managed switch in between, set that port as a trunk too. On the access point, create a second Wi-Fi network, give it a name and a password different from the main one, and tag it with the IoT VLAN number.
3. Assign wired ports. For any wired IoT device (a printer, a hub, a camera), set its switch port to the IoT VLAN, untagged, so the device does not need to know VLANs exist.
4. Move devices across. Reconnect each wireless device to the new Wi-Fi network. This is the tedious part, because most devices need to be re-paired through their app. Do the easy ones first and confirm each works before moving to the next.
5. Confirm addresses. Every moved device should now have an address in the IoT subnet. Check the router’s DHCP lease list and write the addresses down; you will refer to them in the rules.

Set DHCP reservations for the devices that need fixed addresses, such as a hub your controller talks to, so that firewall rules keyed to an address keep working.

Write the firewall rules

Firewall rules are evaluated in order, and a stateful firewall remembers connections: if a rule allows a connection to start in one direction, replies flow back automatically. That is what makes one-way access possible.

The rules, on the router, from the top:

• Allow the main VLAN to reach the IoT VLAN. Your phone and your controller can open connections to any device. Replies come back through the stateful firewall without a separate rule.
• Allow the IoT VLAN to reach a local controller on the main VLAN, if you have one, on the ports it uses. This is the one deliberate hole. Some people move the controller onto the IoT VLAN instead, which avoids the hole and is a reasonable choice if the controller’s own security is good.
• Allow the IoT VLAN to reach DNS and DHCP on the router. Without this the devices cannot get addresses or resolve names.
• Block the IoT VLAN from reaching the main VLAN and any other private range. This is the rule that contains a compromised device. Put it after the allows above.
• Allow the IoT VLAN to reach the internet, either fully, or per device for a stricter setup. The strict version starts by blocking everything, watches the firewall log for a day, and adds an allow for each destination a device genuinely needs. Devices that need nothing get nothing.

Turn on logging for the block rules for the first week. The log tells you which device is trying to reach what, which is also a useful audit of what the devices were doing before you fenced them in.

Handle discovery across VLANs

The one thing that breaks when devices move to their own network is discovery. Many devices announce themselves using multicast DNS, and phone apps find them by listening for those announcements. Multicast does not cross a router, so the app on your main VLAN stops seeing the devices on the IoT VLAN.

The fix is a multicast DNS repeater, sometimes called an mDNS reflector or a bonjour gateway, which most capable routers offer as an option. It listens on both VLANs and repeats the announcements from one to the other. Enable it for the two VLANs and the apps find their devices again. Some ecosystems, Matter among them, use other discovery protocols alongside it; a similar relay exists for the common ones, and if a device is still invisible, adding it by its IP address in the app usually works.

Two things to remember. A repeater only carries the announcements; the actual connection still has to be allowed by the firewall rules, which it is if the main VLAN can reach the IoT VLAN. And devices that discover each other, such as a hub and its satellites, should be on the same VLAN so they never need the repeater.

Test that the isolation works

A rule that has not been tested does not exist. Do three checks with a laptop on each network.

From the main VLAN, open the device’s web page or app and confirm you can reach it. That proves the allow rule and the discovery repeater.

From the IoT VLAN, using a laptop connected to the IoT Wi-Fi, try to reach a computer on the main VLAN: ping its address, try its file share, open its web page. All of it should fail. Try to reach the router’s admin page from the IoT VLAN; that should fail too, unless you deliberately allowed it.

From the IoT VLAN, check the internet access matches what you intended, and look at the firewall log for blocked attempts from devices. Anything unexpected in the log is either a device that needs an allow rule or a device doing something you did not know about.

Repeat the second test after every router firmware update. Firewall rule handling is a place where updates occasionally change behavior, and the whole point of this setup is that the block holds when you are not watching.