Messages

Mit euren Hinweisen konnte ich die Regeln/Aliases korrekt umsetzen und das gewünschte Verhalten im LAN sauber realisieren.

Läuft jetzt wie erwartet.

Danke für die Hilfe – sehr gute Community!

Hallo,

danke für den Hinweis, verstanden 👍

Mir ist bewusst, dass die Richtung immer aus Sicht der Firewall zu sehen ist.
Aktuell blockiere ich die IPs aus der FireHOL-Blockliste bereits am WAN für eingehenden Traffic (in).

Zusätzlich möchte ich ausgehenden Traffic (out) blockieren, damit interne Clients keine Verbindungen zu IPs aus der Blockliste aufbauen können, falls diese z. B. durch DNS, bestehende Sessions oder andere Wege erreicht werden.

Ziel ist also:

WAN / in → eingehenden Traffic von Blocklisten-IPs blockieren

LAN (bzw. relevantem Interface) / out → ausgehenden Traffic zu Blocklisten-IPs blockieren

Daher plane ich eine separate Regel mit Ziel = Blocklisten-Alias und Richtung ,,out" auf dem entsprechenden Interface.

Hallo zusammen,

ich möchte kurz prüfen lassen, ob mein Ansatz grundsätzlich korrekt ist.

Ziel:
FireHOL-IP-Blocklisten (bzw. daraus erstellte Aliase) sollen zentral für ausgehenden Traffic blockiert werden, damit interne Clients keine Verbindungen zu bekannten bösartigen IPs aufbauen können.

Aktueller Aufbau

Alias
Typ: Host(s)
Beispielname: BLOCK_IPS
Inhalt:
FireHOL-IP-Blocklisten + Manuelle IP Blockierung



Globale Firewall-Regel
Aktion: Block
Schnell: aktiv
Schnittstellen: LAN, OPT1, OPT2
Richtung: out
IP-Version: IPv4
Protokoll: any

Quelle:

LAN Netzwerk

OPT1 Netzwerk

OPT2 Netzwerk

Ziel: Alias (FireHOL / BLOCK_IPS)

Zielport: beliebig

Logging: aktiviert

Meine Frage

👉 Ist das der korrekte Weg, um FireHOL-IP-Blocklisten für Outbound-Traffic umzusetzen?

Switch:    Ja, das war im Grunde ein Gedankenspiel, um mein Verständnis zu prüfen.

Ich glaube, ich habe einen grundlegenden Denkfehler beim Gateway gemacht und wollte das kurz verifizieren.

Ausgangslage:

PC hängt am LAN (192.168.13.0/24)

Mini-PC mit Proxmox hängt an OPT2 (192.168.15.0/24)

OPNsense hat:

LAN: 192.168.13.1

OPT2: 192.168.15.1

Ich bin bisher davon ausgegangen, dass ich bei der Proxmox-Installation als Gateway die LAN-IP (192.168.13.1) eintragen muss, da der Zugriff vom LAN erfolgt.

Inzwischen vermute ich, dass das falsch ist und bei einem Gerät, das direkt an OPT2 hängt, als Gateway immer die OPT2-IP der Firewall (192.168.15.1) eingetragen werden muss – unabhängig davon, aus welchem Netz später zugegriffen wird.

Ist diese Annahme korrekt und war genau das der Fehler, warum die Proxmox-Weboberfläche vom LAN aus nicht erreichbar war?

Der PC hängt am LAN, der andere Mini-PC mit Proxmox hängt direkt an OPT2.
Ich habe bewusst das gleiche Subnetz auf LAN und OPT2 konfiguriert, da kein externes Switch vorhanden ist und beide Geräte im gleichen Netz sein sollen.

Trotz identischem Subnetz und Default-Firewall-Regel

allow LAN net (bzw. OPT2 net) to any
ist keine Verbindung zur Proxmox-Weboberfläche möglich.

Mir ist inzwischen klar geworden, dass LAN und OPT2 auch bei gleichem Subnetz technisch getrennte Interfaces bleiben und OPNsense nicht automatisch wie ein Switch arbeitet.

Hallo Maurice,

danke für den Hinweis.

