How can I get this UDP relay package for casting across VLANs?

spaceboy

@captaincathode thanks for the pointers, i think it helped a bit. linux doesnt really like me much so took me a little while to work through this.

i think its running on the pfsense now. in the console i see

for me executing that command to check the path to the udbbroadcastrelay executable returns nothing but i don't know if this is some result of me ssh'ing via admin or what? i also noticed the sudo command wasnt needed on the previous and i understand just enough to know thats related to the admin account.

I moved the executable from /root to /usr/local/sbin to match yours but i kept it in a subfolder so my shellcmd is

and in pftop i see
which seems to me to be good.

but the result is still the same. nothing found by controllers on either windows, android or ios. so i guess whatever the problem is it was probably the same for pimd and that was working too.

my uneducated thought process says there must be something else on the network blocking the broadcast. i have a few switches and a unifi controller running the wireless AP's. is it possible any one of these could be blocking the multicast?

A Former User

@spaceboy you’re saying you have Unifi deployed. Do you by chance have the “Auto Optimize” function or “Block LAN to WLAN multicast and broadcast” enabled? These might be the culprit.

Otherwise, you might want to look into:

Whether your interfaces (vlans) match in the shellcmd command
Firewall rules that block communication

spaceboy

@mg85 thanks, i do have Auto Optimize enabled but not the second.

Also i previously had this working under PIMD once the SONOS controller cached the SONOS devices ip addresses so i don't think its firewall rules.

To be honest i have given up on this for now. I believe i did try with my Sonos One wired into one of the switches to try and determine whether unifi was to blame and i don't think it worked. So i feel it may be more than unifi.

I'm also questioning whether IOT stuff and Sonos devices need seperate VLANs anyway. it was a nice little project but i'm not certain its worth the effort given the large number of ports i have seen people posting about need to have open even once multicast is working. Actually on that point, i'd be interested in understanding people's driver for segregating SONOS devices like this.

Hope to give this another try at some point. Ta

bitrot

This was an immensely helpful thread for me. Yet I had problems still with discovery. It turns out that I needed to do additional work because I have Captive Portal setup on my IoT VLAN
I resolved that issue here: https://forum.netgate.com/topic/164733/captive-portal-causing-sendto-permission-denied-errors-with-udpbroadcastrelay
Leaving a reference to it here. Maybe it'll help someone else.

grillp

Super helpful thread!

I have aVLAN for IoT devices and found this thread to help setup the "Bonjour/Chromcast/mDNS" broadcast between my main vlan and IOT vlan.

After starting the udpbroadczatrelay I was seeing devices on my vLAN appear, albeit slowly, and periodically disappearing. I used Bonjour Browser (Discovery app from the OSX App store) on my Mac to monitor it. I also ran avahi-browse -a on a wired LAN device to watch the comings and goings of the iOT devices.

One minute they were there, the next they were gone and did not come back.

I also could not use the <my_iot_device>.local dns lookups for those IOT devices from my main LAN (.local look up also use mDNS).

I then put udpbroadcastrelay into debug mode (-d) and only saw traffic going LAN vlan -> my IOT vlan, but not the other way around. So no broadcast traffic being received into updbroadcastrelay from the IOT vlan.

I then added a rule to my firewall in Firewall > Rules > IOT (where IOT is my vlan interface) to allow incoming traffic to the IOT vlan Interface, from the IOT net, with destination being the broadcast IP (224.0.0.251) and the broadcast port (5353):

And everything started working! All my devices are now rock solidly discoverable, and the .local look ups work fine!

It still does not explain why without the rule the devices were showing up intermittently, but it all seems to work now!
Thanks to everyone that added to this thread!

stephenw10

What rules did you have there before? I assume you were seeing blocked traffic on IOT?

I expect to need the IP options flag set in a rule for multicast traffic like that.

Steve

grillp

@stephenw10 said in How can I get this UDP relay package for casting across VLANs?:

I assume you were seeing blocked traffic on IOT

