netflector available as plugin (mDNS, SSDP, DIAL, WSD, WoL reflector)

[UnicronHD]

This is a tool that makes all kinds of multicast-based discovery (and casting) work across networks (or VLANs).

I have posted about it on Reddit and reception was quite good, so I thought I'll also mention it here.

The plugin is unofficial (for now). A net/netflector FreeBSD port is currently under review (bug 297489). When (if?) it is accepted - the plugin has a path toward official inclusion. Repository is signed and I am tracking OPNsense releases with the goal to support the last two versions of OPNsense (there are CI pipelines that build and test netflector on FreeBSD 14 and 15 and OPNsense 26.1 and 26.7). There are builds for Linux (binaries and a multi-arch container), macOS and FreeBSD.

Why this plugin when we have X and Y? Features mostly (and a very responsive author :)). There are many mDNS and some SSDP reflectors out there but none of the tools that I know of support both + WoL, DIAL (TCP), WSD and SSDP unicast response forwarding. Another feature missing from the other tools is recovery after interface re-creation. netflector also tracks current IPv4 and IPv6 addresses of the interfaces and recovers after temporary loss (or change) of the IP address.

The main motivation behind this project for me was to solve a real problem I have at home. My phone and my TV are in different VLANs, so vanilla multicast discovery does not work. While there are plenty of mDNS reflectors out there, my LG TV uses SSDP and DIAL. In order to cast YouTube from my phone to my TV following needs to happen:

• Phone sends M-SEARCH SSDP multicast request which needs to be reflected into TVs VLAN (other reflectors can do that).
• TV responds with the unicast 200 OK, which needs to be forwarded back to the phone. (can be allowed in firewall, less secure than using this tool).
• Phone initiates a device discovery TCP connection to TV (can be allowed in firewall, less secure than using this tool).
• TV replies with the details of its REST endpoint (works fine because established connections are usually allowed anyway).
• Phone initiates another TCP connection to TV's REST endpoint. The connection must be from the TV's subnet (could be allowed and NAT'ed in firewall).

So, to do this I would need to poke holes in the firewall and configure NAT. Additionally to that, I would still need to run some sort of reflector for SSDP multicast. How do I know? This is what I was doing for a couple of years :)

I also needed Wake-on-LAN to work across VLANs (PC -> TV), which none of the existing tools could do (at least I did not find any).

This tool does all that automagically:

• It reflects multicast discovery packets (mDNS / SSDP / WSD).
• It proxies unicast UDP responses (SSDP / WSD).
• It proxies the DIAL TCP connections, rewriting the device's advertised endpoints.
• It reflects Wake-on-Lan packets.
• It supports MAC filtering (so only specific devices are discoverable).
• It tolerates network interface re-creation. As long as new interface has the same name - reflection will continue.
• It has CARP support, including config sync (feature requested by kevinchalet on Reddit).

!!! Before adding any third-party repository: back up your config (System > Configuration > Backups) !!!

To install:

Code Select Expand

mkdir -p /usr/local/etc/pkg/keys /usr/local/etc/pkg/repos
fetch -o /usr/local/etc/pkg/keys/netflector-pkg.pub https://netflector.github.io/pkg/netflector-pkg.pub
fetch -o /usr/local/etc/pkg/repos/netflector.conf https://netflector.github.io/pkg/netflector.conf

and install the plugin (it will automatically install netflector as its dependency):

Code Select Expand

pkg install os-netflector
After this all configuration is done under Services > Netflector.

Packages are built for OPNsense 26.1 and 26.7, amd64 and aarch64 (four package trees, each tested on a real OPNsense install before publishing).

To remove:

Code Select Expand

pkg delete os-netflector netflector
rm /usr/local/etc/pkg/repos/netflector.conf /usr/local/etc/pkg/keys/netflector-pkg.pub
rm /usr/local/etc/netflector.toml

Your settings stay in config.xml. If you want those gone too, delete the entries under Services > Netflector before uninstalling.

BSD-2-Clause, full source on GitHub: https://github.com/netflector/netflector

Feedback is welcome.

Updates:
2026-08-13: initial announcement (netflector 0.15.2, plugin 0.1.4)

[Monviech (Cedrik)]

Nice good luck lets see how this goes, seems to fill a real void.

[UnicronHD]

Nice good luck lets see how this goes, seems to fill a real void.

Thank you!

[franco]

Nice work indeed! If upstream gives you trouble we can consider integrating via our ports tree. Just let me know in a couple of weeks how this progresses.


Thanks,
Franco

[UnicronHD]

Nice work indeed! If upstream gives you trouble we can consider integrating via our ports tree. Just let me know in a couple of weeks how this progresses.


Thanks,
Franco

Will do, thanks!

[Seimus]

Looking forward for this plugin.

I have exactly the same problem/use case as you described + as well a problem with Steam play between PC and TV.
This plugin looks like exactly what I would need.

Fingers crossed it will be adopted by FBSD sooner than later!


Regards,
S.

[UnicronHD]

Looking forward for this plugin.

I have exactly the same problem/use case as you described + as well a problem with Steam play between PC and TV.
This plugin looks like exactly what I would need.

Fingers crossed it will be adopted by FBSD sooner than later!


