Messages

[Broadcasts]

Thanks for the detailed answer! The diretions are right, I have now made the changes you suggest and will report back after a while of testing. For now the Sonos app doesn't see the speakers, but I will give it a while before the changes become active.

To mention, I didnt make any specific firewall rules for it.

Edit: Aaaand bam, there are the speakers again in the app. Started to work after the change in Netflector! :D
One thing, do I also need to tick "Broadcasts"?

For now, thanks for this!

Good to hear. Leave Broadcasts off: SSDP goes to the multicast group, and changing one thing at a time tells us what fixed it. Your old setup only failed now and then, so give it a couple of days before we call it solved.

The wait right after the change may come from the firewall. With the relay, the speakers answer the app's searches directly, as new traffic from the Sonos VLAN to the phone's VLAN. If no rule on the Sonos VLAN interface passes it, those answers are dropped and the app has to wait for the speakers' own periodic announcements. Firewall > Log Files > Live View shows such drops as blocked UDP from the speakers to the phone. If you see them, add a pass rule on the Sonos VLAN interface for UDP from the speakers to the phone's network.

[Source]

After using netflector for two days I notice that I regularly cant find my Sonos systeem in the Sonos app because it is on a different VLan. With the old udpbroadcastrelay plugin in combination with the mdns repeater I never had these problems. Am I missing something?

Thanks for the report. First check the direction of your reflector. Unlike udpbroadcastrelay and mdns-repeater, netflector relays one way: Source is the VLAN the phone with the Sonos app is on, Target is the Sonos VLAN. If the app runs on more than one VLAN (say, two SSIDs), each one needs its own reflector. If yours is the other way round, swap it and see whether that alone fixes it.

If the direction is right, there is one real difference from your old setup. udpbroadcastrelay forwarded SSDP (UDP 1900) unchanged, so the Sonos app saw every speaker announcement and search reply coming from the speaker's own IP. netflector relays SSDP through the firewall instead: those packets reach the app from the firewall's address, and the speaker's address is only in the LOCATION header. Some Sonos software, the SoCo library for one, takes the speaker address from the packet source and ignores LOCATION. I haven't confirmed the Sonos app does the same, but it would explain what you see.

To test that:

• On your current reflector, untick SSDP and leave mDNS on.
• Add a second reflector with the same Source and Target, Bidirectional ticked, no protocol boxes, Relay ports 1900 and Multicast groups 239.255.255.250.

That relays SSDP unchanged, as udpbroadcastrelay did, so it relies on the firewall rules you had for it: the speakers answer the app directly, from the Sonos VLAN to the app's VLAN.

If the app still loses the system after that, please post the reflector settings (Source, Target, Bidirectional, the protocol boxes, mDNS services, Devices) and, with Counter interval set to 60, the counter lines from Services > Netflector > Log File around a failed attempt.

I am also using igmp proxy between my iptv wan and vlan.

Do you think I could also configure this with Netflector?

Have a look at this : https://forum.opnsense.org/index.php?topic=51192.msg262139#msg262139

It keeps IPTV issues nicely away from your OPNsense :)

After setting things up and making sure IPTV works, I packed the TV box from KPN and started using an app. Much better experience and no need in IGMP proxy :)

Another question. I am also using igmp proxy between my iptv wan and vlan. Do you think I could also configure this with Netflector?

No, this will not work. IGMP proxy relays multicast subscription requests and then forwards the traffic. Netflector does discovery-related things.

Oké, I replaced both the packages for netflector and everything is still working fine!

One thing I am not sure about is if I need the bidirectional flag for my situation

You almost never need it. If you have client devices (phone, laptop, etc.) in one VLAN and your target devices (TV, Chromecast, etc.) in another VLAN - you do not need it. You make source_if the VLAN with clients and target_if the VLAN with targets.

You will need bidirectional if you have TVs in both VLANs AND you have phones in both VLANs.

Nice!
Currently I run mdns repeater and ssdpreflector between my lan and iot vlan.

If I am correct I can drop these packages for this single package? :D

