Messages

I have try to use this setup my sonos and unable to get it working

Ok.

@Mr.SmartEpants: You should really think about your QFEED rule. But hope you already realized it.

"I'm guessing I need to add a "Sonos pass" rule before the "block access to 'private' networks" rule? "

=> Indeed

A flow is the permitted connection path through the firewall, defined by source, destination, protocol and port. So for Sonos that includes the controller -> speaker TCP connections and the mDNS UDP 5353 traffic that must be able to pass (or be repeated) between the VLANs.

Show me your "LAN" rules.

1. Did you setup the mDNS Repeater correctly?
2. Are you sure the Aliases fit?
3. Sure that the "trusted" network has the correct flows opened? Maybe I was too unclear when talking about trusted network?


Edit: You could even remove the "Rule_1: SRC: Sonos_Speakers, DST: != Local_Networks, Protocol: TCP, Ports: Ports_Sonos_TCP" rule... Basically you already allow any device in the IOT Network to reach the Internet. But I guess you know what you're doing there?

Edit_2: != Local Networks refer to RFC1918
Ref: https://datatracker.ietf.org/doc/html/rfc1918

Based on the log you attached, there is no indication of a full system crash or kernel panic.

What the log clearly shows is:
- Repeated PPPoE link failures (LCP: no reply to echo requests, reconnect loops)
- Frequent WAN down / up cycles
- Continuous dhcp6c "Network is down" errors while the PPPoE interface is offline

Eventually a reboot (---<<BOOT>>---), which strongly suggests a manual reset or watchdog, not a spontaneous crash

This behavior is consistent with an unstable WAN / PPPoE connection or NIC driver issue, not with a WAN problem taking down the whole system. Normally even PPPoE reconnect loops do not stop LAN DHCP or the GUI.

If the box becomes unreachable (no GUI, no SSH, no LAN DHCP) while still replying to ping, likely causes are:
- NIC driver lockup
- Hardware issues (RAM, storage, PSU)
- High load or kernel deadlock triggered by repeated interface resets

In short:
The WAN failure itself is almost certainly not the root cause. The log points to WAN instability acting as a trigger, exposing an underlying system or hardware problem.

Suggestion: As you did not mention the hardware of the appliance. I would do a stress test with the machine. For instance I take this quite seriously,  therefore I test my machines full 24-72h via stress-ng and others like memtest+ etc...
I tested my Protectli 6600 the same way. Result was that it's extremely stable.  In other words "Rock Solid".  I know there are other views in this forum about Protectli, but I can tell only good things. Especially about the support.

Sorry, I have no clue about Harmony Hub. I never used it. From what I found is, it uses SSDP and some cloud functions.

As I cannot reproduce this setup, its kinda hard to explain. At least without you giving the correct input.
Therefore I propose:  If you need help, I guess its best to open another thread for this. And perhaps write later a tutorial for the others? ;)

It shouldn't be a big deal to move HA to your IOT Network. If the Harmony Hub is also placed there, there is no need to do any ingress filtering on the IOT side as they remain in the same broadcast domain. You can easily control HA itself from any other network.

[The issue:]

To 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

EDIT_25012026: Maybe I was to unclear when writing this tutorial. Trusted Network means, there is no restriction for the Clients. Like with the LAN interface by default. If you restrict your Trusted Zones too, surely you have to allow the multicast flows as well.


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

[In detail:]

A few things
My first opnsense instance was protected by apparmor because it was a vm, shared systems

Ok I found out more on what my attacks are
one, the blocked commands I was picking up in logs is in line with crypto malware

two, how it gets there through the browser
I didnt have a name for it but IBM and global security does. Its called zero-click attacks
Its been in cve's since the year 2000, no one can fix it yet.

IBM has a video on zero-click attacks and the first two seconds of it say, boom your hacked, just that fast
Its software of different types downloaded through the browser, two names pegasus, stagefright, thats just two,
not counting all the others and the variations of it, the amount of code varies.
They affect phones and computers, All they have to do to hack your phone is call you
You dont have to answer or even touch your phone and your hacked
There is more information on these types attacks, just some of millions of attacks
This software is sold to people, the one shown was subscription based, strange, around 700 a year
Reason its hard to see, its not just encrypted, it can be double encrypted, it can be obfuscated before encryption,
So decrypting packets doesnt pick it up, they usually skip it
Remember I was talking about the hands on tools to see and break down these embedded malware code
Anyway, these attacks, different types, come through the browser, and effect your phone
Yes I hunt them in spare time sometimes, and bug bounty
Have found a few, I didnt save then, they are dangerous around your system, Ill have to save them from now on
And the corporations didnt offer to pay me, they did ask me to help.

Your latest post contains a large number of claims, but unfortunately no verifiable technical evidence.


In detail:
To be clear and constructive, please provide concrete proof for the following statements:

