An Update to the VLAN Situation10 min read


A few days ago I wrote an article about adding VLANs to my home network in order to segment off my IoT devices. I’m very happy to say that this worked, but it led to me discovering some new problems I wasn’t aware of. Today I’m going to document those problems, explain the problem, and talk about how fixed them. This list will be in reverse order of less important to most important.  

The Problems: 

  1. Guest and IoT were on the same Subnet:

This was an issue I had thought about before setting up my VLANs the way I did, but it was something I didn’t have a great solution for.  In the example, I provided a few days ago all of the guest devices and IoT devices would be placed on the same subnet. This certainly wasn’t the ideal situation as it could lead to compromises on the IoT device spreading to guest devices.  This would obviously be bad, but with the limitations I had and the fact that I rarely have guests connect to the Wi-Fi, I considered it a low priority.  

In theory, I could have enabled Guest mode on one of the Mesh networks; however, I wasn’t sure how that would work with VLANs and I had other concerns.  When you see the end result, I think you’ll understand why I decided against trying to solve this specific issue. 

  1. Captive Portals and IoT: 

One of the things I wanted on my guest network was a captive portal alerting guests that I do active logging of traffic and have security tools like Snort running. I’m pretty sure no one actually reads this, and that’s ok because the Captive Portal provides me another benefit.  I can use the captive portal to force bandwidth limitations on my guest network.  I can also force timeout requirements where users are forcibly disconnected after 10 hours. I have this set up to prevent people from mooching off my guest network. Unfortunately, this causes some problems with IoT devices.  

Since IoT devices don’t have a web browser I can access they can’t accept the terms of service in the Captive Portal and therefore can’t connect.  I also don’t want my IoT devices to be kicked off the network every 10 hours.   This became inconvenient as I had to turn off the Captive Portal, connect the device to the network, set the IoT devices with a static IP, then add the MAC address and IP to the Captive Portal pass list in order to keep them on the network past the 10 hours and allow them to connect. 

This wasn’t terrible as I simply went through my house and added all the IoT devices at one time.  However, it would be very frustrating when/if I add more IoT devices. 

  1. Google Wi-Fi is borked: 

Yes, borked.  That’s a technical term.  Over the last two years of owning Google Wi-Fi I’ve come to like it less and less [review coming soon].  Google is very upfront about the fact that putting the Google Wi-Fi mesh into access point mode will disable Mesh features in addition to some other features like port forwarding and DNS.  I was aware of this and decided to go ahead anyway figuring that the mesh nodes would still operate as independent routers.  I was wrong. 

Google Wi-Fi not in NAT mode (as they call it) not only disables mesh, it also disables multiple routers. When you try to add more than one Google Wi-Fi router on a network and they’re not in mesh mode the app will actually outright block you [Note: This was Google Wi-Fi, not Nest Wi-Fi where there’s only 1 router and 2 satellites.  With Google Wi-Fi all three pucks are a full router]. 

I was not expecting this, and it causes a massive hang-up in my plan. Yes, I could place a Google Wi-Fi puck on every floor of my house and use VLANs to separate them into a Guest/IoT network, but I could only activate 1 Puck as the actual Router.  The VLANs gave me the ability to move that router to my middle floor but it was still not an ideal situation. 

The Solution: 

The solution to this was pretty simple but not something I really wanted to do yet. I needed to get a more advanced router capable of 802.1Q VLAN tagging on SSID.  I actually needed to get three of them so I could replace my current mesh. I would also want something that’s going to be more future-proof for a long while. It was time to do some research again.

 Fortunately I had already been doing research on devices that would support my needs so making this decision wasn’t terribly difficult.  In the end I chose TP-Link Omada for my needs but I’ll explain the others I considered. 

Vendor Comparison:


Ubiquiti UniFi seems like an obvious choice, and indeed it would have provided everything I need; however, there were a number of reasons I didn’t pick UniFI. 

  1. I have a number of reservations about the company. 
    1. Late last year (December of 2020) Ubiquiti suffered a breach.  It was actually a third-party vendor breach but it affected Ubiquiti which I why I call it an Ubiquiti breach. Now companies get breached all the time, no defense is perfect, but companies shouldn’t attempt to downplay the severity of their breach. This is [allegedly] what Ubiquiti did. A “whistleblower ” [Leaker] spoke with Brian Krebs and called the compromise catastrophic. According to the leaker, the attackers compromised Ubiquiti user credentials and potentially access to the users CloudKey. Ubituiti did come out and say that it was not able to confirm this but the leaker says that’s because they weren’t keeping proper logs in the first place. 
    2. The second reason why I chose against Ubiquiti is that they are forcing account registration when setting up the devices.  This isn’t a huge issue, but I don’t like making random accounts for no reason.  
    3. The last reason I didn’t choose Ubiquiti is the lack of Wi-Fi 6 support.  Yes, some of their devices have it, but it’s not many, and they’re expensive. I don’t have any Wi-Fi 6 capable devices yet, but I will in the future I’m sure and I don’t want to try and convince my wife that we need new routers again.  


