"Recent posts
#81
25.7, 25.10 Series / Re: Dnsmasq stops occasionaly
Last post by Monviech (Cedrik) - Today at 09:16:52 AMCould you post your findings to the dnsmasq mailing list to see if you get a response from the author? It would be great if you could do it, since you are affected directly by the issue.
https://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
https://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
#82
25.7, 25.10 Series / Re: [SOLVED] hostwatch at 100%...
Last post by d0shie - Today at 09:14:42 AMQuote from: amarek on Today at 08:14:11 AMTHX for this thread, this service was eating all my memory. after disabling it the usage was immediately at 28%, what a great solution to roll this out for all as fix implemented and started service............I was away from home and thankfully only the firewall's Web UI became non-functional, so I could still do remote SSH and diagnose the problem. For me the new service silently ate up 52GB of space for logging alone in less than 2 days and somewhat stalled the system as a result. I even read the changelog and noticed it but didn't think much at the time.
So, it's one of those blunders with an unexpectedly high impact, yes, but it's rare. And they did promptly push out hotfixes to remedy the issue on reasonably short notice.
#83
25.7, 25.10 Series / Re: New site PPPoE PMTU woes
Last post by meyergru - Today at 08:41:08 AMThat is because OpnSense itself contacts internet sites via its WAN interface (and the MTU of that). Your LAN devices contact OpnSense with their respective LAN MTU size, which should match. If it does not, there is MSS clamping (if enabled) or else it can go wrong.
#84
25.7, 25.10 Series / Re: ISC deprecation issues
Last post by meyergru - Today at 08:38:55 AMYes, I linked it in my first answer.
#85
Tutorials and FAQs / [HOWTO] Sonos speaker in multi...
Last post by fastboot - Today at 08:32:46 AMTo simplify the usage for my wife with the Sonos Speakers I implemented a light weight approach to get this working.
I am really not a fan of custom plugins (Don't get me wrong), but in fact usually I follow strictly the KISS principle. Which is in this case unfortunately not possible. Nontheless, thanks @franz.fabian.94 for your mDNS Plugin.
I also would like to thank the other contributors in the many threads within this forum.
This HOWTO exists to document a minimal working setup, deliberately avoiding unnecessary rules, ports, broadcast traffic, or multicast routing.
The issue:
Sonos devices rely on Multicast DNS (mDNS) for service discovery and control-plane coordination.
mDNS uses UDP port 5353 with the destination address 224.0.0.251 and is explicitly defined as link-local, non-routable multicast. As a result, mDNS traffic does not cross Layer-3 boundaries such as VLANs, SSIDs mapped to separate subnets, or routed interfaces.
In multi-VLAN or multi-SSID environments, controllers (iOS, Androidd Sonos App) and Sonos speakers typically reside in different IP subnets. Even with permissive firewall rules, discovery fails because mDNS packets are neither routed nor forwarded by default, and IGMP or multicast routing mechanisms do not apply to mDNS traffic.
Consequently, Sonos devices cannot be discovered or reliably controlled across VLAN or subnet boundaries unless mDNS packets are explicitly forwarded between the participating interfaces. Firewall rules alone are insufficient, as the limitation is architectural rather than policy-based.
As Is:
IOT_WIFI (192.168.10.0/24) That's the subnet where the Sonos speakers are attached to. Typically you consider this network as untrusted.
WIFI_1 (192.168.20.0/24) The Wifi Subnet where your trusted Wifi Clients are based.
Sonos_speaker_01: 192.168.10.20/32
Sonos_speaker_02: 192.168.10.21/32
iOS_Phone: 192.168.20.100/32
The solution:
1. Install the mDNS Plugin "os-mdns-repeater". You must hit the "Show community plugins" checkbox. Install it and reload the webpage after doing it
System -> Firmware -> Plugins
2. Enable the mDNS Plugin and add only the needed interfaces. You want to keep this clean. E.g IOT_WIFI & WIFI_1. Furthermore you could also add the IPs of the FW itself to the blocklist. 192.168.10.1/32, 192.168.20.1/32
Services -> mDNS Reapter
3. Create some aliases for better visibility and to manage. Not mandatory, but I do like it this way.
Firewall -> Aliases
Sonos_Speakers: 192.168.10.20/32 and 192.168.10.21/32
Ports_Sonos_TCP: 80,443,4070
4. Create the needed FW ruleset
Firewall -> Rules -> IOT_WIFI
Rule_1: SRC: Sonos_Speakers, DST: != Local_Networks, Protocol: TCP, Ports: Ports_Sonos_TCP
Rule_2: SRC: Sonos_Speakers, DST: 224.0.0.251/32, Protocol: UDP, Port: 5353
That's basically it. You can control now the Sonos Speakers with the Sonos App, or even Spotify and others. No broadcast rules, no IGMP rules, and no additional multicast ranges are required.
Cheers,
fb
Edit: This HOWTO does not cover any streaming from e.g LAN/WIFI_1 clients. It's only made to have the sonos speakers streaming as a client from the internet. For other use cases you must adapt it. Feel free to share your settings to the others. Personally I use the Sonos Speakers for other things like alerting via home assistant
I am really not a fan of custom plugins (Don't get me wrong), but in fact usually I follow strictly the KISS principle. Which is in this case unfortunately not possible. Nontheless, thanks @franz.fabian.94 for your mDNS Plugin.
I also would like to thank the other contributors in the many threads within this forum.
This HOWTO exists to document a minimal working setup, deliberately avoiding unnecessary rules, ports, broadcast traffic, or multicast routing.
The issue:
Sonos devices rely on Multicast DNS (mDNS) for service discovery and control-plane coordination.
mDNS uses UDP port 5353 with the destination address 224.0.0.251 and is explicitly defined as link-local, non-routable multicast. As a result, mDNS traffic does not cross Layer-3 boundaries such as VLANs, SSIDs mapped to separate subnets, or routed interfaces.
In multi-VLAN or multi-SSID environments, controllers (iOS, Androidd Sonos App) and Sonos speakers typically reside in different IP subnets. Even with permissive firewall rules, discovery fails because mDNS packets are neither routed nor forwarded by default, and IGMP or multicast routing mechanisms do not apply to mDNS traffic.
Consequently, Sonos devices cannot be discovered or reliably controlled across VLAN or subnet boundaries unless mDNS packets are explicitly forwarded between the participating interfaces. Firewall rules alone are insufficient, as the limitation is architectural rather than policy-based.
As Is:
IOT_WIFI (192.168.10.0/24) That's the subnet where the Sonos speakers are attached to. Typically you consider this network as untrusted.
WIFI_1 (192.168.20.0/24) The Wifi Subnet where your trusted Wifi Clients are based.
Sonos_speaker_01: 192.168.10.20/32
Sonos_speaker_02: 192.168.10.21/32
iOS_Phone: 192.168.20.100/32
The solution:
1. Install the mDNS Plugin "os-mdns-repeater". You must hit the "Show community plugins" checkbox. Install it and reload the webpage after doing it
System -> Firmware -> Plugins
2. Enable the mDNS Plugin and add only the needed interfaces. You want to keep this clean. E.g IOT_WIFI & WIFI_1. Furthermore you could also add the IPs of the FW itself to the blocklist. 192.168.10.1/32, 192.168.20.1/32
Services -> mDNS Reapter
3. Create some aliases for better visibility and to manage. Not mandatory, but I do like it this way.
Firewall -> Aliases
Sonos_Speakers: 192.168.10.20/32 and 192.168.10.21/32
Ports_Sonos_TCP: 80,443,4070
4. Create the needed FW ruleset
Firewall -> Rules -> IOT_WIFI
Rule_1: SRC: Sonos_Speakers, DST: != Local_Networks, Protocol: TCP, Ports: Ports_Sonos_TCP
Rule_2: SRC: Sonos_Speakers, DST: 224.0.0.251/32, Protocol: UDP, Port: 5353
That's basically it. You can control now the Sonos Speakers with the Sonos App, or even Spotify and others. No broadcast rules, no IGMP rules, and no additional multicast ranges are required.
Cheers,
fb
Edit: This HOWTO does not cover any streaming from e.g LAN/WIFI_1 clients. It's only made to have the sonos speakers streaming as a client from the internet. For other use cases you must adapt it. Feel free to share your settings to the others. Personally I use the Sonos Speakers for other things like alerting via home assistant
#86
25.7, 25.10 Series / Re: [SOLVED] hostwatch at 100%...
Last post by aperezva - Today at 08:27:56 AM@franco, What´s your recomendation, I´m in 25.7.10, wait till all the issues wil be solved? Wait 26.1?
Thanks for your efforts and support.
BR
Thanks for your efforts and support.
BR
#87
25.7, 25.10 Series / Re: [SOLVED] hostwatch at 100%...
Last post by amarek - Today at 08:14:11 AMTHX for this thread, this service was eating all my memory. after disabling it the usage was immediately at 28%, what a great solution to roll this out for all as fix implemented and started service............
#88
25.7, 25.10 Series / Re: IPv6 connectivity error af...
Last post by franco - Today at 08:06:11 AMhttps://github.com/opnsense/core/commit/5da971f2c67 should help here. It currently does not apply to 25.7.x as a lot of changes are inbound for 26.1 already.
Cheers,
Franco
Cheers,
Franco
#89
25.7, 25.10 Series / Re: IPv6 connectivity error af...
Last post by franco - Today at 07:54:05 AMOk, right, radvd is for LAN connections. Running it on a WAN has the risk of DHCPv6 client picking up its own configuration and that's why the sanity check was put in place.
https://github.com/opnsense/core/commit/572ae8a66575
Although that was done for SLAAC tracking which no longer exists the same is true for DHCPv6.
We can try to make sure that radvd.conf is cleared and the log message is easier to find from the GUI.
Cheers,
Franco
https://github.com/opnsense/core/commit/572ae8a66575
Although that was done for SLAAC tracking which no longer exists the same is true for DHCPv6.
We can try to make sure that radvd.conf is cleared and the log message is easier to find from the GUI.
Cheers,
Franco
#90
25.7, 25.10 Series / Re: ISC deprecation issues
Last post by stanthewizzard - Today at 07:14:06 AMQuote from: meyergru on January 19, 2026, 08:24:55 PMAnd the difference to DHCPv6-derived IPs is that SLAAC-provided IPs are pushed, i.e. they are applied immediately when the GUA prefix changes.
The only thing you do not have is "known" static IPv6s that you can reference in DNS names (because the prefix can change). Usually, you do not need them anyways, because you can always use the IPv4 for internal purposes in DNS. All of that is covered in the HOWTO I linked above.
https://forum.opnsense.org/index.php?topic=45822.0
This one ?
Thanks again
