"Recent posts
#21
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
#22
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
#23
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............
#24
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
#25
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
#26
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
#27
25.7, 25.10 Series / Re: IPv6 connectivity error af...
Last post by dmurphy - Today at 06:15:02 AMOK, so I went ahead and tried removing /var/etc/radvd.conf altogether.
Guess what? Works perfectly now. dhcp6c starts right up on boot, prefixes are allocated to the various VLANs correctly, all looks perfect.
I think, perhaps, I see how we ended up with a rogue radvd.conf.
Here's what I did and how I think we got there:
Step 1 - Wipe DEC2752
Step 2 - Fresh install 25.7
Step 3 - Restore A10-gen3-config.xml to get proper tunables etc.
*** This has igc0 assigned as the LAN interface. ***
Step 4 - Restore my DEC2752 backup on top of the A10-gen3-config.xml
--> I have radvd disabled, but I believe the radvd.conf was ALREADY generated by the A10-gen3-config.xml, and wasn't "cleaned up" when igc0 was deassigned.
Step 5 - Orphaned radvd.conf was in /var/etc, but since radvd is disabled, it was never overwritten with a 'clean' copy.
So I think that's how we got a /var/etc/radvd.conf that referenced igc0, which it shouldn't as that's now the WAN interface.
Odd scenario for sure. Just wondering as more of us move from ISC/KEA+radvd to straight dnsmasq, if there's a way to 'scrub' the radvd config?
Guess what? Works perfectly now. dhcp6c starts right up on boot, prefixes are allocated to the various VLANs correctly, all looks perfect.
I think, perhaps, I see how we ended up with a rogue radvd.conf.
Here's what I did and how I think we got there:
Step 1 - Wipe DEC2752
Step 2 - Fresh install 25.7
Step 3 - Restore A10-gen3-config.xml to get proper tunables etc.
*** This has igc0 assigned as the LAN interface. ***
Step 4 - Restore my DEC2752 backup on top of the A10-gen3-config.xml
--> I have radvd disabled, but I believe the radvd.conf was ALREADY generated by the A10-gen3-config.xml, and wasn't "cleaned up" when igc0 was deassigned.
Step 5 - Orphaned radvd.conf was in /var/etc, but since radvd is disabled, it was never overwritten with a 'clean' copy.
So I think that's how we got a /var/etc/radvd.conf that referenced igc0, which it shouldn't as that's now the WAN interface.
Odd scenario for sure. Just wondering as more of us move from ISC/KEA+radvd to straight dnsmasq, if there's a way to 'scrub' the radvd config?
#28
25.7, 25.10 Series / Re: IPv6 connectivity error af...
Last post by dmurphy - Today at 05:59:49 AMQuote from: franco on January 18, 2026, 08:30:33 PMWhat I don't understand is that there are actually two ways dhcp6c is started: once immediately and once per rtsold. 25.7.11 decouples the starts of both so they don't race to the finish line together, but OTOH that was never really the case and only the side effect that the second one would release the IP of the first one and try again (and sometimes fail because the ISP says no to the second request).
You can just start via "/var/etc/rtsold_wan_script.sh igb1" normally which is how the system does it. "wan" and "igb1" may be different for you.
The other thing is to check /var/etc/dhcp6c.conf if the configuration for "igb1" is actually there or not. In the worst case it's not there when it decides to start which means it may exit as soon as it was started and then it looks like it wasn't started. If not some code path decided that it's simply not ready (or misconfigured).
Cheers,
Franco
So - I don't seem to have that script (at least, not with an interface assignment name in it -- see the two scripts below):
Code Select
[root@dmurphy-gw /var/etc]# ls -l *sh
-rwxr-xr-x 1 root wheel 1355 Jan 19 23:35 dhcp6c_wan_script.sh
-rwxr-xr-x 1 root wheel 1041 Jan 19 23:35 rtsold_script.sh
[root@dmurphy-gw /var/etc]#
Contents of /var/etc/dhcp6c.conf here - all of which look at least nominally correct to me.
Code Select
root@dmurphy-gw:~ # cat /var/etc/dhcp6c.conf
interface igc0 {
send ia-pd 0; # request prefix delegation
request domain-name-servers;
request domain-name;
script "/var/etc/dhcp6c_wan_script.sh"; # we'd like some nameservers please
};
id-assoc pd 0 {
prefix ::/56 infinity;
prefix-interface lagg0_vlan77 {
sla-id 2;
sla-len 8;
};
prefix-interface lagg0 {
sla-id 1;
sla-len 8;
};
prefix-interface lagg0_vlan91 {
sla-id 3;
sla-len 8;
};
};
Now, this may be where things are getting interesting.
I've migrated 100% over to dnsmasq - not running ISC or KEA, and (perhaps crucially) - not radvd.
That said, for whatever reason, "Router Advertisements" was unchecked in my dnsmasq configuration, too.
That was very much not intentional - I could've sworn that was enabled. Not sure if it matters one way or another, but I turned on the RA setting in dnsmasq, and then did want to verify that /var/etc/radvd.conf exists - it does, and it also appears (nominally) correct:
Code Select
root@dmurphy-gw:~ # cat /var/etc/radvd.conf
# Automatically generated, do not edit
# Generated RADVD config for dhcp6 assignment from wan on lan
interface igc0 {
AdvSendAdvert on;
AdvLinkMTU 1500;
AdvManagedFlag on;
AdvOtherConfigFlag on;
DNSSL localdomain { };
};
So after a fresh reboot, I see that rtsold is running, looks like it's hooked the correct scripts, but dhcp6c never starts.
Code Select
root@dmurphy-gw:~ # ps auxwww|grep -i rtsol
root 78062 0.0 0.0 13924 2552 - SCs 23:51 0:00.13 /usr/sbin/rtsold -aiu -p /var/run/rtsold.pid -A /var/etc/rtsold_script.sh -R /usr/local/opnsense/scripts/interfaces/rtsold_resolvconf.sh -D
root 79643 0.0 0.0 13924 2504 - Is 23:51 0:00.03 rtsold: rtsold.llflags (rtsold)
root 80526 0.0 0.0 13924 2504 - Is 23:51 0:00.00 rtsold: rtsold.script (rtsold)
root 81395 0.0 0.0 13924 2496 - Is 23:51 0:00.00 rtsold: rtsold.sendmsg (rtsold)
root 81902 0.0 0.0 13924 2616 - Ss 23:51 0:00.01 rtsold: system.syslog (rtsold)
root 7004 0.0 0.0 13744 2416 u2 S+ 23:53 0:00.00 grep -i rtsol
root@dmurphy-gw:~ #
root@dmurphy-gw:~ #
root@dmurphy-gw:~ #
root@dmurphy-gw:~ #
root@dmurphy-gw:~ # ps auxwww|grep -i dhcp
root 7612 0.0 0.2 29944 18272 - Ss 23:51 0:00.57 /usr/local/bin/python3 /usr/local/opnsense/scripts/dhcp/unbound_watcher.py --domain home (python3.11)
root 47467 0.0 0.0 14504 2656 - Is 23:52 0:00.01 /usr/local/bin/dpinger -f -S -r 0 -i WAN_DHCP -B 98.111.111.111 -p /var/run/dpinger_WAN_DHCP.pid -u /var/run/dpinger_WAN_DHCP.sock -s 1s -l 4s -t 60s -d 1 1.1.1.1
_dhcp 76103 0.0 0.0 14080 2816 - SCs 23:51 0:00.00 dhclient: igc0 (dhclient)
root 12022 0.0 0.0 13744 2416 u2 S+ 23:53 0:00.00 grep -i dhcp
I still have to run it by hand. Trying to run "/var/etc/rtsold_script.sh igc0" just results in "Rejecting own configuration" as it finds igc0 in /var/etc/radvd.conf (see logic in the rtsold_script.sh)
So without deeper knowledge, I guess the question is --- should /var/etc/radvd.conf contain an igc0 stanza for WAN? And is it correct? Or should I remove it altogether (what generates it if radvd is disabled?)
#29
25.7, 25.10 Series / Re: CSRF Check
Last post by d0shie - Today at 04:25:07 AMHi Steve, I have a faint suspicion that you're having problems with the new Automatic Discovery feature in Interfaces -> Neighbors. This is unfortunately enabled by default on the latest update and known to cause excessive logging as well as high CPU usage. Log into the console and run
Remove the logs and disabling the service will solve your issue.
Code Select
du -h / | sort -rh | headto see if your disk has run out of space. I'll bet that it has, and all taken up by /var/log/hostwatch.Remove the logs and disabling the service will solve your issue.
#30
25.7, 25.10 Series / Periodic interface reset - ren...
Last post by clarknova - Today at 04:16:06 AMOPNsense 25.7.11_2
My ISP has informed me that my assigned IP address will change at midnight. Looking at /var/db/dhclient.leases.igc0 (WAN), I see that my lease is valid for a few more days.
So I set up a cron job for shortly after midnight for periodic interface reset on wan. Will this have the desired effect of renewing the lease on the WAN and pulling the new address?
My ISP has informed me that my assigned IP address will change at midnight. Looking at /var/db/dhclient.leases.igc0 (WAN), I see that my lease is valid for a few more days.
So I set up a cron job for shortly after midnight for periodic interface reset on wan. Will this have the desired effect of renewing the lease on the WAN and pulling the new address?
