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.
pfSense running on Netgate SG-1100
ubiquity controller running on an Ubuntu VM
ubiquity 8 port switch
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 manager
LAN 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.
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 188.8.131.52. 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 184.108.40.206 -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.
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...
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.
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?
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.
Raffi_ last edited by
@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.
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."
Raffi_ last edited by
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!