Configuring VLANs with UniFi for IoT devices

Not all devices on my network are created equal. I place differing levels of trust in things depending on the security maturity and resources of the organisations behind them. Yet if I place them all on my network then by default they’re all peers. I don’t really want to treat IoT lightbulbs as equally deserving of trust as my primary computers and mobile devices. But I also want to be able to communicate with them for control purposes and I don’t want to set up alternate networking hardware just to support these less trustworthy devices. It’s at this point my rather excessive amount of Ubiquiti UniFi hardware becomes useful.

I already have a guest WiFi network that I can grant access to that does not have any access to anything else on my network. This is an out of the box feature of UniFi and straightforward to set up but it won’t give me the kind of one way access to devices I’m looking for. We can accomplish that by utilising the VLAN capability of UniFi gear plus some appropriate firewall rules.


The first thing to do is work out how you want to divide your devices. The more divisions you have the more complicated your firewall rules will get. I initially tried having complicated VLANs and it was extremely painful for relatively little value. As such for your personal devices I would suggest starting with two networks:

I’m also working from home right now1 using my work supplied laptop. For security and privacy reasons I don’t want this laptop to be able to communicate with any of my other devices. This is not because I think my employer is likely to use it to look around my network but to protect both my systems from a compromise of work systems and work systems from a compromise of mine. It will also reduce the likelihood that I accidentally commingle personal and work data. I have therefore set up a third VLAN called Work that is firewalled in both directions and has external Internet access only. This VLAN is assigned to the switch port to which the laptop is connected2.

Trusted devices

The list of devices that I’m placing in the trusted VLAN is a function of my threat model3 and limitations of what I’m using. I’m also taking a deliberately simple initial approach which I can expand on later so any issues are easier to troubleshoot.

The most obvious devices for this category are my personal laptop, desktop and mobile devices. These are all kept current with security updates and contain most of my critical personal data. I’m already trusting them.

I’m also including my other Apple hardware. These run on the same OS platform as the devices above so the incremental risk is small. I’ve also found that HomePods in particular have real problems when devices on a single Apple account are on different WiFi networks in the same location4.

Trusted for now

In my initial rollout I’ve got a number of devices that might get their own VLANs in future but are not currently sufficiently a concern to warrant that:

Untrusted devices

UniFi hardware

This setup relies on having a UniFi device that will perform the routing and firewall duties. This means a UniFi Security Gateway (UDG) or UniFi Dream Machine (UDM). A UDM also means you will not need a separate device to run the controller software and contains an inbuilt switch (that is sadly not PoE). If you use a USG you will need a Cloud Key and UniFi switch. Which models of UniFi WiFi APs are suitable for your usage is a topic for a blog post in itself6.

UniFi configuration

This assumes a basic level of understanding of the UniFi controller UI. Before starting work out how you’re going to recover if you accidentally completely break your network configuration7. Follow these instructions at your own risk.

VLAN setup

The first things to do is work out the IP subnets to be associated with each VLAN. These need to be in the ranges defined by RFC 1918. The trusted and IoT subnets should not overlap so traffic can be routed between them. The Work VLAN can be anything but I’ve made it also not overlap. The subnets I’ve assigned8 are:

As I don’t particularly feel like grappling with IPv6 firewalls and routing right now I’ve not configured the IoT or Work VLANs to support IPv6.

We also need VLAN IDs for the IoT and Work VLANs (LAN will use the default). I picked 20 and 30 respectively, any valid VLAN ID other than 1 should work.

Where you find the VLAN configuration depends on whether you’re using the new Settings UI or the Classic mode in the UniFi controller. I will be assuming the new UI but the Classic mode isn’t terribly dissimilar.

Find the Local Networks setting under Networks in Settings. You’ll first want to edit the existing LAN network to change the subnet. This is entered with the Gateway IP and subnet as a single setting (hence the above where the gateway IP is and the subnet is a /17). You can use the Auto Configure option to assign the DHCP range. The other settings can be left as their defaults.

You’ll then want to create two new networks. Create New Network will give the option of creating a Standard or Advanced network; select Advanced.

Property IoT Work
Name IoT Work
Network Purpose Corporate Corporate
Network Group LAN LAN
VLAN ID 20 30
Network Size Custom Small LAN (253 Clients)9
Gateway IP / Subnet
DHCP Range Start
DHCP Range End
Domain Name iot work
Enable IGMP Snooping On Off

The other settings can be left with the default values.


Under Gateway locate the mDNS item. Ensure Enable Mulitcast DNS is on.


