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

stephenw10

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. Or be more secure and do neither.

Steve

spaceboy

Took a look at this as i was hoping it could help me overcome what PIMD seemingly could not, that is the initial discovery of SONOS devices on other VLANS. My set up was working fine once the controller had been connected to the SONOS VLAN and cached the ip addresses.

Unfortunately it does not. Followed what seems to be the fairly straightforward step by step guide by Qinn in post 55 and everything seems to work but nothing is discovered when i restart the pfsense.

Shellcmd per below

is there any way i can check it is properly running? other than SONOS detection working :)

CaptainCathode

@spaceboy - a few suggestions based on my trial and error experiences.

SSH to the console and check if the process is running:

[2.5.1-RELEASE][user@pf.internal.xxx.net]/home/user sudo ps | grep udpbroadcastrelay
13600 u0- S    0:02.44 /usr/local/sbin/udpbroadcastrelay --id 1 --port 1900 --dev igb1 --dev igb2 --multicast 239.255.255.250 -f

Check the path to the udbbroadcastrelay executable:

find / -name updbroadcastrelay

My working shellcmd entry is:

/usr/bin/nohup /usr/local/sbin/udpbroadcastrelay --id 1 --port 1900 --dev igb1 --dev igb2 --multicast 239.255.255.250 -f > /dev/null

Run pfTop From the diagnostics menu and filter on port 1900. You should be able to see your Sonos devices periodically connecting:
Screenshot 2021-04-29 104221.jpg

Also check that you don't have anything else on pfSense running a process bound to UDP/1900 on the same subnet/vlan. I initially had UPnP/NAT-PMP running for the XBox that's on the same subnet as my Sonos devices. That stopped udpbroadcastrelay from working so I made an executive decision that my kids could live without being able to host games and disabled UPnP for the Xbox

Hope that helps

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?

MG85

@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?

Qinn

@stephenw10 You mean Oracle VM or pfS version?

VirtualBox Graphical User Interface Version 7.0.6 r155176 (Qt5.15.2)
pfS 2.6.0 release CE

stephenw10

The pfSense and pkg versions.
And also what exactly you did to trigger it. It seems to work as expected for me in 23.01.

Steve

stephenw10

Ah, Ok. Note that the package build 26/12/2022 that's on the redmine is for 2.7 or 23.01 only right now.

Qinn

Missed out that one ;) try an install on the beta (2.7.0) soon