Sophos Firewall: mDNS-Reflector für Gerätesuche zwischen VLANs

Der mDNS-Reflector in SFOS 23 ermöglicht die Gerätesuche zwischen ausgewählten internen Netzen und VLANs. Damit kann beispielsweise ein Client einen AirPlay-Empfänger in einem anderen VLAN finden. Der Reflector überträgt Suchanfragen und Dienstankündigungen, nicht automatisch den anschliessenden Anwendungsverkehr. Die Freigabe für Streaming, Drucken oder Fernzugriff wird separat geplant und geprüft.

Der schnelle Ablauf: Unter Network > mDNS mDNS reflector einschalten, IP version, Allowed interfaces und Services gezielt wählen und mit Apply übernehmen. Danach werden Discovery, tatsächliche Nutzung und die weiterhin gesperrten Netzgrenzen einzeln getestet.

Diese Anleitung beschreibt die SFOS-23-Oberfläche. Eine vorhandene SFOS-22-Anleitung für statisches Multicast-Routing bleibt ein anderer Ablauf; sie ersetzt keinen Reflector. Die Verfügbarkeit einer Dokumentation allein ist kein Nachweis für den Freigabestatus oder die Eignung eines bestimmten Firmware-Builds.

Discovery und Nutzung auseinanderhalten

mDNS, also Multicast DNS, dient zusammen mit DNS-SD zur lokalen Dienstsuche. Bonjour ist Apples Bezeichnung für entsprechende Zero-Configuration-Dienste. In getrennten Subnetzen bleibt diese Suche normalerweise im jeweiligen Segment. Der Reflector verbindet die Discovery-Ebene der ausdrücklich gewählten Interfaces, ohne die Netze zu einem gemeinsamen VLAN zu machen.

Das hat zwei unterschiedliche Folgen:

• Ein Gerät kann sichtbar werden, obwohl die Verbindung zu seinem Dienst noch blockiert ist. Sichtbarkeit beweist weder eine passende Firewall-Regel noch funktionierendes Streaming.
• Die ausgewählten Netze erhalten zusätzliche Informationen über angebotene Dienste. Auch bei gesperrtem Anwendungsverkehr kann diese Sichtbarkeit unerwünscht sein, etwa zwischen Gäste- und Verwaltungsnetz.

Allowed interfaces ist deshalb eine Sicherheitsgrenze, nicht nur eine technische Auswahl. Der Dialog definiert teilnehmende Interfaces, kein gerichtetes Paar aus Quelle und Ziel. Man sollte nicht annehmen, dass damit nur Clients im einen VLAN Geräte im anderen sehen. Services begrenzt die reflektierten Dienstkategorien; eine Kategorie ist jedoch keine Freigabe für jeden Host oder jeden Port einer Anwendung.

WAN- und VPN-Interfaces werden nicht unterstützt. Ein entfernter VPN-Client wird durch diese Einstellung nicht automatisch Teil der lokalen Discovery. Auch ein anderes Suchprotokoll wird nicht allein dadurch unterstützt, dass eine Anwendung zusätzlich mDNS verwendet.

Voraussetzungen und begrenztes Beispiel

Vor der Änderung benötigt man:

• Einen SFOS-23-Build mit Network > mDNS, WebAdmin-Zugriff und einen unabhängigen Managementzugang.
• Bereits konfigurierte interne Interfaces mit korrekt zugeordneten VLANs und Netzen. Zonen und Interfaces müssen zur tatsächlichen Topologie passen.
• Einen Client und einen bekannten Dienstanbieter, deren mDNS-Suche im selben Segment bereits funktioniert.
• Eine Entscheidung, welche Dienstkategorien segmentübergreifend sichtbar sein dürfen, und die erforderlichen Anwendungsports gemäss der eingesetzten Anwendung und Geräteversion.
• Ein Konfigurationsbackup sowie eine Notiz zum bisherigen Reflector-Zustand, zur IP-Version, zu den Interfaces, Kategorien und bestehenden Anwendungsregeln.

Für einen begrenzten AirPlay-Test verwendet man beispielsweise:

