UDP Broadcast Relay

[nomatt]

I'm trying to get a (for me) complex setup going, an access point with a VLAN trunk and the management VLAN as PVID, being able to communicate with a server on a different subnet but it's using UDP broadcast. So that's why I'm here as firewall rules didn't seem to solve this.

Setup:

Opt3-6: VLAN 10, 20, 30, 90 (PVID) with DHCP on them all. All are seperate "interface" with parent igc2 as the real network interface. This part seems to be working as the AP device gets a DHCP address of 192.168.90.200 on VLAN 90 (gateway 192.168.90.1). This interface is called "WLANManagement".

LAN: on interface igc1, with no VLAN, subnet 192.168.0.0/24. I have a Omada Controller server here on IP 192.168.0.244.

The server and the AP can't communicate at default.
The AP sends a broadcast from 192.168.90.200 with port udp/random to 255.255.255.255 with port udp/29810.
As I adopted it earlier on the same subnet as the server to test and update, I'm not in need of the adoption feature right now, but I'll also be needing to be able to adopt devices using the device IP and tcp/29814. This shouldn't need the broadcast relay.

I've created a broadcast-relay with the following settings:
Relay Port: 29810
Interfaces: LAN,WLANManagement
Broadcast Address: 0.0.255.255 (since communicating between 192.168.0.0 and 192.168.90.0 I assumed this)
Source Address: empty (but also tried 1.1.1.1)

I also have a firewall rule on interface WLANManagement:
protocol: IPv4 - UDP
src: WLANManagement net
src_port: *
dst: *
dst_port: 29810
gateway: *

But it's still getting blocked by the "Default deny / state violation rule".
I also tried with Port Forward before UDP broadcast relay but that didn't work either. I'm lost how to proceed as I'm not sure I've set UDP broadcast relay correctly or I'm making a mistake with my firewall rules.

EDIT: I made it work with Firewall > NAT > Port Forward for UDP/29810 and TCP/29814.

[vincentkhoo]

Hi all,

First, I want to thanks marjohn56 for developing this awesome UDP Relay application. I need some assistance here and hope someone can give me some advice.

I have make and install UBR and works well with Chromecast. My objective is allow the user to cast for 2 hour, and once i stop the service, user is not able to see the Chromecast. But after I stop the UBR services, I can still see the Chromecast, is there anyway I remove the Chromecast appearing on the user device.

Thank you

Vincent Khoo

[waka324]

Not a direct answer, but instead of jellyfin music, have you considered Roon? https://roon.app/en/

I found a forum post about your WiiM mini and Vlans here, maybe that helps also: https://forum.wiimhome.com/threads/app-option-for-fixed-ip-devices-on-another-network.127/

I have a seemingly identical issue. Did you come to a solution?

[securid]

Maybe its not related to the this but since I enabled IPv6 on the interface udp broadcast relay is enabled, it started failing to start. In the logs it just says:

Code Select Expand

2023-11-12T17:42:55 [Notice] root /usr/local/etc/rc.d/os-udpbroadcastrelay: WARNING: failed to start osudpbroadcastrelay

What can I do to troubleshoot this? I tried some different settings, like clearing and setting 1.1.1.1 or 1.1.1.2 but nothing seems to matter, it always fails to stat.

Any ideas please?

[train_wreck]

Hello, i actually don't use OPNSense, i run regular Arch Linux on an x86 firewall appliance, but i wanted to see if people knew how to solve an issue i am having. Basically, i have 2 VLANs, one for my Iphone and other things and another for IoT devices like my LG smart TV and a Roku Ultra. I am currently able to cast Youtube from my phone to either the TV or the Roku, but not both. I have the following mDNS relay running:

Code Select Expand

udpbroadcastrelay --id 2 --port 5353 --dev lan.20 --dev lan.30 --multicast 224.0.0.251 -s 1.1.1.1 --msearch dial

Then, to get the TV working I have to run:

Code Select Expand

udpbroadcastrelay --id 1 --port 1900 --dev lan.20 --dev lan.30 --multicast 239.255.255.250 --msearch dial -d -s 1.1.1.2

To get the Roku to work I have to run:

Code Select Expand

udpbroadcastrelay --id 1 --port 1900 --dev lan.20 --dev lan.30 --multicast 239.255.255.250 -d

I tried running both commands with a different ID number but this caused a multicast flood. I can apparently only run one of these at a time. I will say that Airplay always works no matter what command i use.

So is there not a way to be able to cast to both of these devices?

[_drs_opn]

Hello everyone,
I am currently trying to get this plugin working for me. I am running:
OPNsense 23.7.10_1-amd64
FreeBSD 13.2-RELEASE-p7
OpenSSL 1.1.1w
os-udpbroadcastrelay 1.0_3

