Updated on 12/13/2020
I have been toying around with the idea of creating separate VLANs for IOT devices. With the growth of IOT devices, it seems prudent to me to create some logical separation of broadcast domains as many of these devices are very “talkative” utilizing protocols like mDNS and flooding the network with multicast traffic. Many times VLANs are utilized to reduce the size of broadcast domains and ensure more reliable bandwidth when there are a large number of devices on the network. However, there is additional value when paired with a good firewall and the ability to further restrict VLAN to VLAN traffic. My goals in this effort are as follows:
- Reduce the broadcast traffic on my main network
- Logically segment and firewall the traffic between VLANs and in/out of my network
- Ensure my IOT devices are unable to negatively impact my primary network
Every time I see an article similar to this one posted, I always see negative comments about the futility of the efforts from a security perspective. Understand that I comprehend the methods that could be employed by a hacker to navigate my home network even with VLAN segmentation. The focus of this article is not so much security, but network performance.
OSI Layers 3 & 4 – Firewall
I am currently running an OPNsense open source firewall which is extremely powerful. My firewall provides the standard SOHO features like DHCP, NAT, and a packet filter firewall. It also provides some nonstandard features such as remote syslog, netflow, IPS, and NTP services. OPNsense is based on the BSD packet filter firewall. The firewall is a critical piece of my setup since it will host the DNS services and DHCP services for all of my networks. It will also be monitoring each interface (physical and virtual) with Suricata running in IPS mode to block any potentially offensive traffic.
OSI Layer 2 – Switching infrastructure
For my switching infrastructure, I chose to install a new TPLink T1500G-8T. This is an 8 port gigabit ethernet SMB fully managed switch. One of the things I like the most is that the OS is very similar to Cisco, which helps me as I have spent years working with Cisco devices. If you are comfortable working in the Cisco IOS, then this device will be easy to pick up at the CLI, or you can simply use the web GUI to make any necessary modifications. The switch offers a number of business-class features such as MAC-based VLANs (which I utilize here), protocol-based VLANs, and auto-voice VLAN. The only layer 3 feature available on this particular switch is the DHCP repeater.
I also own two TPLink TL-SG1016DE switches. These are higher priced consumer grade smart-managed switches with 16 gigabit ethernet ports. These switches has more limited layer 2 feature sets that are a perfect fit for most people on a simple home network. I opted for the T1500G-8T simply because I wanted to be able to isolate some of my wireless devices onto separate VLANs simply by MAC address. This is something the consumer grade switches cannot do. However, the TL-SG1016DE switches do support 802.1Q VLANs. So, I have configured each of the switches with trunk ports that can share all of the VLANs I am creating for my network.
I have a number of varying devices on my home network. This is actually the reason for this particular home lab activity. As I continue to add devices to the network, especially smart devices or IOT (Internet of Things) devices, I see more and more broadcast and multicast traffic on my network. I am using a mixture of small business class and consumer grade switches which host devices such as IP cameras, smart TVs, Amazon Echo devices, a smart thermostat, etc. The devices that seem to generate the most traffic on the network are those that support video streaming. Most of those devices support the Bonjour service or some flavor of mDNS. There are constant streams of messages which relay information about the devices on the network and the services they offer.
There are a number of ways to slice up the broadcast domains and limit some of the traffic. I have been considering delineation by device type, device manufacturer, video/voice/server/workstation, and many other possibilities. At this time, I have landed on the decision to separate the networks by service offered. So, I will be segmenting my workstations, laptops, and phones from other devices such as printers, servers, etc. I have also created a VLAN for voice and for video. I am also configuring the firewall and switch to utilize QoS to ensure that each VLAN’s traffic is treated respective to the services offered. In most home networks, possibly including mine, there is a small chance of overwhelming the switch and causing the need for QoS, but it never hurts to go the extra mile and ensure the switching infrastructure understands the priority of the traffic in the same way I do.
The first thing to understand as you start this process is that VLANs are a OSI layer 2 functionality. I mention that because I began this journey mistakenly assuming that I could do what I wanted without upgrading my switches. To even consider creating VLANs on your network, you will need to have one or more switches that are VLAN (802.1Q) aware. When it comes to consumer grade switches, do not assume that all of them support VLANs. There are many that not only are missing the options to configure VLANs, but may not properly pass through VLAN traffic either.
Once you have the proper switching devices, you can configure your VLANs. For me, this was a multi-step process. First, I had to create the VLAN on the switch. This usually consists of setting a VLAN ID and assigning the ports that will carry the VLAN traffic. A key piece to consider here is which ports will require tagging. Typically, you will tag VLAN traffic between infrastructure devices. For instance, if I have an access port with a computer attached, I will not tag that port. If I have a port from one switch that uplinks to another switch on which I expect to have VLAN traffic passing, I will tag the port with the associated VLANs. Access ports are typically not tagged and therefore associated to the default, or native, VLAN.
As you can see in the image above, I configured my VLANs on the T1500G-8T first. I have ended up with more VLANs, but this serves the purpose of visualizing the configuration. I associated the VLANs to all of my interfaces, but I only tag the ports between switches (my trunk ports). I leave the rest of the interfaces untagged. The reason I associated the VLANs with all interfaces is because I am using MAC-based VLANs. My wireless AP is on interface G-1/0/1, but I have some wired devices plugged into the switches that I might also want to assign to VLANs using MAC-based VLAN configuration.
Here, you can see where I am only tagging the traffic to 3 interfaces. Those interfaces are my firewall connections and my switch in the basement that eventually will feed into a 3rd switch in my bedroom/office. Those are the only ports that I need to be configured for tagging.
On the OPNsense side of the configuration, I simply added a new interface on the firewall. I used a USB 3.0 Gigabit Ethernet adapter that I had purchased off Amazon a while back for another project. The device was automatically detected by the OS and the driver was loaded for me. All I had to do was create a new VLAN by going to Interfaces->Other Types->VLANs in the menu and following the prompts. I based the VLAN on the physical interface I had just installed in the previous step.
The next step is to configure DHCP service on the new interface. In the menu, under services, there is an option for DHCP. Under that item, I now have a new interface on which I can configure DHCP services for my VLAN. That is pretty standard and not really any different than setting up your initial LAN upon a new installation, so I will not cover those steps in this post.
Keep in mind that OPNsense sets up some basic rules for your LAN during your firewall install, but these are not replicated as you add new virtual interfaces. You will need to copy those rules over and modify them accordingly. A newly created VLAN has no firewall rules in place, so it will be a default deny, except for the DHCP rules which OPNsense does create for you to allow for devices on the VLAN to pull an IP address. Hopefully you are also using some of the other DHCP options to ensure your users get the correct gateway, NTP server, etc.
As I work through these details and make any necessary changes, I will update this post and share any valuable information that may help others seeking to tackle the same objective. I look forward to any advice my readers have and your comments below. I expect this to be a fun experiment and it should be well documented as this is not a new idea. I know many people are currently looking for ideas on how to segment traffic from IOT devices with all of the security concerns that have been noted in many articles on the web in recent years.