Messages

Hallo zusammen,
 
ich nutze OPNsense als Firewall und habe mehrere Blocklisten als Aliase vom Typ "URL-Tabelle (IPs)" eingerichtet (u.a. eine Datencenter-IP-Blockliste und eine GeoIP-/Länder-Blockliste). Dazu habe ich am WAN-Interface jeweils eine Block-Regel angelegt:
 
- Aktion: Block
- Interface: WAN
- Richtung: eingehend (in)
- Quick: aktiviert
- Quelle: der jeweilige Blocklisten-Alias
- Ziel: ursprünglich "Diese Firewall" (self), inzwischen auf "beliebig" (any) geändert
 
Zu meiner Situation:
- Ich verwende KEIN VPN.
- Ich muss NICHT von außen auf die OPNsense oder Dienste dahinter zugreifen.
- Ich habe (soweit ich sehe) keine Portforwards / eingehenden Dienste offen.
 
Meine Fragen:
 
1. Bringen diese WAN-Block-Regeln in meinem Fall überhaupt einen messbaren Mehrwert? Soweit ich verstanden habe, blockt OPNsense eingehenden WAN-Verkehr ohnehin per Default, wenn man nichts ausdrücklich freigibt. Ist die Blockliste dann eher Kosmetik, oder fängt sie trotzdem relevante Dinge ab?
 
2. War die Umstellung des Ziels von "Diese Firewall" auf "beliebig" richtig, oder reicht in meinem Szenario "Diese Firewall"?

Möchte einfach verstehen, ob mein Aufbau sinnvoll ist oder ob ich mir mit den vielen Listen nur unnötige Komplexität einhandle, ohne echten Gewinn.
 
Danke vorab!
 

Hallo zusammen,

ich beschäftige mich aktuell mit Suricata/IPS unter OPNsense 26.x und bin dabei über die Dokumentation zu Divert (IPS) in Kombination mit Rules [new] gestolpert.

Mir ist klar, dass es zwei Ansätze gibt: Netmap (IPS) als klassisches, globales IPS ohne zusätzliche Firewall-Regeln und Divert (IPS) mit selektiver Inspektion über ,,Divert-to"-Regeln.

Aktuell nutze ich weiterhin Netmap (IPS), da es für mein Setup stabil und unkompliziert funktioniert. Divert (IPS) wirkt auf mich dagegen deutlich komplexer. Ich bin in dem Thema kein Profi und würde daher gerne wissen, ob Divert primär für sehr granulare, regelbasierte Inspektion gedacht ist oder ob es darüber hinaus konzeptionelle Vorteile gegenüber Netmap gibt? Außerdem interessiert mich, ob Divert als neuer empfohlener Weg gilt oder eher eine Advanced-/Speziallösung ist?

Vielen Dank vorab für eure Einschätzungen!

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.