I had a rule which allowed UDP traffic on port 5353 on the IOT interface, but the destination was an RFC1918 alias (Non Routeable IP Addresses), which I then changed to to 244.0.0.251 to make it work.

I wonder if mDNS clients also send out to other multicast addresses at times, which is why some slipped through?

Now I have:

DNS rule required to get my MQTT adddress through DNS.

Then the invisible, default DROP Everything rule, so I could not see what else was being blocked.

bitrot

@grillp

The UDP relay package is only one part of this puzzle. It helps the secure LAN side "discover" your Bonjour/Chromecast/mDNS/Sonos/SSDP/etc devices.

But in addition to that, you are going to have to punch some holes into your firewall so that those devices can communicate with stuff that's on your secure LAN.

This post helped me with Sonos stuff but can also be used as a basis for anything else.: https://www.reddit.com/r/Ubiquiti/comments/gu19sa/iot_vlan_settings_specific_to_sonos/

Here's what the end result looks like in the firewall rules on my IoT interface
son is an alias containing the IPs of Sonos hosts
Sonos_TCP0, Sonos_UDP0, Sonos_TCP1, and Sonos_UDP1 are aliases for the ports needed, as outlined in the Reddit thread specific to Sonos. These might not apply to your situation. But remember, your IoT devices might require being allowed to initiate some traffic to your LAN devices. Unless you open up the ports required, things might not work right.

brswattt

@stephenw10 Hey stephen, I know this is an old thread but I didn't want to PM you.

I have this same scenario. UPnp was nice for online services like Xbox, Call of Duty, etc.
You mention accepting and using the SSDP packets with UPnP. How is something like this achieved?

stephenw10

Can you clarify that? The UPnP service in pfSense only supports the Internet Gateway Device part of the protocol.

Steve

brswattt

@stephenw10 said in How can I get this UDP relay package for casting across VLANs?:

Can you clarify that? The UPnP service in pfSense only supports the Internet Gateway Device part of the protocol.

Steve

That's for port forwards right? What did you mean by this? "Yes, you can't have two processes listening on the same port like that. You can either relay the SSDP packets or accept and use them with UPnP."

I understand that upnp uses port 1900, and so does this udpbroadcastrelay, but is there a way to get them both working?

stephenw10

Ah, OK. No, that's still true. I would not expect to be able to both accept UDP port 1900 packets into the UPnP process and relay them at the same time.
Unless perhaps the relay process were also relaying them to UPnP?
I've never tried that. I could see many ways that might also not work.

Steve

tman222

Just wanted to follow up on this thread and mention that udpbroadcastrelay still works flawlessly under pfSense 23.01/FreeBSD 14.

It looks like there have been a few updates to the code since I first started using it:

https://github.com/marjohn56/udpbroadcastrelay

Also, it is great to see that a lot of work has already been done to turn this into a formal pfSense package:

https://redmine.pfsense.org/issues/10818

GeorgeCZ58

What is actual approach to install this package to 23.01?

bitrot

@georgecz58 said in How can I get this UDP relay package for casting across VLANs?:

What is actual approach to install this package to 23.01?

Good question. I'd like to know this too. I still have it installed manually as per instructions in this post. The package doesn't appear to be available yet. Not sure what the status is. Bug report is here: https://redmine.pfsense.org/issues/10818

stephenw10

It's not been merged yet so you still need to fetch and install it manually:

[23.01-RELEASE][root@4100.stevew.lan]/root: fetch https://redmine.pfsense.org/attachments/download/4621/pfSense-pkg-udpbroadcastrelay-1.0.pkg
pfSense-pkg-udpbroadcastrelay-1.0.pkg                   12 kB 7983 kBps    00s
[23.01-RELEASE][root@4100.stevew.lan]/root: pkg install pfSense-pkg-udpbroadcastrelay-1.0.pkg 
Updating pfSense-core repository catalogue...
pfSense-core repository is up to date.
Updating pfSense repository catalogue...
pfSense repository is up to date.
All repositories are up to date.
The following 2 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
	pfSense-pkg-udpbroadcastrelay: 1.0 [unknown-repository]
	udpbroadcastrelay: 0.3.b [pfSense]

