Messages

Also mal meine zwei Cent zu dem Thema.


Protectli: Tolle Hardware und wirklich guter Support. Und ja, je nach Model schlagen die Hardwareseitig auch locker eine Deciso. Nein, dass soll kein Deciso gebashe werden. Einfach simple Fakten ;)

Fritzbox: Eine Fritzbox ist ein Consumer produkt. Bzw eine Eier legende Wollmilchsau. Ich hatte jahrelang eine 7590 und letzlich damit nur Probleme.

Für die Stabilität würde ich deutlich zu einem reinen Modem greifen und pppoe über die OPNsense aufbauen lassen. Warte selbst immer noch auf  Fibre... Allerdings tut mein Vigor 166 nun seit Jahren den Dienst. Das deutlich performanter und stabiler als die Fritzbox jemals war. Auch bezogen auf Gaming und den heiß begehrten niedrigen Latenzen.

Und wenn Du auch noch WLAN auslagern willst, kauf Dir einen gebrauchten Ubiquiti 6 LR und pack OpenWRT drauf. Kostenpunkt ~100€

Think about the order of your rules and what they cover.

I assume that this QFEED contains external IP addresses.

You allow everything what is not local in rule 2. When will any flow reach that rule exactly if it contains non RFC1918 addresses?

I did mention that the HOWTO does not cover any streaming from local. For that: I don't know your setup.

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...