Lab: putting IoT devices on their own VLAN or guest network

Aim and what you need

The aim is segmentation: putting IoT devices in their own network so a weak device cannot be used to attack the rest. You can do it the simple way, with your router's guest Wi-Fi, or properly, with a VLAN (virtual LAN) and firewall rules.

• Option A: a home router with guest Wi-Fi and a setting that stops guests reaching the local network.
• Option B: a VLAN-capable router or firewall, a managed switch and an access point that can map an SSID to a VLAN. Cisco Packet Tracer or GNS3 works for practice with the commands below.
• Example plan: VLAN 10 trusted 192.168.10.0/24, VLAN 30 IoT 192.168.30.0/24.

Steps

Option A: create a guest SSID with WPA2 or WPA3 and a strong passphrase, enable client isolation and disable access to the local network, then move each smart device onto it. This is enough for many homes.

Option B, shown in Cisco IOS syntax (other vendors use the same ideas):

1. Create the VLANs on the switch, put IoT ports in VLAN 30 and make the uplink a trunk.
2. Create a router subinterface per VLAN (router on a stick) and a DHCP pool for the IoT VLAN.
3. Write an ACL applied inbound on the IoT subinterface: allow DNS and replies to trusted devices, block new connections to the trusted VLAN, allow the internet.
4. Map your IoT SSID to VLAN 30 on the access point and reconnect devices.

! switch
vlan 10
 name TRUSTED
vlan 30
 name IOT
interface range gi0/5 - 8
 switchport mode access
 switchport access vlan 30
interface gi0/1
 switchport mode trunk
 switchport trunk allowed vlan 10,30

! router
interface gi0/0.10
 encapsulation dot1Q 10
 ip address 192.168.10.1 255.255.255.0
interface gi0/0.30
 encapsulation dot1Q 30
 ip address 192.168.30.1 255.255.255.0
 ip access-group IOT-IN in
ip dhcp excluded-address 192.168.30.1 192.168.30.9
ip dhcp pool IOT
 network 192.168.30.0 255.255.255.0
 default-router 192.168.30.1
 dns-server 192.168.30.1
ip access-list extended IOT-IN
 permit udp 192.168.30.0 0.0.0.255 host 192.168.30.1 eq domain
 permit tcp 192.168.30.0 0.0.0.255 192.168.10.0 0.0.0.255 established
 deny ip 192.168.30.0 0.0.0.255 192.168.10.0 0.0.0.255 log
 permit ip 192.168.30.0 0.0.0.255 any

This simple ACL only lets TCP replies back. A stateful firewall (zone-based firewall, pfSense, OPNsense or a business router) handles replies for UDP and other protocols properly, so prefer one for real use.

How to verify and troubleshoot

An IoT device should get a 192.168.30.x address and reach the internet. From a laptop in VLAN 10 you should still be able to open the device's app or web page. From a test machine plugged into an IoT port, ping 192.168.10.20 and a connection to a laptop share should fail, and show access-lists IOT-IN should show matches growing on the deny line. Use show vlan brief, show interfaces trunk and show ip dhcp binding to check the build.

• Device gets no address: VLAN not allowed on the trunk, wrong access VLAN, or DHCP pool missing.
• App cannot find the device: discovery uses mDNS or SSDP multicast, which does not cross VLANs. Use an mDNS reflector on the firewall carefully, or control the device through its cloud app.
• No DNS: the router needs ip dns server or point DHCP at another resolver.

Clean-up and next steps

This build is meant to stay, so document it: VLAN IDs, subnets, SSIDs and rule purposes (see documenting a network). In a lab, reload the saved startup config or erase it with write erase and reload. Next, watch what your devices actually send in the IoT traffic lab, and tighten the last permit line to only the destinations they need.