Übersicht

Nachdem wir im letzten Beitrag die VLANs in OPNsense eingerichtet haben, geht es nun um die passenden Firewall-Regeln. Ohne diese Regeln können die VLANs nicht miteinander kommunizieren – oder sie haben vielleicht mehr Zugriff, als gewünscht. In diesem Beitrag zeige ich dir, wie man gezielt den Datenverkehr zwischen den VLANs steuert, um Sicherheit und Kontrolle zu gewährleisten. Dabei richten wir Regeln ein, die nur die gewünschte Kommunikation erlauben und unerwünschten Traffic blockieren.

Das Video zum Beitrag findet ihr hier: https://youtu.be/AUR3-kT7zk0

Aliases

Unter dem Reiter "Aliases" können wir, wie der Name schon sagt, verschiedenste Aliases für Geräte, Ports, Netzwerke, URLs und vieles mehr erstellen. Die Aliases lassen sich dann für die Firewall-Regeln nutzen. Dies hat den Vorteil, dass wir uns nicht jede IP und Port merken müssen, sondern einmal alle benötigten Geräte und Ports entsprechend als Alias anlegen können und so immer wieder darauf zugreifen können.

Private Netzwerke

OPNsense hat eine Eigenheit: Es ist nicht einfach möglich, eine WAN-Regel auf OPNsense zu erstellen, die einfach nur den Zugriff auf alle WAN-Adressen erlaubt. Wenn wir hier eine Regel erstellen und das Ziel auf "Any" setzen, erlauben wir dem Netz automatisch Zugriff auf alle anderen Netze, da hier auch alle privaten Netze enthalten sind.

Um das zu verhindern, rate ich euch, ein Alias für private Netzwerke anzulegen. Diesen Alias könnt ihr dann bei euren WAN-Regeln nutzen und die Regel quasi auf das Gegenteil umstellen. So erlaubt ihr dem Netz dann den Zugriff auf alle WAN-Adressen, verbietet aber den Zugriff auf private Adressen (wir betrachten das später genauer).

Firewall-Regeln

Bevor wir jetzt unsere Regeln erstellen, möchte ich einmal kurz die Funktionsweise bei OPNsense erklären. Ich war selbst im ersten Moment ein wenig ratlos, wie ich nun meine passenden Regeln erstellen soll, aber sobald man einmal das Konzept verinnerlicht hat, erscheint es logisch.

OPNsense ist so aufgebaut, dass ihr die Regeln immer für das Netz konfiguriert, aus dem der Host kommt, also eingehend. Das bewahrt eine gute Übersichtlichkeit. Wenn wir also beispielsweise dem Host 10.3.2.1 aus dem Server-VLAN 10.3.2.0/24 erlauben wollen, auf das Clientnetz VLAN03 zuzugreifen, müssen wir die Regel unter VLAN02_Server erstellen.

Wir nutzen also unsere angelegten Aliases und erstellen uns als Beispiel eine Regel, die dem Server-Host den Zugriff auf das Client-Netz erlaubt.

Mit dieser Regel erlauben wir unserem Server-Host praktisch "alles" für das Client-Netz. Wir können das Ganze weiter einschränken, indem wir beispielsweise das Protokoll auf TCP setzen und nur HTTPS angeben.

Achtet darauf, auf jeden Fall immer die Logs mitanzuschalten. Wenn ihr fertig seid, speichert ihr die Regel und klickt dann abschließend auf Apply, um sie zu übernehmen. Danach taucht die Regel in der Übersicht auf.

OPNsense-Services

OPNsense bietet verschiedene Services an, die wir in den verschiedenen VLANs nur nutzen können, wenn wir dafür auch die entsprechenden Regeln erstellen. Es kann immer sinnvoll sein, das Pingen zur OPNsense im entsprechenden Netz zuzulassen.

Wenn wir außerdem beim DHCP keinen spezifischen DNS-Server hinterlegt haben, wird auch hier automatisch die OPNsense für DNS-Anfragen aus dem Netz genutzt. Auch dafür muss eine entsprechende Regel erstellt werden, um die Anfrage zu erlauben.

Wenn wir auf die OPNsense-Weboberfläche aus einem VLAN zugreifen wollen, benötigen wir hierfür ebenfalls eine Regel, die den Zugriff per HTTPS erlaubt.

Diese Regel können wir ganz einfach anlegen. Hierfür gibt es bereits eine bestehende Destination, die zur Auswahl steht, nämlich This Firewall. Mit dem Objekt als Destination meinen wir in den Regeln dann immer die OPNsense.

Im Bild unten sehen wir die verschiedenen Regeln als Beispiel aus dem VLAN02-Server Interface.

WAN-Regel

Kommen wir jetzt noch zu der bereits erwähnten Eigenart von OPNsense. Da wir die Regeln immer auf dem eingehenden Interface konfigurieren, um es übersichtlich zu halten, können wir nicht einfach dediziert alles ins WAN erlauben. Das bedeutet, wenn wir eine Regel anlegen mit Destination Any, erwischen wir dabei zwar alle öffentlichen WAN-IP-Adressen, aber leider auch alle privaten Netzwerke, sodass wir danach auf alles in unserem Netzwerk zugreifen können und die Firewall an sich überflüssig wird. Das wollen wir natürlich nicht.

Das ganze können wir aber leicht umgehen und mithilfe des Privaten-Netzwerke-Aliases nur die Verbindung ins WAN erlauben, aber nicht in unsere anderen Netze.

Dafür erstellen wir wieder für unser gewünschtes Interface eine neue Regel. Als Destination geben wir allerdings die privaten Netze an bzw. den Alias. Hier gibt es nun noch einen Haken, der die Destination quasi umdreht und die Regel dann zu allem außer privaten Netzwerken macht.

Wenn wir die Regel speichern, sehen wir in der Übersicht bei Destination nun !Private_Networks. Das Ausrufezeichen vorne deutet auf die Umkehrung der Destination hin.

Mit dieser Regel erlauben wir nun allen Geräten in unserem Servernetz den Zugriff ins WAN, aber nicht den Zugriff auf andere VLANs.

Logs

Kommen wir nun noch zu den Logs. Sollte mal irgendein Traffic nicht durchgehen oder allgemein etwas komisch sein, können wir die Live-View nutzen, um in Echtzeit zu sehen, welche Anfragen möglicherweise blockiert werden und eine entsprechende Regel dafür erstellen.

Das Live-Log finden wir unter Firewall → Log Files → Live View.

Wir haben oben Filter, die wir nutzen können, um unsere Suche ein wenig einzuschränken, beispielsweise auf ein Interface.

Dann sehen wir alle Anfragen, die auf der Firewall ankommen. Grün sind dabei alle Anfragen, die durchgehen, und rot sind alle Anfragen, die blockiert werden.