I simply don’t know enough about ZyXEL devices to make an informed decision.  I’ve heard a lot of good things about them in Home Networking Subreddits, but I decided I wasn’t going to look to far into them. 


The Aruba devices are another brand that I’ve heard a lot about in home-networking subreddits, and I very strongly considered them. The ultimate reason I decided against them is that they do not allow local controllers.  All the Aruba devices must be managed by a cloud controller.  As I discussed earlier with Ubiquiti a compromise could give hackers access to your network and give them the ability to control your network.  This was a big no for me. 



In fairness I love MikroTik, but man they’re difficult. MikroTik devices are fantastic. They’re incredibly powerful and cheap, but they can be difficult to figure out if you’re unfamiliar with their terminology and how they handle packets. In my early days of learning, I bought MikroTik hAP AC devices on a recommendation but I never quite figured them out.  I could probably struggle my way through now, but I need something that I don’t have to read through 12 manuals to figure out how to set up an outbound allow-all rule. 


I’ve worked with a lot of TP-Link devices in the past.  They’ve always felt like low-cost networking devices that offer good features for a cheap price. They may not offer features as groundbreaking as something like Cisco but they get the job done for relatively cheap. 

The TP-Link  Omada line seems to be in the same boat.  Here’s the reasons I went with Omada:

  1. High-end Omada devices were $50 chapter than mid-range UniFi
  2. Supports VLANs
  3. Supports Mesh
  4. Supports Wi-Fi 6 (802.11AX)
  5. Can be locally managed

The Omada line seemed like a great option, and so far, it has supported everything I needed from it. I only have two complaints about the Omada EAP660HD that I bought. 

  1. There’s only one RJ45 port. This wasn’t a big issue for me as I was placing the AP off a switch but if you didn’t have a switch then this wouldn’t work. 
  2. This thing is chonky, (Another Technical term, look it up). This thing is actually massive.

Here’s a picture of it in my basement, and a picture of it with a Google Wi-Fi router on top of it. These Omada’s are massive.  They’re made to be ceiling mounted but since I’m moving soon, I didn’t want to mount it.  Fortunately, they are relatively flat so hiding them is easy. 

Implementing the Solution: 

With the routers at my house, I needed to set up a TP-Link Omada Controller. I had a bit of trouble installing the Controller on a Linux VM, but that was completely my fault.  TP-Link actually has a great article on how to install it and when I followed their guide it worked flawlessly. Point being: RTFM. 

With the Controller installed I was able to login to the webpage and bulk adopt the EAP660HDs. From there I was able to configure the SSID for my main net and the SSID for my Guests with the VLAN support.  At first, I was going to go through and configure all my IoT devices to use the Guest network as I had planned; this would have included the nonsense with disabling and reenabling the captive portal once I set up pass rules.  I quickly realized that I didn’t have to do that now. The Omada could create multiple SSIDs.  So I changed plans. 

I created three networks:

  1. Home Network ( [VLAN1]: My trusted devices.
  2. Guest Network ( [VLAN10]: This one is where my guests will land when they visit.  It has the captive portal enabled. 
  3. IoT Net ( [VLAN20]: I created a new VLAN network to put my IoT devices on so that they were logically separated from the guest network.  Now I didn’t have to deal with the captive portal nonsense.  Firewall rules would keep guests from interacting with the IoT devices.  

The nice thing with a Software-Defined Networking solution like Omada (or UniFi)  is that a change to the controller will get pushed and replicated to all the devices. So as soon as I added the SSIDs all three of the Omada’s started broadcasting them.  This is significantly more convenient then logging into each one individually. (A note with MikroTik: The MikroTik’s don’t have a controller like this, but they have a control/subservient role. You update the control device and all the subservient devices will pull their configs from the control.) 

An added bonus I wasn’t planning for but am glad I can now do is I can now enable WPA3 on my main network. May IoT devices don’t support WPA3 and some routers (Google Wi-Fi) can’t set different security for Guest and Main networks.  Now I can enable WPA3 for the Home Network and WPA2 for the rest.  Also, I can turn off the 5GHz radio for the IoT network.  There’s functionally no reason I should have to do this, but some IoT device makers won’t let you continue if you are connected to a 5GHz network.


Once again, I had a lot of fun setting this up and this time thanks to proper planning I was able to transfer all of this over with less than 10 minutes of downtime. 

WordPress Appliance - Powered by TurnKey Linux