Messages

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.

This behavior is normal with OpenVPN when clients use a dynamic address pool. persist-ip alone does not guarantee a fixed address per user; it only helps reuse addresses within the same server runtime and does not survive restarts or guarantee per-user consistency.

If you want the same user to always receive the same IP, you must use client-specific configuration (CCD) and assign the address explicitly with ifconfig-push, making sure that each user has a unique Common Name and that username-as-common-name is enabled if you authenticate via user/password. Alternatively, enable pool-persist with a persistent file so the server remembers past assignments across restarts, but this still does not strictly bind an IP to a specific user identity.

In short: what you see is expected, and the reliable solution is per-user static IP assignment via CCD, not persist-ip.

My other two cents. Wireguard is way more reliable, not so picky in configuration and as well way faster.

check if your allow rules apply and make as well a dump and check it via wireshark

System log angeschaut? Zum eingrenzen der exakten Zeit nen ping laufen lassen? Ergo Ping wech = Firewall platt?

Ob deine Suricata-Konfiguration tatsächlich aktiv blockiert, lässt sich nicht anhand der Regelwerke oder der gesetzten Aktion allein beurteilen. Entscheidend ist, dass Suricata in OPNsense im IPS-Modus (Inline/Netmap) läuft und auf den relevanten Interfaces aktiv ist. Andernfalls werden auch Regeln mit Aktion ,,Verwerfen" nur alarmieren, aber keinen Traffic blockieren.

Am sinnvollsten testest du das mit einer gezielten Testsignatur oder einem reproduzierbaren Testtraffic, bei dem du erwartest, dass die Verbindung aktiv abbricht. Wenn der Traffic weiterhin durchgeht und nur Alerts erzeugt werden, greift die Blockierung nicht. Erst wenn du in den Suricata-Logs eindeutig ,,drop" siehst und die Verbindung tatsächlich scheitert, ist sichergestellt, dass IPS aktiv arbeitet.

Notfalls mal nen Dump erstellen und sich mit Wireshark anschauen. Damit sollte klar ersichtlich sein, wo es klemmt.

Hallo,

ein paar grundsätzliche Hinweise, die aus meiner Sicht unabhängig von einzelnen Optionen oder Plugins wichtig sind.

Der zentrale Punkt ist das Grundverständnis des Firewall-Konzepts von OPNsense. Regeln sind strikt interfacebezogen und ingress-basiert. Das bedeutet: Regeln unter Firewall → Rules → LAN wirken ausschließlich auf Traffic, der vom LAN in die Firewall hinein kommt. Pakete aus anderen Netzen können dort technisch nicht matchen. Entsprechende Regeln haben daher keine Wirkung.

Zusätzlich fallen auf mehreren Interfaces sehr früh platzierte any -> any-Regeln auf. Da pf nach dem Prinzip first match wins arbeitet, machen diese Regeln sämtliches nachgelagertes Filtering wirkungslos. Feinere Regeln für VLAN-Übergänge oder Multicast greifen in diesem Fall praktisch nicht mehr. Die VLAN-Trennung existiert damit nur noch logisch, nicht aber durch eine wirksame Policy.

Ein weiterer Punkt ist die Behandlung von Multicast. Sehr offene Firewall-Regeln werden mit mDNS-Repeater und UDP-Broadcast-Relay kombiniert. Das erschwert die Nachvollziehbarkeit und führt häufig zu unnötigem Multicast-Traffic. Gerade WLAN-Clients reagieren darauf sehr empfindlich.

Wichtig ist außerdem die Einordnung der Symptome:
Die beschriebenen Probleme betreffen vor allem WLAN-basierte Dienste (WLAN-Telefonie, IPTV über WLAN, Cast-Funktionen). Die eigentliche Funkstrecke, Airtime-Auslastung, Multicast-Handling der Accesspoints und der Switches liegen jedoch außerhalb der Kontrolle von OPNsense. Wenn diese Ebenen nicht getrennt betrachtet werden, sucht man schnell an der falschen Stelle.

Mein Eindruck ist daher, dass es weniger um einzelne Stellschrauben geht, sondern darum, das Grundkonzept (Segmentierung, Regelrichtung, State-Logik, Multicast-Design) klar zu verstehen und konsequent danach zu konfigurieren. In der Praxis hilft es oft, das Regelwerk zunächst deutlich zu vereinfachen:

- pro VLAN nur Regeln auf dem jeweiligen Quell-Interface,

- keine pauschalen any:any-Regeln,

- Multicast gezielt und sparsam behandeln,

- WLAN-Probleme bewusst auch auf WLAN- und Switch-Ebene analysieren.

Das ist nicht als Kritik gemeint, sondern als konstruktiver Hinweis. Ein sauberes Grundkonzept erspart am Ende viel Zeit bei der Fehlersuche.


Niemand wird wirklich bei so einen Setup helfen wollen, besonders wenn elementare Dinge fehlen.

Your comments make it very clear that you are mixing up fundamental concepts, so let me clarify this with precision:

1. AppArmor is not an endpoint IPS.
It is a Mandatory Access Control mechanism. It limits process capabilities but does not inspect traffic, block intrusions, or act as a behavioral prevention system. Presenting it as an IPS shows a misunderstanding of its purpose.

2. Linux Mint does not offer "built-in endpoint protection"
Having AppArmor enabled by default is a basic security measure, not an EDR/XDR or IPS solution. Treating it as such misrepresents what it actually does.

3. Bringing Wazuh into this only demonstrates further confusion.
Wazuh is an entirely separate SIEM/XDR platform that requires a complete backend infrastructure. It is not related to Mint's default configuration and has no connection to AppArmor's functionality.

4. None of this applies to OPNsense.
OPNsense is based on FreeBSD. Linux MAC frameworks like AppArmor or SELinux do not apply here. Mentioning them as protection for OPNsense shows that you are discussing technologies from entirely different systems as if they were interchangeable.

If your OPNsense system becomes unstable after two weeks, you should focus on logs, configuration, hardware, or plugins. Linux security frameworks will not solve a FreeBSD issue.

And to avoid further confusion: OPNsense is a firewall platform, not a router.

This should settle the topic.

Thanks, but I don't rely on local log retention.
My setup includes a centralized logging system cluster with redundancy – if one SIEM node fails, another one takes over. Logs are streamed live via UDP, so there's no need to store old logs locally.

That's exactly why I use a RAM disk for /var/log: to minimize wear on the NVMe and avoid unnecessary local writes.

The issue is not about log availability – it's about Suricata ignoring the log rotation and retention settings, which causes the RAM disk to fill up.