UniFi Setup from Scratch Part 3 – Setting Up VLANs and Firewall Rules
Today on the hookup I’m going to show you how to create the most secure smart home network possible by creating VLANs and firewall rules to separate your IoT and NoT devices from the rest of your network. This is part 3, the final part of my Ultimate Smart Home Network Series… here we go.
In part 1 of this series I showed you how to pick the right networking hardware for your needs and price point. In part 2 I showed you how to set up your new equipment, migrate from your old network, and start dividing your network by device type. Today I’m going to walk you through creating VLANs and firewall rules to make sure your network is as safe and secure as possible without limiting functionality.
At this point if you’ve been following along with this video series you should have a fully functioning home network with multiple SSIDs being broadcast for your different device types. So far all of your devices are on a single subnet and can all communicate with each other, which is not great since a single compromised IoT device could allow a hacker to setup a tunnel into your home network. To segregate your network by device type we are going to setup virtual local area networks or VLANS. You can think of each VLAN as a completely separate network with a different router, a different switch, and different access points. By default, one VLAN can’t access another VLAN any more than you can access your neighbors home network from your own. The advantage of a VLAN is of course that you don’t have to actually have separate equipment, since the separation is going to happen via software. The other advantage is that we can easily set up different firewall rules to allow only specific traffic to be able to cross VLANs since cutting your IoT devices off from your network completely will disable some of their most useful features.
To setup our first VLAN we’re going to click on settings -> network, and click on “create new network”. I’m going to call this network IoT, select “corporate” for the purpose, select LAN as the network group, assign it to vLAN 20, and I’m going to change the IP range for this group to 192.168.20.1/24, you don’t need to have the vLAN number match the subnet, but it makes it easier for me to remember. Press Update DHCP range, click the box that says enable IGMP snooping, hit save and you’re all done with that network.
We’re going to repeat these same steps for our NoT VLAN, hit “create new network” call it NoT, select “corporate”, leave LAN as the network group, and this one I’m going to set to VLAN 30 and make my subnet 192.168.30.1/24, hit update DHCP range, enable IGMP snooping, and press save.
That covers the VLANs for NoT and IoT devices, but I have one more device type on my network: My PoE IP Security cameras. These devices don’t need to talk to anyone or anything. Basically, each camera produces a video stream called RTSP and if you want to see that video stream you connect to the camera directly, but the camera doesn’t need to contact any other device, except for NTP requests to synchronize time, which we’re going to allow everything on our network to do. I originally had my IP cameras on another vLAN as well, but I noticed some degradation in the quality of the stream when doing so. I did some research, and wasn’t able to find any definitive answers as to why it was occurring, but there was speculation that some of the hardware offloading that allows the USG to be such a high throughput router cannot be used across vLANs, and since 9 video streams ranging from 2 to 6 megapixels represents quite a bit of data it could cause some slowdowns. I’ll show you how I regulate their traffic when we setup firewall rules, but I’m not going to set up a separate vLAN for them.
So now you’ve got different VLANs, what’s the point? Firewall rules is the point. We’re going to be able to manage the exact traffic that is allowed to travel across VLANS by writing different rules for the internal firewall. Go to settings, routing and firewall, and then click on firewall on the top. You’ll see lots of different areas where we can apply firewall rules, but the most efficient place to regulate traffic is at the front door of the router before any resources are wasted on determining a route. The tab titled “LAN In” corresponds to that front door, so that’s where we’ll create our rules.
Basically when we set up rules they are processed from the top down, so if the traffic is allowed to pass based on a rule that is higher up on the list, it will not then be subsequently blocked by a rule that is lower on the list. To make things easier on myself I always make more specific rules for allowing traffic, and broad rules for dropping traffic, then I put all the allow rules at the top and the drop rules at the bottom.
The first rules we need to create are the ones that will apply to all of the IP addresses on your network, and one of the most important ones is a rule to allow established and related sessions. This is a common rule that exists on all routers at the WAN level, which is what allows a website or service to talk back to your computer if you establish the initial connection. Since we’re going to be blocking the other networks from communicating from the LAN later on, we need to establish a rule to let them answer if talked to.
To do this click on LAN IN, then click on “create new rule”. I always name my rules with whether they are accepting or dropping, so I’m going to call this one “Allow all established and related sessions” select “accept”, then under advanced click on “Established” and “Related”, and then for source we’ll need to create a group that contains all possible IP addresses on all the VLANs, so for me that’s 192.168.86.0/24, 192.168.30.0/24 and 192.168.20.0/24.
I’ll call the group “All Local IP Addresses”, then select that group for both source and destination.
I also want to allow all the devices on the network to send NTP or time synchronization requests. These requests go out on port 123, so I’m going to create a rule called “Accept all NTP requests”, select “accept”, and under source I’ll select “All Local IP Addresses”, and under destination I’m going to create a port group called “NTP” that only contains port 123. There are other options for taking care of this NTP problem like creating custom DNS entries to redirect traffic to a local NTP server, or doing fancy routing to trick the NTP traffic, but this solution is plenty secure for now.
Next lets configure your NoT firewall rules. For me, my NoT needs to be able to communicate via MQTT with my MQTT server, so I’m going to make a rule called Allow NoT to MQTT, select accept, then under source I’ll select the NoT network, then under destination select address/port group, and I’ll add a new group under ip addresses that I’ll call Home Assistant with my specific home assistant server IP address since that is where my MQTT server lives, and under port group I’ll add a new group called MQTT ports that will contain the two common MQTT ports which are 1883 for non secure MQTT and 8883 for secure MQTT.
The next accept rule that I need is one to allow my IoT network to access Home Assistant, or specifically my node red server. I only need this rule because I use the Alexa Local node to configure all my echo voice commands. If you don’t use Alexa local, you probably don’t need this rule. Anyways, I’ll call it “Allow IoT to Home Assistant”, select accept, then for source select your IoT network, and for destination I’m going to put in the IP address of my Home assistant virtual machine. I could enter this as a singular IP address, but I like to use groups instead, and I already have this group defined from my previous rule.
These are basic accept rules that will probably apply to your smart home, but you may need have other ones as well based on your specific devices. For instance, chromecast uses ports 8008, 8009, 5556, 5558, and 5353 when advertising and casting. So for me I needed to add an allow firewall rule to allow my IoT network to communicate on those ports. If you wanted to further limit the rule you could create a group that only contained your chromecast devices to use as the source instead of using the entire IoT network.
If you notice something on your network that doesn’t function after imposing firewall rules you can generally figure out which ports they need for their services with a quick google search.
Alright, that does it for our accept rules, now its time to start blocking traffic.
Our IoT network isn’t allowed to talk to the LAN or the NoT network so we’ll make a rule called “Block IoT from LAN”, select drop, then under source select the IoT network and under destination select your LAN network. Repeat the exact same process to block IoT from NoT.
Next we’ll create the rules to block the NoT. Remember, the NoT only needs to communicate with the MQTT server, which we’ve already accepted, so all that’s left is to drop the rest of the traffic. Create a rule called “Block All NoT” and select drop, then for source select the NoT network, and for destination we’re going to create a group that contains every possible ipv4 address, so call it “All IP Addresses” and start with 0.0.0.0/1, then 220.127.116.11/2, then 192.0.0.0/3, and last 18.104.22.168/4
As I mentioned earlier, IP cameras don’t need to communicate at all, except for time synchronization to an NTP server which is already allowed by one of our first rules. And again, the reason I didn’t put the cameras on a VLAN is that there seemed to be a performance drop when routing that much data constantly over across the VLAN, so instead I’m going to create an IP address group called Cameras, and add in each of my cameras IP addresses manually. Then I’ll create a rule called “Block All Cameras”, select drop, and for source I’ll select the Cameras IP group and for destination select that All IP Addresses group.
If you ever need to edit these groups later on you can do it under “routing & firewall”, firewall, then groups.
Since we specified this group based on specific IP addresses we need to make sure that the IP addresses of these cameras won’t change, so if you haven’t already done so you should go to clients then select each camera and click on the gear, then network and turn on the “use fixed IP” toggle. It will autofill the current IP address of the device, but you can also specify another IP address in this area if you’d like.
The last thing that we need to allow in order for our smart home devices to function as expected is enable multicast DNS or mDNS. Basically these devices will advertise their IP address and their services to all of the other devices on that VLAN. This is required for things like device discovery on amazon echo devices, and chromecast streaming. Multicast traffic can cause significant slowdowns on a network since even a small amount of multicast data takes a relatively long time to process in each access point. We already enabled IGMP snooping to try to control some of this multicast data, but in a smart home multicast is a necessary evil.
In order to allow mDNS is we need to turn off a feature under our site settings. So go to settings then site, and turn off the setting that says “auto optimize network and wireless performance”. We need to do this because disabling mDNS will certainly increase wireless performance, but it’s also going to stop your devices from working.
Now that all of our rules are in place we can force our devices onto their respective VLANS. To do this for our wireless devices we’ll go to settings, then wireless networks and first select your IoT SSID and click edit. Under advanced options we’re going to click on “use VLAN” and select VLAN 20 since that’s what we assigned to our IoT network earlier. Make sure the button for block LAN to WLAN multicast and broadcast data is unchecked. Also down at the bottom check the enable multicast enhancement button, this is the 2nd step to allowing your UniFi equipment to optimize that multicast data so it doesn’t slow down your network too much.
Repeat this process for your NoT network, assign it to VLAN 30, make sure the LAN to WLAN multicast button is unchecked, and enable multicast enhancement.
While we’re at it, I got a great suggestion to eliminate some unnecessary SSID broadcasting by disabling the 5ghz NoT SSIDs since none of my NoT devices are capable of 5ghz. Do this by clicking devices, then APs, then select an AP and click the gear. Under WLANs select the 5ghz NoT network and toggle the enabled on this AP switch. Hit queue changes then apply.
After your APs provision and your wireless networks come back up should have a theoretically functioning network, but many of your IoT devices may not function well. The problem is that those mDNS broadcasts cannot cross VLANs by default. So what we need to do is repeat those mDNS broadcasts across all the different vLANS. Luckily the unifi controller makes it pretty easy. All we need to do is go to settings, services, then mDNS and turn on multicast DNS. This, along with the unchecked box for blocking multicast lets devices broadcast their IP addresses across all VLANS which should allow them to function properly, and the IMGP snooping should take those multicast requests and send them only to the devices that need to hear them, which lowers the effect on your network performance. It’s worth noting here that even though these devices are advertising their IP addresses, it doesn’t mean that they will be reachable because they will still have to obey the firewall rules that we setup earlier.
Now that your settings are all in place it’s a good idea to go through and test your most use smart home integrations to make sure they are still working in order to not lose too much of the wife approval factor.
Setting up a network like this isn’t cheap, and it’s not quick, but it is orders of magnitude more secure than letting all of your IoT devices from various manufacturers comingle with your trusted devices. If you follow along with this video your network should be fully functional and very secure, but I’ve only scratched the surface of what is possible with this equipment.
In future videos I’ll cover VPNs, presence detection, custom DNS and other advanced functionality, but you don’t need to wait for me, there are plenty of other youtubers making great networking content, two of my personal favorites are Chris from crosstalk solutions and Willie Howe, you should check them out. Remember that I’m not a network administrator by trade, and while I did consult with professionals while I was making this video I’m not claiming that what I have setup is the only way, or even the best way. If you have something to add, or I got something wrong, please let me know down in the comments. If you’re interested in buying any of the equipment that I used in this video series please consider using my Amazon affiliate links in the description, it doesn’t cost you anything extra but I get a few percent of the profit.
Thank you to all of my awesome patrons over at patreon for your continued support of my channel, if you’re interested in supporting my channel please check out the links in the description. If you enjoyed this video and you’d like to see more like it please consider subscribing, and as always, thanks for watching the hookup.
🔥Amazon US Links🔥
UniFi PoE Switches:
16 Port 150W PoE: https://amzn.to/2WizmUp
8 Port 150W PoE: https://amzn.to/2WNhs05
8 Port 60W PoE: https://amzn.to/2WbNBKA
UniFi Access Points:
Unifi Cloud Key Gen2+: https://amzn.to/2WlKx3o
Google WiFi: https://amzn.to/2IkSPP5
🔥Amazon UK Links🔥
UniFi PoE Switches:
16 Port 150W PoE: https://amzn.to/2Ksk1hF
8 Port 150W PoE: https://amzn.to/2KqXcuJ
8 Port 60W PoE: https://amzn.to/2EUKxwm
UniFi Access Points:
Unifi Cloud Key Gen2+: https://amzn.to/2KqKsnW
Google WiFi: https://amzn.to/2KtV8lM
Follow me on Twitter: @TheHookUp1
Support my channel:
Tesla Refferal Code: https://www.tesla.com/referral/robert37264
Music by www.BenSound.com