Regards,
S.

You can try it now, before it becomes official (see instructions in the first post). If you do - let me know if works well for you.

[Seimus]

Planning to test it once I have more time.

I have two use cases I want to try.
First is same as yours.
Second is Steam link, to stream games from PC to TV.

I will definitely let you know.

Regards,
S.

[drosophila]

Without having tried it for lack of need ATM (but will likely arise in the future): does it have a way of restricting discovers reflection to specific (V)LANs, so that, say, the IoT VLAN cannot discover a phone nor TV, while the guest VLAN can see the TV VLAN but not the phones VLAN, but not wake up devices in the server and office VLANs, etc.? Or would that just be set up via conventional firewall rules?

[UnicronHD]

Without having tried it for lack of need ATM (but will likely arise in the future): does it have a way of restricting discovers reflection to specific (V)LANs, so that, say, the IoT VLAN cannot discover a phone nor TV, while the guest VLAN can see the TV VLAN but not the phones VLAN, but not wake up devices in the server and office VLANs, etc.? Or would that just be set up via conventional firewall rules?

This should work. You would configure several reflector entries. Each reflector entry is unidirectional, so LAN -> IoT lets devices in LAN discover (and wake up) devices in IoT, but not vice-versa. Also, each VLAN pair needs to be configured independently, so there will be no wildcard LAN -> ANY_VLAN things. You explicitly allow discovery between two VLANs in each direction. You could have something like this (each point is a reflector entry with the corresponding protocols enabled):

• LAN -> IoT (mDNS, SSDP)
• LAN -> Cameras (WSD)
• LAN -> Servers (WoL)
• Guest -> IoT (mDNS, SSDP)

This way devices from LAN can discover devices in IoT and Cameras VLANs and wake devices on Servers VLAN. Devices from Guest VLAN can only discover devices in IoT VLAN.

If you need even more control, you could use MAC filters (e.g. to allow devices from LAN to discover TV1 in IoT VLAN and devices from Guest to discover TV2 in the same IoT VLAN).

I hope this answers your question. Let me know if you need any help with the configuration.

[UnicronHD]

Nice work indeed! If upstream gives you trouble we can consider integrating via our ports tree. Just let me know in a couple of weeks how this progresses.

Update (because more than two weeks have passed): I got absolutely no reaction to my new port suggestion. On the bright side: it was not rejected :) So I guess I'll keep waiting...

[franco]

Years can pass without rejection...  ;)

Can you create a PR for https://github.com/opnsense/ports preferably under opnsense/netreflector to avoid clashing with an eventual FreeBSD inclusion? The files can stay the same, but so we know it's out of tree.


Thanks,
Franco

[RamSense]

This looks like a very interesting plugin.

Would you consider adding dedicated support for Roon discovery (SOOD/RAAT discovery) as an additional reflector type?

Roon music uses UDP port 9003 and relies on both broadcast and multicast (239.255.90.90:9003) for discovery. This normally does not cross routed VLANs or Layer-3 VPNs such as WireGuard or OpenVPN.

For this reason I currently use udp-proxy-2020 directly on OPNsense. It was specifically designed to make Roon discovery work across routed networks and VPN tunnels, and in my case it allows Roon clients/endpoints connected through WireGuard to discover and communicate with the Roon server on the LAN.

One important detail is that simply forwarding UDP/9003 may not be sufficient for all Roon use cases. A remote Roon endpoint connected through a routed VPN must remain reachable on its actual VPN IP after discovery.

Projects such as RoonBroadcastRelay therefore explicitly preserve the original source IP when relaying Roon discovery traffic. This allows the Roon server to subsequently connect back to the endpoint using its real VPN address. It also supports unicast delivery towards roadwarrior VPN clients where multicast/broadcast cannot be delivered directly.

So, if Roon support were added to Netflector, an ideal implementation would probably need to cover:

* UDP 9003
* IPv4 broadcast discovery
* multicast 239.255.90.90:9003
* LAN/VLAN <-> routed Layer-3 VPN interfaces such as WireGuard/OpenVPN
* preservation of the original endpoint/source IP where required
* unicast forwarding towards VPN peers/roadwarrior clients
* preferably either configured VPN peer targets or some form of automatic client/peer learning

The reason Netflector is especially interesting for this is that it already has native OPNsense/FreeBSD integration, interface monitoring, directional reflector configuration and a GUI. If it could handle the Roon-specific discovery semantics as well, it could potentially replace the separate udp-proxy-2020 service completely.

Would a dedicated Roon/SOOD reflector like this fit within the scope of Netflector?

[UnicronHD]

Would a dedicated Roon/SOOD reflector like this fit within the scope of Netflector?

Thanks for the idea! From what you are describing it sounds like Roon/SOOD might be a good candidate to support. I will look into it.

[Monviech (Cedrik)]

Careful that you don't accumulate too many edge cases and turning it into an unmaintainable swiss army knife without a clear identity.

I know AI helps but long term having less or dedicated tools fits unix philosophy better.

Not saying you cannot add whatever you want though, just saying from some experience. Though everybody should of course make their own experiences.

I think the gist is, define what Netflector is before accepting every discovery protocol it could theoretically support, especially application specific ones you will have to support forever long after the application might have already died.