• Client 10.20.20.50 im Mitarbeitenden-VLAN 10.20.20.0/24, Firewall-Interface Port2.20, Zone LAN.
• Empfänger 10.30.30.20 im Medien-VLAN 10.30.30.0/24, Firewall-Interface Port2.30, eigene Zone MEDIA.
• IP version: IPv4, weil dieser Test ausschliesslich IPv4 verwendet.
• Allowed interfaces: nur Port2.20 und Port2.30.
• Services: nur AirPlay.

Adressen, VLAN-IDs, Interface-Namen und die beispielhafte Zone MEDIA werden durch die eigene Konfiguration ersetzt. Der Reflector wählt Interfaces, nicht diese zwei einzelnen Hosts: Auch andere Geräte auf den beteiligten Interfaces können im Rahmen der gewählten Kategorien an der Discovery teilnehmen. Für eine feinere Vertrauensgrenze braucht es ein passendes Segmentierungsdesign, nicht bloss engere Anwendungsregeln.

Gäste-, Management- und andere unbeteiligte Interfaces bleiben in diesem Beispiel ausgeschlossen. Ein zuerst erfolgreicher Test mit zwei Interfaces ist aussagekräftiger als eine breite Freigabe, bei der Ursache und Wirkung kaum noch zuzuordnen sind.

mDNS-Reflector konfigurieren

Vorzustand sichern und IP-Version wählen

1. Im WebAdmin Network > mDNS öffnen und die bisherigen Einstellungen festhalten. Ein ausgeschalteter Reflector kann eine ältere Konfiguration behalten; vor dem Einschalten deshalb auch die gespeicherte Auswahl prüfen.
2. mDNS reflector einschalten. Der dokumentierte Standardzustand ist Off.
3. Bei IP version die tatsächlich benötigte Variante wählen: IPv4 reflektiert nur IPv4-mDNS, IPv6 nur IPv6-mDNS und Dual beide Versionen.

Für das Beispiel bleibt man bei IPv4. Dual ist kein allgemeiner Reparaturschalter: Es erweitert die Discovery auf beide IP-Versionen. Werden später IPv6-Dienste genutzt, müssen auch Erreichbarkeit und Anwendungsregeln für IPv6 bewusst geplant und separat geprüft werden.

Interfaces und Dienstkategorien begrenzen

1. Unter Allowed interfaces Port2.20 und Port2.30 auswählen. Nur die ausgewählten Interfaces nehmen an reflektierten Suchanfragen und Ankündigungen teil; maximal 16 Interfaces werden unterstützt.
2. Unter Services AirPlay auswählen.
3. Vor dem Übernehmen prüfen, dass kein Gäste-, WAN-, VPN- oder Managementinterface versehentlich in der geplanten Auswahl liegt.
4. Auf Apply klicken. Die Firewall reflektiert den unterstützten Discovery-Traffic sofort zwischen den ausgewählten Interfaces.

Neben AirPlay stehen AirDrop, Apple File Share, Chromecast, IoT Smart Home, Printer, Remote Desktop, Scanner, Sonos und Spotify Connect zur Auswahl. Die Auswahl wird an den tatsächlichen Bedarf angepasst. Eine Dienstkategorie ersetzt keine Prüfung, ob die konkrete Anwendung ausser Discovery weitere Voraussetzungen hat.

⚠️ Any verarbeitet alle mDNS-Dienstkategorien, auch nicht einzeln aufgeführte. Das kann zusätzlichen Netzwerkverkehr erzeugen und die Systemleistung beeinträchtigen. Es erweitert ausserdem die sichtbaren Dienste. Nicht auf Any wechseln, nur weil ein einzelnes Gerät fehlt; zuerst dessen Discovery und die passende Kategorie prüfen.

Anwendungsverkehr separat freigeben

Für die spätere Nutzung wird eine gezielte Firewall-Regel erstellt oder eine bereits passende Regel geprüft. Im Test ist der Regelname beispielsweise AirPlay-Test-Client-zu-Media, die Quelle der Host 10.20.20.50 in LAN und das Ziel der Host 10.30.30.20 in MEDIA. Die Services entsprechen den für dieses Gerät und diese Anwendung bestätigten TCP-/UDP-Ports; Logging wird für die Abnahme aktiviert.

