allowing roku discovery across VLANs
-
@JKnott Maybe I'm misunderstanding Avahi in general. Maybe it's not "passing through the router" but there appear to be Avahi configuration options to control which interfaces it's listening on. It seems that would be a mechanism to circumvent the router entirely...? Maybe?
-
Roku uses SSDP not mDNS for discovery. Multicast address of 239.255.255.250. I think, don't know, that avahi will not work. You will need to look at pimd (pfsense package) or udpbroadcastrelay (roll your own, not a package).
Not a lot of free time ATM but that's the same as SONOS. I use us-broadcast relay (not as bad to get setup as it first looks) and it works really well. Some google foo around udpbroadcastrelay and roku will be helpful. Also the thread on udpbroadcastrelay in this forum will get you going with getting the binary and getting it setup. I wonder of Roku uses port 1900 like SONOS?
If so you run this with the shellcmd package:
/usr/bin/nohup /root/udpbroadcastrelay/./udpbroadcastrelay --id 1 --port 1900 --dev igb1.200 --dev igb1.300 --multicast 239.255.255.250 -f > /dev/null
Be careful, do your research first. You can make a bit of a mess of things if not careful.
-
@jwj That's fair, and maybe worth locking down later. For now I'm trying to keep things wide open while troubleshooting this discovery issue. Also, fwiw, many configuration iterations ago I did have LAN and LAN_IOT selected. It didn't seem to help.
-
@jaaasshh said in allowing roku discovery across VLANs:
I would like those Roku's to still be discoverable from the iphone Roku app running on my "safe" wifi network.
Why?? I don't understand this logic... You on purpose want to isolate your rokus - ok great put them on a roku vlan.. Why do you then want to circumvent that isolation by breaking the L2 boundry with discovery protocols/multicast. Defeats the whole purpose really of isolating them onto their own L2..
There is no need to be able to discover a roku more than once.. You can then control said roku from any vlan on your network that has permissions to talk to that roku..
Here my phone is on my trusted wifi wlan, you have to have a cert to join via eap-tls.. Only devices on this vlan 192.168.2/24 are my phones, my laptops and tablets.. My rokus are all on a roku vlan 192.168.7/24
I can connect to any of the rokus and control it from my phone, which is on the 192.168.2 vlan.
As you can see the rokus on the 192.168.2 network.. If you can not connect to them then just join your phone to the roku vlan to connect to a different one. Or hit the connect manually and put in the IP.. As typical security is thrown to the wayside because its not convenient... OMG I have to click this extra button...
What I don't understand is why users want to be secure to my network, let me run pfsense, let me segment my networks. Then first thing they want to do is break L2 segmentation they just created in the sake of security ;)
When there is zero reason to do it... My rokus are isolated on their own vlan - they can not create any connections into any of my other vlans. I can control them just fine using roku app on a different vlan.. I can control my TV (roku) from my alexa which is on a different vlan even, its on my psk vlan..
If you want to learn how multicast discovery works - that great, lets go into that first, before the first thing you want to do is violate your L2 boundary you just setup when there is no reason..
Your goal is to control your roku's from the AP while your on a different vlan, there is no reason or need for pimd, or avahi or any violation of the L2 boundary for that to happen.
-
For sure you can just connect to the network were your roku lives if you want to talk to it. Same for Apple TV or Sonos. Poking holes in your carefully isolated networks is a bit of a contradiction ;)
That said, a lot of people do poke holes... I do. I know it's it's not great. I guess that's something...
-
@jwj said in allowing roku discovery across VLANs:
a bit of a contradiction
A bit? ;) its a bit more than a bit, at least a full byte ;)
-
Humans. :) We all know that hitting yourself in the thumb with a hammer is bad. We all think that just before we say "hey, do you know where I left my hammer?"
-
Guys - that other post clearly covered that "poking holes is bad". If that's all you have to contribute can you just go respond over there? I got that bit.
@johnpoz It seems that I disagree that "roku's only have to be discovered once. If I kill the roku app, it loses connection to a previously connected device. So any time my phone restarts I have to switch networks, re-discover it, then switch back. I don't want to do that. I'd also have to do that with other phones on my network and any guests that show up that want to stream content to my roku.
-
@jaaasshh Absolutely. You're going to need udpbroadcastrelay or pimd. I was not successful getting pimd to work for Sonos (also uses SSDP) and udpbroadcastrelay worked very well. YMMV. See my post above and adjust the interfaces as needed.
-
Read up on what Bonjour does. Avahi does similar. I have not seen passing through a router mentioned anywhere as that's not what they do.
Consider the multicast addresses used. They are in a special block, which can never be used as a host address. This means a router does not know what to do with it. The exception is when some device on the LAN side of a router wants to subscribe to that multicast. It then asks the router to act on it's behalf and then when a packet comes from the source, then it will pass it on to the local LAN. This will happen with as many routers as necessary, to get the packets from the source to the eventual requesting host.
-
@JKnott Of course. Broadcast/Multicast traffic isn't going anywhere specific. Where would you route it? What is being done is the Broadcast/Multicast traffic on one L2 network is being copied to another. Passing through the router (pfsense) or not is semantic hair splitting. This can be done (arguably better done) on your switch, if at all.
-
@JKnott Thanks for those links. My interpretation of that (watch out world) is that Bonjour is running on my various Apple devices, but those are all confined to the subnet they are on. So, they have no ability to listen on my IOT VLAN and rebroadcast on the opposing side.
Avahi is different given that it is running on pfsense, bound to both networks which allows it to listen on both and rebroadcast on both. That, to me, essentially bypasses pfsense (for better or worse) which otherwise wouldn't rebroadcast those messages, or as you put it, wouldn't know what to do with it.
So all that said, I guess I'm still not connecting the dots as to what "passing through the router" has to do with any of this. Avahi is running, it's supposed to be doing that job instead of the router. No?
-
@jaaasshh said in allowing roku discovery across VLANs:
So any time my phone restarts I have to switch networks
So in line with OMG I have to click a button... F security - its not convenient enough ;)
You want a simple solution for your guest to control your rokus - let them connect to your roku vlan.. I have cards printed out with my different wireless vlans.. That guest could connect too.. Normally they connect to just guest. But if I wanted them to stream something to my rokus - which for the life of me could never see wanting to do in the first place ;)
But if did - I would hand them the roku QR code card.. They couldn't type in the PSK anyway.. Its more than 3 characters and that is just too much work ;)
I'm with @jwj users asking for help with how to best line up the hammer to do the most damage as they strike themselves not in the thumb but in the head..
-
@jaaasshh avahi is for mDNS/Bonjour. Not SSDP. As I have said you need to look elsewhere.
-
@jwj said in allowing roku discovery across VLANs:
This can be done (arguably better done) on your switch, if at all.
I'm curious about this. I never found a solution to my Youtube discovery issue across VLANs. How would it be done on the switch? Is that what IGMP snooping on a switch does?
-
@Raffi_ Partly. Then you need to setup what to do with the traffic you are snooping. Depends on the switch. My CISCO Small Business (SG-220 50P) has a terrible interface and garbage documentation. That's why I haven't done it yet. I really should do it soon.
-
@Raffi_ said in allowing roku discovery across VLANs:
Is that what IGMP snooping on a switch does?
Yep, or a router. Here's what Wikipedia says:
"The Internet Group Management Protocol (IGMP) is a communications protocol used by hosts and adjacent routers on IPv4 networks to establish multicast group memberships. IGMP is an integral part of IP multicast and allows the network to direct multicast transmissions only to hosts that have requested them."
-
Thanks guys, I'll have to look into that more for my switch.
-
Where that is really meant to be used.. Is say you have a L2 network.. That you want to multicast some video too.. You could allow only devices that want to see this multicast stream to join this group.. So that multicast is not sent to them if they are not a member of that group.
If not then every port on the switch would see that multicast traffic..
Now you can do this across multiple vlans with a multicast group that spans L2 networks.. But again you allow a client to join this group.. Then only then do you send them traffic from that group or let them send traffic to that group.
You don't just flatten the different L2 networks by sending all multicast traffic to both or multiple L2 allowing for discovery.. That defeats the whole point of isolation and security.
To be honest its the software makers lack of thought that brings these sorts of problems... Why does the roku app have to discover.. Because it makes it easy for the user - and 99% of users just have 1 flat network.. So why should they do anything different.. You know like actually publishing what specific ports and protocols are used.. The ability to add a device via fqdn/IP and be done with.. The roku apps allows you to add a device manually.. But then again - that is a like a button click, and just too much work ;)
Security goes out the window as soon as there is any sort of lack of convenience to it..
-
@johnpoz Good overview. Thank you!
