Configuring UDP Broadcast Relay
-
I've read the few threads I could find on here, primarily:
- https://forum.netgate.com/topic/155698/how-can-i-get-this-udp-relay-package-for-casting-across-vlans/115
- https://docs.netgate.com/pfsense/en/latest/packages/udpbroadcastrelay.html
- https://forum.netgate.com/topic/174725/udp-broadcast-relay) about UDP Broadcast Relay
and it sounds like exactly what I need. I have created a few VLAN and everything is working wonderfully EXCEPT viewing Google Home Speaker Groups from the IOT VLAN when the device is on the LAN. My questions are:
- Do I need to disable Avahi for this to work?
- Do I need to include the WAN interface when selecting the interfaces during Instance configuration, for instance port 5353 on interfaces LAN, IOT AND WAN (or omit WAN)
- I assume I no longer need the shellcmd autostart script, correct?
- Any recommendations for what ports to include? mDNS, Google Home Speaker Groups and LIFX discovery.
-
@RickyBaker bump? If there's anything i should/could include to help elicit some sort of help, please pass that on
-
@RickyBaker I used a blog post initially to get speaker groups working and since migrated to the new package. See https://iambartlett.com/blog/pfsense-chromecast-and-speaker-groups
Before moving to the new interface, I removed the FreeBSD package I manually installed and removed the shellcmd.
I do not use Avahi and only use the associated (non-WAN) interfaces with port 5353 in the rule. The destination is the multicast address 224.0.0.251.
It's possible that my firewall rules are a little different since I followed the guide, as it's been a while. Hopefully this points you in the right direction.
-
@pecan Thanks so much for sharing your experience.
To the best of my knowledge I never installed a different FreeBSD, so that shouldn't be the issue. I did insert the Shellcmd command but pretty quickly realized it was pertinent to a pre-authorized package install (I followed the same guide) and deleted it. I did have Avahi but had them running concurrently for a short bit before realizing the conflict. Maybe a reboot was warranted when one makes that mistake....
But i for sure didn't put in the destination multicast address of 224.0.0.251, i thought i'd want multicast to work on all addresses (a fundamental misunderstanding I now realize).
My only question is whether you still have the firewall rules detailed in that tutorial enabled?
If so, I think my next troubleshooting workflow is:
Disable Avahi
Enable both Firewall rules (i used Aliases for each group of TCP and UDP ports)
Enable UDP as well as both instances 5353 and 1900 (though maybe 1900 isn't necessary?)Anyways, I'll try this out when in arms reach of the firewall and report back. Thanks for the color!
-
@pecan It works! thanks so much for your help!
-
@pecan Did you ever have to add any other ports into this? Chromecast (and LIFX) work rock solid since switching to UDP Broadcast relay, but I've noticed that a number of my other iot devices having issues.
For example the following devices are NOT able to be accessed by their respective apps on my phone when connected to LAN Wifi, but can be accessed when connected to the IOT VLAN Wifi (parenthesis has specific idiosyncratic info)
*Epson printer (interestingly, when my laptop is connected to LAN Wifi, it CAN access the printer)
-
Logitech Harmony remote
-
the VSSL app won't show my VSSL A.6's
-
Epson Projector app (this one interestingly DOES work after connected via IOT VLAN Wifi if I switch back to LAN Wifi, but not if I start on LAN Wifi)
-
Deebot Ecovacs
-
Denon Receiver (this one interestingly DOES work after connected via IOT VLAN Wifi if I switch back to LAN Wifi, but not if I start on LAN Wifi)
-
Kodak Luma projector
I am able to ping many of these devices from the same phone connected to LAN Wifi so I'm extra stumped. (haven't tested all of them, but most of them).
I also can't ssh into a windows pc on a different VLAN but i suspect that one is Windows related, but I don't have any other windows devices on vlans so it's difficult for me to test...
This is what i currently have:
-
-
@RickyBaker For mDNS (port 5353) you probably want to use Avahi instead of a broadcast repeater. Port 1900 is not mDNS btw, that's SSDP.
-
@dennypage I had total breakdown when I tried to run avahii and UDP broadcast relay concurrently. Would you mind sharing your settings if the 2 tools please?
-
@RickyBaker
In Services -> Avahi:- Select "Enable the Avahi daemon"
- Select your interfaces via either the Allow or Deny approach.
- For simplicity, I recommend that you select "Disable support for IPv6".
- Select "Enable reflection".
- Add filters if you want, although I recommend that you test first without them.
Other notes:
- Do you actually need SSDP forwarded?
- Your OpenVPN interfaces may not work with broadcast.
-
@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
