Device discovery across VLANs?
-
Most "device discovery" protocols limit themselves to the local network only -- meaning they will not work across different IP subnets. VLANs are different IP subnets.
If your IoT devices use multicast for discovery, then the
avahi
package might help because it acts as a proxy copying the multicast traffic back and forth between VLANs.The intrinsic behavior of automatic device discovery protocols is to limit themselves to the local network only. Otherwise, the apps would attempt to find everyone's devices from all over the world, and that would not be very helpful . Everyone who had a badly configured firewall (or worse yet, no firewall) would have their devices replying back to your discovery request. And another issue the discovering device would have is knowing what subnets to go searching for. Would it just try them all? For these reasons device discovery is limited to the local subnet.
-
@bmeeks said in Device discovery across VLANs?:
attempt to find everyone's devices from all over the world
haha - that would be insane.. You can have problems with amount of multicast and broadcast on a single small little L2 with only a few hundred devices.. Can you picture the insanity if every device on the internet traffic went everywhere ;) hehehehe
-
@johnpoz said in Device discovery across VLANs?:
@bmeeks said in Device discovery across VLANs?:
attempt to find everyone's devices from all over the world
haha - that would be insane.. You can have problems with amount of multicast and broadcast on a single small little L2 with only a few hundred devices.. Can you picture the insanity if every device on the internet traffic went everywhere ;) hehehehe
Yeah -- that would be a world record DDoS for sure!
-
Yah. I get that for sure, but I do control my own network and can block/allow whatever I want on it. I know in big IT environments they separate all of that to optimize the network. I know there are people that know this a lot better than I do but I do know enough about networking to know that something is either blocking something between my VLANs or something is assuming the subnet and thinking no further. I could do some creative tricks to make a larger subnet that spans both VLANs but devices are still controlled to which VLAN they go on by other means. Right now for WiFi I have two SSIDs one for each VLAN and for Ethernet I have two physical LANs but I don't do anything more than that since this is my house. It's good enough for me. I trust anyone in my house. And I do question sometimes if it's even stupid to bother trying to separating IoT and guests and just use one network like everyone else does, but I also know these IoTs have got to be magnets for attempts to worms.
-
@scottlindner:
The banter between @johnpoz and me is just for internal humor and not directed at you or your post.You are 100% correct in your assessment. Security on a home LAN by definition generally has some compromises. We buy widgets for our home networks and install them with the hope they make our lives easier (think smart light bulbs and thermostats), add some entertainment (think music streamers and smart TVs), or perform some rudimentary security function (think Ring doorbells and security cameras). We want to plug these in and have them just "work".
Us IT Security guys tend to bring our work home ... . We want our home LAN to be locked down like the corporate network we mangage. But that does not always work so well at home. If the kids can't watch cartoons on Netflix, or the wife can't watch tear-jerker movies streaming on Prime or has issues using Zoom, then we hear about it loudly! So, I'm with you to a degree. If your home LAN does not contain the secrets to the alien technology stored at Area 51 (I'm exaggerating, not really a conspiracy theorist!), then putting the bulk of your IoT devices on the regular LAN can be okay. I'm talking things like Smart TVs and music streaming gizmos that you want to easily be able to connect with at home using your phone or other devices.
-
@bmeeks I knew i was professional humor. I work in the broader sense of IT so I know it. I'm an engineer that designs very custom and complex "IT like solutions" for very special customers. Started as a EE doing more EE oriented work for signal type of stuff and slowly morphed into embedded software and into more IT type stuff. But I'm not the guy designing the network stuff, I'm doing more of the new capabilities and cloud architecture type of stuff for scaling, performance, etc. So I know this shit is all there, and I have written many k8s deployments so I do get networking.. but sometimes when I hit the lower level stuff it becomes our IT guys issues to deal with because they are managing the network for reasons that don't exist at home so it stretches my knowledge and experience a bit.
I just tried avahi and it doesn't seem to be doing anything. So it could be how Spotify does discovery is based on the subnet it is on and not some multicast/broadcast protocol of devices. I may have to dig more into what Spotify is doing.
At the same time, I might "trust" IoT devices and just not trust guests. I had one guest abuse my network. He was a jackass IT guy that thought it was funny to try to crack into my firewall within 5 minutes of me giving him my WiFi. He's an ass, but it was a good lesson to have some type of device trust in place.
-
That would be me -- put my IoT devices on the LAN with my other "stuff" that they need to interact with, but put guest Wi-Fi on a separate VLAN and isolate it from everything but the Internet.
-
@bmeeks said in Device discovery across VLANs?:
If your home LAN does not contain the secrets to the alien technology stored at Area 51
haha - how did you know I had those ;) The example I use asking home users about their security setups, more related to when they use disk encryption and then forget to back up the keys, and then redo their OS install and wonder why they can't get into their data..
Not like your storing the nuclear launch codes are you?
@scottlindner yeah that was not meant to be towards you - that was more a personal joke between me and bmeeks.. Sorry I prob could of sent that to him directly.. I personally am not a fan of breaking the L2 barrier even on my home network.. But that is me, it has valid use in a home setup sure.. Unless you do have the launch codes for the US Nuclear Arsenal? hehehe
I have a few posts around here about setup and validation of avahi, but depends on what exactly your using for discovery avahi is for mdns, and you need a rule for the multicast address, etc.
Me not being a fan of it, doesn't mean not willing to help others set it up and validate it works. Me personally for like my printer and air print.. You just have to be on that wifi network to use airprint. Easier to just put the printer on that vlan, My PC can just point to its IP to print, no need for discovery anything. And I have nothing else on my network that would even leverage discovery.. Maybe the roku apps on my phone, but if you join my roku wifi network you can discover, and once you discover you don't heed to be on that network any more to use the remote on the phone, etc.
-
@scottlindner said in Device discovery across VLANs?:
I have two VLANs setup to isolate trusted and untrusted traffic, Basically guests and IoT that only need Internet access all go on untrusted which doesn't have access to the firewall, switch, NAS, printer. I keep swapping my phone from VLANs because I want to discover the Alexa devices in the Spotify app, and then bounce back to the trusted VLAN for a few other reasons. Is there a way for the trusted VLAN to discover devices on the untrusted VLAN? Routing already exists. I can ping, SSH and HTTP/S to any untrusted device from a trusted device. Unfortunately I know just enough to realize it is a networking/firewall issue between VLANs but not enough to know what isn't happening. Appreciate the the feedback on this.
Have you thought about leaving your phone in the IOT VLAN/wireless network and simply adding an IOT VLAN firewall rule to allow that one device to access the Trusted VLAN? If you are simply logging off the IOT and logging into the Trusted network with the same device, there is little reason NOT to simply let it have access across the IOT VLAN to the Trusted VLAN. What I'm trying to say is the "security" element/risk is the same in either case, so why not make it as easy as possible.
You'll want to set a static IP for your phone on the IOT VLAN (in the IOT VLAN DHCP service) and then create a rule in the IOT VLAN firewall rules that allows that one IP address to pass all traffic to the Trusted VLAN.
-
@sic0048 said in Device discovery across VLANs?:
@scottlindner said in Device discovery across VLANs?:
I have two VLANs setup to isolate trusted and untrusted traffic, Basically guests and IoT that only need Internet access all go on untrusted which doesn't have access to the firewall, switch, NAS, printer. I keep swapping my phone from VLANs because I want to discover the Alexa devices in the Spotify app, and then bounce back to the trusted VLAN for a few other reasons. Is there a way for the trusted VLAN to discover devices on the untrusted VLAN? Routing already exists. I can ping, SSH and HTTP/S to any untrusted device from a trusted device. Unfortunately I know just enough to realize it is a networking/firewall issue between VLANs but not enough to know what isn't happening. Appreciate the the feedback on this.
Have you thought about leaving your phone in the IOT VLAN/wireless network and simply adding an IOT VLAN firewall rule to allow that one device to access the Trusted VLAN? If you are simply logging off the IOT and logging into the Trusted network with the same device, there is little reason NOT to simply let it have access across the IOT VLAN to the Trusted VLAN. What I'm trying to say is the "security" element/risk is the same in either case, so why not make it as easy as possible.
You'll want to set a static IP for your phone on the IOT VLAN (in the IOT VLAN DHCP service) and then create a rule in the IOT VLAN firewall rules that allows that one IP address to pass all traffic to the Trusted VLAN.
I did think of that and I was switching my phone between VLANs since I have a SSID for each VLAN but opted to just go stupid simple and od it's a device I want on my network, it goes on the same trusted VLAN. It isn't ideal because I'd rather not trust IOTs because what is the patch/push cycle for cheap LEE strip lights that my kids have connected to their Echo Dots? But...what is my real vulnerability here like others pointed out? I already back up my NAS using a disk rotation pattern. So worst case is home network disruption or hassle to rebuild my NAS?
So now Mt untrusted network is what I give out to friends and people that swing by casually and if they need to print something, throw music on a smart speaker, or cast video, I'll just trust them.
I would prefer better security but I couldn't get around the IOT discovery issue across VLANs.
That said, I have been considering creating a freely available VLAN on an open SSID called "FreeToRoll" and all HTTP traffic routes to a Rick Roll video.
-
Well I am with you, but on the other side why not
creating a DMZ putting all "snitches" (SmartTV,
PlayStation,.....) in that DMZ? And in the LAN all is fine.I have set up two routers one from the AVM company
called Fritz!Box I can VPN to home, connect all devices
such phones Home automation (Smart home devices)
and I can use the APPs from that company makes life
more easy, but behind that I set up the pfSense to
secure the entire LAN. Benefits on top are, that
the pfSense is not using PPPoE anymore and all
WAN traffic is running now over more queues! -
I was attempting to do exactly that with two OPT interfaces in pfSense. Maybe there is another way to set up the firewall rules for that.
Long ago I used to use two routers for exactly the purpose you describe. But I would expect the very same discovery protocol issue that led me to posting this. I had routing and name resolution workitjust fine, just not the discovery broadcast protocols. I did try that one plugin for that. I couldn't get it to work.
-
@dobby_:
Nothing wrong with the DMZ approach. It does provide the most isolation of IoT devices and other perhaps more "private" LAN devices.But in a home network sometimes security compromises are required for "ease of use" by other family members. For example, "casting" from an iPhone or other mobile device to a SmartTV likely will not work across subnets. At least not without some add-on package to relay mDNS and whatever else is necessary between the networks. Likewise, many mobile apps designed to communicate with and configure IoT devices will also not work across different subnets. Yeah, you can explicitly create multiple WiFi networks and connect one each to LAN and DMZ. But it can be a pain to switch your mobile device back and forth.
How you choose to segment things is really a user decision. Depending on the sensitivity of data on your LAN, maybe it's not a big deal to share that subnet with IoT devices when doing so makes interoperability between all the smart things in your home easier to implement.
-
The issue isn't two interfaces with routing rules between them vs two physical routers to produce the isolation, it is the desire to have trusted devices discover untrusted devices that rely on broadcast discovery protocols. Those packets aren't getting across and for good reason, that is what a DMZ does.
I might try that plugin again for the discovery protocols. Maybe I didn't configure it right.
-
@scottlindner:
We might be sort of talking past each other. My reply was simply meant to say that in a home network, many times security might take a bit of a back seat to ease of use for other family members.Yes, a DMZ does a really good job of isolating things, and that unfortunately means many popular home automation widgets get isolated from the devices on the more secure LAN that want to talk with them. And while there are some utilities that purport to help certain traffic types cross that LAN/DMZ boundary, not all are 100% successful with all IoT devices. So, that puts you back to balancing ease of use and security.
But each network admin can make their own choices in this area. Some will go for security and isolation and use the DMZ route. Others may decide making "casting" work seamlessly and having music streamers and other devices "just work" on the LAN without requiring configuration and network gymnastics is worth the risk of just putting those IoT devices directly on the LAN with everything else.