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.
Partitioning
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:
- LAN The default network for trusted devices.
- IoT Everything you want to connect that you don’t really trust. IoT lightbulbs, smart TVs, and all the random devices that want to be online. We’ll also create a separate WiFi network for these attached to the IoT VLAN so anything that connects to it is automatically segregated.
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:
- My Sonos sound system. All my Sonos speakers have wired connections and their wireless networking disabled.
- My NAS
- A Google Home mini and Chromecast. Almost entirely used so I can turn off the TV without knowing where the remote is.
- Games consoles. Regularly updated by companies looking to stop copyright infringement. An easy future reconfiguration.
Untrusted devices
- Lights. This is not a category with a great security track record.
- IoT weather system. Cloud based but no need to access internal resources.
- Allegedly smart TV5. Not normally on the network but shouldn’t be trusted when connected for updates.
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:
- LAN 192.168.1.1/17 (This involved dividing the existing range in half as this network already existed)
- IoT 192.168.128.1/17
- Work 172.16.6.1/24 (The UniFi UI picked this when I selected a network size of Small)
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 92.168.1.1/17
above where the gateway IP is 192.168.1.1
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 | 192.168.128.1/17 | 172.16.6.1/24 | ||
DHCP Range Start | 192.168.128.41 | 172.16.6.6 | ||
DHCP Range End | 192.168.255.254 | 172.16.6.254 | ||
Domain Name | iot | work | ||
Enable IGMP Snooping | On | Off |
The other settings can be left with the default values.
mDNS
Under Gateway
locate the mDNS
item. Ensure Enable Mulitcast DNS
is on.
UPNP
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.
Firewall
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 192.168.0.0/16
, 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.
-
There’s a global pandemic on ↩︎
-
I’m a big fan of using wired networking whenever possible ↩︎
-
I’m not protecting anything of significant value. I’m unlikely to be specifically targeted by malicious groups. ↩︎
-
They’ll do things like have one speaker from a pair change network and stop working. It’s incredibly aggravating. ↩︎
-
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? ↩︎
-
Someone has probably already written one, I’m not going to. ↩︎
-
I leave this as an exercise for the reader. ↩︎
-
Somewhat arbitrarily ↩︎
-
Setting this will cause the UI to put in defaults for Gateway IP / Subnet and the DHCP range that are fine for this usage. ↩︎
-
The new UI doesn’t seem to have an option to filter to
LAN In
rules only. ↩︎ -
Wired is best, obviously. But impractical or inconvenient for many devices. ↩︎
-
Before tracing cables see if you can work this out from the
Clients
view. ↩︎