What's new

Why separate SSIDs for IoT devices?

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

vargas

New Around Here
At a recent tech talk I attended, the speaker strongly recommended to the audience that all IoT devices on the network must have their own SSID. Why? It can't be a security concern because devices are going to be on the same network anyway.

Can anybody suggest why this recommendation was made?
 
That's usually recommended when the SSID in question is isolated from the rest of the LAN.
 
Either the speaker misspoke, or you misheard.

What IOT devices need is some form of isolation. Ideally, they should have their own ethernet + IP network. How that's achieved will vary from router to router, and firmware to firmware. And whether you have to support wired and/or wireless devices on your IOT network.

In the case of my ASUS RT-AC68U using stock or Merlin firmware, you could use a guest network for such purposes. And that guest network would have its own SSID. But as implemented, both the private and IOT networks share the same ethernet + IP network, and isolation is achieved w/ a layer 2 (ethernet) firewall. Not ideal imo, but it works. Even so, guest networks on ASUS do NOT support wired devices. So anyone needing support for wired IOT devices would have to find another solution.

Other routers and firmware are able to create a new ethernet + IP network for IOT, plus support both wired and wireless. In that case, you'd have a unique SSID, plus one or more LAN ports dedicated to wired IOT devices.

In short, there's no way to determine what's possible or necessary to achieve your IOT goals unless you know what's needed (wired? wireless? both?) and the capabilities of your networking equipment.
 
Thanks Colin and eibgrad.

The speaker never referred to guest networks or VLANs. He was referring to separate SSIDs as some sort of holy grail of IoT networking!

But here is another thing I don't understand. If I have an IoT toaster, lets say. And it's on a "Guest Network" but the network I connect to is called "Home Network" . Doesn't this defeat the whole convenience factor of IoT device? I'm on my sofa watching Netflix and I now have change network on my smartphone just to adjust the toaster (or whatever IoT device) settings?
 
But here is another thing I don't understand. If I have an IoT toaster, lets say. And it's on a "Guest Network" but the network I connect to is called "Home Network" . Doesn't this defeat the whole convenience factor of IoT device? I'm on my sofa watching Netflix and I now have change network on my smartphone just to adjust the toaster (or whatever IoT device) settings?
Indeed. It really depends on what exactly these IoT devices are, how they work and how much you trust them.

Some devices may only need access some central server on the internet and don't touch the LAN at all. When the user wants to interrogate the device they connect to the internet server, which may or may not (depending on what you're doing) forward the request back to the device. It may not be the most efficient communications model in terms of latency, but if you're talking about a toaster does it really matter?
 
As @ColinTaylor says, it depends on the device. The term IOT is used so broadly to describe a wide array of products, it's difficult to speak about IOT isolation in a way that's applicable to every device in every situation. Truth is, within IOT, you probably have different sub-classifications that may warrant their own unique isolation.

In my own case, I consider my smart TVs to be IOT devices (others may feel differently). I keep them on my IOT network along w/ smart AC plugs, neo (Tesla solar array controller), OOMA voip adapter, etc. Basically, anything I know has no need to access or even see my most trusted personal devices on the private network. However, w/ the smart TVs on a separate network, it means network discovery doesn't work, and therefore the Chromecast feature doesn't work! I had to enable an mDNS proxy (Avahi) in order to add that capability back between the two networks (a bit of a compromise). I also allow *any* device on the private network to initiate contact w/ any other device on the IOT network, but NOT the reverse (once again, a bit of a compromise).

Of course, that kind of sophisticated solution is beyond what the speaker is suggesting. He's just assuming you only have wireless devices, and a "one size fits all solution" is probably better than nothing. But in reality, YES, you do have to think more deeply about the matter to deal w/ the good questions you're raising.
 
But in reality, YES, you do have to think more deeply about the matter to deal w/ the good questions you're raising.
Sometimes I wonder are all these speakers at conferences mere theorists. Have any of them worked on a real-life network ;)
 
Sometimes I wonder are all these speakers at conferences mere theorists. Have any of them worked on a real-life network ;)
Well, we can't really guess what the intention (or competence) of the speaker was as we know nothing about this "tech talk". It could have been some well-meaning amateur giving general advice aimed at a non-technical audience. Or it might be some super-clever WiFi security expert with 20 years experience diving deep into theoretical vulnerabilities in WPA3... or something in between.
 
How do you configure that?
One way is to put your IoT devices on an router that directly connects to the Internet then double NAT a second router behind the first router and use it for your private and more secure devices.
 
How do you configure that?

Using firewall rules. I create rules that allows everything on the private network interface (br0) to be forwarded to any other network interfaces, be it the guest (br1) or iot (br2).

Code:
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i br0 -o br+ -j ACCEPT
iptables -A FORWARD -i br+ -o br+ -j REJECT

br+ is a wildcard. It will match on any network interface beginning w/ br.