1. AppArmor on OPNsense / FreeBSD
OPNsense is based on FreeBSD. AppArmor is a Linux-specific LSM and does not exist on FreeBSD.
If you claim it was "protecting" an OPNsense instance, please explain how, including:
- exact OS version
- where AppArmor was loaded
- how it was enforced on FreeBSD

2. "Crypto malware commands found in logs"
Please provide:
- example log entries
- the exact protocol and payload
- how you verified these were malware commands and not normal application traffic

3. Zero-click attacks via browser affecting OPNsense
Zero-click exploits (e.g. Pegasus, Stagefright) target end-user operating systems, not a FreeBSD-based firewall appliance.
Please explain:
- how a browser exploit compromises an OPNsense system
- which CVE applies
- how this bypasses FreeBSD's userland separation

4. "Embedded malware in forum images/icons"
This is a very strong claim. If true, it requires evidence:
- hash of a malicious file
- decoded payload
- reproduction steps
Without this, it remains an unsubstantiated allegation.

5. Traffic inspection claims
Monitoring connections alone does not prove malware. Modern web traffic includes CDNs, telemetry, ads, fonts, APIs, etc.
Please show how you distinguish malicious behavior from normal web traffic.

At the moment, your posts consist mostly of buzzwords (zero-click, Pegasus, AI, CVEs, encrypted payloads) without technical depth or reproducible data.

If you have verifiable evidence, please share it.
If not, I strongly suggest continuing these experiments complete privately with your preferred AI tools instead of posting speculative claims here, as this may confuse less experienced users.


This forum works best with facts, logs, CVEs, and reproducible results. NOT assumptions.




In short: STOP that bullshit bingo and go troll somewhere else. Preferably a useless AI.

Hello Franco,

I do understand your point.
Nonetheless... that person is a troll. Floodding the forum with bullshit bingo, which potentially harm others.

It would be appreciated if you can do something against such nonsense posts. Especially as that person is proven wrong many times.

@Zapad: Die Qualität sieht man in Deinen bisherigen Fragen und Antworten... Hier würde ich das tshooten bei L8 ansetzen.

Wäre ich der TE, würde ich meine komplette Rule Policy komplett überdenken und überarbeiten. Da sie löchrig ist und potenziell zu ungewolltem Verhalten führen wird...

[intentional comedy]

At this point it is worth asking who exactly you believe you are helping with this advice. 🤦

Anyone with a basic understanding of IDS/IPS, operating system architecture, or OPNsense will immediately recognize the technical errors. New users, on the other hand, would be actively misled by conflating Linux endpoint hardening with network-based intrusion prevention on a FreeBSD firewall.

Security advice that ignores platform boundaries and basic definitions is not just unhelpful, it is harmful. If I were looking for guidance, this is precisely the kind of commentary I would avoid, either by walking away or by treating it as intentional comedy. What it is...😁

This forum section exists to exchange accurate, actionable information. What you are providing is neither.

Last but not least: https://docs.opnsense.org/manual/wazuh-agent.html
Read the "Warning" carefully...

Aus meiner Sicht ist der Beitrag von Zapad fachlich unhaltbar und konzeptionell gefährlich, weil er grundlegende Prinzipien von OPNsense und zustandsbehafteten Firewalls ignoriert und durch pauschale Empfehlungen ersetzt, die weder sauber hergeleitet noch technisch begründet sind.

Die Empfehlung, auf allen VLANs zunächst pauschal pass any any zu setzen, ist kein sinnvoller Startpunkt, sondern ein vollständiges Abschalten der Policy-Ebene und damit genau das Gegenteil von strukturierter Fehlersuche.
Wer so vorgeht, zerstört jede Aussagekraft der Logs, verwischt Asymmetrien im Routing, maskiert Multicast-Fehlkonzepte und kann am Ende nicht mehr beurteilen, warum etwas funktioniert oder eben nicht.

Das Argument "damit sollte Streaming und Telefonie laufen" ist sachlich falsch, weil WLAN-Qualität, Airtime, Multicast-Flooding, IGMP-Handling der Switches und Accesspoints sowie Client-Roaming dadurch in keiner Weise adressiert werden.

Besonders problematisch ist, dass gleichzeitig Multicast- und Broadcast-Relays relativiert werden, obwohl gerade diese in Kombination mit offenen Regeln massiv zu unnötigem Traffic und instabilem WLAN führen können!

Auch der Umgang mit "Default Deny Meldungen" und DF-Flags wirkt deplatziert und zeugt nicht von systematischem Verständnis, sondern von nachträglicher Rechtfertigung unsauberer Konfigurationen.

Das hier sollte kein Trial-and-Error-Spiel sein, bei dem man erst alles öffnet und dann "langsam zuschraubt"

@Zapad
Kurz gesagt: Dein Beitrag liefert keine belastbare technische Hilfe, sondern propagiert ein Vorgehen, das Sicherheitskonzept, Fehlersuche und sauberes Design gleichermaßen untergräbt.