Hier gibt es bewusst keine universelle AirPlay-Portliste zum Kopieren. Gerätefunktionen und benötigte Verbindungsrichtungen müssen vor der Freigabe feststehen. Eine fehlende Herstellerangabe wird nicht durch Any ersetzt. Benötigt die Anwendung zusätzlich eine vom Dienstanbieter initiierte Verbindung, wird diese separat begründet und eng freigegeben. Die normale Antwort auf eine bestehende Verbindung ist nicht automatisch ein Grund für eine breite Gegenregel.

Es ist ebenso wenig sinnvoll, auf Verdacht eine allgemeine UDP-Freigabe als Ersatz für die Reflector-Konfiguration einzurichten. Discovery-Auswahl und Anwendungsregel lösen unterschiedliche Aufgaben. Änderungen bleiben auf den dokumentierten Test beschränkt; andere Regeln, NAT und Multicast-Routen werden nicht nebenbei verändert.

Erfolg in drei getrennten Prüfungen nachweisen

1. Discovery auf den gewählten Interfaces

Nach Apply die gespeicherte IP-Version, Interface-Auswahl und Kategorien erneut kontrollieren. Anschliessend auf dem Testclient die Gerätesuche der Anwendung neu starten. Erwartet wird der bekannte Empfänger aus dem Medien-VLAN, nicht nur ein Eintrag aus einem früheren Suchlauf.

Bei unklarem Ergebnis unter Diagnostics > Packet capture eine kurze, zeitlich begrenzte Aufnahme starten. Als BPF-Filter für mDNS eignet sich:

udp port 5353

Der Filter ist nur eine Beobachtungshilfe und ändert keine Freigaben. Für den IPv4-Test erwartet man mDNS-Verkehr mit der lokalen Multicast-Adresse 224.0.0.251. Interface und Zeitstempel werden verglichen: Entsteht die Suche im Client-Netz und ist entsprechender Discovery-Verkehr auch am ausgewählten Medien-Interface zu sehen? Paketinhalt und eine Client-Aufnahme helfen zu prüfen, ob der erwartete Dienst tatsächlich angekündigt wird. Ein einzelnes Paket oder ein bestimmter Paketstatus allein beweist keine erfolgreiche Suche. Den Ablauf erklärt Packet Capture auf Sophos Firewall.

2. Den tatsächlichen Dienst nutzen

Den entdeckten Empfänger auswählen und einen kurzen AirPlay-Test starten. Erfolg bedeutet, dass die gewünschte Funktion auf dem Empfänger arbeitet, nicht bloss dass sein Name erscheint. Im Regel-Log oder in einer separaten Aufnahme des Hostpaars 10.20.20.50 und 10.30.30.20 werden Zieladresse, Ports, Verbindungsrichtung und passende Regel geprüft.

Ist Discovery erfolgreich, die Nutzung aber nicht, bleibt die Reflector-Auswahl zunächst unverändert. Jetzt prüft man Anwendungsregeln, tatsächliche Ports, Routing, lokale Geräte-Firewalls und die Anwendung selbst. Ein breiterer Reflector behebt keinen blockierten Anwendungsdienst.

3. Die nicht freigegebenen Grenzen kontrollieren

Mit einem frischen Suchlauf in einem ausgeschlossenen Testsegment prüfen, dass der Dienst nicht durch diesen Reflector sichtbar wird. Zusätzlich testen, dass nicht freigegebene Verbindungen weiterhin blockiert sind. Vorhandene Caches und andere Discovery-Gateways können das Ergebnis verfälschen; eine Anzeige ohne passenden neuen Netzwerkverkehr ist kein ausreichender Nachweis für eine unerwünschte Reflexion.

In HA werden die Reflector-Einstellungen zwischen den Geräten synchronisiert. Die SFOS-23-Funktion unterstützt Discovery auch bei Failover. Das ist keine Zusage für unterbrechungsfreie Anwendungssitzungen. Einen ohnehin geplanten HA-Test nutzt man, um nach dem Rollenwechsel Discovery und Nutzung erneut zu prüfen; ein produktiver Failover wird nicht nur für diese Anleitung ausgelöst.

Fehler gezielt eingrenzen

Network > mDNS fehlt oder ein Interface fehlt

