"Recent posts
#91
25.7, 25.10 Series / Re: [SOLVED] hostwatch at 100%...
Last post by troplin - Today at 09:39:00 AM@franco Even if the log message has been fixed (and is now disabled), it still makes no sense:
Firstly,
So why would hostwatch think that the LLA of the OPNsense box itself has been previously used by my dishwasher?
Secondly, the message is always just ,,host X moved from A to B", shouldn't the database be updated to reflect that after the fist time? There are no messages the opposite way, i.e. ,,host X moved from B to A".
I still believe that the logging issue is just a symptom of the actual problem, e.g. you're somehow comparing the wrong addresses.
Firstly,
Code Select
00:1d:63:63:eb:35 is the MAC address of my dishwasher and Code Select
64:62:66:22:44:8c is the LAN interface of the OPNsense box itself. The IPv6 address is the link-local address of the OPNsense box.So why would hostwatch think that the LLA of the OPNsense box itself has been previously used by my dishwasher?
Secondly, the message is always just ,,host X moved from A to B", shouldn't the database be updated to reflect that after the fist time? There are no messages the opposite way, i.e. ,,host X moved from B to A".
I still believe that the logging issue is just a symptom of the actual problem, e.g. you're somehow comparing the wrong addresses.
#92
25.7, 25.10 Series / Re: How to increase a proxmox ...
Last post by meyergru - Today at 09:23:29 AMJust made it into the HOWTO, thanks @Maurice!
#93
25.7, 25.10 Series / Re: ISC deprecation issues
Last post by stanthewizzard - Today at 09:21:46 AMQuote from: meyergru on Today at 08:38:55 AMYes, I linked it in my first answer.
Thanks I'll read it (didn't see it the first time)
#94
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
#95
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.
#96
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.
#97
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.
#98
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
#99
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
#100
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............