Bei mir hängt an OPT2 kein Switch. Ich habe die Geräte jeweils einzeln direkt
an OPT2 getestet (PC direkt an OPT2: Internet funktioniert; TP-Link Repeater
im AP-Modus bzw. N150 Mini-PC direkt an OPT2: ich komme nicht auf deren
Weboberflächen).

Daher sollte der Traffic nicht "im Subnetz geswitcht" werden, sondern über
OPNsense laufen.

Hast du eine Idee, welche OPNsense-Einstellung das lokale Management (HTTP/HTTPS)
in so einem Direktanschluss-Szenario blockieren könnte? (OPT2 = 192.168.15.0/24,
DHCP aktiv, Block private/bogon auf OPT2 ist aus, Firewall-Regeln auf OPT2
Allow OPT2 net -> any).
Vielen Dank!

Hallo zusammen,

ich habe ein Problem mit einer OPNsense-Installation und einem OPT2-Interface und komme aktuell nicht weiter.

Setup

OPNsense (aktuelle Version)

Interface: OPT2

Subnetz: 192.168.15.0/24

DHCP auf OPT2 aktiviert

Kein VLAN im Einsatz

NAT-Reflektion deaktiviert (Standard)

Firewall-Regeln auf OPT2 getestet:

OPT2 net → any (any)

zusätzlich OPT2 net → OPT2 net (any)

Beobachtung

Wenn ich einen PC direkt an OPT2 anschließe, erhält dieser per DHCP eine IP und hat Internetzugang.

Wenn ich jedoch andere Geräte an OPT2 anschließe, z. B.:

einen TP-Link Repeater (Access-Point-Modus) oder

einen N150 Mini-PC-Firewall-Router, auf dem ZimaOS installiert werden soll,

bekommen diese Geräte ebenfalls eine IP aus dem OPT2-Netz,
die jeweilige Weboberfläche (HTTP/HTTPS) ist jedoch nicht erreichbar.

Das Verhalten ist bei beiden Geräten identisch, daher gehe ich nicht von einem gerätespezifischen Problem aus.

Zusammenfassung

OPT2 → WAN (Internet): funktioniert

OPT2 → Geräte im gleichen Subnetz (Weboberflächen): funktioniert nicht

Fragen

Wird lokaler Verkehr innerhalb eines OPT-Interfaces von OPNsense standardmäßig eingeschränkt oder blockiert?

Reicht eine Regel OPT2 net → OPT2 net, oder fehlt eine weitere Einstellung (z. B. Interface-Optionen)?

Gibt es bekannte Besonderheiten bei lokalen Management-Zugriffen innerhalb eines OPT-Netzes?

Eine config.xml kann ich bei Bedarf zur Verfügung stellen.

Vielen Dank für eure Hilfe.

nicht nachgedacht dann passiert sowas :-)

von mir selber :-)

Ich habe mir kürzlich bei AliExpress den Topton MiniPC mit dem N305 ohne 10G Port gekauft, aber ich muss sagen, der läuft richtig schnell! Das Teil rennt wie die Sau. Es müsste bei dir auch funktionieren, es gibt den MiniPC auch mit einem 10G Port. Der integrierte Lüfter ist allerdings etwas störend, wenn er anspringt, aber ansonsten funktioniert alles super. Es gibt keine Internetabbrüche, und der PC ist mit i226 Ports ausgestattet, die 2,5GB Geschwindigkeit unterstützen. Außerdem war auf der CPU der WLP (Wärmeleitpaste) ausreichend drauf, also keine Probleme in der Kühlung. Bin echt zufrieden mit der Leistung!

Ich habe kürzlich meine Suricata-IDS-Regeln in OPNsense angepasst und möchte wissen, ob diese Konfiguration die neuesten Bedrohungen effektiv blockiert und ob sichergestellt ist, dass die Blockierung tatsächlich aktiv erfolgt. In der aktuellen Konfiguration habe ich folgende Regelwerke verwendet: 3coresec.rules, abuse.ch.feodotracker.rules, und andere. Als Aktion habe ich 'Deaktiviert, Alarm' festgelegt, und die neue Aktion ist 'Verwerfen'.

