"Recent posts
#1
Development and Code Review / Re: netflector available as pl...
Last post by RamSense - Today at 05:44:20 PMThanks for looking into this in more detail. This sounds very promising.
I had a closer look at how udp-proxy-2020 actually handles this, since it is already proven to work with Roon across routed networks and VPN connections.
As far as I can see, udp-proxy-2020 does not implement any SOOD-aware query/response proxying and does not interpret the SOOD payload. It captures the configured UDP traffic and reinjects it onto the other interfaces while preserving the original source IP and UDP source/target ports.
So I think your "naive" solution may actually be the right model for SOOD: preserve the original endpoint and let subsequent unicast communication use normal routing, rather than making Netflector part of that unicast conversation.
That also seems to fit the output-device case you mentioned. Netflector would not need to decide whether a "Q" semantically represents a discovery query from a Remote or an announcement/discovery packet from an output device. It can simply relay the SOOD packet while preserving its original source identity.
There is another detail which seems relevant to your question about unicast responses. Aaron Turner's Roon Wireshark dissector indicates that, besides the normal Roon Server discovery on UDP/9003, there is also a Roon Discovery service where replies may originate from an ephemeral UDP port and the dissector therefore uses conversation tracking. To me that is another argument in favour of preserving the original source IP and port rather than introducing SOOD-specific response translation.
One implementation detail from udp-proxy-2020 may also be worth keeping in mind. In addition to BPF capture/injection it opens a normal UDP listener on the configured port and discards anything received there. That was added because ICMP Port Unreachable responses could otherwise cause problems for Roon clients, particularly iOS clients over VPN. I don't know whether that will be relevant to Netflector on OPNsense, but it seems worth being aware of when testing a first implementation.
So I would definitely start with the simple source-IP/source-port preserving model. If you build an initial SOOD implementation that way, I would be very happy to test it with Roon Remote over WireGuard and also with the Roon server/output side.
I had a closer look at how udp-proxy-2020 actually handles this, since it is already proven to work with Roon across routed networks and VPN connections.
As far as I can see, udp-proxy-2020 does not implement any SOOD-aware query/response proxying and does not interpret the SOOD payload. It captures the configured UDP traffic and reinjects it onto the other interfaces while preserving the original source IP and UDP source/target ports.
So I think your "naive" solution may actually be the right model for SOOD: preserve the original endpoint and let subsequent unicast communication use normal routing, rather than making Netflector part of that unicast conversation.
That also seems to fit the output-device case you mentioned. Netflector would not need to decide whether a "Q" semantically represents a discovery query from a Remote or an announcement/discovery packet from an output device. It can simply relay the SOOD packet while preserving its original source identity.
There is another detail which seems relevant to your question about unicast responses. Aaron Turner's Roon Wireshark dissector indicates that, besides the normal Roon Server discovery on UDP/9003, there is also a Roon Discovery service where replies may originate from an ephemeral UDP port and the dissector therefore uses conversation tracking. To me that is another argument in favour of preserving the original source IP and port rather than introducing SOOD-specific response translation.
One implementation detail from udp-proxy-2020 may also be worth keeping in mind. In addition to BPF capture/injection it opens a normal UDP listener on the configured port and discards anything received there. That was added because ICMP Port Unreachable responses could otherwise cause problems for Roon clients, particularly iOS clients over VPN. I don't know whether that will be relevant to Netflector on OPNsense, but it seems worth being aware of when testing a first implementation.
So I would definitely start with the simple source-IP/source-port preserving model. If you build an initial SOOD implementation that way, I would be very happy to test it with Roon Remote over WireGuard and also with the Roon server/output side.
#2
26.7 Series / Re: APU1: No network with 26.7...
Last post by iam - Today at 04:04:30 PMI don't know if it's the same issue as I haven't observed any upgrade failure. But the 26.7.3 works indeed after removing the driver plugin.
Thank you.
Thank you.
#3
High availability / Managing HA cluster via OPNCen...
Last post by upscale4446 - Today at 03:50:51 PMHi guys,
can someone guide me through the setup of adding existing OPNsense clusters to an OPNCentral instance?
I've got a few questions:
If there are any further best practices/good to know-points please let me know.
Thanks & BR,
upscale4446
can someone guide me through the setup of adding existing OPNsense clusters to an OPNCentral instance?
I've got a few questions:
- Do I just add both nodes as normal standalones?
- If there is no cron job for syncing the two nodes would I need to publish all changes on both nodes or would I push changes to the master, connect to the master and sync with the secondary?
- Are there best practices for managing clusters via OPNCentral?
- Can I install the OPNCentral plugin on a cluster or should it be a dedicated device?
If there are any further best practices/good to know-points please let me know.
Thanks & BR,
upscale4446
#4
26.7 Series / Re: Fetching base-26.7.3-amd64...
Last post by franco - Today at 03:34:38 PMYes, sorry. Remembered it wrong. Wonder who made these options so confusing. ;)
Cheers,
Franco
Cheers,
Franco
#5
26.7 Series / Re: Fetching base-26.7.3-amd64...
Last post by nerd - Today at 03:27:29 PMI am guessing you meant lower-case g instead of uppercase G?
-G Return the log file of the last upgrade. Since
upgrades run without network connectivity and user
interaction there is no direct way to observe it
other than an attached console or monitor which
can still miss important context.
-g Return the log file of the last update. Update
logs are stored persistently when the update or
upgrade procedure requested a reboot. It is also
stored when errors have been encountered. This
can help with diagnosing update problems, package
conflicts and package manager bugs.
lowercase g is indeed only from when the upgrade succeeded so not useful to debug further.
-G Return the log file of the last upgrade. Since
upgrades run without network connectivity and user
interaction there is no direct way to observe it
other than an attached console or monitor which
can still miss important context.
-g Return the log file of the last update. Update
logs are stored persistently when the update or
upgrade procedure requested a reboot. It is also
stored when errors have been encountered. This
can help with diagnosing update problems, package
conflicts and package manager bugs.
lowercase g is indeed only from when the upgrade succeeded so not useful to debug further.
#6
26.7 Series / Re: Wan connection fails after...
Last post by RamSense - Today at 03:25:35 PMThanks for the update. Your gateway-group finding prompted me to check my configuration as well.
I also found an old unused gateway group. It contained only `WAN_DHCP6` as Tier 2 and was not referenced by any firewall rule, so I removed the group through the GUI and applied the configuration.
However, this does not appear to be the root cause on my system.
After removing the unused gateway group, I kept my existing `radix4` workaround active and then tried to switch the IPv4 FIB algorithm live back to `radix4_lockless`:
sysctl net.route.algo.inet.algo=radix4_lockless
This failed immediately:
net.route.algo.inet.algo: radix4
sysctl: net.route.algo.inet.algo=radix4_lockless: Invalid argument
At the same time the kernel logged a new failure:
[fib_algo] inet.0 setup_fd_instance: radix4_lockless algo instance setup failed, failures=0
The active algorithm therefore remained `radix4`.
My WireGuard IPv4 route and connectivity remained correct during the test, but this was because the switch to `radix4_lockless` never succeeded:
route to: 10.10.10.2
fib: 0
interface: wg0
So in my case, removing the old unused gateway group did not make `radix4_lockless` usable again.
For now I therefore still need:
net.route.algo.inet.algo=radix4
as the workaround.
This suggests that an incomplete or stale gateway group may be a trigger in some configurations, but it does not appear to be the sole cause of the `radix4_lockless` setup/rebuild failure.
I have not rebooted after removing the group; this was a live test while keeping the persistent `radix4` tunable in place.
DEC850v2 / OPNsense 26.7.3_8 / PPPoE / WireGuard
I also found an old unused gateway group. It contained only `WAN_DHCP6` as Tier 2 and was not referenced by any firewall rule, so I removed the group through the GUI and applied the configuration.
However, this does not appear to be the root cause on my system.
After removing the unused gateway group, I kept my existing `radix4` workaround active and then tried to switch the IPv4 FIB algorithm live back to `radix4_lockless`:
sysctl net.route.algo.inet.algo=radix4_lockless
This failed immediately:
net.route.algo.inet.algo: radix4
sysctl: net.route.algo.inet.algo=radix4_lockless: Invalid argument
At the same time the kernel logged a new failure:
[fib_algo] inet.0 setup_fd_instance: radix4_lockless algo instance setup failed, failures=0
The active algorithm therefore remained `radix4`.
My WireGuard IPv4 route and connectivity remained correct during the test, but this was because the switch to `radix4_lockless` never succeeded:
route to: 10.10.10.2
fib: 0
interface: wg0
So in my case, removing the old unused gateway group did not make `radix4_lockless` usable again.
For now I therefore still need:
net.route.algo.inet.algo=radix4
as the workaround.
This suggests that an incomplete or stale gateway group may be a trigger in some configurations, but it does not appear to be the sole cause of the `radix4_lockless` setup/rebuild failure.
I have not rebooted after removing the group; this was a live test while keeping the persistent `radix4` tunable in place.
DEC850v2 / OPNsense 26.7.3_8 / PPPoE / WireGuard
#7
General Discussion / Re: Device Monitor - a tool fo...
Last post by pc44 - Today at 03:19:19 PMFantastic !!
Can't wait to update to this. Will probably do so this evening.
Thank you for your work.
Can't wait to update to this. Will probably do so this evening.
Thank you for your work.
#8
Zenarmor (Sensei) / Re: Cancelling my subscription...
Last post by Glitch01 - Today at 03:14:32 PMI disabled ZA free edition and didn't subscribe to the home tier because of lack of multi-threaded support. I found it was indeed bottle-necking my 10G network. While I did enjoy the extra layer of controls, it wasn't worth limiting my network traffic.
#9
Development and Code Review / Re: netflector available as pl...
Last post by UnicronHD - Today at 03:14:25 PMQuote from: RamSense on September 01, 2026, 05:46:59 PMWould you consider adding dedicated support for Roon discovery (SOOD/RAAT discovery) as an additional reflector type?
I have read a bit about SOOD discovery protocol. There are a few differences from existing protocols, but I still feel like it's a good match. Differences:
- We need to preserve source IPs. This is easy because netflector already uses raw BPF devices for all UDP traffic.
- There are 3 types of devices involved: remotes, server and outputs. Discovery would need to happen for remotes -> server and for server -> outputs. Potentially, all three could be in separate VLANs. For now, I think it would require two reflector entries.
Regarding your specific setup with blackjack and VPNs: I don't think we need to implement anything specific for that to work. If remotes are connected via VPN, that VPN interface would just be a source_if in the entry responsible for remote -> server discovery. I don't think that netflector needs to be aware of anything VPN-specific.
There is also the question of unicast responses. For SSDP and WSD netflector proxies these responses. For SOOD, I'm not yet sure what would be the best approach. The normal discovery flow is not a problem: remote sends "Q", server responds with "R". We can proxy the unicast response fine here, just use netflector's source IP/port when relaying "Q" to the server. However, it looks like "Q" does not necessarily mean Query. Output devices also send "Q" messages to server, which are not discovery queries. For these there is no unicast response, server connects directly to output device instead. So this "Q" must be relayed with the preserved IP/port. Naive solution here would be to not relay unicast responses and always preserve source IP/port for all relayed SOOD packets. This will require allowing UDP unicast packets from server back to remote (and from output back to server) in firewall. In your case you should probably already have that configured.
#10
General Discussion / Re: Device Monitor - a tool fo...
Last post by hacesoft - Today at 03:14:17 PMNew version released Device Monitor v2.3 : https://github.com/hacesoft/opnsense-devicemonitor
v2.3 (August 2026) — Direct SMTP and notification improvements
v2.3 (August 2026) — Direct SMTP and notification improvements
- Added selectable Email delivery method in Device Monitor settings.
- Local Sendmail / Postfix remains the default and preserves existing installations.
- Added built-in Direct SMTP delivery using Python smtplib; no additional Python package is required.
- Direct SMTP supports STARTTLS, SSL/TLS, and unencrypted SMTP.
- Added SMTP server, port, username and password configuration to the UI.
- Test Email now uses the currently selected delivery method.
- Existing configuration files are merged with new defaults automatically, so upgrading does not require a configuration reset.
- SMTP credentials are read from the protected Device Monitor configuration instead of being passed on the process command line.
- Configuration containing SMTP credentials is stored with restrictive file permissions.
- Includes the v2.2 Hostwatch fixes: newest Hostwatch record is selected per MAC, deleted devices no longer return from historical records, VLAN notification filtering was corrected, and real Hostwatch last_seen values are preserved during quick status updates.