I am having two VLANs setup: VLAN20 (Guest) and VLAN50 (LAN). VLAN20 contains my TV (Samsung) and VLAN50 has my client (iOS).
For the firewall rules I am having the following on both interfaces to rule out firewall issues:
pass in log quick on re0_vlan50 inet from {any} to {any} keep state label "x" # Test in
pass in log quick on re0_vlan50 inet6 from {any} to {any} keep state label "x" # Test in
pass out log quick on re0_vlan50 inet from {any} to {any} keep state label "y" # Test out
pass out log quick on re0_vlan50 inet6 from {any} to {any} keep state label "y" # Test out

I want to AirPlay and YouTube Chromecast from my iOS device to my TV.

I have set the following in UDP Broadcast Relay:
Interfaces: Guest & LAN
Multicast Addresses: 224.0.0.251
Source Address: 1.1.1.1
Listen Port: 5353
ID: 1

With that AirPlay works fine and I can see my TV in the YouTube App. But if I try to connect to my TV inside the YouTube App, it doesn't connect.
I also added the following thing to UDP Broadcast Relay:
Interfaces: Guest & LAN
Multicast Addresses: 239.255.255.250
Listen Port: 1900
ID: 2

But with that the connection is also not working.

Has anyone similar issues? Sorry for asking, but I cannot figure it out after reading this thread? Can this behavior related to that msearch dial stuff?

Thanks in advance to everyone :)

[FBachofner]

Hi @brinm00

Thanks marjohn56, this put me on the right track. It works beautifully now - can control my Logitech server from within my guest VLAN.

Could you please provide details on how you setup your firewall rules to successfully achieve this?

I am struggling with my Squeezebox finding its Logitech Media Server across VLANs.  I have it detailed in a separate thread since this one has been inactive since Dec. 18 . . . but perhaps tagging you directly will get this post some notice.

Thanks in advance.

[marjohn56]

I see a lot of questions on how to get UDPBR working, I personally only use it for relaying SKY UK from my IOT VLAN where the Sky box lives and my private VLAN where my PC's and other devices live. I have tested it in the past with Chromecast and others have tested it with Sonos etc and it works, so here's how I've set mine up.


That's it as far as UDPBR is concerned, but we need to add firewall rules to allow it also.

UDPBR will send the packets out from the primary VLAN to the IOT VLAN, so my Sky Go App running on my PC sends out the UDP broadcast packets looking for the Sky Q box that is on the IOT Lan, the Sky Q box will reply to these sending packets back to the app on my PC, but the firewall blocks them, UDPBR does not relay those packets as they are not broadcast packets, we need to allow them through in the firewall.


I only allow traffic from the Sky Q box itself to send packets back to the primary VLAN, I am not worried about whether they are TCP/UDP or what port, if you want to tie it down to specific ports you can try, but it changes whenever a new connection is made, so best to allow any.
So now the packets have made it across the firewall, but still it may not work, and that is down to the firewall on the PC in my case, I need to add an exception in the firewall rules to allow the packets from the SKY Q box on the IOT VLAN. Hey presto, it all works.

Ninety nine times out of 100 if it doesn't work it's because the firewall has not been set correctly.

[Joe]

Hi,

me also need some help to get multicast working across VLANs.

As a test, I'd want to serve an video, like this:

Code Select Expand


cvlc  BigBuckBunny_320x180.mp4  --sout "#rtp{dst=239.255.1.2,port=5004,ttl=10,mux=ts,sap,name=Bunny}" --no-sout-all --sout-keep --loop


Being on the same VLAN, I can see this video with:

Code Select Expand


vlc rtp://239.255.1.2:5004


When server and client are on the same VLAN, tcpdump shows me:

• SSDP and mDNS, advertising all kinds of services
• IGMP queries and reports, which show that the clent has actually joined the 239.255.1.2 group
• the video data on 239.255.1.2:5004

So I set up udpbroadcastrealy like this:

Code Select Expand


udpbroadcastrelay --id  2 --dev re2 --dev re2_vlan10 --dev re2_vlan12 --port 5353 --multicast 224.0.0.251 -s 1.1.1.1 -f
udpbroadcastrelay --id  1 --dev re2 --dev re2_vlan10 --dev re2_vlan12 --port 1900 --multicast 239.255.255.250 -s 1.1.1.2 -f
udpbroadcastrelay --id 20 --dev re2 --dev re2_vlan10 --dev re2_vlan12 --port 5004 -f


All the interfaces have firewall rules to pass everything. Even set "Allow IP options", which is advised to be set so that IGMP messages can be passed.

AFAICS, SSDP, mDNS and the video stream should be forwarded across the VLANs. But unfortunately, I don't see anything.

Any idea what I might be doing wrong here?

Can I advise udpbroadcastrelay to tell what it is receiving?

Thanks!

[marjohn56]

Perhaps because it's RTP and not UDP?

[Joe]

Perhaps because it's RTP and not UDP?