Außerdem sind die spezifischen Regelkriterien für Produkte wie 2wcom, 3CX, ABB, ASMAX und Adobe festgelegt, und die Angriffsziele reichen von Client-Endpunkten über Server bis zu DNS-Servern. Die Bedrohungsstufen wie 'High', 'Medium' und 'Low' sowie CVE-Daten aus den Jahren 1999 bis 2025 wurden integriert. Die neue Richtlinie wurde mit der Beschreibung 'IDS Neu Eingestellt 11/2025' hinzugefügt.

Ich möchte wissen, ob diese Konfiguration in Suricata in OPNsense sicherstellt, dass die Bedrohungen tatsächlich aktiv blockiert und nicht nur alarmiert werden. Werden die aktuellsten Bedrohungen wie APTs und Malware-Familien (z.B. ACR_Stealer) ausreichend blockiert, oder sind noch Anpassungen erforderlich, um eine vollständige Sicherheitsabdeckung zu gewährleisten?

Update:
Ich habe OPNsense auf der neuen M.2 SSD noch einmal komplett neu installiert, diesmal mit ZFS als Dateisystem. Die Installation lief problemlos durch und auch die Updates wurden ohne Fehler installiert.

Es scheint also, dass das Problem nur bei der vorherigen Installation bzw. beim verwendeten Dateisystem aufgetreten ist. Mit ZFS funktioniert jetzt alles wie erwartet.

Es wurde auf UFS installiert.
Zur M.2-SSD: Sie ist nagelneu, und die SMART-Werte sind alle unauffällig.
Die Logs kann ich leider nicht mehr auswerten, da ich die SSD inzwischen formatiert habe.

Ich starte demnächst einen neuen Versuch mit der OPNsense-Installation – diesmal werde ich allerdings ZFS als Dateisystem verwenden, um auszuschließen, dass UFS hier eine Rolle spielt.

Hallo zusammen,

ich habe OPNsense 25.7 auf eine neue M.2 SSD installiert, und die Installation lief problemlos. Leider habe ich dann festgestellt, dass die neuesten Updates nicht korrekt installiert werden – sie bleiben hängen und werden nicht abgeschlossen.

Daraufhin habe ich die alte M.2 SSD wieder eingebaut, auf der bereits die neueste Version von OPNsense installiert ist, und das System funktioniert einwandfrei.

Kennt jemand dieses Problem und hat vielleicht eine Lösung, warum die Updates auf der neuen SSD nicht abgeschlossen werden? Ich würde mich über jede Hilfe freuen!

Danke im Voraus!

Titel: Suricata blockiert trotz Drop-Policy nicht – Alarmmeldung zeigt ,,allowed" (OPNsense 27.7)

Beitrag:

Hallo zusammen,

ich habe ein Problem mit Suricata unter OPNsense 27.7, das ich nicht nachvollziehen kann.

Folgendes ist eingerichtet:

IDS/IPS ist aktiviert

Die richtige Netzwerkschnittstelle ist ausgewählt

Die Suricata-Policy ist gesetzt.

Die Standardaktion ist ,,Alert"

Ich habe bei mehreren Regeln die Aktion manuell auf ,,Verwerfen (Drop)" gestellt

Die Regeln sind aktiv

Außerdem habe ich folgende Regelwerke aktiviert (siehe Screenshot):

botcc.portgrouped.rules

botcc.rules

ciarmy.rules

compromised.rules

drop.rules

emerging-* (mehrere)


Trotz dieser Einstellungen zeigt Suricata bei einem auslösenden Ereignis nur einen Alert an – aber keine Blockierung. In den Logs unter Protokolle → Suricata → Alerts steht nur allowed. Die Verbindung wird also nicht unterbrochen.

Meine Fragen:

Warum greift die Drop-Regel nicht, obwohl sie aktiv und richtig gesetzt ist?

Muss man zusätzlich noch etwas global aktivieren, damit ,,Drop" überhaupt angewendet wird?

Funktionieren Drops nur auf bestimmten Schnittstellen (z. B. nur WAN oder nur intern)?

Gibt es irgendwo Logs oder eine Debug-Ansicht, die zeigt, ob Suricata versucht zu blockieren?

Ich wäre sehr dankbar für Hinweise oder eine kurze Erklärung, falls ich etwas übersehen habe.

Viele Grüße