Under Gateway locate the UPNP item. Ensure Enable UPNP is on. Also ensure that it is on for the LAN and IoT networks. It is not necessary for the Work network unless you are doing work things that require UPNP.


These firewall rules allow connections from the LAN network into the IoT network. Packets that are associated with connections originating from the LAN network can move from IoT to LAN. This will work for any IoT device which does not need to initiate connections to devices in your trusted network. If you have such a device then this configuration will not be suitable for you. Connections between Work and the other VLANs are not permitted.

The firewall rules are located under Internet Security in the cunningly named Firewall section. We will be adding a number of LAN In rules that preceed the existing rules. Select the LAN tab to filter down to LAN rules only10.

If you do this wrong you can entirely break your internet access so tread carefully. If you already have custom rules applying this list is probably unwise.

First let’s create two Groups. The first is for the NTP port so we can always allow devices to connect to the Internet to get the time. This is not strictly necessary with the configuration here that does not restrict outgoing access but is useful for future adaptions. Create the group with the name NTP Port as a Port Group containing port 123. The create a group called Local Networks IPv4 as an IPv4 Address/Subnet group. If you’re using the ranges above you can assign this the address, otherwise add the subnet or subnets that cover the LAN and IoT networks.

Then create the following rules. All rules should have a type of LAN In (this is easy to forget as it’s not the default) and use Before Predefined Rules as the Rule Applied value. They should appear in this order in the list with incrementing rule IDs.

Description Action Source Destination Advanced
All established/related Allow Address/Port Group Any/Any Address/Port Group Any/Any Match State Established and Match State Related
Accept all NTP requests IPv4 Allow Address/Port Group Local Networks IPv4/Any Address/Port Group Any/NTP Port
Drop invalid Drop Address/Port Group Any/Any Address/Port Group Any/Any Match State Invalid
IoT to LAN drop Drop Network IoT Network LAN
LAN allow Allow Network LAN Address/Port Group Any/Any Match State New, Match State Established and Match State Related
IoT allow Allow Network IoT Address/Port Group Any/Any Match State New, Match State Established and Match State Related
Work to Local deny Drop Network Work Local Networks IPv4/Any
Local to Work deny Drop Local Networks IPv4/Any Network Work
Work allow Allow Network Work Address/Port Group Any/Any
LAN deny Drop Address/Port Group Any/Any Network LAN Match State New

I’m fairly confident this list can be improved upon so think the rules through rather than just applying them verbatim.

Before you go any further check that everything on your network still has internet access. This rule set should not stop the default VLAN from working. Note that changes may take a couple of minutes to apply.

Assigning the VLAN to things

Now you have some VLANs let’s make use of them. There are two ways to do so, depending on whether your device has a wired or wireless connection11.

For wired devices find the switch it is attached to in Devices. Select the port it’s connected to12 and select edit (the pencil icon). There is a drop down marked Switch Port Profile. Select the IoT or Work network as appropriate and apply your changes. Verify that things continue to work as expected.

For WiFi connected devices first create a new WiFi network in Wi-Fi Networks under Wi-Fi. Select the Advanced option. Assign whatever name you want as the SSID of your IoT WiFi network. You can use the security defaults and assign a (strong) password. Enable Use a VLAN and set the VLAN ID to the ID you gave the IoT network (20 if using the values in the table above). Use the defaults for the other values. Reconfigure your IoT devices to use this WiFi network. They will automatically be on the IoT VLAN.

If things break

Curse the networking gods and leave technology behind forever.

  1. There’s a global pandemic on ↩︎

  2. I’m a big fan of using wired networking whenever possible ↩︎

  3. I’m not protecting anything of significant value. I’m unlikely to be specifically targeted by malicious groups. ↩︎

  4. They’ll do things like have one speaker from a pair change network and stop working. It’s incredibly aggravating. ↩︎

  5. From UX to privacy to security smart TVs as a category are just terrible. Where’s my high quality dumb panel with a large number of HDMI inputs? ↩︎

  6. Someone has probably already written one, I’m not going to. ↩︎

  7. I leave this as an exercise for the reader. ↩︎

  8. Somewhat arbitrarily ↩︎

  9. Setting this will cause the UI to put in defaults for Gateway IP / Subnet and the DHCP range that are fine for this usage. ↩︎

  10. The new UI doesn’t seem to have an option to filter to LAN In rules only. ↩︎

  11. Wired is best, obviously. But impractical or inconvenient for many devices. ↩︎

  12. Before tracing cables see if you can work this out from the Clients view. ↩︎