Separate Network and SSID for IoT Devices


  • The popularity of smart speakers / digital assistants from Amazon, Google, Apple, and others has also broaden the smart home ecosystem in the last few years. This has increasingly led to IoT device sprawl on home WiFi networks but also potentially created security hazards by co-mingling IoT with devices like PCs, Macs, smartphones, etc.

    The ability to have a separate network (IP subnet and DHCP scope) with a corresponding WiFi SSID for Amplifi HD Router customers to use for IoT devices would be a welcome feature and show that Ubiquiti promotes safe WiFi practices. A slider option to hide IoT SSID should also be a part of this. While IoT is a wide category, this separate WiFi SSID and IP subnet would be targeted to many smaller IoT devices (cameras, light bulbs, electric plugs, thermostats) that utilize the 2.4Ghz band for maximum compatibility and coverage.

    Users will have the option use this or place any and all devices into any SSID they wish including "smart" or "digital assistant" enabled devices (eg smart speakers, video speakers) that are designed to use either 5Ghz and 2.4Ghz wireless bands.


  • @joe-chenevey Thank you for the suggestion, I will add it to our list of feature requests for future consideration.


  • @ui-jt
    Any word on where it is on the product road-map? This has been a requested feature for as long as I have owned my device. Some transparency from your product managers would be welcome!


  • This is something that I think is really important. I've started to play around with some IoT devices, but I'm not comfortable with them sitting on my standard network. Seriously considering selling the HD and purchasing something else, but I like it so would prefer to keep it if I know that the feature is coming soon. If you could give us an idea of when it would be available, that would really help. Thanks.


  • @ben-christian Thanks for the input, have you thought about putting them on the guest networks so they are isolated from your network.


  • @UI-JT Is that code for your not adding to the product baseline? I'm curious because this is a core feature I'm interested in.


  • @cyberreefguru Its not code for anything, just a suggestion that may help users who want to client isolation. We are constantly working on improvements and features, we have added a lot in the past year. We certainly are not going to stop improving our products. Thanks.


  • @UI-JT Are endpoints on guest network also isolated from each other while on that network? If so, I don't think guest wifi is a long-term solution because some devices require your Phone/Computer to be on the same network as the device in order to configure and setup.

    I've run into this issue in past which means I must then put the device I wanted on a separate network to be on my main network. Or I end up using an older WiFi AP and ssid so it's on its own subnet -- but then I lose the advantage of mesh network coverage.


  • @originlly In a past update, this was a feature request so now devices that are on the primary network can access devices that are on the guest network. So for example your phone can communicate to a Chromecast that has been configured on the guest network. Is this what you were referencing?


  • @UI-Brett The Chromecast scenario is one such example (and yes, one of my pain points but in the opposite manner wherein cast receiving device is on the main network). But, there are other scenarios:

    • Device on 'main' network allowed access to a guest network device (note: this is targeted 1 device on Trust to the untrust)

    • Device on 'guest' or 'IoT' network to be allowed to talk to devices on the 'main' network (note: this is targeted 1 or more devices on Untrust to Trust) (e.g., a hardwired printer, smart TV casting).

    • Device(s) on 'IoT' network may talk to each other but not to the 'main' network (e.g., security cameras with NVR storage need to talk to the NVR and there are scenarios where the NVR should be isolated from 'main' network).

    • Regular 'guest' network for which devices are not allowed to talk each other.

    For a Smart TV or similar that supports hardwired (and 4k streams where we want consistent, trouble-free connectivity), the device would be on the 'main' network and not the guest. Therefore, having a guest 'cast' to that device is impossible without moving a guest onto the 'main'. And once the guest is on the 'main' they have free reign.


  • @UI-Brett You mentioned that in a past update it was a feature request. Does that mean it's already how it works in released versions now and that devices on my primary network can access hosts on the guest network? Or still not implemented/released?


  • @originlly said in Separate Network and SSID for IoT Devices:

    primary network can access hosts on the guest network

    Correct, in a past firmware release we added the ability for Primary network devices to communicate with guest devices, so for example a Chromecast on the guest network can be used by a smartphone on the Primary network. However a smartphone on the guest network would not be able to use the Chromecast on the guest network.


  • @UI-Brett And this is not user configurable as an option? If it is configurable, where is the setting to enable, disable, or override specific devices on guest network to be able to be reached from primary network?

    I think more useful in my scenario would be the opposite. Being able to specify devices on Guest network that can either talk to each other within the Guest or that can reach specific devices on the Primary.


  • @originlly said in Separate Network and SSID for IoT Devices:

    And this is not user configurable as an option

    Correct, it is a feature that is static.

    In regards to the separate configurable network for IoT devices, I will add your vote to that feature request. We more than likely won't be making those changes to the guest network, because the purpose for guest is device isolation.


  • @UI-Brett I view "guest network" as multi-fold and it is not an all or nothing:

    • Device isolation
    • Not giving out primary network password to people who don't require continual access
    • Allowing a temporary network for connectivity and disabling when not required

    If the "purpose for guest is device isolation," then it seems at odds to add a feature that breaks that purpose by being always-on, not configurable, and not verifiable by owners. I'd rather explicitly know which devices can be talked to as opposed to not knowing whether any TCP 8008 and 8009 port traffic would be allowed from primary to guest network potentially exposing my primary hosts existence to guests.

    Just my opinion (obviously).


Log in to reply