allowing roku discovery across VLANs
-
Goal: In a home setting, I would like to isolate Roku devices on a separate VLAN from "safe" home devices (iphone/laptop/etc) to prevent the Rokus from accessing those "safe" devices. I would like those Roku's to still be discoverable from the iphone Roku app running on my "safe" wifi network.
Problem: With wide open firewall rules, if I move the Roku to that separate VLAN, my iPhone's Roku App can no longer discover that Roku device. This blocks me from using the App's remote feature as well as streaming content to the device. Both these features work as expected when they are on the same VLAN.
Setup:
pfSense running on Netgate SG-1100
ubiquity controller running on an Ubuntu VM
ubiquity 8 port switch
ubiquity AP
3 VLANs and associated wifi networks only two are relevant to this post
(LAN, LAN_IOT are relevant, LAN_NOT is not)
Avahi installed using pfsense package managerLAN is supposed to be my "safe" network
LAN_IOT is where I would like my Roku's to end up.As of this writing my "Basement" Roku is on LAN and Living Room is on LAN_IOT. One is discoverable, the other is not. If I manually enter the IP of the LAN_IOT device it becomes accessible in the app, however it doesn't last. If the app is restarted that connection is lost, so, this is not a solution.
I believe my LAN and LAN_IOT have wide open Firewall rules right now. At least, the Roku can play media over the internet, and I can ping it from LAN.
I also believe Avahi is up and running across all three of my networks, so, in theory(?), it's reflecting broadcast across the VLANs and is supposed to be allowing my iphone to discover both Rokus. Maybe? I'm not sure how to confirm Avahi is doing its thing correctly.
I followed this guide (https://help.testlio.com/en/articles/1144492-wireshark-guide-for-roku-and-apple-tv) which has a whole different network setup, in an attempt to learn if there are any protocols or ports in play that would need to be open, but truth be told, I'm not sure I learned much. Yes, there are lots of TCP/mDNS packets. There were no blocked packages that I saw, but since all devices there were on the laptop-based network, presumably pfSense's firewall and Avahi were out of play. Oddly, I didn't see any HTTP traffic as that guide suggests, so I could've been doing something wrong. I'm a bit of a Wireshark rookie.
I've also tried running Wireshark on my laptop in an attempt to see my iPhone talking to the Roku or to see blocked packets, but I suspect I'm doing that wrong as well. (Again, wireshark rookie). I don't see any blocked packets, just lots of TCP and mDNS. I've done this while conected to both the LAN and LAN_IOT wifi networks. My guess is Wireshark needs to be running on one of pfsense/switch/AP in order to see that traffic.
So yea, with wide open firewall rules, and Avahi running, this is supposed to work, right? Maybe? Why doesn't it? Thanks! :)
*This question has already been asked here (https://forum.netgate.com/topic/139310/need-assistance-willing-to-pay-up) but the subject is inaccurate, no solution was figured out and the post seems to have diverged into "this is a terrible idea" talk. Some on that thread suggested the security/convenience trade off proposed here is perfectly acceptable for some use cases. With that in mind, I'd hope this thread can stick to the technical pieces and try to stay on topic :) If anything I'd like to learn some things about pfsense, VLANs, Avahi, etc... Thanks!!!
-
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.