Installierte SFOS-Version und tatsächliche Interface-Konfiguration prüfen. Diese Anleitung setzt die SFOS-23-Oberfläche voraus. WAN- und VPN-Interfaces sind ausgeschlossen. Ein fehlendes internes Interface oder eine nicht speicherbare Auswahl wird mit Build, Interface-Typ und genauer Meldung dokumentiert; die Grenze von 16 Interfaces darf nicht überschritten werden. Nicht mit einer statischen Multicast-Route oder einer undokumentierten Shell-Änderung umgehen.

Der Dienst wird nicht gefunden

Zuerst im lokalen Segment des Anbieters prüfen, ob dessen Discovery funktioniert. Fehlt sie schon dort, sind Gerät, Anwendung, WLAN-Client-Isolation oder lokale Netzfilter die nächsten Kandidaten, nicht der Reflector. Funktioniert sie lokal, werden IP-Version, beide ausgewählten Interfaces, Dienstkategorie und das tatsächlich gespeicherte Ergebnis nach Apply kontrolliert.

Danach die kurze mDNS-Aufnahme auf beiden Seiten vergleichen. Fehlt bereits die Suchanfrage am Client-Interface, Client und Netzweg prüfen. Ist die Anfrage vorhanden, aber keine passende Dienstankündigung, den Anbieter untersuchen. Bei passender Ankündigung ohne Discovery am Client wird der Netzweg zurück zum Client geprüft. Änderungen werden einzeln vorgenommen und danach mit demselben Test wiederholt.

Der Dienst ist sichtbar, funktioniert aber nicht

Den Anwendungsverkehr gesondert erfassen und einen Drop anhand von Hosts, Ports und Regelkontext untersuchen. Die Freigabe nur um nachweislich benötigte Werte ergänzen, nicht alle Dienste zwischen beiden VLANs öffnen. Auch eine angekündigte, vom Client nicht erreichbare Adresse kann die Nutzung verhindern; die tatsächliche Zieladresse und ihren Routingpfad prüfen.

Zu viele Dienste oder zusätzliche Last erscheinen

Services auf Any, ungewollte Kategorien und Allowed interfaces auf zusätzliche Segmente prüfen. Eine unbeabsichtigte Erweiterung auf den notierten Vorzustand zurücksetzen. Wenn die Störung unmittelbar nach der Aktivierung begann, den Reflector kontrolliert ausschalten und denselben begrenzten Test wiederholen. Keine Dienst-Neustarts oder zusätzlichen Reflectors auf Verdacht einführen.

Bleibt das Problem bestehen, für die Eskalation Build, IP-Version, beteiligte Interfaces, Kategorien, anonymisierte Hostadressen, Zeitstempel und kurze Aufnahmen beider Seiten sichern. Kundendaten und unnötige Paketpayloads gehören nicht in ein öffentliches Supportbeispiel.

Sicher zurückrollen

1. Den Test beenden und das Ergebnis sowie die zuletzt gespeicherten Einstellungen dokumentieren.
2. War der Reflector vorher aus, unter Network > mDNS wieder ausschalten und mit Apply übernehmen. War er bereits aktiv, stattdessen die zuvor notierte IP-Version, Interface- und Kategorieauswahl wiederherstellen und übernehmen; andere abhängige Dienste nicht pauschal abschalten.
3. Nur die für diesen Test hinzugefügte Anwendungsregel deaktivieren beziehungsweise die dokumentierte Änderung an einer bestehenden Regel zurücknehmen.
4. Einstellungen erneut öffnen und Discovery, bisherige Dienste sowie weiterhin gesperrte Verbindungen mit einem frischen Suchlauf überprüfen.

Beim Ausschalten bleibt die Reflector-Konfiguration erhalten; beim erneuten Einschalten wird die vorherige Auswahl wieder verwendet. Ausschalten ist daher kein Löschen der gespeicherten Vertrauensgrenzen. Vor jeder späteren Reaktivierung Interfaces und Kategorien erneut prüfen. Bereits vorhandene Discovery-Einträge im Client können nach dem Rückbau noch angezeigt werden, und eine bereits laufende Anwendung ist kein Beweis dafür, dass neue Discovery weiterhin reflektiert wird.