It would seem so, yes. Let me know if you need help with the configuration. If you will want to enable dial - you will probably require some firewall adjustments (for input chain to accept DIAL responses from IOT VLAN). If everything works for you now though - you will probably only need mdns and ssdp set to true. Dial is for things like my stupid LG TV that does not accept DIAL connections from other networks even after successful SSDP discovery.

Thanks everyone! I'm surprised it has released already. I was expecting to wait until 27.x :).

Any chance for SSDP via wireguard? Adding peers did not help.

SSDP over WireGuard should work, but peers are not the part that makes it work. Discovery over a tunnel depends on the client searching. When the phone's M-SEARCH arrives on the WireGuard interface, netflector relays it to the LAN and sends the devices' unicast replies back to the phone. That leg needs no peers. Peers only cover the devices' periodic NOTIFY advertisements, which reach a peer as unicast on port 1900. A client sees those only if it listens on that port, and most find devices by searching anyway.

Things to check:

• Searches go from Source to Target. With the phones behind the tunnel, set the reflector up as:
  
  • Source: your WireGuard interface
  • Target: LAN
  • SSDP: checked
  • Source peers: the phones' tunnel addresses, e.g. 10.10.10.2
  With the WireGuard interface as Target and Bidirectional unchecked, the phone's searches are counted as skipped and never relayed.
• Check that the search reaches the firewall at all. Run this in a shell while the app is searching, with your WireGuard interface's device name:
  
  Code Select Expand
  tcpdump -ni wg0 udp port 1900The phone's WireGuard only sends to destinations in its AllowedIPs, so 239.255.255.250 has to be covered (0.0.0.0/0, or add 239.255.255.250/32). Some apps also search only on Wi-Fi whatever the VPN does. If tcpdump shows nothing, netflector has nothing to relay.
• Once a device is found, the app connects to its LAN address, so the phone's AllowedIPs need the LAN subnet, and a firewall rule on the WireGuard interface has to let it reach the LAN. Some TVs refuse clients from another subnet; for casting, checking DIAL works around that.

If it still fails, please post /usr/local/etc/netflector.toml, the netflector and os-netflector versions, the client and app, the tcpdump output, and the log (Services > Netflector > Log File) with Log level set to Debug on the General tab. The line I'm looking for starts with "reflected SSDP search from 10.10.10.2".

Great, The plugin 0.1.6 with netflector 0.16.0 is installed and working perfectly here.

Thanks again for all the work and support!

Happy to help, thanks for the idea and all the testing.

