Alle Beiträge von Don Matteo

lebt in der Schweiz, ist System Engineer MCP bei A-Enterprise GmbH. Mitglied des UNBLOG Knowledge Network. Author und Blogger zu den Themen, Tutorials für Linux und Open Source.

Zugriff auf OPNsense Web GUI via WAN nach Installation

Nach der Initialisierung einer OPNsense als virtuelle Maschine wird der Zugriff via WAN verweigert. Bei einer neu bereitgestellten OPNsense virtual Machine auf einem Hypervisor, wie beispielsweise auf einem VMware ESXi Host, ist das Web GUI aus dem Internet noch nicht direkt zu erreichen.

Zugriff zur OPNsense via WAN

Damit der Zugriff zur OPNsense via WAN möglich wird, muss man wie bei jeder neuen Installation, den Wizard mit der Option 1) Assign interfaces und 2) Set interface IP address aufrufen und befolgen. Dies um die Basis für die OPNsense zu legen, mit den Schnittstellen und der IP-Konfiguration für das WAN- und LAN-Interface.

OPNsense VMware ESXi Console

Danach muss die Firewall vorübergehend deaktiviert werden, was in der vSphere Konsole der virtuellen Maschine erfolgt.

Packet Filter (pf) deaktivieren

Mit der Option 8) Shell das Kommando pfctl -d ausführen:

root@OPNsense:~ # pfctl -d
pf disabled

Nun kann das Web GUI über die WAN IP im Browser erreicht werden.

OPNsense Firewall WAN Rule erstellen

Um jetzt den Zugriff zur OPNsense via WAN dauerhaft zu ermöglichen, muss unter Firewall – Rules – WAN eine neue Regel erstellt werden, für eingehend passieren für diese Firewall.

OPNsense – Firewall – Rules – WAN. Klick für Zoom.

WICHITG! Explizit kein Gateway wählen, der Gateway muss default sein. Der zuvor in der Console durch Set interface IP address erstellte Gateway wird nur für das WAN interface benötigt.

Nachdem der default Gateway gewählt wurde, muss die OPNsense neu gestartet werden, mit dem Befehl reboot, oder mit der Option 6 aus dem OPNsense Konsolen Menü.

Hinweis! Nach jedem Neustart wird die Paket-Filter Firewall (pf) aktiviert, der Befehl pfctl -e um die pf-Firewall zu aktivieren ist nicht erforderlich. Zu Beginn sollte beim Einrichten der OPNsense kein zweiter Gateway hinzugefügt werden.

  Es soll hier nicht unerwähnt bleiben, die OPNsense adäquat vor Missbrauch und Brute-Force-Angriff zu schützen. Es empfiehlt sich die WAN Regel für den Zugriff zum Web-GUI nur von bekannten Quellen zu erlauben. Dazu kann unter System – Settings – Administration bei TCP Port eine benutzerdefinierte Portnummer für das Web-GUI definiert werden, um die Standardeinstellung (80 für HTTP, 443 für HTTPS) zu überschreiben. Ebenfalls wird die 2FA TOTP Authentifizierung mit Google Authenticator ermöglicht, in der Anleitung hier.

Microsoft ersetzt NetBIOS durch mDNS Multicast DNS

Multicast DNS (mDNS) wird ab Windows 10 1703 unterstützt, Microsoft beginnt jedoch erst jetzt mit den Vorbereitungen um NetBIOS und Link-Local Multicast Name Resolution (LLMNR) vollständig durch mDNS zu ersetzen. In den Windows 11 Pre­views ist die NetBIOS-Namensauflösung per Voreinstellung vorerst als Fallback konfiguriert.

Ursprünglich wurde mDNS von Apple entwickelte und ist ein Protokoll zur Namensauflösung, das ohne zentralen DNS-Server auskommt. Es sendet per Multicast eine Anfrage an alle Geräte im Netzwerk, dieses dass auf den gewünschten Hostname zutrifft, antwortet ebenfalls mit einem Multicast an das gesamte Netzwerk.

Mehrere mDNS-Resolver

mDNS-Resolver hören auf UDP-Port 5353 dazu in der Praxis mehrere Resolver gleichzeitig aktiv sind. Neben dem Betriebssystem gehören etwa Microsoft Teams Clients dazu, oder auch Chromium-basierte Web-Browser.

Aktive mDNS-Resolver können in der PowerShell ausgegeben werden:

Get-NetUDPEndpoint -LocalPort 5353 | Select-Object LocalAddress,LocalPort,OwningProcess, @{ Name="Prozess"; Expression={((Get-Process -Id $_.OwningProcess).Name )} }

Eine zentrale Instanz in Form eines DNS-Servers gibt es bei mDNS nicht, es kann zudem nicht ausgeschlossen werden, dass mehrere Geräte in einem Netzwerk denselben Hostname verwenden.

Eine Gefahr besteht in dessen, wo sich Schadprogramme über UDP-Port 5353 einnisten und Clients über DNS-Spoofing an Hosts weiterleiten, die von Cyberkrimineller Herkunft zeugen.

mDNS deaktivieren

Aufgrund dieser Umstände könnten Administratoren es in Erwägung ziehen, mDNS zu deaktivieren. Microsoft empfiehlt jedoch vor der generellen Deaktivierung abzusehe. Da sonst die Kommunikation mit verschiedenen Geräten im Netzwerk wie etwa Druckern oder kabellose Geräte beeinträchtigt sein könnten.

Wenn Unternehmen eine solche Maßnahme dennoch bevorzugen, dann empfiehlt Microsoft, mit der Windows-Firewall nur eingehende Anfragen zu blockieren. Die Windows-Firewall enthält dafür die vordefinierte Regel „mDNS (UDP-In)“.

Die Windows-Firewall öffnen mit den Tasten Windows+R und firewall.cpl Ausführen, dann zu Erweiterte Einstellungen gehen.

Windows Firewall – Erweiterte Einstellungen

Man sollte mDNS nur für das Domänen Profil und das Öffentliche Profil deaktivieren, für private Netzwerke aber ermöglichen. Damit sichergestellt wird, dass Anwender im HomeOffice Geräte nutzen können, die auf mDNS ausgelegt sind.

Windows Multicast DNS mDNS ersetzt NetBIOS und LLMNR

Ein Grund mehr um mDNS nicht vorzeitig zu deaktivieren ist, dass Microsoft zunehmend auf dieses Protokoll setzt. In aktuellen Previews von Windows 11 läuft NetBIOS standardmäßig so, dass dieses veraltete Protokoll nur zum Zug kommt, nachdem Anfragen an mDNS und LLMNR gescheitert sind.

Das Standard Verhalten von LLMNR wurde noch nicht geändert. Microsoft will aber künftig mDNS zur Voreinstellung machen, für die Namensauflösung mit Multicast-Protokoll.

Dort wo Anwendungen weiterhin NetBIOS benötigen, kann eine neue Gruppenrichtlinie entsprechend konfiguriert werden. Sie bietet neben mDNS die Optionen, die Namensauflösung über NetBIOS vollständig zuzulassen. Und ganz zu untersagen oder nur in öffentliches Netzwerk zu blockieren.

NetBIOS und Windows Multicast DNS (mDNS)