OPNsense Forum
English Forums => General Discussion => Topic started by: marjohn56 on February 03, 2020, 06:34:50 pm
-
Opening a discussion here to move this daemon development forward. Although my work on the plugin is complete and working well, testing of the daemon itself, while not having any issues with it performing in the way it's designed, has brought up some options that may improve it further. We've been doing some of this by PMs, but it will be easier to throw it open to all.
@bertofurth has been doing some work on the daemon code and we want to reach out for further testing. I'll let him kick off with what he has discovered.
-
Hi everyone,
Thanks for welcoming me to this forum. I'm not very experienced with OPNsense or FreeBSD but marjohn56 has been extremely helpful and generous with his time trying to bringing me up to speed.
I wanted to get your feedback in regards to the "udp-broadcast-relay" tool. It's a similar concept to the "mdns-repeater" plugin but for other UDP based discovery protocols as well.
I'm going to dedicate this particular message to how the tool, in it's original form, currently works (Cutting and pasting from the docs I'm trying to write). If you're already familiar with the tool then please go to my next post where I'm going to point out some small problems I've found and some questions I have and ask for some feedback about what (if anything) should be done.
udp-broadcast-relay is a tool that allows automatic network discovery and configuration protocols that normally only work within a single LAN to successfully operate over multiple subnets / VLANs / broadcast domains.
The way udp-broadcast-relay works is that it listens for broadcast or multicast packets on a specified UDP port and then relays the packets to other specified interfaces.
Some examples of UDP based Network Discovery Protocols include...
- mDNS (Chromecast, Apple Bonjour Networking, others)
- SSDP (UPnP, DLNA Media Servers, others)
- Microsoft Windows Network Discovery without preconfigured AD or WINS server
- Multi Player Game Server Discovery (Minecraft, Warcraft, etc)
- IoT Device Discovery (Sonos Speakers, Lifx Bulbs, etc)
A separate instance of udp-broadcast-relay is run for each UDP port being relayed and each instance is assigned a unique numerical "ID" by the user. By default udp-broadcast-relay listens for broadcast packets but can be configured to listen for protocol specific IP multicast addresses instead.
Packets received by the tool are relayed as they have come from the original broadcaster except...
- The source IP may be optionally set as either the original packet source IP (default), another specific IP address, or to the IP address of the outgoing interface.
- For broadcasts the destination subnet wide broadcast address is modified to suit the output interface. So an incoming UDP broadcast with destination (e.g.) 192.168.1.255, might be relayed to an output interface with a corresponding modified address of (e.g.) 192.168.99.255, or 10.2.3.255, depending on the IP address of the outgoing interface.
- The TTL is NOT decremented by 1 like a normal router would do. Instead it is set to a value corresponding to the ID of the udp-broadcast-relay instance that is being run (ID + 64).
On the behavior with TTL, this is so that the tool can use the TTL as a kind of "tag" to identify already relayed packets in order to avoid floods. If it sees that an incoming packet has the same TTL as the "tag" value then it is discarded. This is useful in networks where broadcasts/multicasts are incorrectly transmitted back to the source by faulty/poorly configured switches. It also means that if packets are being relayed by one router, but then need to be relayed by another, then the two instances of udp-broadcast-relay running on the separate routers need to use different IDs otherwise the second router in the path will discard the packets.
This tool is geared towards home networks, or to small business networks where administrators don't have the time or resources to set up such things a Windows Servers with Active Directory, or DNS servers that cater for an Apple Networking environment. Where the tool only operates over a small number of networks the extra overhead of relayed broadcasts is not at all detrimental.
It is not easily suited to a sophisticated corporate or service provider network with a large number of subnets. In these cases there's the potential for this tool to generate a very large number of broadcasts across networks. In networks where there are multiple redundant paths between subnets there is the potential for loops to occur unless very careful configuration is applied. Since this tool does not decrement IP header TTL, if loops occur then packet storms can result.
I have attached a screen shot of the beta plugin written by marjohn56 as running on my network. I have tested Chromecast, Apple Networking, Windows Network Discovery, Media Service Discovery, and some gaming apps across subnets and they appear to work nicely.
One thing to note is that Chromecast mDNS Discovery works *WELL* with this tool. What tends to happen with some other similar tools (e.g. avahi reflector. (N.B. Correct me if this is now wrong)) is that Chromecast devices on other subnets will pop in and out of the list of available devices.
This is because most Chromecast devices are programmed to ignore discovery packets from sources not in the local subnet. This means that relayed client discovery packets are discarded and clients are only seeing remote Chromecast devices briefly when the Chromecast devices periodically announce themselves every 2 or 3 minutes.
The udp-broadcast-relay tool has the ability to set the source IP address of relayed discovery packets to the local IP address of the outbound router interface. This means that remote Chromecast devices do not ignore discovery packets forwarded from remote clients and they answer the requests straight away.
When using this tool firewalls, NAT and other such facilities operating on the host system need to be taken into account. This tool does not automatically create firewall rules that allow discovery traffic to flow between clients and servers, or for servers to respond to clients. In addition this tool does not disable any configured NAT rules for relayed packets.
If another service on the host system is using a UDP port that is also specified as a port for a udp-broadcast-relay instance then there may be a conflict causing either the service or udp-broadcast-relay to fail. Use a command such as "sockstat -l -P udp" or "netstat -p udp -n" to view UDP ports that are currently in use on a system.
Here are some examples follow of how to configure this tool in the proposed OPNsense plugin for common Broadcast/Multicast based discovery systems. (Please help add to this list if you know of other UDP based protocols that work in a similar way). Note that in all cases you also need to specify at least 2 interfaces, and specify a unique ID. Also note that the special value "Source Address = 1.1.1.1" means to relay packets using the outbound interface IP address.
mDNS (Chromecast/Apple Bonjour) : Port = 5353, Multicast Address = 224.0.0.251, Source = 1.1.1.1
SSDP (UPnp/DLNA Media) : Port = 1900, Multicast Address = 239.255.255.250
Windows Networking Netbios Name Service : Port = 137
Windows Networking SMB : Port = 138
Syncthing Discovery : Port = 21027
Lifx Bulb Discovery : Port = 56700
Broadlink IR Emitter Discovery : Port = 80
Warcraft 3 Server Discovery : Port = 6112
Thanks everyone
-
My previous message in this thread details how udp-broadcast-relay works.
Here I'd like to note some of the problems, observations and questions I've had while testing the tool using the latest beta plugin written by marjohn56. Please comment on one, some or all. I've summarized them here and I've put the details of each further below....
1) Should we change the tool to preserve TTL and use something else as the "ID" marker (maybe DSCP)?
2) Should we allow multiple multicast addresses to be specified per instance (e.g. mDNS on 224.0.0.251 and non standard 224.0.0.250)?
3) How important / useful would be adding IPv6 functionality?
4) When creating a plugin like this one based on an existing external tool that hasn't really been actively maintained, how much modification is it normally acceptable to do?
5) Very rare corner case involving "IPv4 Upstream Gateway" and Multicasted packets.
Details:
1) TTL : The tool currently marks the TTL of outbound relayed packets with a value of (instance ID + 64). The problem I see here is that I suspect there are some devices out there that are picky about the TTL because they want to ensure that they are only dealing with local traffic. For example from https://tools.ietf.org/html/rfc6762#section-11 (https://tools.ietf.org/html/rfc6762#section-11)
11. Source Address Check
All Multicast DNS responses (including responses sent via unicast)
SHOULD be sent with IP TTL set to 255. This is recommended to
provide backwards-compatibility with older Multicast DNS queriers
(implementing a draft version of this document, posted in February
2004) that check the IP TTL on reception to determine whether the
packet originated on the local link. These older queriers discard
all packets with TTLs other than 255.
To be frank, I haven't seen any direct examples of this kind of behavior. Does anyone know of examples where devices are picky about TTL?
I have tested a modified version of the tool that uses IP DSCP as the field to mark and preserves the TTL of the original packet. Since DSCP is only 6 bits it means that the range of the instance ID shrinks from (1 - 99) down to (1 - 63). I didn't touch the ECN bits (least significant 2 bits in ToS) because I've seen some evidence that a small number of hosts might not like it when ECN is modified inappropriately.
Another alternative might be to use the IP Packet Header Identification field to store a "tag" but it may be that some devices might react poorly to seeing a lot of packets with the same IP ID.
2) Multiple Multicast Addresses per instance.
I've been informed that in some cases mDNS can not only use the standard 224.0.0.251 address but might also use a non standard 224.0.0.250 address as well. Is this common? Does this happen in any other discovery protocols that you know of? If so then we might need to consider adding support for Multiple Multicast Addresses per entry. I *think* the original tool supports this now, but the beta plugin for OPNsense doesn't. Thoughts?
3) IPv6 : The original tool only supports IPv4. Do you think there's any significant call for IPv6 support? In my own network which is dual stacked I noticed that a fair few devices are sending discovery messages with both protocols. That being said everything still worked fine with IPv4 only. If an IPv6 version were developed should it be integrated into the original or should it become a completely separate tool and plugin?
4) How much to modify the original : What's the consensus on how much a tool being converted to an OPNsense package can be modified or improved? I have some suggestions seen above here in regards to TTL and IPv6 which would significantly alter the original tool. Given that the tool doesn't seem to be really under significant active development is that appropriate to do or do we want to stick as closely as possible to the original?
5) Corner case with "IPv4 Upstream Gateway" and Multicast packets (rare)
I've left this one till last because it is the least important issue, and I don't expect many others to encounter it but it's the one I spent the most time and effort trying to troubleshoot and therefore I have some emotional investment in it!! I couldn't get Chromecast working properly while this problem was present.
To summarize, if an interface is configured with an explicit "IPv4 Upstream Gateway" pointing at host "w.x.y.z", then an automatic rule is generated that for some reason causes pf to set the destination MAC address to "01:00:5e:x:y:z" for all multicast traffic _originating_ from the interface (that is, using the source IP address of the interface)
This means that multicast traffic generated from the interface has an invalid multicast mac address and it is therefore dropped by receiving hosts and other network devices (like my OpenWRT based access point.)
A bug was raised about this behavior, but for some reason it wasn't fixed and it looks like it's not going to be.
https://github.com/opnsense/core/issues/3629
The issue affects other multicast related plugins like "mdns-repeater" and it also occurs when you do a simple "ping" to a multicast address with a source IP of an affected interface.
The workaround/solution for me was simply to remove the explicit "IPv4 Upstream Gateway" on my affected interface and set it back to the default of "Auto-detect". (I tested this and everything worked fine with Chromecast after I did this) The bug implies that another workaround is to construct an extra pf rule on the affected interface that excludes multicast traffic from the auto-generated "IPv4 Upstream Gateway" rule.
The problem with all of this is that I misinterpreted the purpose of this "IPv4 Upstream Gateway" field. Based on the name of the field I thought it was to specify a host to use as a default gateway if the interface was up but it's something else entirely. I didn't need to specify it but as I was configuring the affected interface for the first time I thought it was something I had to set up.
Thanks everyone, I look forward to your feedback.
-
I'll throw some responses in here, as I started the whole shebang. In answer to your questions
- If this does not affect anything that uses DSCP then I think it's a good idea, remembering that changing the TTL was why we use it in some cases.
- I have gone back to the original Linux version and can see no reference to multiple multicast instances, where did you see that?
- Not much I think, as IPv4 is never going to disappear or only if certain devices are IPv6 specific, which I doubt we'll see in our lifetime!
- I think as long as you give credit to the original and state where the fork came from you can do what you wish, a bit like Opnsense. :)
- That one is for the devs. Franco if you read this it's your baby, or we could add a rule creation to the plugin itself.
-
Hi marjohn56,
Thanks again for the excellent work you did to produce this plugin. I'm already using it at home and now my kids can play minecraft together without me having to make sure their iPads are on the same SSID!! :-)
With the multiple mcast addresses, if you run the binary with multiple "--multicast <addr>" specified then it will listen for multicasts using all the specified addresses. e.g if you wanted to relay udp port 7777 being sent using either 224.1.1.1 or 224.2.2.2 you could use.....
root@OPNsense:~ # /usr/local/sbin/udpbroadcastrelay --id 22 --dev re0 --dev re0_vlan7 --port 7777 --multicast 224.1.1.1 --multicast 224.2.2.2 -f -d
ID set to 22
Port set to 22
Forking Mode enabled
ID: 22 (ttl: 86), Port 7777
re0: 1 / 10.0.2.10 / 10.0.2.255
re0_vlan7: 6 / 10.0.7.1 / 10.0.7.255
found 2 interfaces total
IP_ADD_MEMBERSHIP: 10.0.2.10 224.1.1.1
IP_ADD_MEMBERSHIP: 10.0.7.1 224.1.1.1
IP_ADD_MEMBERSHIP: 10.0.2.10 224.2.2.2
IP_ADD_MEMBERSHIP: 10.0.7.1 224.2.2.2
Done Initializing
I thought this might be useful because I was lead to believe that mDNS might sometimes work on multiple multicast addresses at the same time (both 224.0.0.251 and 224.0.0.250) but it seems that this probably isn't the case.
Does anyone know of any multicasted discovery protocols that work on different mcast addresses but the same UDP port?
Completely agree on the IPv4/IPv6. I was just wondering if anyone had an example of a case where they needed IPv6 urgently.
Thanks again marjohn56!
-
OK, I'll add the option to add multiple multicast addresses. Hopefully I can do it this weekend.
-
Great thread
Marjohn has done some great work getting the plugin sorted. One day he will forgive me for all the work I caused him by saying “eh take a look at this pimd thing I’ve found” as always he did his normal “that’s really good but here’s something better”
Back to the questions
I’ve not needed to specify more than one mcast address but I agree allowing it will future proof the plugin
I like the idea of using the DSCP as the id and allowing the user to manually set the TTL value maybe via advanced options. Again future proofing
-
Multiple multicast is done, I'll post it later. I cannot do the Instance ID/TTL change until the daemon is updated. I'll send out the plugin shortly.
-
Hi marjohn56,
I couldn't see a way to add an attachment to a PM so here are my proposed changes attached to this public post!!
I've attached 2 files that I've modified and I think will help to move udp-broadcast-relay to using DSCP for ID marking rather than TTL.
I've put a switch "-t" in to revert back to the original behavior of using TTL in case anyone finds that modifying DSCP causes problems.
Because DSCP is only 6 bits, I've had to reduce the range of the ID from 1 -> 99 down to 1 -> 63. Is that ok? If not then we can just make it DSCP == (id & 63) or something.
I've also fixed a few small bugs and spelling errors and I've added a few things to the "help" dialog of the cli.....you might not like that stuff so feel free to remove it.
I tested the compiled binary and it seems to work well with your most recent plugin. Everything in my network still seems to see each other.
Thanks marjohn56!
berto.
-
Oh one more thing...I was going to suggest that if you approve of the "-t" option to revert to the ttl to being the tag then perhaps it could be added as an "Advanced" option in the OPNsense plugin.
Thanks again!
berto.
-
OK, I'll take a gander. I'll PM you.
-
Hi guys,
I dont need/use any functions of this tool, but if you have a stable version, a stable repo and a stable build process, I can add it as a port to FreeBSD to make it some kind of official so the plugin get's merged.
-
Thanks Michael, I'll checkout Berto's changes and then I'll update the repo that's waiting on ports now.
-
Hi guys,
I dont need/use any functions of this tool, but if you have a stable version, a stable repo and a stable build process, I can add it as a port to FreeBSD to make it some kind of official so the plugin get's merged.
Updated the commit on ports. It's there waiting for you to do your thing. This has 'quite considerable' changes, tidy ups and additions that Berto has done too.
-
Which commit on ports? I only saw a force push to the plugin branch ...
-
Opnsense.. Ports.. pulls.. also on mirc
-
Hi,
I would like to test your plugin.
Can you tell me where to get and how to install it? Is there a ready to install binary or do I have to setup a OpenBSD build machine and compile it?
-
https://forum.opnsense.org/index.php?topic=15910.0 (https://forum.opnsense.org/index.php?topic=15910.0)
-
Sorry to hijack but I figured this would be the best place to post this:
I'm trying to enable port 5353 for chromecast etc, but the service won't start. Relevant log locations? same for port 1900.
Quick edit, Disabling the mdns repeater service allows me to start the 5353 forwarder but 1900 still doesn't start
-
Upnp plugin?
-
Upnp plugin?
Yes! good catch. needs nat pnp disabled correct?
Edit: Rather, What needs to be configured for them to play nicely together?
Edit 2: nvm, I helped myself to some quick google-fu and found out what I was doing wrong. Of course the 1900 port won't work...smh its for upnp lol
-
How can I install this on my opnsense and try it out for sonos? make gives a gcc error.
-
pkg install os-udpbroadcastrelay-devel
via console
-
Thanks. I was able to figure it out slightly before the response. So i have this weird result with sonos.
IOS App for sonos works fine. (UDP 1900 or 1901)
MacOS App for sonos seems to only work if i'm fwd'ing UDP 1900. If I try to use 1901, the result is the app opens, it sees my controller for a moment, and then disconnects and starts searching and then ultimately cannot find it again. Every time. very repeatable.
I doubt it has anything to do with pimd or udpbroadcastrelay, however it's very weird that it only happens on the MacOS App for me.
Thoughts?
-
Hi,
thx for that great plugin, cause it helped much to get Airplay working between my VLANS. I tried mDNS and IGMP Proxy before, but never worked for me.
Now I'm trying to get DLNA working as well. I use minidlna as server in my LAN and wanna use serveral clients/players in my IOT VLAN.
I tried the port 1900 and the address 239.255.255.250 mentioned in one of the first posts, but I still couldn't connect to the server. Is there any other plugin needed for DLNA? What else I'm missing, maybe some ports on the firewall?
Thanks in advance
Torsten
-
I noticed when trying to launch the plugin I cannot successfully launch it. Running it from the CLI I get the following error. Note: This is caused by miniupnpd (Killed it and the process started okay afterwards)
root@OPNsense:/ # /usr/local/etc/rc.d/os-udpbroadcastrelay start
osudpbroadcastrelay is not running.
Starting osudpbroadcastrelay.
bind: Address already in use
rcv bind
/usr/local/etc/rc.d/os-udpbroadcastrelay: WARNING: failed to start osudpbroadcastrelay
I also noticed another issue with the the black theme on opnsense you cannot read any of the plugin info at all.
https://imgur.com/a/eUPetuU
-
There was a fix for the theme, try going to plugins and updating it.
-
@all: thanks for the nice work in preparing and delivering this pkg to opnsense.
I'm struggling however to get it to work. I've browsed the various webpages, the github repo and this forum, but still haven't found my answer. The thing I see is an error message in the 'General' logfile: /usr/local/etc/rc.d/os-udpbroadcastrelay: WARNING: failed to start osudpbroadcastrelay.
Trying to get some more information I tried starting the relay using '/usr/local/etc/rc.d/os-udpbroadcastrelay start' as root. The result was a somewhat more explicit message: IP_ADD_MEMBERSHIP on rcv: Invalid argument.
What I don't know at the moment if this message is the result of something missing in my installation or the result of my usage (and lack of understanding) of this pkg. To describe the setup: I've just updated opnsense to OPNsense 20.7.2-amd64. The system is running on an APU2D4 since 6+ months and completely stable.
I'm segmented my network using vlan's (x.x.0.x as the main LAN and x.x.100.x as the (wifi) guest network). Normally guests don't have access to the normal lan.
I'm running a couple a squeezeboxes and the LMS server in the x.x.0.x LAN. I'm using the iPeng app on an iPhone to control the server (Logitech LMS) and thus the SB's. I would like to control however LMS even when my iPhone is in the guest network.
iPeng (like any normal LMS/Squeezebox client) sends out a UDP server discovery request towards port 3483 as a network broadcast (x.x.100.255:3483). Any listening server responds the address of the server via a UDP answer. And after that it uses a couple of TCP ports (3483 and 9000) to handle the rest of the protocol.
My thought was to use udpbroadcastrelay to forward the initial UDP broadcast to the main LAN). For now I've come up with the following settings:
- Relay Port: 3483
- Relay interfaces: the names of the two LAN's in Opnsense
- Broadcast Address: x.x.100.255
- Source address: 1.1.1.2
- Instance ID: 1
- Use TTL for ID: <blank>
Any hints/tips/answers much appreciated...
-
forget the broadcast address, the source address, leave them blank, just put the port and lan interfaces and try that. you'll likely as not need firewall rules too, but First just see if it fires up.
-
Hi, I got this work with one chromecast (xiaomi mibox s). however sometimes it disappears. And it did take sometime to get it appear to android tablet..
My phones and tablets are in LAN vlan and try to put chromecast devices to IoT vlan.
I did add Sony android tv to same vlan as mibox, but it doesnt work even if I waited over night.
Should I make firewall rule for port 5353, and to point where and to which side?
My LAN is allowed to pass all vlans, but IOT is only allowed to internet and 53 to my pihole which is in LAN.
Edit: strange I installed igmp proxy plugin to opnsense and upstream to IOT vlan, sony tvbs chromecast is also working now from iot vlan! Even stranger that google chromecast troublehshooter advice to disable igmp proxy. So igmp proxy for sony tv(android 8) and broadcast relay for mi box (android 9).
But enough for me like this :D
-
forget the broadcast address, the source address, leave them blank, just put the port and lan interfaces and try that. you'll likely as not need firewall rules too, but First just see if it fires up.
Thanks marjohn56, this put me on the right track. It works beautifully now - can control my Logitech server from within my guest VLAN.
-
@pumo: I don't have a direct answer on the solution based upon the use of the udpbroadcastrelay plugin. I have a working solution based upon the standard opnsense firewall capabilities. It took a bit of work to hunt for the right ports beeing used but these are the rules I use for my IoT LAN where the CC's are active
-
The daemon sends any log info to the system log, but it doesn't log very much anyway, it's very lightweight. The best option to find out what's going on is to run it from the shell directly and work out the problem from there. There are examples of the commands to use here. https://github.com/marjohn56/udpbroadcastrelay (https://github.com/marjohn56/udpbroadcastrelay)
-
Little update. I got some strange problems with precense detection in home assistant so I removed igmp proxy upstream. And now chromecasting still works with Sony android tv.
So udp broadcast relay is enough with 5353 224.0.0.1 multicast address is enough, but its slow to find Sony.
And there is no firewall rules with it. My wifi APs are ubiquiti models and in controller there is igmp snooping enabled in all VLANs.
It didnt help with home assistant but thats another story.
-
It's an odd thing, but I had to turn off snooping on my switches to get Sky to work, it could be something odd with my DLink switches though. Try it, see if it makes any difference.
-
I'll try that if mibox or sony disappears. But now those have been found all the time.
I hqve couple chromecast audios but I will leave those in LAN vlan for now.
-
I assume I am going to have to setup a firewall rule based on the log beow:
filterlog[12364] 16,,,0,igb1,match,block,in,4,0x0,,1,15941,0,DF,17,udp,129,172.16.20.1,239.255.255.250,48581,1900,109
Trying to access my Sonos that sits in my IOT VLAN (20) from the my LAN. I have a FW rule that allows access to VLAN20 (IOT), but the VLAN20(IOT) does not have access to my LAN network. I assume I am on the right track here?
Thanks
-
Yes, you needs to specifically allow the address of the device on the IOT LAN that needs to seen on the LAN segment your sending the requests from. Port 1900 will be forwarded to the IOT VLAN, but the response won't be on port 1900, so you need to allow all ports back, but limit it to the sonos only.
-
Not having much success, but here is the FW rule I setup, see attached.
Any feedback would be appreciated. One question, if you setup a FW rule to pass traffic between the 2 networks wouldn't that defeat the purpose of this plugin?
Thanks
-
You only set a firewall rule in one direction. I do not use Sonos, but I do use Sky which uses the same ports, so on my IOT VLAN have one rule for the Sky box.
Action - Pass
Protocol - Any
Source 10.4.15.91 - The Sky box itself
Destination - QPVLAN - The LAN where my PC's and laptops live.
Port Range - Any - The ports change all the time
So this rule allows the Sky box to send traffic back to the private QPVLAN, and only that device.
-
Thanks for the reply and that is straight-forward and works fine. where I am confused is specific to the plugin, obviously when you have that FW rule enabled you can communicate across networks and I was under the impression that the plugin would take care of not having to create FW rules.
I'm sorry, but call me confused, which is not difficult...
TIA
-
No, It can't create a firewall rule as it has no idea what the address is of the device that will respond to the broadcast; the only way that would work would be to open up the firewall to every device which would rather defeat the purpose of the firewall in the first place.
-
Have this working w/ Sonos app and Roon endpoints, now I am working on the Spotify app. Anyone have any specifics for Spotify?
I read where Spotify uses TCP 4070, but that was unsuccessful.
Installed mDNS repeater and that addressed the issue w/ Spotify and other devices on other VLANs.
@marjohn56, will your plugin do mDNS?
Thanks
-
No.. it doesn't do mDNS.
-
forget the broadcast address, the source address, leave them blank, just put the port and lan interfaces and try that. you'll likely as not need firewall rules too, but First just see if it fires up.
Thanks marjohn56, this put me on the right track. It works beautifully now - can control my Logitech server from within my guest VLAN.
What did you end up configuring?
Thanks.
-
Just want to thank you for this great plugin. You made my day. Sonos and CIFS/SMB lookups perfectly work across VLANs.
-
Good evening,
I'm having some troubles with this plugin.
Here it's my network configuration:
LAN: 10.172.1.x
IoT: 10.172.10.x
GUEST: 10.172.20.x
I'm trying to transmit the audio from my phone on LAN network to the Google Mini in IoT network and I've configured the plugin as described in the second post (see the attached screen) but it's not working, instead I can transmit audio from Guest network without problem.
I've tried also with different phones
According to my firewall rules the LAN network can go everywhere, the GUEST network can go to Internet and to IoT net but not to LAN and the IoT can go only to internet.
Anyone can help me?
Thanks in advance
-
You need to add a rule to allow the specific device on the IoT network to talk to the LAN network; So in the IoT VLAN firewall rules, add a pass rule for the host device with the destination being your LAN, direction is 'in'. You cannot specify as specific port as the host device will use whatever port it feels like.
-
Hi @marjohn56
First, thanks for this plugin. I’ve been using it for mDNS relay (Bonjour, AirPrint) across two VLANs, with success for the most part.
I have noticed, however, that from time to time the mDNS traffic will stop being relayed between VLANs. udpbroadcastrelay is still shown as running in the OPNsense dashboard, but the traffic is not being relayed. A restart of the plugin brings it back.
I had noticed previously similar behaviour with mdns-repeater, which is what prompted me to try udpbroadcastrelay (also I eventually want to get it working with Sonos).
It happens every few days. I’ve been trying to see whether the behaviour is associated with any other particular event in OPNsense, but I can’t pinpoint a pattern. Sometimes I have noticed it follows interfaces being detached/attached, but most recently it happened without any apparent trigger.
So I was wondering whether this is known behaviour? Even if not, would you have any suggestions on how I might configure OPNsense to monitor the plugin (eg through monit) to restart it when this behaviour occurs? I could probably just implement a daily cronjob to restart the plugin, but if possible I’d like something a little more refined (ie that only restarts it when needed).
Thanks in advance
-
It's not a known behaviour, mine runs day in day out without issues. Are you saying that UDPBroadcast shuts down, or just that there are no packets being sent out?
Best way of testing is using wireshark to check the packets on both networks segments.
-
Thanks for the response. The plugin is still running, packets are just not being relayed.
But further investigation suggests the issue may be switch or AP related. I will keep looking into it
-
@marjohn56 Is it possible to use the SSDP broadcast settings along with the uPNP plugin? If so, what is a working set of configs?
I need both, and currently I'm only able to run one or the other, not both at the same time.
-
UDP uses port 1900, so you cannot also use UDPBR on the same port. You could use both if UDPR was relaying a different port.
-
Thank you for this plug-in!! Now I can put my Minecraft server in my DMZ and still have my kids find the server without having to fuss in the server lists!
-
Thank you! Thank you! Thank you! Thank you! Thank you! Thank you! Thank you! Thank you! Thank you! Thank you! Thank you!
And for those wondering, here's what you need to add for Apple TV Home Sharing:
| Enabled | Interfaces | Multicast Addresses | Source Address | Listen Port | ID | Description | Use ID as TTL |
X | WAN,LAN | 224.0.0.251 | 1.1.1.1 | 5353 | 1 | iTunes | X |
-
Hi all, thanks.
I did not expect that within my lifetime I'll be able to get my cross VLAN DLNA streaming working.
Thanks to that it works now
My setup
| Enabled | Interfaces | Multicast Addresses | Source Address | Listen Port | ID | Description | Use ID as TTL |
X | VLAN10,VLAN15 | 239.255.255.250 | empty | 1900 | 1 | SSDP multicast | X |
Firewall rule for the Multicast on VLAN where the server is located.
Firewall rule from Clients to Server.
br
-
Hi Mks,
could you please post your
Firewall rule for the Multicast on VLAN where the server is located.
Firewall rule from Clients to Server.
Mine isn't working yet.
Thx and kind regards
Torsten
-
Hi Torsten
VLAN10 (DLNA Server)
VLAN25 (DLNA Clients)
Protocol/Source/Port/Destination/Port
VLAN10:
IPv4 UDP/VLAN10 net/*/239.255.255.250/1900
VLAN25:
IPv4 TCP-UDP/IPs-StreamingClients/*/IP-StreamingServer/StreamingPorts (in case of synology 50001,50002)
Explenation:
The server sends regular multicasts on port 1900 with information (IP & Port) where the server is located.
Each Client which receives the message could connect to the server
br
-
You only need to add one rule.. ( as a rule! ). Say for example you are using Sky Q, port 1900 239.255.255.250, it's the same as Sonos. All you need to add is one rule from the server LAN/VLAN allowing traffic back to your client LAN/VLAN.
As you do not know what port the server will use to send traffic back to the client(s) you will need to add a rule that allows any port, but you limit that rule to the server address only, hence the server must live at a fixed IP.
So for example here's mine. This is the single rule on the server side IoT VLAN allowing traffic from the server to the primary VLAN.
Action: Pass
Quick: Enabled
Interface: VLANIOT ( must be your IoT or Server VLAN )
Direction: In
TCP/IP Version: IPv4
Protocol: Any
Source: Single Host or Network
10.4.15.91 ( This is the IP of my Sky Q box, it should be the server IP of whatever your server is.
Destination: QPVLAN ( My Primary VLAN - Select yours )
Destination Port Range: Any Any
Description: Sky Relay ( call yours whatever you like )
That's it, simples.
-
Thanks for pointing this thread out marjohn56. Feel free to delete the thread I created originally.
I've had a read through this thread, however havn't had much luck in figuring out what's not allowing devices to discover my Virgin Media chromecast.
I've installed the devel version of UDP Broadcast relay (encase there are any additional features).
To allow for ease of testing, I've created allow all rules (IPv4 & IPv6) between the vlans, and as far as I can see no traffic is being blocked by rules etc... If I can at least get my phone connected, I'll then restrict the rules.
To further troubleshooting, I've ran UDP Broadcast Relay manually and can see MDNS broadcasts being relayed between the vlans. I can confirm this as I've ran Wireshark on both LAN & IOT Vlan's and can see the MDNS broadcasts. The interesting bit, is if I run Youtube app on my phone, I see the broadcast being replicated across the vlan, my Virgin media box (in IOT VLAN) answering the MDNS query, the answer then coming back to my LAN Vlan, and my phone never picks the answer backup. Its as if its ignored. If I leave wireshark running on the LAN vlan, I can intermittently see broadcasts originating from my Virgin Media box as it contains the answers for the MDNS queries.
As for settings for UDP Broadcast relay:
Interfaces: IOT & LAN Vlans
Multicast Address: 224.0.0.251
Source Address: 1.1.1.1
Port: 5353
ID: 1
Use ID as TTL: Tried both enabled & disabled.
As the broadcasts are originating from the interface IP of the vlan, this I hope removes the issue with Chromecasts not responding back to devices on different networks.
I saw you mentioned about snooping being enabled on your switch marjohn56, so i thought I'd check mine and as far as I can see such features are already disabled.
-
I'll go and plug my chromecast in and have a play. Usually only use it when I'm on holiday, fat chance of going anywhere at the moment! I'll get back to you. I know others have got Chromecast working so its a bit odd.
-
To further troubleshooting, I've ran UDP Broadcast Relay manually and can see MDNS broadcasts being relayed between the vlans. I can confirm this as I've ran Wireshark on both LAN & IOT Vlan's and can see the MDNS broadcasts. The interesting bit, is if I run Youtube app on my phone, I see the broadcast being replicated across the vlan, my Virgin media box (in IOT VLAN) answering the MDNS query, the answer then coming back to my LAN Vlan, and my phone never picks the answer backup. Its as if its ignored. If I leave wireshark running on the LAN vlan, I can intermittently see broadcasts originating from my Virgin Media box as it contains the answers for the MDNS queries.
What's even more interesting is that it works from my Chrome browser on the desktop... still investigating!
-
Thanks marjohn56.
I did a network capture on my phone and can see that the Youtube application is making both mdns & ssdp discovery requests. I've tested adding another relay for the ssdp protocol, however had no joy. From what I can tell, ssdp is not being relayed correctly. I get "IP TTL (65) matches ID (1) + 64. Packet Ignored." when ttl-id is enabled.
-
Sooo....
After much playing about I have made it work. Try this, use two multicast addresses, 224.0.0.251 and 224.0.0.51, source address I have set at 1.1.1.1
The 224.0.0.51 is what mdns repeater uses and it appears that's what it needs...
(https://i.ibb.co/1L50MQc/Capture.png) (https://ibb.co/R9mgNb8)
Don't forget the fixed IP and firewall rule for the chromecast itself on the IOT VLAN!
-
Thanks for the great suggestion, but just tried that with still no joy.
As I'm still in the process of configuring my network, I've got wildcard rules on both IOT & LAN vlans, to take them out of the equation.
I do have a ubquiti AP, so was wondering if that would cause issues with the broadcasts, so I did what you did and connected directly to the switch and tried finding devices in Chrome, with still no joy.
I'm gunna do some more packet captures tonight and see if I can work out what's going on.
-
Are you allowing your primary vlan to access anything on the IoT vlan? It's a one way street. Nothing on my IOT can access the primary lan but from the primary I can ping and access anything on the IoT.
-
I've just attached a screenshot of the rules I have in my LAN rule set. I have added a similar allow rule back from the IOT network. As mentioned before, once I've fixed this issue I'll lock everything down to a "T". I just find it really odd that I don't see blocked traffic or anything. I've ran more network logs tonight, and I don't see anything much of interest. When my phone is on the IOT network, I don't see SSDP or MDNS, the phone very quickly discovers the Virgin Media Chromecast. My TV (Also on the IOT network) also has a chrome cast built in, and that isn't discovered either. Is there any config within Opnsense you can think of that could block the traffic? I've also double checked the IGMP snooping is disabled on my switch.
-
What rules do you have on your IOT VLAN?
I am talking of the Chromecast dongle, which as I say works fine. I'll check and see if any of my TVs have Chromecast, as I said, I usually only ever use it on holiday to connect to the hotel TV's!
-
I've just found another document, a Cisco one... not sure it's totally correct.
https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/7-6/chromecastDG76/ChromecastDG76.pdf (https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/7-6/chromecastDG76/ChromecastDG76.pdf). Interesting in they say you can cast to the chromecast, but not manage it.
Have you tried MDNS repeater? You can use it alongside UDPBR providing you don't use the same ports, mdns repeater uses port 5353 and 224.0.0.251
-
Are there any plans to make this plugin ready for IPv6?
-
no.
-
Have you tried MDNS repeater? You can use it alongside UDPBR providing you don't use the same ports, mdns repeater uses port 5353 and 224.0.0.251
Works great here in my home network with a lot of Apple devices and a lot of Bonjour/mDNS going on. IPv4 and IPv6. Single exception is a Brother printer/scanner that announces its scanning service with the link local address instead of the global unicast one. Which of course does not work across a router. Apart from that single buggy device everything "just works", activate and forget.
-
Same here. I use both of them.
-
hello guys,
i cannot make it works with Sky Go App and Sky Q boxes.
I've setup the entry with multicast address 239.255.255.250 and port 1900, doing a TCPDUMP i can see traffic forwaded from my IoT VLAN to main LAN, but the app doesn't find the Sky Q Platinum
Any hints?
Before OPNSense I was using UniFi and i should force TTL to 4 when using IGMP Proxy
Thanks in advance!
-
Have you set up the firewall rule needed?
-
yes, currently my LAN zone has just a rule with anything open
in the attachment this is my current IoT rule set
-
You need the rule on the IOT LAN from the Sky box. Add a rule on the IOT LAN
Action: Pass
Direction: In
Interface: The IOT LAN/VLAN on which the Sky Q lives
TCP version: 4
Protocol: Any
Source: Single Host or network: Enter the address of your Sky Q box.
Destination: The Net of the LAN where your client app is, in my case it's my primary VLAN so it appears as QPVLAN net from the dropdown box
The rest if the settings are default.
As there is no way of knowing what port(s) the Q box is going to use to talk to the client you have to leave all ports open for it, but only for the Q box itself, hence specifying the source as the Q Box.
-
it's not working :(
this is a TCPDUMP on the LAN side, I can see the packet with multicast and 1900 port:
19:39:50.925776 IP 10.0.1.122.58010 > 239.255.255.250.1900: UDP, length 132
19:39:51.400938 IP 10.0.1.122.58010 > 239.255.255.250.1900: UDP, length 132
19:39:51.974473 IP 10.0.1.122.58010 > 239.255.255.250.1900: UDP, length 132
19:39:52.409893 IP 10.0.1.122.58010 > 239.255.255.250.1900: UDP, length 132
19:39:53.021373 IP 10.0.1.122.58010 > 239.255.255.250.1900: UDP, length 132
19:39:54.575089 IP 10.0.2.102.33820 > 239.255.255.250.1900: UDP, length 391
19:39:54.585951 IP 10.0.2.102.33820 > 239.255.255.250.1900: UDP, length 400
19:39:54.586837 IP 10.0.2.102.33820 > 239.255.255.250.1900: UDP, length 443
19:39:54.595408 IP 10.0.2.102.56461 > 239.255.255.250.1900: UDP, length 435
19:39:54.608613 IP 10.0.2.102.35998 > 239.255.255.250.1900: UDP, length 431
19:39:54.611086 IP 10.0.2.102.55354 > 239.255.255.250.1900: UDP, length 431
19:39:54.675932 IP 10.0.2.102.52893 > 239.255.255.250.1900: UDP, length 391
19:39:54.699198 IP 10.0.2.102.52893 > 239.255.255.250.1900: UDP, length 400
19:39:54.700161 IP 10.0.2.102.52893 > 239.255.255.250.1900: UDP, length 443
19:39:54.700186 IP 10.0.2.102.45252 > 239.255.255.250.1900: UDP, length 435
19:39:54.700205 IP 10.0.2.102.44194 > 239.255.255.250.1900: UDP, length 431
19:39:54.700222 IP 10.0.2.102.50255 > 239.255.255.250.1900: UDP, length 431
19:39:54.852066 IP 10.0.2.102.47141 > 239.255.255.250.1900: UDP, length 391
19:39:54.864000 IP 10.0.2.102.47141 > 239.255.255.250.1900: UDP, length 400
19:39:54.865469 IP 10.0.2.102.47141 > 239.255.255.250.1900: UDP, length 441
19:39:54.877949 IP 10.0.2.102.45838 > 239.255.255.250.1900: UDP, length 439
19:39:54.964780 IP 10.0.2.102.35901 > 239.255.255.250.1900: UDP, length 391
19:39:54.970416 IP 10.0.2.102.35901 > 239.255.255.250.1900: UDP, length 400
19:39:54.970432 IP 10.0.2.102.35901 > 239.255.255.250.1900: UDP, length 441
19:39:54.971131 IP 10.0.2.102.42460 > 239.255.255.250.1900: UDP, length 439
19:39:54.978979 IP 10.0.1.100.36914 > 239.255.255.250.1900: UDP, length 101
19:39:57.402953 IP 10.0.2.103.46812 > 239.255.255.250.1900: UDP, length 391
19:39:57.403721 IP 10.0.2.103.50473 > 239.255.255.250.1900: UDP, length 439
19:39:57.403739 IP 10.0.2.103.46812 > 239.255.255.250.1900: UDP, length 400
19:39:57.403749 IP 10.0.2.103.46812 > 239.255.255.250.1900: UDP, length 441
19:39:57.501526 IP 10.0.2.103.45625 > 239.255.255.250.1900: UDP, length 391
19:39:57.502320 IP 10.0.2.103.45625 > 239.255.255.250.1900: UDP, length 400
19:39:57.502338 IP 10.0.2.103.45625 > 239.255.255.250.1900: UDP, length 441
19:39:57.512406 IP 10.0.2.103.59306 > 239.255.255.250.1900: UDP, length 439
19:39:58.609947 IP 10.0.2.101.50033 > 239.255.255.250.1900: UDP, length 391
19:39:58.616509 IP 10.0.2.101.50033 > 239.255.255.250.1900: UDP, length 400
19:39:58.617198 IP 10.0.2.101.50033 > 239.255.255.250.1900: UDP, length 449
19:39:58.623296 IP 10.0.2.101.57373 > 239.255.255.250.1900: UDP, length 431
19:39:58.651478 IP 10.0.2.101.40230 > 239.255.255.250.1900: UDP, length 435
19:39:58.651497 IP 10.0.2.101.41778 > 239.255.255.250.1900: UDP, length 435
19:39:58.651512 IP 10.0.2.101.34482 > 239.255.255.250.1900: UDP, length 453
19:39:58.651526 IP 10.0.2.101.52958 > 239.255.255.250.1900: UDP, length 439
19:39:58.712615 IP 10.0.2.101.52922 > 239.255.255.250.1900: UDP, length 391
19:39:58.713300 IP 10.0.2.101.52922 > 239.255.255.250.1900: UDP, length 400
19:39:58.725730 IP 10.0.2.101.52922 > 239.255.255.250.1900: UDP, length 449
19:39:58.736272 IP 10.0.2.101.51055 > 239.255.255.250.1900: UDP, length 435
19:39:58.736290 IP 10.0.2.101.53165 > 239.255.255.250.1900: UDP, length 453
19:39:58.736307 IP 10.0.2.101.38655 > 239.255.255.250.1900: UDP, length 431
19:39:58.736349 IP 10.0.2.101.46696 > 239.255.255.250.1900: UDP, length 435
19:39:58.736371 IP 10.0.2.101.55974 > 239.255.255.250.1900: UDP, length 439
19:39:59.671583 IP 10.0.2.103.55595 > 239.255.255.250.1900: UDP, length 391
19:39:59.680952 IP 10.0.2.103.55595 > 239.255.255.250.1900: UDP, length 400
19:39:59.687785 IP 10.0.2.103.55595 > 239.255.255.250.1900: UDP, length 443
19:39:59.687811 IP 10.0.2.103.53717 > 239.255.255.250.1900: UDP, length 435
19:39:59.698524 IP 10.0.2.103.36531 > 239.255.255.250.1900: UDP, length 431
19:39:59.698542 IP 10.0.2.103.33524 > 239.255.255.250.1900: UDP, length 431
19:39:59.776345 IP 10.0.2.103.45391 > 239.255.255.250.1900: UDP, length 391
19:39:59.777213 IP 10.0.2.103.45391 > 239.255.255.250.1900: UDP, length 400
19:39:59.777242 IP 10.0.2.103.45391 > 239.255.255.250.1900: UDP, length 443
19:39:59.780551 IP 10.0.2.103.51321 > 239.255.255.250.1900: UDP, length 435
19:39:59.796703 IP 10.0.2.103.42519 > 239.255.255.250.1900: UDP, length 431
19:39:59.797466 IP 10.0.2.103.36201 > 239.255.255.250.1900: UDP, length 431
10.0.1.122 is my iPhone where SkyGo is running
10.0.2.101 is Sky Q Platinum
10.0.2.102-103 are the two Sky Minis
I don't see any other traffic than the SSDP, it looks like the app cannot really find where is the Platinum
-
It definitely works, many of us are using it right now. So let's see what settings you have. It should look like below...
(https://i.ibb.co/KyxW94h/UDPRSetting.png) (https://ibb.co/tCpDbjK)
and the firewall rule.
(https://i.ibb.co/QPdph1C/UDPR-IOTVLAN-rule.png) (https://ibb.co/VgmJbPQ)
-
It definitely works, many of us are using it right now. So let's see what settings you have. It should look like below...
(https://i.ibb.co/KyxW94h/UDPRSetting.png) (https://ibb.co/tCpDbjK)
and the firewall rule.
(https://i.ibb.co/QPdph1C/UDPR-IOTVLAN-rule.png) (https://ibb.co/VgmJbPQ)
Hi,
i've the same rules.
Just a question: Are your Sky Q boxes replies to ping?
Mine not, but i'm in Italy and we don't have the same firmware..
Looks like that after some time, the OPNSense lost ARP entries and the box reply only if the traffic start from it
Thanks
-
Sky Q's definitely do not reply to pings.
-
ok, so also other firmware have the same behaviour
i'll try to find why this damn app cannot find the Q :(
-
If you can, run wireshark on the IOT VLAN/LAN, you should see the multicast packets coming from the LAN, the source address should be the client app. You should also see the packets then coming from the Q itself, they will not be multicast but will have the source address of the Q and the destination should be the client app. If you see all that and the app is not getting those packets then there is a firewall issue.
-
the problem is that i'm seeing multicast packet on both interface, but anything else.
Looks like that the client doesn't know where is the SkyQ, so it doesn't start the TCP communication
-
You will see multicast on both, that's the idea, when the Q sees that packet it responds unicast back to the client.
-
ok.. may be i've found the problem.
The Multicast traffic is passed over ethernet, but when reach the AP (Unifi AC HD), the packet is not broadcasted over WLAN
I think this is related to the block broadcast on IoT WLAN that i've put in place for a problem with Shelly devices.
Now i'll try to see if I can put an exception..
-
ok fixed!
i've put a rule to allow OPNSense and my iPhone to multicast on IoT SSID, and now I can reach my Sky Q Platium :D
Thanks for the hits :)
-
Told you it worked. :)
-
Great piece of software, has helped me getting a multi-function device discovered across VLANs. I have a situation with a smart TV now that I can't quite solve. Maybe you can point me in the right direction.
I have a 2017 Samsung TV so it implements the Google Cast/Chromecast built-in predecessor Discovery and Launch (DIAL), specs for reference (http://www.dial-multiscreen.org/dial-protocol-specification). Essentially DIAL clients such as the Youtube app on a smartphone use Simple Service Discovery Protocol to 239.255.255.250 on UDP port 1900.
From udpbroadcastrelay's side I'm using:
udpbroadcastrelay --id 4 --port 1900 --dev igb0_vlan1060 --dev igb0_vlan1042 -s 1.1.1.1 --multicast 239.255.255.250 -d
Matching rules are in place:
# DIAL clients net (smartphones and their Youtube apps live here)
pass in quick on igb0_vlan1060 inet proto udp from {(igb0_vlan1060:network)} to {239.255.255.250} port {1900} keep state
# Entertainment net (TV implementing a DIAL server lives here)
pass in log quick on igb0_vlan1042 inet proto udp from {(igb0_vlan1042:network)} to {10.10.42.1} port {1900} keep state
Now when a DIAL client sends SSDP requests, here's the output of udpbroadcastrelay that I'm a bit confused by. In this example the client's at 10.10.60.100, the DIAL server at 10.10.42.16.
ID set to 4
Port set to 1900
Outgoing source IP set to 1.1.1.1
ID: 4 (DSCP: 4, ToS: 0x10), Port 1900
igb0_vlan1060: 12 / 10.10.60.1 / 10.10.60.255
igb0_vlan1042: 19 / 10.10.42.1 / 10.10.42.255
found 2 interfaces total
IP_ADD_MEMBERSHIP: 10.10.60.1 239.255.255.250
IP_ADD_MEMBERSHIP: 10.10.42.1 239.255.255.250
Done Initializing
<- [ 10.10.60.100:40536 -> 239.255.255.250:1900 (iface=12 len=125 tos=0x00 DSCP=0 ttl=1)
-> [ 10.10.42.1:1900 -> 239.255.255.250:1900 (iface=19 len=125 tos=0x10 DSCP=4 ttl=1)
<- [ 10.10.42.16:41954 -> 10.10.42.1:1900 (iface=19 len=411 tos=0x00 DSCP=0 ttl=64)
-> [ 10.10.60.1:1900 -> 10.10.42.1:1900 (iface=12 len=411 tos=0x10 DSCP=4 ttl=64)
<- [ 10.10.60.1:1900 -> 10.10.42.1:1900 (iface=5 len=411 tos=0x10 DSCP=4 ttl=64)
IP DSCP (4) matches ID. IP ToS 0x10. Packet Ignored.
I'd expect the replicated response back in DIAL clients' net to go something like:
-> [ 10.10.60.1:1900 -> 239.255.255.250:1900 (iface=12 len=411 tos=0x10 DSCP=4 ttl=64)
Instead the replicated response looks like
-> [ 10.10.60.1:1900 -> 10.10.42.1:1900 (iface=12 len=411 tos=0x10 DSCP=4 ttl=64)
DIAL server at .42.16 gets the request and sends its response, tcpdump confirms it's got what looks like proper content.
Simple Service Discovery Protocol
HTTP/1.1 200 OK\r\n
CACHE-CONTROL: max-age=1800\r\n
DATE: Sun, 04 Apr 2021 02:58:36 GMT\r\n
EXT: \r\n
LOCATION: http://10.10.42.16:7678/nservice/\r\n
SERVER: Samsung-Linux/4.1, UPnP/1.0, Samsung_UPnP_SDK/1.0\r\n
ST: urn:dial-multiscreen-org:service:dial:1\r\n
USN: uuid:7bbede11-cb5a-4c60-b356-ab6914661a7f::urn:dial-multiscreen-org:service:dial:1\r\n
WAKEUP: MAC=9c:8c:6e:00:00:02;Timeout=10\r\n
Content-Length: 0\r\n
BOOTID.UPNP.ORG: 9\r\n
\r\n
[HTTP response 1/1]
In DIAL clients net that response is never seen. Am I missing something obvious why the reply packet apparently doesn't get replicated back into the DIAL client's net?
//edit: Similar to Chromecast in later versions I only get a response at all by using source address 1.1.1.1. I also tried '--ttl-id' for fun, it increased the TTL header as outlined in the manual, behavior itself was the same.
-
The reply packet is not 239.255.255.250, try adding a specific rule to allow the reply packets to get back to the LAN where the client is.
-
Just as a side note to anyone reading this thread. I reconfigured my network and lost my relay. Now it turns out that the switch my PC is connected to did not have IGMP snooping turned on, once I did that, everything started working again. So if you've tried everything else, check your switches.
-
The reply packet is not 239.255.255.250, try adding a specific rule to allow the reply packets to get back to the LAN where the client is.
I temporarily removed all restrictions except for port 1900 and got a match just as well so I'm almost sure the old rule was sufficient as well:pass in quick on igb0_vlan1042 inet proto udp from {10.10.42.16} to {10.10.42.1} port {1900} keep state
Or in config/XML style:<?xml version="1.0"?>
<opnsense>
<filter>
<rule>
<type>pass</type>
<interface>opt10</interface>
<ipprotocol>inet</ipprotocol>
<statetype>keep state</statetype>
<direction>in</direction>
<quick>1</quick>
<protocol>udp</protocol>
<source>
<address>10.10.42.16</address>
</source>
<destination>
<address>10.10.42.1</address>
<port>1900</port>
</destination>
</rule>
</filter>
</opnsense>
One curious thing I noticed is that the TV sends SSDP response packets to 10.10.42.1.1900 which then show up on interface lo0. File '/var/log/filter.log' confirms:Apr 4 21:09:33 fw-a filterlog[33972]: 123,,,0,lo0,match,pass,out,4,0x10,,64,4660,0,none,17,udp,440,10.10.60.1,10.10.42.1,1900,1900,420
Apr 4 21:09:33 fw-a filterlog[33972]: 122,,,0,lo0,match,pass,in,4,0x10,,64,4660,0,none,17,udp,440,10.10.60.1,10.10.42.1,1900,1900,420
So first these response packets come out of the firewall into lo0, then go in to the firewall never to emrge again - at least not according to tcpdump.
Firewall log live view shows the first out with comment "let out anything from firewall host itself", the in with comment "pass loopback":
(https://i.imgur.com/bdGAZV1.png)
At the end of the day if I'm being particularly dense here I can always link Youtube smartphone apps with the TV via the Watch YouTube on TV with a TV code feature; I'm guessing that just establishes comms via YouTube's servers.
Am I missing something obvious? Anything I should be trying?
//edit: Oh I also played around with port forwards and outbound NATting for packets to show up where I'm guessing the Youtube smartphone app is expecting them. Didn't do me any good so far. While testing over time I've seen the TV send out four different types of HTTP NOTIFY requests (also all via 239.255.255.250:1900). It's letting everyone kow that it has:
- http://10.10.42.16:7678/nservice/
- http://10.10.42.16:7676/rcr/
- http://10.10.42.16:9119/screen_sharing
- http://10.10.42.16:9197/dmr
I haven't seen the Youtube smatphone app try to reach any one of those endpoints once so I'm pretty sure it doens't care about those specific SSDP replies.
-
From a couple of minutes research this is more complex than a simple UDPR, for example:
https://community.ui.com/questions/How-do-I-set-up-my-network-so-that-I-cast-to-an-LG-TV-on-an-isolated-network/dbb36518-d720-452a-b640-fc234f11474f (https://community.ui.com/questions/How-do-I-set-up-my-network-so-that-I-cast-to-an-LG-TV-on-an-isolated-network/dbb36518-d720-452a-b640-fc234f11474f)
-
@MarJohn56
What's the recommended solution to use both UPNP - 1900 and having UDPbroadcast relay handle forwarding 1900 to different subnets. I get port conflicts and surprised not more people have mentioned this as an issue.
-
This is not an issue, you cannot have both daemons using port 1900, if you read this entire thread ( not for the faint hearted ) from the beginning you'll find it is mentioned.
-
Subscribe
and hoping if I can find a solution for relaying DLNA windows10 server media through an IPSEC tunnel to a remote network
-
Subscribe
and hoping if I can find a solution for relaying DLNA windows10 server media through an IPSEC tunnel to a remote network
You might find help in the VPN section, UDPR only forwards multicast between LANs and VLANs, not VPNs.
-
I've been out of luck to use this amazing UDP Broadcast Relay for WS-Discovery across VLANS...
It works well for mDNS with my chromecasts
But for WS-Discovery, no matter what source IP I use, "empty", "1.1.1.1" or "1.1.1.2" it just does not manage to let WS-Discovery work from one vlan/subnet to another.
In fact, with "empty", it almost works : probe requests reached the other subnet, that answsers with a probe-match. But Windows has the good idea to see the probe-match packet, but since the source IP is outside it's subnet, it doesn't try to resolve it...
I would like/need this UDP to act like a proxy for WS-discovery, and replace do something similar to NAT, which I thought could be the 1.1.1.1 or 1.1.1.2 source, but in fact sadly no...
Would you be willing to look at the ws-discovery protocol and implement some other mechanism to be able to act as a ws-discovery proxy (lots of documentation show this is allowed by the protocol but I could find no implementation of this anywhere).
Thanks in advance for your reading.
-
I need to access some cameras on a VLAN, and they are contacted via broadcast packets on a random UDP port (e.g. UDP/2230 for 255.255.255.255 - although I think OPNsense will translate this to x.x.x.255?)
Is there a way to use UDP broadcast relay for this? I only see options for fixed ports and broadcast address 255.255.255.255 is not valid.
Or is there any forwarding solution for OPNsense?
-
Just wanted to share something that confused me as it might help others with their firewall rules. My home network is set up with my primary LAN network (most trusted devices) having access to all VLAN machines. My firewall rules for this are on the LAN interface. However, broadcasts weren't getting through to the VLAN and I couldn't figure out why (source and multicast addresses were left blank, so the broadcasts still appeared to be coming from the original machine). I discovered I needed an additional rule on my VLAN interface to specifically allow broadcasts from my LAN network, despite that rule already being in place on my LAN interface. It seems the source interface's rules aren't being looked at in the event the firewall box itself is generating the traffic or something? I understand why if that's the case, it's just something to be aware of for this plugin.
Hopefully this helps someone else.
-
UDPR itself does not need rules as it bypasses the fw. The only rule(s) needed are for the server to respond back to the client which does not go via UDPR.
-
forget the broadcast address, the source address, leave them blank, just put the port and lan interfaces and try that. you'll likely as not need firewall rules too, but First just see if it fires up.
Thanks marjohn56, this put me on the right track. It works beautifully now - can control my Logitech server from within my guest VLAN.
I was having this issue too. If I try to use the multicast address of 255.255.255.255 (port 987, PS4 device discovery but only sometimes), it'd silently fail and I had no idea if it was actually running or not. Restarting it from shell, or starting the binary manually with the same options (thanks to the config file for making it a copy/paste ordeal) gave me the IP_ADD_MEMBERSHIP on rcv: Invalid argument message. It wasn't until I saw this part of the thread and got rid of the multicast option that it was able to start up successfully. I suppose it probably won't matter to me if I leave it like that but I like to be explicit in my rules.
I'm guessing this is thrown because 255.255.255.255 is technically outside the "official" multicast range? Either way, I think it'd be nice to have some kind of feedback in the web UI if the daemon can't be started for some reason. The most I can see from there is that it failed to start in the system log files but it doesn't tell me why.
-
UDPR itself does not need rules as it bypasses the fw. The only rule(s) needed are for the server to respond back to the client which does not go via UDPR.
This where I'm confused. I'm actually seeing 2 broadcasts on the vlan interface in the firewall log live view, one in the OUT direction (which is allowed through, "let out anything from firewall host itself") and one in the IN direction (which is being blocked via a default deny rule). The IN is what I needed an additional rule for. Both broadcasts are from the same IP on LAN. If I disable the rule, the PS4 Second Screen application doesn't find my PS4. It's only when I re-enable it that it works.
I also have a rule allowing broadcast traffic back from the VLAN to LAN, and that was enabled the entire time while testing all this.
-
I'm guessing this is thrown because 255.255.255.255 is technically outside the "official" multicast range? Either way, I think it'd be nice to have some kind of feedback in the web UI if the daemon can't be started for some reason. The most I can see from there is that it failed to start in the system log files but it doesn't tell me why.
Correct, that's not multicast it's broadcast.
-
I'm guessing this is thrown because 255.255.255.255 is technically outside the "official" multicast range? Either way, I think it'd be nice to have some kind of feedback in the web UI if the daemon can't be started for some reason. The most I can see from there is that it failed to start in the system log files but it doesn't tell me why.
Correct, that's not multicast it's broadcast.
Thanks for clarifying, so if it's broadcast, users are meant to leave that field blank? I mean I know it's labeled "multicast addresses" but it wasn't super clear to me what should be done in that case.
-
To be honest, I never even thought about someone relaying a broadcast 255.255.255.255 packet. It was intended to relay multicast and unicast packets on a specific port.
Just did a quick google and it mutters something about the Playstation using SSDP on port 987. So that is what you should have set in the port number, which address you should use I cannot quickly find. I suggest you use wireshark and see what the packet address is. You can add a filter of ssdp, that should easily allow you to see the address being used. If it is using 255.255.255.255 that's a bit odd.
-
There's actually 2 different broadcasts in play here on port 987 (it's different for 2nd screen vs. remote play). I just did another capture to be sure of what I saw per application. And just to be clear, the only SSDP traffic I see on either interface is just UPnP.
2nd screen is the application that does a network broadcast I'd expect (so for example if the network is 192.168.1.0/24, the broadcast address is 192.168.1.255), and at the OpnSense box I see up to 5 of those when UDPR is off. Their remote play application is the one that does a wide open 255.255.255.255 (I see it once from the OpnSense box). I agree, it's a bit strange but that's what is being done (and to be honest I've mostly just been testing the 2nd screen app so far, figured that'd be the simpler of the two).
The packet data themselves contain the same thing, even reference the same "device-discovery-protocol-version", so it's a little funny they do broadcasts differently. In any case, I haven't found another way to send these broadcasts across different networks until your plugin existed, though I admit I'm not exactly fully familiar with OpnSense yet.
BTW, thanks a ton for your work on this.
-
I actually need to forward these broadcast packets to another VLAN, since these are sent by my camera client software and need to find the camera on another VLAN. I installed UDP Broadcast Relay thinking that it was able to do so... Is there any alternative?
EDIT: Both VLANs can see each other, and I tested the packet to x.x.x.255 was forwarded. But the packet to 255.255.255.255 does not seem to be forwarded
-
In addition you need to setup the appropriate firewall rules.
br
-
Hi, strange one... I'm running OPNsense 21.1.5-amd64 on a dedicated Optiplex PC. All seems to be running fine, but after having installed os-udpbroadcastrelay via plugins (v1.0_1), when I go to UDP Broadcast Relay under Services I just see "No Results Found" rather than the option to "Add".
If I refresh the page I see a "+" button flash briefly under the Interfaces heading, but it's quickly replaced by "No results Found".
If I try running /usr/local/sbin/udpbroadcastrelay --id 1 --dev igb1_vlan30 --dev igb1 --port 5353 --multicast 224.0.0.251 -s 1.1.1.1 in a shell the relay runs fine & I can see Chromecast devices across the vlans.
Any idea why I don't have the "Add" option in the GUI? I'm using a Chrome browser, but have also tried Edge & IE (via IEtab).
-
No issues on my systems. Are you using the default theme or one of the plugins?
Here's mine, theme is a custom one, but it's based on rebellion.
(https://i.ibb.co/B4Gwm4c/UDPRSetting.png) (https://ibb.co/LQrvMQY)
-
Not as neat on some displays (Brave on iPad in this example) 😂
-
I have a solution... don't use a tablet! :)
-
@Greelan - try 17825d0
Looks better on my tablet.
-
OK, will do. But it is not just a tablet thing - Brave on MacBook:
-
Don't get me wrong, BTW, this is just a small UI niggle, I'm very grateful for your work on the functionality
-
No worries. Try it and see if it's an improvement. The only other way is a complete change of interface,
-
Yes, that makes it fit. Although as you state in the commit, truncates the data fields and headings somewhat. Cheers
-
There are other options, I could remove some of the info from the entry, question is, what should stay and what should be hidden.
-
No issues on my systems. Are you using the default theme or one of the plugins?
Here's mine, theme is a custom one, but it's based on rebellion.
(https://i.ibb.co/B4Gwm4c/UDPRSetting.png) (https://ibb.co/LQrvMQY)
Ah - brilliant, thanks - you put me onto the right track!! Even though I'm on a 1280x1084 display the "+" button was off the righthand side of the screen and (on the default skin) I hadn't noticed the scrollbar at the bottom as it's a very similar colour to the main screen. Every day's a school day!!!
-
There are other options, I could remove some of the info from the entry, question is, what should stay and what should be hidden.
I think Use ID as TTL could probably be removed, and shortening the headings for other entries would also help (eg Port rather than Listen Port). What about also the “dynamic display” approach that eg the firewall rules adopt - items are variably hidden based on the width of the display, but not removed from the list outright so that they still appear if the display is wide enough?
-
I've done that on my local version already, changed Listen Port etc.. also hidden Source Address. I've just done a clean install on my test machine, it's been a while since it was clean - now I'm struggling to switch to the dev branch.. something odd is going on.
-
Hi guys, does someone know how do I get device discovery working when using a Samsung TV?
When I'am in the same subnet I can cast from Chrome or the YouTube app to "[TV] Samsung".
Based on this article [1] I assumed that DIAL is used for this, but enabling SSDP has no effect.
Any ideas?
[1] https://blog.oakbits.com/google-cast-protocol-discovery-and-connection.html
EDIT:
Using this script [2] devices in the same subnet are discovered but not in another VLAN with the SSDP relay (which is used by the script).
[2] https://gist.github.com/jcarbaugh/e08dcfe61ece0e7eea12
-
Just wanted to thank the community and @bertoforth / @marjohn56 for this great plugin/service.
Have been able to successfully use 7 VLANs of segregation - chromecasts, yamaha receivers, Anthem pre/pro, BubbleUPnP, unRaid, server/services, HD Homerun, cameras, etc. all logically separated in their corresponding VLANs created for my purposes - while having the convenience of being able to use my primary wireless LAN to cast, discover, stream, etc.
The UDP Broadcast Relay with point/click/type has really made things easy and prevented me from going down the scripted socat route.
Thank you again
-
Just wanted to thank the community and @bertoforth / @marjohn56 for this great plugin/service.
Have been able to successfully use 7 VLANs of segregation - chromecasts, yamaha receivers, Anthem pre/pro, BubbleUPnP, unRaid, server/services, HD Homerun, cameras, etc. all logically separated in their corresponding VLANs created for my purposes - while having the convenience of being able to use my primary wireless LAN to cast, discover, stream, etc.
The UDP Broadcast Relay with point/click/type has really made things easy and prevented me from going down the scripted socat route.
Thank you again
Awesome, would you mind sharing your config for HD Homerun?
-
Just want to say thank you for this app, got airplay working across VLANs, i had to leave the source address in the plugin empty though it would not show my sonos via airplay with 1.1.1.1 or 1.1.1.2.
-
Glad it's working for you. Sadly I have had no time over the last few months to even look at Opnsense, in fact I've only just updated the system to 21.7 I've been that busy. Fortunately it's very stable and just carries on regardless.
-
anyone figured out how to get Win10 miracast working?
I've got the relay running and can see it in action using tcpdump.
I've set rules on both my LAN and main WLAN (which is a vlan) allowing any traffic in both directions (cause i'm lazy).
Win10 can't see my Roku (which does have all the necessary services enabled)....?
Win10's on eth, but apparently 10's supported eth to wlan miracast sinced 1703...
-
ignore me: https://docs.microsoft.com/en-us/surface-hub/miracast-over-infrastructure
-
First, THANK YOU!
I have two homes, both running OPNSense. Site-to-Site WireGuard VPN. Both sites have their own respective LAN and WG interfaces set up. Both sites have gateways set up for the WireGuard traffic (GWs are required and must be designated as "Far Gateways" for selective routing). FW rules on both sides allow all from their respective WG interfaces. Both sites have "Disable Routes" enabled in the Local Configuration; all routing is selectively handled via firewall rules based on either source or destination IPs. Outbound NAT is set up on both sides to assign the WG interface IP to outgoing packets. Endpoint Allowed IPs on both sides have 0.0.0.0/0.
So far, all the discussions in this forum pertain to relaying UDP broadcasts across multiple VLANs. Is there any reason why this wonderful plugin would not work when one of the interfaces is a VPN interface, and specifically WireGuard? Is there any specific configuration needed to make it work?
Also, why do some relay setup lines appear in yellow (vs. Green) in OPNSense? Yellow ones show their services inactive on the dashboard. I assume incorrect configuration of some sort but can't tell what is wrong with them.
-
I posted a variation of this on reddit, but thought I might get a bit more traction here.
I have udp broadcast relay setup and working. As a new user to opnsense I was pleasantly surprised how easy it was to get up and running.
Everything was working great until I tried to cast from netflix on my android. Casting from all other apps on my phone is fine.
It appears that netflix is using ipv6 for mDNS on more recent chromecasts (my gen1 chromecast is discovered by netflix ok). As udp broadcast relay doesn't support ipv6 at the moment, I have to connect to my IoT vlan to cast netflix which doesn't go down well with the family.
I've tried blocking and rejecting all ipv6 udp to see if netflix would fall back to ipv4, but no joy. All of my devices are connected via ipv4, so don't mind nuking ipv6 for now.
Is ipv6 support on the roadmap for udp broadcast relay?
Any other suggestions of things I can try?
TIA
-
Can you open an issue in GitHub about V6 support please? I know the plugin allows only v4 but unsure about the daemon itself
-
Thanks mimugmail. Assuming you meant here: https://github.com/marjohn56/udpbroadcastrelay, all done.
-
opnsense/plugins
-
First of all, thank you for this plugin!
I managed to install it offline after a lot of searching for the source files. I am new to OPNSense and to FreeBSD in general and finding those 2 files was not easy for me. :)
The issue that I have now is that in my case, I need to use the broadcast address 255.255.255.255 as it is hard-coded by the application, but when I try to set this address in the plugin, the plugin stops after the Save button is pressed and does not start anymore even if I try to start it from the System > Diagnostics > Services area.
In the General log:
/usr/local/etc/rc.d/os-udpbroadcastrelay: WARNING: failed to start osudpbroadcastrelay
It looks like this address is not supported and it may be a value validity check inside the plugin that does not expect this one and gives an error.
Is there a reason why this address is not accepted by the plugin, or maybe, are there some other settings outside this plugin that could cause this issue?
-
The plugin is installable through the plugins menu in the UI - no need to install files manually from source
Unfortunately I can’t answer your specific query regarding that broadcast address
-
255.255.255.255 is not a multicast address. If you click on the help "i" next to the broadcast address it says "Multicast addresses to use on this port when relaying multicast packets. e.g Sonos is 239.255.255.250, you may enter multiple addresses."
-
I struggled with my miniDLNA since weeks (came from another FireWall Software AND started use VLANs stricter)
It needed tons of forum threads and lots of hours - do some missunderstanding from my side - i used a wrong plugin and did tweak wrong rules :o.
At the END: THANK YOU Major!!! (was so tired when read your posts the first time - Major56 burned in my brain ;D)
So: Thank you marjon56 - would really spend you a big big chocolate and a nice coffee(or tea)
For all others struggling with miniDLNA - use this plugin - set source empty and watch your livelog - Ports 8200 and 1900 (UDP/TCP) and you are done.
Using VLC on windows from VLAN-A to VLAN-S (miniDLNA) and other DENON-devices that find the server from VLAN-M. Even my Teufel seems to work. But I have to stop for today and get some sleep.
Once again - marjon56 - you saved my Christmas! (family expected to play Christmas songs from the Devices as usual
-
Curious if anyone has had any success w/ Logitech Harmony Hubs? If so, would you mind sharing some specifics.
ROON and SONOS is working fine, but have been unable to setup the Logitech HUBs across VLANs.
NM, think it's working now, had to use multicast of 224.0.0.1 and port 5224.
Thanks
-
Curious if anyone has had any success w/ Logitech Harmony Hubs? If so, would you mind sharing some specifics.
ROON and SONOS is working fine, but have been unable to setup the Logitech HUBs across VLANs.
NM, think it's working now, had to use multicast of 224.0.0.1 and port 5224.
Thanks
I'm glad you posted the answer. I'll have to give it a try as getting the Hub talking across VLANs is on my todo list.
-
Dear all,
[SOLVED], it was a switch issue ;)
anyone out there who are also facing issues since the last Opnsense update to 21.7.7?
I'm not sure if its really related to the update.
My DLNA server is not discovered anymore.
br
-
Running 22.1.r2 and I'm having some difficulty getting it to run:
2022-01-24T16:48:55-06:00
root /usr/local/etc/rc.d/os-udpbroadcastrelay: WARNING: failed to start osudpbroadcastrelay
Are there any known compatibility issues known at this moment?
-
Curious if anyone has had any success w/ Logitech Harmony Hubs? If so, would you mind sharing some specifics.
ROON and SONOS is working fine, but have been unable to setup the Logitech HUBs across VLANs.
NM, think it's working now, had to use multicast of 224.0.0.1 and port 5224.
Thanks
Can you share what your entry is to get Roon working? I have read on Roon forums that it needs port 9003, but that doesn't seem sufficient. I have Airplay and Sonos working, but not Roon.
-
Running 22.1.r2 and I'm having some difficulty getting it to run:
2022-01-24T16:48:55-06:00
root /usr/local/etc/rc.d/os-udpbroadcastrelay: WARNING: failed to start osudpbroadcastrelay
Are there any known compatibility issues known at this moment?
No issues, working fine.
-
I'm unable to start the service. It indicates that it's loading (Please wait pop up), then nothing happens. I'm fairly new to OpnSense, so I'm not quite sure where to look for errors or what might be wrong. :-X I'm trying to set it up for Chromecast.
Versions OPNsense 22.1.2_1-amd64
FreeBSD 13.0-STABLE
OpenSSL 1.1.1m 14 Dec 2021
Edit: Turns out port was in use. Solved it. Now it's "green" and running, but still can't get it to work. Not sure if I did the Firewall correct.
-
So I think I have a bit of strange problem. I have setup UDPBR as per the guide for mDNS (specifically for Chromecast devices. As most people seem to do, I have my IoT vlan and my main LAN. Currently they're both wide open to each other as I test things. While I was able to see and connect to the various chromecasts, the connections would randomly drop out. This was especially apparent in the home app where you could see devices appear and disappear.
I then installed IGMP Proxy and configured the upstream as my LAN and my downstream as my IoT vlan. If I have both services running, Chromecast connections are rock solid (and extremely fast to discover). The weird thing though, is in my logs, I have warnings from IGMP proxy that various multicast addresses are in use, which I assume is due to UDPBR using them.
EDIT - Just tested mDNS Repeater and it works as expected without IGMP Proxy enabled.
EDIT 2 - Spoke to soon. Without IGMP proxy installed, some devices don't load in the Google Home app even with using mDNS.
Any thoughts on this, or anyone else see this?
Thanks in advance!
~Spritz
-
Is it possible to merge this new functionality? https://github.com/deonvdw/udpbroadcastrelay
Thanks
BTW: This is totally awesome plugin!!!
-
Is there a pull requests against the official repo?
-
Yes.
No impact to GUI, but subnet filtering will need some GUI filed for that, but Im not that PHP proficient.
Merged DIAL support from https://github.com/deonvdw/udpbroadcastrelay
Subnet filtering from https://github.com/Baune8D/udpbroadcastrelay
Added PURE M-SEARCH proxy
README clarification about spoof IPs
-
Curious if anyone has had any success w/ Logitech Harmony Hubs? If so, would you mind sharing some specifics.
ROON and SONOS is working fine, but have been unable to setup the Logitech HUBs across VLANs.
NM, think it's working now, had to use multicast of 224.0.0.1 and port 5224.
Thanks
@guyp2k how did you got ROON to work with what setup settings? And does it also work over wireguard/vpn ?
-
Yes, https://github.com/marjohn56/udpbroadcastrelay/pull/7
Is there a pull requests against the official repo?
-
I have to admin, that https://github.com/synfinatic/udp-proxy-2020 is more stable for my tv.
-
thnx, yeah I'm run-in udp-proxy-2020 now also and it works great.
I was a little hesitant because it was for pfsense instead of opnsense, but finally gave it a try.
Maybe UDP Broadcast Relay can have this udp-proxy-2020 option also? Would be nice to have this feature from the plugin's available instead of manually installing from terminal :-)
Btw: did you manage to get dup-proxy-2020 start automatically after a reboot? somehow that does not work for me and I have to start this tool manually after an reboot.
-
https://file.io/jZtYnHbJkNCI
I have 2 services (UDP ports 1900 and 5353) so files are duplicated. Binary in sbin is from github repo (better not to trust and replace :) )
Its not perfect, but its ok, running as service even after reboot.
-
:P
Great. I got the file and will try it out. thnx for the help.
-
@mnaim, i noticed 1 missing file in your config in regards to mine:
etc/conf.d/udp_proxy_2020_1900 (with content udp_proxy_2020_1900_enable=YES)
i had etc/rc.conf.local (with content udp_proxy_2020_enable=YES)
so I added
etc/conf.d/rc.conf.local (with content udp_proxy_2020_enable=YES)
rebooted, but still not auto booted.... should the filename matter? I uses rc.conf.local as described https://github.com/synfinatic/udp-proxy-2020/tree/main/startup-scripts/pfSense (https://github.com/synfinatic/udp-proxy-2020/tree/main/startup-scripts/pfSense)
-
If you copy all files to folders as in archive udp_proxy_2020 will start in 2 instance after reboot, you can check using ps aux | grep udp-proxy-2020
I have another problem, process probably start before interfaces and in my case VLANs are initialized, need to postpone it little bit or setup service dependency.
-
this is the result (so maybe I should add a delay as you describe? never done that. how does that work?)
# ps aux | grep udp-proxy-2020
root 48357 0.0 0.0 12740 2216 0 S+ 09:10 0:00.00 grep udp-proxy-2020
=======
after manual starting
# ps aux | grep udp-proxy-2020
root 47945 0.0 0.0 12752 2088 - Ss 09:12 0:00.00 daemon: /usr/local/bin/udp-proxy-2020[48122] (daemon)
root 48122 0.0 0.1 731088 13592 - S 09:12 0:00.05 /usr/local/bin/udp-proxy-2020 --port 9003 --interface igb1,wg0 --logfile /var/log/udp-proxy-2
root 73316 0.0 0.0 12740 2216 0 S+ 09:13 0:00.00 grep udp-proxy-2020
-
I found out, that unlike osudpbroadcastrelay udp-proxy-2020 cant forward multicast traffic, so its useless for some of my devices :/ https://github.com/synfinatic/udp-proxy-2020/issues/98
This upnp,ssdp are so crappy protocols...
-
Hey there,
I already posted a thread in the german forum here (https://forum.opnsense.org/index.php?topic=28465.0) but I think this might be better placed here. I beg your pardon for the crosspost.
I use the plugin to transmit some multicast packets between my vlans. This is working great for normal vlans, but not for my OpenVPN. I connect some devices per OpenVPN. Those devices are in the OpenVPN network (10.10.0.0/24 in my case).
The plugin lets me select the networks to serve, but the OpenVPN-network is not listed, so I can't use it over vpn.
Does anyone have suggestions how to solve this issue?
Thanks alot
-
Running 22.1.r2 and I'm having some difficulty getting it to run:
2022-01-24T16:48:55-06:00
root /usr/local/etc/rc.d/os-udpbroadcastrelay: WARNING: failed to start osudpbroadcastrelay
Are there any known compatibility issues known at this moment?
I have the same issue, for all but the first rule...
No other logging available, unfortunately...
How can I find out what is causing this?
(Running on latest - OPNsense 22.7.1-amd64)
-
Login via ssh as root and try:
sh -x /usr/local/etc/rc.d/os-udpbroadcastrelay start
That should give you a hint at what exactly is failing.
-
Login via ssh as root and try:
sh -x /usr/local/etc/rc.d/os-udpbroadcastrelay start
That should give you a hint at what exactly is failing.
That gave me IP_ADD_MEMBERSHIP on rcv: Invalid argumentI had 192.168.70.255 as multicast address. Removed it and the line turned green and the service started.
Needed to add a rule to allow (in my case udp/5901) traffic to other vlan.
For my ChromeCast this was not needed to add additional firewall-rules (but the broadcast address there is: 224.0.0.251).
-
Does anyone have any good suggestions on how to best get the port in use by devices if documentation is unavailable?
I have some Harman Kardon speakers that I would like to reach from a separate VLAN but I got no idea which port I should be forwarding.
-
Sorry to bring up an older thread. I have some questions about this udpbroadcastrelay. I understand how it cand replace avahi as a mdns repeater. I'm not convinced on the use of it to replace pimd or any form of pim sparse mode. The reason I say this is because udpbroadcastrelay can send out multicast traffic without regard to whether a device is part of the group or not increasing its packet overhead. Pim-sm on the other hand has been designed to allow clients to join or leave multicast groups.
I am currently running avahi and pimd on pfsense. I may take up opense in the near future. My system is running without any issues with Sonos, HEOS, Airplay , Apple screen sharing, and Miracast across multiple vlans. Currently only firewall rules are to allow all. Trying to get connectivity working first then lock it dowm
Marjohn56 maybe you could help.
The issue I'm trying to resolve is with the DIAL multiscreen protocol my packet captures look like the post from thexy post 88
To answer thexy the problem at hand is the server needs to send it's reply to client doing the search via tcp at the client ip address and application port. From your capture listed the server is seeing the request from the relay, but the source ip address and port were changed during the relay, so the client never establishes the connection.
I am unclear on the command string to have the relay maintain the source ip and port that is critical.
MKnusperer is also describing the same issue in post 122. Others that are having issues with TVs Roku's chromecasts.... are probably having problems with this DIAL multiscreen protocol.
If the code could parse the ssdp packet for the. ST DIAL Multiscreen line maybe it could be handled differently
As a side note if you start DIAL multiscreen server client connection while in the same vlan and then move the client to a different vlan it's possible to maintain the connection,
-
Hi All,
I have split my network into VLANs and am struggling to see Bonjour devices (else why would I be here? 😛 )
The 3 VLANs I am concerned with, that have Bonjour devices, are;
- VLAN1 - mgmt, 10.0.1.0/24
- VLAN10 - my devices, 10.0.10.0/24
- VLAN20 - service devices, 10.0.20.0/24
Main goal, at moment, is that I have an LG TV, advertising Apple TV, on VLAN20 that my iPhone on VLAN10 cannot 'see'.
I have installed and enabled the plugin as described for mDNS (running manually shows lots of '<-' and '->' lines, so mDNS traffic is being detected (?).
I currently have allow TCP any>any rules on each VLAN.
I have tried running a Bonjour browser on laptop, also VLAN10, and can see iPhone and other devices, all in VLAN10. But, nothing else.
Any help here would be greatly received 😀
EDIT - not sure how, but it seems VLAN10 sends to the broadcast address, and other VLANs send to their gateway?
SOLVED - For anyone else having similar issues in future;
- Installing the plugin and enabling on selected interfaces may be enough.
- The problems come when you have firewall blocking certain things. In my case this was the FireHOL block list which blocks RFC1918 networks, and AND 224.0.0.0/3 networks 😟
Adding a negation for these and it all magically works!
- No, seriously, it is magic and it is as easy as installing. Just be aware of what else you already have in place 😟
-
I've just found another document, a Cisco one... not sure it's totally correct.
https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/7-6/chromecastDG76/ChromecastDG76.pdf (https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/7-6/chromecastDG76/ChromecastDG76.pdf). Interesting in they say you can cast to the chromecast, but not manage it.
Have you tried MDNS repeater? You can use it alongside UDPBR providing you don't use the same ports, mdns repeater uses port 5353 and 224.0.0.251
How would you run mdns and udpbr together? Would the ports need to be changed on udpbr? I followed your guide for casting from my phone to YouTube and it doesn't work for me. I'm using the exact rules you had for 5353 listening on the 2 interfaces one where the TV is and one where the phone is. Firewall is wide open for the TV to talk back to the phone.
-
Curious if anyone has had any success w/ Logitech Harmony Hubs? If so, would you mind sharing some specifics.
ROON and SONOS is working fine, but have been unable to setup the Logitech HUBs across VLANs.
NM, think it's working now, had to use multicast of 224.0.0.1 and port 5224.
Thanks
Can you share what your entry is to get Roon working? I have read on Roon forums that it needs port 9003, but that doesn't seem sufficient. I have Airplay and Sonos working, but not Roon.
Yes, added 9003 to UDPBR, selected interfaces/networks, and created a FW rule to allow my ROON server to talk to the other networks. That's about it and was a minimul effort.
-
Hi all,
I'm trying to find a solution to the following problem: I have two separate apartments behind the OPNsense firewall, each apartment with its own client-vlan and IoT-vlan. I want to relay udp packages between the client-vlan and IoT-vlan of each apartment, but not between both appartments (Apartment A should not see devices in apartment B and vice versa). I had this working with multicast-relay https://github.com/alsmith/multicast-relay (https://github.com/alsmith/multicast-relay) on docker on the udm-pro, but would like to switch to OPNsense.
I have tried starting multiple instances of UDPBR on the different vlans/interfaces, but it's not letting me use the same port twice. Is there any way to get around this, seeing that I am using different interfaces?
Multicast-relay uses a single instance and lets the user specify in the ifFilter.json which subnets are allowed to talk to each other. Could this be an option for UDPBR?
-
It seems that since upgrading to 23.1, my setup for SSDP which had been working reliably in 22.X is now only working for a short time and then silently stops working. The daemon is still running but packets are no longer forwarded between subnets.
If I change the config of udpbroadcastrelay in the UI to force a restart of the daemon it will work for a few minutes but then packets stop flowing stop again. For example, if I change the interfaces to something else and then back.
Has anyone else encountered this? I can't imagine what else could cause this besides udpbroadcastrelay having some issues.
-
Hello, very new opnsense user here. I'm about 3 days in. UDP broadcast relay made casting to my TVs stupid simple, so thanks! I followed the guidance in this thread and it was working pretty quickly across VLANs. However, I was wondering if anyone has a situation similar to my other. I have some security cameras around the home, they are configured for multicast on 224.1.3.X (X being 1 through 10) on port 20016. When on the same vlan, i can subscribe to these feeds with udp://224.1.3.X:20016. I have some raspberry pis affixed to the back of monitors around the home all displaying these multicast feeds in a no WAN access vlan.
I would also to view the multicast feed from my PC which is in a different VLAN. I have IGMP setup on my trunk ports, the camera ports, my PC's port, and the router's port. in UDP Broadcast relay, i set the relay port to 20016, selected my two vlan interfaces, and individually put in each multicast ip the cameras are on. I have some pretty open rules for the camera IPs, their multicast IPs, and all the ports they might use. It's not working and I'm not seeing anything in the firewall logs. I am hoping someone else has attempted to do something similar and may have some advice? :)
-----
As an additional note, I found in Marjohn56's gh repo that udp broadcast relay supports --msearch dial, this support doesn't appear to have made it into the opnsense plugin yet. Unknown arg: --msearch
-
Hi, I'm also jumping on this thread to say first, it works pretty great with HomeKit and chromecast.
I have no issue using this 2 services but I tried to debug only one issue where in the google home app, I'm unable to configure my nest hub but I can see the player on the small dashboard card or in the media dashboard but when I click on the device, it says that I'm not on the same wifi (but time to time it works and I'm able to configure...).
When it works I can see on the firewall that my phone communicate with the nest port on 8443.
Has someone figured out this thing?
-
-----
As an additional note, I found in Marjohn56's gh repo that udp broadcast relay supports --msearch dial, this support doesn't appear to have made it into the opnsense plugin yet. Unknown arg: --msearch
I've not had much time to play with Opnsense or the plugins for quite a while, work has been a pig since the end of covid. The PR's to udpbroadcastrelay to add the --msearch dial features etc were submitted by others quite a while ago, and whilst I did merge the PR's recently I never got around to pushing them upstream to the Opnsense repo. Apart from that I had not compiled the update and tested it. I have now done so and running it on my system it appears to work fine, though I don't use the new features. I've attached it here so you can try it. It's substantially larger than the executable distributed with Opnsense but that's because of my compiler settings. Try it, if there's an issue it might take a while for me to take a look so back up the original which lives in /usr/local/bin so you can change back if needed.
-
Hi all,
I'm currently using UDPBR as a relay for the Unifi Discovery Protocol, and things have been working swimmingly since day one of my opn deployment. Recently, I've been wanting to setup a failover Multi-WAN and have followed the instructions here (https://docs.opnsense.org/manual/how-tos/multiwan.html).
Things worked, however I've noticed that the relay no longer responds how I want it to. I did a little investigation and found the following:
- Wireshark shows that the packets are still being broadcast
- Setting the "Default Allow LAN to any" rule's gateway to "default" makes things work (not an option due to the routing getting all wonky)
Has anyone successfully used UDPBR on a multi-WAN setup? I realize this might not be related to UDPBR at all, but just wanted to boomerang this here just in case.
-
Recently, I've been wanting to setup a failover Multi-WAN and have followed the instructions here (https://docs.opnsense.org/manual/how-tos/multiwan.html). Things worked, however I've noticed that the relay no longer responds how I want it to.
I just experienced the exact same issue. Switching back to the default gateway rule didn‘t even work for me directly. Had to completely reboot the box to get it running again. If anyone has a solution to this, I‘d be very much interested.
-
Ok, I think I found a solution to this. Need to do some more thorough testing, but at least for the time being it seems stable. What helped me was to add the following rule to all interfaces that are part of the mdns relay, before the rule that sends traffic to the failover gateway group:
ALLOW from * to 224.0.0.251 port 5353, protocol UDP, IPv4
This should also work as a single floating rule instead of having to create the rule on all individual interfaces – something to be checked.
-
Hi,
I have got several VLANS in my home.
Two of them are "home" (my standard networ) and "IoT" (where I putt all my little internet of things devices).
I have two WiiM Mini Streamers in my IoT Network.
I now want to use the Symfonium app on my Android phone (home network) to stream my Jellyfin music to the WiiM Mini Streamer using the WiiMs functionalty as an UPNP renderer.
When I connect my mobile phone to the IoT Network, I can see the WiiMs as UPNP streaming targets.
When I am connected to my home network, I do not see them.
I now set up UDP Broadcast Relay as you can see in the attached scrrenshot.
I also opened the firewall between IoT and Home completetly (for testing).
However, I still don't see the WiiM Minis from my home network. However for the Chromcasts it works.
Any idea?
-
Not a direct answer, but instead of jellyfin music, have you considered Roon? https://roon.app/en/ (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/ (https://forum.wiimhome.com/threads/app-option-for-fixed-ip-devices-on-another-network.127/)
-
I can find the WiiM in the WiiM app. I think this works with the mDNS Multicast.
Only it cannot be discovered as an UPNP renderer. Seems to be different independent things that rely on different multicast of whatever...
-
post deleted
-
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.
-
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
-
Not a direct answer, but instead of jellyfin music, have you considered Roon? https://roon.app/en/ (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/ (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?
-
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:
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?
-
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:
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:
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:
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?
-
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 :)
-
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 (https://forum.opnsense.org/index.php?topic=38254.0) since this one has been inactive since Dec. 18 . . . but perhaps tagging you directly will get this post some notice.
Thanks in advance.
-
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.
(https://i.postimg.cc/9Xq1M9qP/UDPBR.png) (https://postimages.org/)
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.
(https://i.postimg.cc/65JGtjRK/Screenshot-2024-01-22-125251.png) (https://postimages.org/)
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.
-
Hi,
me also need some help to get multicast working across VLANs.
As a test, I'd want to serve an video, like this:
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:
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:
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!
-
Perhaps because it's RTP and not UDP?
-
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:
IP (tos 0x0, ttl 10, [DF], UDP) 192.168.12.101.47386 > 239.255.1.2.5004: UDP
And this is consistent with Wikipedia (https://en.wikipedia.org/wiki/Real-time_Transport_Protocol), where it is stated that RTP runs over UDP.
But maybe I simply misunderstood your reply?
-
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)
-
Then, to get the TV working I have to run:
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:
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:
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.
-
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.
-
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
-
thank for all information. ufabet com สมัครสมาชิก (https://www.ufag7.info/สมัครสมาชิก-ufabet)