netflector 0.16.0 and plugin 0.1.6 are released. The main change is addition of generic UDP relay (udp_ports, udp_groups, udp_broadcast) to support other discovery protocols (like Roon's SOOD) and peers (source_peers, target_peers) to support interfaces without multicast/broadcast domains.

Thanks for running the baseline. If it's just as flaky on plain Wi-Fi with no tunnel and no netflector, then it's Roon itself after a force-close, and there's nothing left to fix on the network side.

Good to know where things stand though. Peers fix discovery over WireGuard, but the phone needs a /24 on its tunnel address, otherwise it sends its endpoint announcement to itself. And the router has to drop 10.10.10.255 on the WireGuard interface, or it forwards the packet back into the tunnel and replies to the phone with ICMP. I'll put both into the docs, we'd never have found them without your captures.

Thanks again for all the testing. I'll prepare a new official release soon.

Great, thanks for nailing down the rule direction. That closes the netflector side: discovery now crosses correctly both ways. The Core's queries reach the phone, the phone's announcements reach the LAN broadcast once each with the phone's source kept, nothing answers the phone with ICMP anymore, and the Core replies to them.

What is left happens after discovery. From the announcement the Core learns the endpoint's RAAT port (tcp_port 9200 in your capture) and connects to the phone over plain routed TCP, which netflector is not part of. Three things would tell us where it fails:

• A baseline: the same four force-close/open attempts with the phone on your LAN Wi-Fi, WireGuard off. If the endpoint is intermittent there too, it is Roon's own behaviour after a force-close, for example the Core still holding the previous session for that device.
• During a run over WireGuard with both good and failed attempts, capture on both interfaces at once:
  tcpdump -ni wg0 -w /tmp/wg0.pcap host 10.10.10.2
  tcpdump -ni ax1 -w /tmp/ax1.pcap host 10.10.10.2
  Note the time of each attempt and whether the endpoint appeared, then send me both files. I want to see whether the Core opens a TCP connection to 10.10.10.2:9200 on the failed attempts, whether that connection shows up on both interfaces, and what the phone answers.
• In a failed attempt, how long did you wait? The phone re-announces every few seconds, so if the endpoint never shows up while announcements keep arriving, the Core is ignoring them or its TCP connect keeps failing.

@RamSense, thanks, this run settles the relay question: wg0 resolves with its /24, both directions are registered with broadcasts, and the announcements reach ax1 on every attempt. Sorry about trace, by the way: release builds compile it out, so debug was all that binary could log.

Your log shows something else though: every datagram from the phone is relayed twice. I reproduced that locally once I enabled IP forwarding on my test router. WireGuard interfaces have no broadcast flag, so the router treats 10.10.10.255 as an ordinary host and forwards the packet back out wg0. netflector picks up that forwarded copy too, and the WireGuard driver, finding no peer for 10.10.10.255, answers the sender with an ICMP "host 10.10.10.255 unreachable". So since the /24 change OPNsense has most likely been answering every Roon announcement with an ICMP error to the phone, which is exactly what udp-proxy-2020 found breaks Roon on iOS. Your earlier capture without ICMP was taken with the /32, where this does not happen.

Could you try this:

• First confirm the ICMP: run tcpdump -ni wg0 icmp while opening Roon on the phone. I expect "host 10.10.10.255 unreachable" from 10.10.10.1 to 10.10.10.2.
• Add a firewall rule on the WireGuard interface: action Block (not Reject), direction in, quick, destination single host 10.10.10.255, placed above your pass rules.
• Repeat the ICMP capture, it should now stay empty, and repeat the four open/close attempts.

netflector captures ahead of the firewall, so it still relays the announcement. In my test setup the rule leaves exactly one relayed copy per announcement and no ICMP toward the phone.

@RamSense, thanks, that narrows it down. I rebuilt your setup locally: FreeBSD, a real WireGuard tunnel, the router's wg0 at 10.10.10.1/24, a client at 10.10.10.2/24 sending 348 bytes to 10.10.10.255:9003. There netflector relays the packet to 192.168.1.255:9003 with the client's source kept, so something differs on your box.

Could you set log_level = "trace", restart netflector, open Roon on the phone so it announces a couple of times, then stop it, and send me:

• The output of netflector-0.16.0rc2-freebsd15-amd64 --version and your config file.
• Command line you use to start it, and any NETFLECTOR_* environment variables set for it.
• The full log of that run.
• Whether your LAN is ax1 itself or a VLAN, bridge or lagg on top of it.

Also, please make sure the netflector service from the plugin is not running at the same time. pgrep -lf netflector should list only the netflector-0.16.0rc2-freebsd15-amd64 process you started by hand. If it also shows /usr/local/sbin/netflector or a daemon: line for it, disable the service on the plugin's page, or stop it with service netflector onestop.

@RamSense, that is the smoking gun, thank you. The 348-byte packet is the phone announcing itself as an endpoint, sent to the broadcast address of its tunnel interface. Roon derives that from the address and mask, and for a /32 the broadcast address is the host's own address, which is why you see 10.10.10.2 -> 10.10.10.2. netflector relays broadcasts from wg0, but that packet is not one, so the Core never hears the announcement and only learns the phone when it happens to answer one of the Core's own queries.

Could you change the iPhone's interface address in the WireGuard app to 10.10.10.2/24 and test again? Roon should then announce to 10.10.10.255, which netflector relays to the LAN broadcast with the phone's source address kept. A capture on the LAN should show the 348-byte packets arriving at 192.168.1.255:9003.