The last rule blocks *all* communications between the network interfaces. But it's tested last. Before it, I make an exception to allow br0 access to any other network interfaces. But I also need the ESTABLISHED rule before it because I still need to allow devices on br1 and br2 to minimally *reply* to any contact initiated from br0. But any attempt by br1 or br2 to *initiate* contact w/ any other network interfaces hits the last rule, thus blocking it.

Of course, I'm just cherry-picking rules here out of a much larger set of rules I apply to manage access between devices. It's only intended to show how it's possible to allow connections to be established in one direction.
 
Last edited:
Learned something new today… Thank you!

Looks like I should be reading more about iptables.

What’s a good resource for that?
 
One way is to put your IoT devices on an router that directly connects to the Internet then double NAT a second router behind the first router and use it for your private and more secure devices.

A good idea. But even here, you need to be careful. Since your private network is now traversing the IOT network, it's subject to eavesdropping, MITM attacks, arp poisoning, etc., by compromised IOT devices. Might be prudent to always route your private network over a VPN to be safe.

The other option is to place the IOT network *behind* the private network. That avoids the problems above, but now you need to configure the IOT router's firewall to deny its clients access to any resources on the upstream private network (or any other potential local networks (e.g., a VPN to a friend's network)). IOW, strictly internet access.

In short, neither solution magically solves the problem. Each has advantages and disadvantages, and requires some additional "tweaking" to keep your private network truly safe.
 
Using a double NAT is just part of my security plan. For those IoT devices that will run on a VPN they connect using a VPN client that is not used by other devices. Wifi IoT devices connect on one of several guest networks. Also my private upstream network devices on the double NATed router connect using a different VPN client and I also use VLANs to further segregate traffic on my more secure network.

Security is about building layers. No one solution is perfect but by combining several methods I hope that I make a network penetration from a poorly engineered IoT device more difficult.
 
To expand on Colin's comments, I have an IOT network with a few devices which report to and and are accessed through servers on the internet. I can access and manage these from any node with internet access, regardless of the network I am locally connected to. On the same IOT network, I have some IP cameras that are managed 100% locally. To access them I need to be on a device on the same network, so yeah if I'm kicked back watching Netflix and I want to watch for my Doordash delivery, I need to switch my phone to the IOT WiFi to access the cameras.
 
Using firewall rules. I create rules that allows everything on the private network interface (br0) to be forwarded to any other network interfaces, be it the guest (br1) or iot (br2).

Code:
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i br0 -o br+ -j ACCEPT
iptables -A FORWARD -i br+ -o br+ -j REJECT

br+ is a wildcard. It will match on any network interface beginning w/ br.

The last rule blocks *all* communications between the network interfaces. But it's tested last. Before it, I make an exception to allow br0 access to any other network interfaces. But I also need the ESTABLISHED rule before it because I still need to allow devices on br1 and br2 to minimally *reply* to any contact initiated from br0. But any attempt by br1 or br2 to *initiate* contact w/ any other network interfaces hits the last rule, thus blocking it.

Of course, I'm just cherry-picking rules here out of a much larger set of rules I apply to manage access between devices. It's only intended to show how it's possible to allow connections to be established in one direction.
Is it possible to manually create a new network interface, say br3, and to manually add ip addresses to it, so that you could apply the above technique to only specific devices on your network?
 
Is it possible to manually create a new network interface, say br3, and to manually add ip addresses to it, so that you could apply the above technique to only specific devices on your network?

Yes. But that device has to support those capabilities. Many typical consumer-grade routers and switches do NOT.

I happen to use an ASUS RT-AC68U router running FT (FreshTomato) third-party firmware, which natively supports VLANs, bridging, etc. So it's trivial for me to add new IP networks and keep them isolated from each other. But the ASUS OEM (and even Merlin) firmware does NOT support those same capabilities. At best, you could use Merlin and perhaps make some low-level changes using the CLI (command line interface) to make it happen, but certainly NOT via the GUI.

IOW, what's possible comes down to your hardware/firmware choices.
 
Yes. But that device has to support those capabilities. Many typical consumer-grade routers and switches do NOT.

I happen to use an ASUS RT-AC68U router running FT (FreshTomato) third-party firmware, which natively supports VLANs, bridging, etc. So it's trivial for me to add new IP networks and keep them isolated from each other. But the ASUS OEM (and even Merlin) firmware does NOT support those same capabilities. At best, you could use Merlin and perhaps make some low-level changes using the CLI (command line interface) to make it happen, but certainly NOT via the GUI.

IOW, what's possible comes down to your hardware/firmware choices.
Yes, I have Merlin inside my AC86U. The technique above uses iptables statements that are only available via the CLI. I know the current GUI does not support VLANs. But if I could create a br3 and add IP addrs to it, then using the technique above, I could accomplish the same isolation as with VLANs. And while I believe you that VLANs are easy with FreshTomato, I'd hate to move away from Merlin, so I'm looking for a technique that works with that f/w.
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top