Number of packages to be installed: 2

15 KiB to be downloaded.

Proceed with this action? [y/N]: y
[1/2] Fetching udpbroadcastrelay-0.3.b.pkg: 100%   15 KiB  15.3kB/s    00:01    
Checking integrity... done (0 conflicting)
[2/2] Installing udpbroadcastrelay-0.3.b...
Extracting udpbroadcastrelay-0.3.b: 100%
[1/2] Installing pfSense-pkg-udpbroadcastrelay-1.0...
[1/2] Extracting pfSense-pkg-udpbroadcastrelay-1.0: 100%
Saving updated package information...
done.
Loading package configuration... done.
Configuring package components...
Loading package instructions...
Custom commands...
Executing custom_php_resync_config_command()...done.
Menu items... done.
Services... done.
Writing configuration... done.

tman222

@stephenw10 said in How can I get this UDP relay package for casting across VLANs?:

It's not been merged yet so you still need to fetch and install it manually:

[23.01-RELEASE][root@4100.stevew.lan]/root: fetch https://redmine.pfsense.org/attachments/download/4621/pfSense-pkg-udpbroadcastrelay-1.0.pkg
pfSense-pkg-udpbroadcastrelay-1.0.pkg                   12 kB 7983 kBps    00s
[23.01-RELEASE][root@4100.stevew.lan]/root: pkg install pfSense-pkg-udpbroadcastrelay-1.0.pkg 
Updating pfSense-core repository catalogue...
pfSense-core repository is up to date.
Updating pfSense repository catalogue...
pfSense repository is up to date.
All repositories are up to date.
The following 2 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
	pfSense-pkg-udpbroadcastrelay: 1.0 [unknown-repository]
	udpbroadcastrelay: 0.3.b [pfSense]

Number of packages to be installed: 2

15 KiB to be downloaded.

Proceed with this action? [y/N]: y
[1/2] Fetching udpbroadcastrelay-0.3.b.pkg: 100%   15 KiB  15.3kB/s    00:01    
Checking integrity... done (0 conflicting)
[2/2] Installing udpbroadcastrelay-0.3.b...
Extracting udpbroadcastrelay-0.3.b: 100%
[1/2] Installing pfSense-pkg-udpbroadcastrelay-1.0...
[1/2] Extracting pfSense-pkg-udpbroadcastrelay-1.0: 100%
Saving updated package information...
done.
Loading package configuration... done.
Configuring package components...
Loading package instructions...
Custom commands...
Executing custom_php_resync_config_command()...done.
Menu items... done.
Services... done.
Writing configuration... done.

@stephenw10 - with 23.01 having been released, any idea when this might become an official pfSense pacakge? Judging by the Redmine ticket it looks like the majority of the work has already been completed. Is more community testing needed?

stephenw10

It might just need a nudge. Let me see what I can do....

Qinn

Just out of curiosity I tested it with a VM (Oracle) and ran into a php error

PHP errors

    PHP ERROR: Type: 1, File: /usr/local/pkg/udpbroadcastrelay/udpbroadcastrelay.inc, Line: 458, Message: Uncaught Error: Call to undefined function config_get_path() in /usr/local/pkg/udpbroadcastrelay/udpbroadcastrelay.inc:458
    Stack trace:
    #0 /usr/local/pkg/udpbroadcastrelay/udpbroadcastrelay.inc(202): udpbr_get_settings(true)
    #1 /etc/inc/pkg-utils.inc(802) : eval()'d code(1): udpbr_resync()
    #2 /etc/inc/pkg-utils.inc(802): eval()
    #3 /etc/inc/pkg-utils.inc(928): eval_once('udpbr_resync();')
    #4 /etc/rc.packages(76): install_package_xml('udpbroadcastrel...')
    #5 {main}
    thrown @ 2023-03-20 13:53:47

stephenw10

You should add that to the open redmine issue: https://redmine.pfsense.org/issues/10818

What version were you testing against there?