Configuring UDP Broadcast Relay
-
@RickyBaker said in Configuring UDP Broadcast Relay:
the VSSL app won't show my VSSL A.6's
Btw, it's been a while since I had VSSLs, but they should work just fine with Avahi and mDNS only. No SSDP required here. They were, and I assume still are, actually Avahi based themselves.
One other thing that comes to mind... some Wifi APs have "smart" mDNS features that can really muck things up. There are a few use cases for these, but in general I recommend that those features be disabled unless you really know mDNS well.
Last thing of note, make sure you do not have an Avahi instance in the network somewhere with caching enabled. This can also muck things up with Bonjour.
-
@dennypage said in Configuring UDP Broadcast Relay:
Do you actually need SSDP forwarded?
I actually don't remember what I had that in for. It's possible I was just following another tutorial. Do you recommend removing that for collision prevention? or just for safety of not having something forwarded that doesn't need it?
@dennypage said in Configuring UDP Broadcast Relay:
Your OpenVPN interfaces may not work with broadcast.
Thanks for the warning. Just for giggles, i connected to my OpenVPN and it could NOT find my printer, VSSL couldn't find any devices and Harmony couldn't find the hub (nothing else on my list of doesn't work would be powered on), so it would appear this is correct.
@dennypage said in Configuring UDP Broadcast Relay:
Select "Enable the Avahi daemon"
Would i FIRST need to remove the 5353 forward in UDP Broadcast relay?
@dennypage said in Configuring UDP Broadcast Relay:
Btw, it's been a while since I had VSSLs, but they should work just fine with Avahi and mDNS only. No SSDP required here.
WOW another VSSL user! I've never met another in the wild (former or not). So you are correct, Avahi worked pretty well, BUT Google speaker groups did NOT. I could connect to all the individual zones but not the speaker groups created in Google Home. This was actually confirmed by VSSL and the groups do indeed show up now when on LAN Wifi.
@dennypage said in Configuring UDP Broadcast Relay:
One other thing that comes to mind... some Wifi APs have "smart" mDNS
I use Unifi switches and APs and been troubleshooting this in one form or another for literally years (embarassing but true) so I'm near positive that I have turned off Unifi's dynamic mDNS feature but I will quadruple check, thank you
@dennypage said in Configuring UDP Broadcast Relay:
Last thing of note, make sure you do not have an Avahi instance in the network somewhere with caching enabled. This can also muck things up with Bonjour.
So, I apologize but I really don't understand this point at all, and it sounds promising. What kind of things would have an "Avahi instance"? Is this something on a client device or in the networking equipment. and where would I check if "caching is enabled"?
-
@RickyBaker said in Configuring UDP Broadcast Relay:
Do you actually need SSDP forwarded?
I actually don't remember what I had that in for. It's possible I was just following another tutorial. Do you recommend removing that for collision prevention? or just for safety of not having something forwarded that doesn't need it?
Also googling SSDP to try to jog my memory did no such thing. Maybe if you could pass on some common things that use it it'll jostle something loose:)
-
@RickyBaker eh i think it was just from the tutorial that i used at first: https://iambartlett.com/blog/pfsense-chromecast-and-speaker-groups
-
@RickyBaker said in Configuring UDP Broadcast Relay:
Do you recommend removing that for collision prevention? or just for safety of not having something forwarded that doesn't need it?
Both. All sorts of potential issues if you run Avahi and also forward the multicast packets. And as a general rule, I very much recommend against forwarding things unless you absolutely need to. You set up the IOT VLAN for a reason, yes?
@RickyBaker said in Configuring UDP Broadcast Relay:
Would i FIRST need to remove the 5353 forward in UDP Broadcast relay?
Absolutely.
My overall advice is to remove everything from the relay, set up Avahi and test, then consider what you might want to add back into the relay.
@RickyBaker said in Configuring UDP Broadcast Relay:
So, I apologize but I really don't understand this point at all, and it sounds promising. What kind of things would have an "Avahi instance"? Is this something on a client device or in the networking equipment.
In general I am referring to general purpose computers that have Avahi installed. That said, sometimes embedded systems use Avahi, and occasionally with old configurations that have caching enabled by default. VSSL was one such system, and I worked with them (years ago) to fix this.
If you have systems that use Bonjour (such as Macs), and there is a caching instance of Avahi in the network, the systems will rename themselves with numeric suffixes ('myhost-2', 'myhost-3', 'myhost-4', etc.) because Avahi caching creates false name collisions.
-
@RickyBaker said in Configuring UDP Broadcast Relay:
i think it was just from the tutorial that i used
I don't have Chromecast, so I can't go through and evaluate all of it. But just looking quickly at the list, it seems to be a bit of a kitchen sink approach. I.E. these are ports that these devices use in some way, shape or form, so forward them all.
This doesn't mean that it won't work, but that doesn't mean it's a good approach either. It's certainly not the approach a network security engineer would take.
-
@RickyBaker said in Configuring UDP Broadcast Relay:
Logitech Harmony remote
By googling "Logitech Harmony udp broadcast relay port multicast group" I found this port number and multicast group IP...and it worked! So i guess i just need to find that port number and group for any devices not working as expected across vlans. Anyone have any suggestions for tracking down the more obscure ones without a vibrant community?
-
@RickyBaker said in Configuring UDP Broadcast Relay:
Anyone have any suggestions for tracking down the more obscure ones without a vibrant community?
This may be more of an answer than you were looking for...
You can discover the ports in use by sniffing the appropriate interface on your firewall for multicast/broadcast packets originating from the host in question. Example:
tcpdump -i igc0 \( broadcast or multicast \) and host myhostwhere 'igc0' is the interface you want to examine, and 'myhost' is the name of the host you want to see packets for.
Multicast/broadcast discovery is usually unidirectional, meaning the multicast packets go from the server to the client, or from the client to the server server, but not both. In general, I would feel better about forwarding multicast packets from the trusted network to the untrusted network than the reverse.
If your trusted devices are clients in the LAN, start looking there. See if your clients are sending any multicast packets, and if so on what port.
If you don't find anything being sent by the clients, then look for packets being sent by the server on the untrusted network.
Based on what you discover, you will be able to determine which multicast ports need forwarding, which hosts they need forwarding from, and set up your forwarding accordingly.
If you have been hearing Mission Impossible music in your head while reading this, don't sweat it. It really isn't that bad. It may seem tedious at first, but you will learn a lot and have a much better idea of how things work when you are done. And if you add another device in the future, you'll know how to make it work yourself.
NB: don't create a loop by forwarding the same port both directions.
-
@dennypage said in Configuring UDP Broadcast Relay:
If you have been hearing Mission Impossible music in your head while reading this, don't sweat it. It really isn't that bad. It may seem tedious at first, but you will learn a lot and have a much better idea of how things work when you are done. And if you add another device in the future, you'll know how to make it work yourself.
NB: don't create a loop by forwarding the same port both directions.
lol thank you very much, I'm gonna give it a try. I'm def going to straight up ignore a few of them that are just not needed (like the kodak projector that really only gets used OUTSIDE the house)
@dennypage said in Configuring UDP Broadcast Relay:
tcpdump -i igc0 ( broadcast or multicast ) and host myhost
so i'm running this on a terminal of the pfsense? or on any PC that's on the LAN Wifi?
-
@RickyBaker said in Configuring UDP Broadcast Relay:
so i'm running this on a terminal of the pfsense? or on any PC that's on the LAN Wifi?
You would do the sniffing on the firewall. Assuming you have ssh enabled, that would be the best way.
-
@RickyBaker Sorry to wake this topic up but i have added the rules and I am still not able to cast to my fireTV (SSDP) which is on the IOT subnet and my phone is on LAN subnet
-
@iptvcld what interface are these rules on? IoT? Here are my IoT rules in case they are helpful:
-
@RickyBaker thank you! Are you able to share the ports for this alias?
Also have you tested this to see if it works on any Amazon FireTV devices (if you have any) - those devices use SSDP protocol.
This is my IOT - i made an alias with all the IPS that are the CastingDevice and then the CastFromNetwork alias, i just out in the LAN net and Guest Net. But i want to block it a bit better using ports.
-
@iptvcld sure:
Never done anything with a fire, but I did get the Nvidia Shields to be operable across vlans...
-
@RickyBaker thanks. The fire uses something called SSPD and not mdns but cannot locate the ports it needs yet.
-
@iptvcld i'm sure there's a more eloquent and effective way to find out but I've actually just googled and messaged various companies to ask them what the udp forwarding port the app uses and been moderately successful. Can't get the the printer to reliably talk across the vlans but that could be a "printers are terrible" thing