Not sure I understand what you try to tell me :)

You are about the video data? IIUC, tcpdump says this is UDP:

Code Select Expand


IP (tos 0x0, ttl 10, [DF], UDP)  192.168.12.101.47386 > 239.255.1.2.5004: UDP

And this is consistent with Wikipedia, where it is stated that RTP runs over UDP.

But maybe I simply misunderstood your reply?

[Joe]

Please help me get a better understanding about the topic by confirming and/or correcting some questions:

- UDPBR obsoletes Avahi, IGMP-proxy, mDNS and SSDP (if setup correctly)

- UDPBR obsoletes pimd in the simple case when there is only one router

- For proper operation, multicast depends on IGMP reports to join/leave MC-groups. Is UDPBR involved in this IGMP thing, or is this handled by the kernel?

- UDPBR does NOT depend on the setting of ip_mroute in the kernel, because it actively copies the packets in user-land?

(Edit: typo)

[Joe]

Then, to get the TV working I have to run:

Code Select Expand

udpbroadcastrelay --id 1 --port 1900 --dev lan.20 --dev lan.30 --multicast 239.255.255.250 --msearch dial -d -s 1.1.1.2

Just curious: have you set up firewall rules such that source:port (which should be unicast, IMHO) of those packets can be reached accross the networks?

To get the Roku to work I have to run:

Code Select Expand

udpbroadcastrelay --id 1 --port 1900 --dev lan.20 --dev lan.30 --multicast 239.255.255.250 -d

I tried running both commands with a different ID number but this caused a multicast flood.

When running both commands with different IDs, both instances receive all the the traffic to 230.355.255.250:1900. This includes traffic from the other instance, respectively. Thus, packets sent by one instance are received by the other instance and will be re-sent on all configured interfaces by the other instance (if not filtered by --msearch). This results in the two instances playing ping-pong with packets containing the --msearch string, effectively flooding the networks.

The clean way to get this working would be to have only one instance and let the result of --msearch decide whether source address/port is to be preserved or replaced instead of completely discard the packet.

I just digged through this thread, and found more contradicting suggestions:

Code Select Expand


mDNS (Chromecast/Apple Bonjour)
224.0.0.251:5353                 -s1.1.1.1
224.0.0.251:5353 224.0.0.51:5353 -s1.1.1.1
224.0.0.251:5353
224.0.0.1:5353

SSDP (UPnp/DLNA Media)
239.255.255.250:1900
239.255.255.250:1900 -s1.1.1.1


So it seems you are not the only one having this problem. You're just the first one who did a systematic analysis of the problem.

PS:
To be honest, I have a hard time to understand what this 1.1.1.1/1.1.1.2 is good for and how it is supposed to get things working.

Without this mangling, the receiver will respond to the original unicast address:port. As long as receiver can do unicast with the original address:port (check firewall rules), communication should work, IMHO. All is good.

OTOH: having this -s mangling in place, UDPBR would put its own interface-address (which would be UNICAST) (and port with 1.1.1.1) into the packet. Unless it also listens to this address:port and remembers to forward traffic to the address:port which were sitting in the original packet, I don't see how this is supposed to work. Have just done a quick glance on the source and I don't think UDPBR is currently doing this forwarding.

So, if I understand things correctly, this -s option is only good for breaking things. Please correct me if I am wrong.

Please double-check that both sides can properly do unicast-communication for the ports/protocols they need to the other side.

[scot]

I got this working after several failed attempts over the years (mostly with igmp proxy). But with UDP Broadcast realay it was pretty simple.

For my config there is an assumption or two

1. Devices on my "trusted" vlan can speak to the IOT vlan (but not the reverse by default) though the primary allow any any rule. The only outbound blocks it to a guest vlan.

https://imgur.com/DFy4cs1

2. Devices on the IOT vlan have a rule right above this specifically restricting access by default to all other vlans (with a few specific exceptions for things like DNS).

So for the setup.

First the UDP relay. I left the source addresses blank. Theres no NAT here. Which is really the main reason i could maybe see to need to spoof the source interface

https://imgur.com/rguquhN

THen when looking at the live view of the firewall on the IOT interface i noticed the drops to the specific devices...like my iphone.

Example: https://imgur.com/Rcpnyf4

So i whipped up a rule on that interface (or 2)

https://imgur.com/jeBAsBz

Airplay works. The roku app works as well. Private listening kinda always worked but i had to manually connect to the roku by typing the IP. Now its discoverable which is quite nice.

[nerd]

Any ideas to debug this?

2024-03-25T17:21:11   Notice   root   /usr/local/etc/rc.d/os-udpbroadcastrelay: WARNING: failed to start osudpbroadcastrelay   
2024-03-25T17:21:11   Notice   root   /usr/local/etc/rc.d/os-udpbroadcastrelay: WARNING: failed to start osudpbroadcastrelay