allowing roku discovery across VLANs
-
I bet it uses multicast. Multicast is not normally passed by routers, including pfsense.
-
@JKnott My understanding is that is explicitly what Avahi is supposed to fix in a situation like this - https://www.avahi.org/
-
It says Avahi is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite. I don't see anything there about passing through a router.
-
Looking at your screenshots it appears you have not selected any interfaces in avahi. It's not going to proxy mDNS/Bonjour traffic until you tell it which interfaces to use.
What protocols does Roku use for discovery? You may need a solution other than avahi. Look at the threads concerning Sonos discovery. Using pfsense for this a bit of a hack (albeit a common hack, I do it for Airplay and Sonos) for something better done with your switch(s) if possible.
-
@jwj From the screenshot: Interfaces that the Avahi daemon will listen and send on (Allow mode) or be prevented from listening or sending on (Deny mode). If empty, Avahi will listen on all available interfaces.
I don't know really. I saw a lot of mDNS traffic in wireshark.
-
@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?
