Sophos Firewall Multicast mit statischer Route einrichten und testen
Eine statische Multicast-Route leitet den Datenstrom eines bekannten Senders an eine feste Multicast-Gruppe über ausgewählte Interfaces weiter. Das passt beispielsweise für einen Video-, Audio- oder Telemetrie-Stream, dessen Quelle, Gruppe und Receiver-Netze dauerhaft feststehen.
Dieser Ablauf behandelt statisches IPv4-Multicast-Routing. IPv6-Multicast ist nicht Gegenstand dieser Anleitung.
Der kurze Weg lautet:
- Source-IP, Multicast-Gruppe, UDP-Port, Eingangs- und Ausgangsinterface dokumentieren.
- Unter Routing > Static routes Enable multicast forwarding aktivieren.
- Unter Manage multicast route > Add die Source, Gruppe und Interfaces eintragen.
- Einen echten Receiver die Gruppe abonnieren lassen und den Stream starten.
- Route sowie Eingang und Ausgang mit
mroute showund Packet Capture prüfen.
⚠️ Enable multicast forwarding ist eine globale Einstellung. Vor dem Aktivieren müssen vorhandene PIM-SM-Konfigurationen, statische Multicast-Routen und abhängige Streams inventarisiert sein. Die Änderung wird zuerst mit einem begrenzten Teststream geprüft; bei unerwartetem Verhalten wird sie zurückgenommen, bevor weitere Destination Interfaces hinzukommen.
Multicast, IGMP und die statische Route verstehen
Bei Unicast sendet ein Host an eine einzelne Zieladresse. Bei Multicast sendet die Quelle einmal an eine Gruppenadresse; mehrere Receiver können denselben Datenstrom abonnieren. Die Firewall kopiert den Stream nicht an beliebige Netze, sondern nur auf die in der Multicast-Route eingetragenen Destination Interfaces.
Das Beispiel verwendet die feste Kombination aus Sender 10.10.10.20 und Gruppe 239.10.10.10. Diese Kombination wird häufig als Source und Group, kurz (S,G), betrachtet. Ändert die Anwendung ihre Source-IP oder Gruppe, passt die Route nicht mehr.
IGMP meldet im lokalen IPv4-Segment, dass ein Receiver einer Multicast-Gruppe beitreten oder sie verlassen möchte. Ein Switch mit IGMP Snooping kann den Stream dadurch nur an Ports mit interessierten Empfängern weitergeben. Die statische Sophos-Route lernt daraus jedoch keine neuen Destination Interfaces: Port3 bleibt fest konfiguriert, auch wenn dort gerade kein Receiver lauscht.
PIM-SM löst eine andere Aufgabe. Es baut Multicast-Pfade dynamisch zwischen mehreren Multicast-Routern auf und benötigt dafür ein geplantes Rendezvous-Point- und Unicast-Routing-Design. Für einen einzelnen bekannten Sender und wenige feste Receiver-Interfaces ist die statische Route meist übersichtlicher. Bei mehreren Routern, wechselnden Gruppen oder vielen Multicast-Pfaden gehört PIM-SM in ein eigenes Design.
Eine statische Multicast-Route ist ausserdem keine normale statische Unicast-Route. Sie verwendet keinen klassischen Next Hop und erscheint in einem eigenen Bereich.
mDNS ist ein anderer Anwendungsfall
mDNS für Bonjour, AirPlay oder viele Chromecast-Suchen verwendet die link-lokale Adresse 224.0.0.251. Sophos erlaubt in der statischen Multicast-Route Gruppen von 224.0.2.0 bis 239.255.255.255; mDNS liegt ausserhalb dieses Bereichs und wird von Routern nicht wie normaler Multicast-Traffic weitergeleitet.
Diese Anleitung ersetzt deshalb keinen mDNS-Reflector oder Discovery-Gateway. Ein Media-Stream kann über Multicast funktionieren, während die automatische Gerätesuche zwischen VLANs weiterhin nicht funktioniert.
Ab SFOS 23 wird diese separate Discovery-Aufgabe über den mDNS-Reflector unter Network > mDNS konfiguriert. Die Auswahl interner Interfaces und Dienstkategorien sowie die getrennte Freigabe des Anwendungsverkehrs gehören zu diesem eigenen Ablauf; die hier beschriebene statische Multicast-Route wird dadurch nicht ersetzt.
Beispieltopologie planen
Das Beispiel verwendet folgende Werte:
- Sender:
10.10.10.20 - Source Interface:
Port2 - Source Zone:
DMZ - Multicast-Gruppe:
239.10.10.10 - Anwendungsdienst: UDP
5000 - Destination Interface:
Port3 - Destination Zone:
LAN - Receiver-Netz:
10.20.20.0/24 - Testreceiver:
10.20.20.50
10.10.10.20 und 10.20.20.0/24 sind private Beispielwerte. 239.10.10.10 liegt im administrativ begrenzten Multicast-Bereich und eignet sich für ein kontrolliertes lokales Beispiel. In der eigenen Umgebung werden Source, Gruppe, Port und Interfaces gemeinsam durch die Werte der Anwendung und Topologie ersetzt. Die Gruppe darf nicht willkürlich geändert werden: Sender und Receiver müssen dieselbe Adresse und denselben Dienst verwenden.
Die Anwendung muss zudem eine ausreichende TTL senden. Im normalen Routingbetrieb wird die TTL an jedem Hop um eins reduziert. Sendet die Anwendung mit TTL 1, erreicht der Stream bei aktiver TTL-Dekrementierung kein weiteres Segment.
Vor der Änderung sollten diese Punkte feststehen:
- Die Firewall läuft im Gateway Mode.
- Der Sender erreicht
Port2, die Receiver liegen hinterPort3. - Die Receiver-Anwendung kann die Gruppe
239.10.10.10und UDP5000tatsächlich abonnieren. - Vorhandenes PIM-SM, andere Multicast-Routen und deren Abhängigkeiten sind dokumentiert.
- Switches, VLANs und IGMP-Snooping-Einstellungen im Receiver-Netz sind bekannt.
- Ein Konfigurationsbackup und ein unabhängiger Managementzugang sind vorhanden.
Wie Interfaces, VLANs und Zonen zusammenhängen, erklärt Sophos Firewall Zonen und Interfaces konfigurieren.
Statische Multicast-Route anlegen
Multicast Forwarding aktivieren
- Im WebAdmin Routing > Static routes öffnen.
- Unter Multicast forwarding setting Enable multicast forwarding auswählen.
- Auf Apply und danach OK klicken.
Kann die Option nicht aktiviert werden, wird die bestehende Multicast-Konfiguration geprüft. Eine vorhandene PIM-SM-Konfiguration wird nicht spontan verändert: Die aktuelle SFOS-22-Hilfe dokumentiert auf den betreffenden Seiten keinen pauschalen Koexistenzsatz. Deshalb werden das Verhalten des installierten Builds und die geplante Koexistenz getrennt geprüft und freigegeben.
Source, Gruppe und Interfaces eintragen
- Unter Manage multicast route auf Add klicken.
- Bei Source IPv4 address
10.10.10.20eintragen. - Als Source interface
Port2wählen. - Bei Multicast IPv4 address
239.10.10.10eintragen. - Als Destination interface
Port3wählen. - Mit Save speichern.
Der WebAdmin kann mehrere Destination Interfaces in einer Route speichern. Jedes zusätzliche Interface erweitert aber den Bereich, in den der Stream weitergeleitet wird. Es sollte nur gewählt werden, wenn dort wirklich Receiver existieren und die Sicherheitsfreigabe ebenfalls passt. Source und Destination Interface dürfen nicht identisch sein.
CLI als kontrollierten Ersatzweg verwenden
In der Device Console führt der Pfad über 3. Route Configuration > 2. Configure Multicast Routing. Multicast Forwarding muss vor der ersten Route aktiv sein. Es lässt sich in Gateway und Transparent Mode einschalten, statische Multicast-Routen lassen sich jedoch nur im Gateway Mode konfigurieren. Unter Option 1 aktiviert dieser Befehl die globale Weiterleitung:
enable multicast-forwarding
⚠️ Unvollständige Device-Console-Befehle können laut Sophos dazu führen, dass
access_servernicht mehr reagiert. Die Syntax deshalb mit?oder Tab auf dem installierten Build prüfen und vervollständigen; erst danach den vollständigen Befehl ausführen.
Unter 2. Configure Static-routes kann eine Route zwischen zwei statischen Interfaces angelegt und sofort kontrolliert werden:
mroute add input-interface Port2 source-ip 10.10.10.20 dest-ip 239.10.10.10 output-interface Port3
mroute show
Die CLI benötigt für jedes Output Interface einen eigenen mroute add-Eintrag. Sie bietet nur statische Interfaces an, während der WebAdmin auch dynamische Interfaces wie DHCP und PPPoE anzeigen kann. Ein- und Ausgangsinterface müssen verschieden sein; ein nicht Ethernet-basiertes Interface wie IPsec0 gehört nicht in diese Port-Form.
Für einen gezielten Rückbau nennt Sophos bei einer physischen Route die Werte positionsbasiert. Die Interface-Bezeichnungen werden vorher mit mroute show kontrolliert:
mroute del Port2 10.10.10.20 239.10.10.10 Port3
mroute show
Bei IPsec- und GRE-Routen veröffentlicht Sophos eigene input-tunnel- und output-tunnel-Formen, die Beispiele verwenden jedoch nicht durchgehend dieselbe Schreibweise. Dort gilt die Befehlsvervollständigung der installierten SFOS-Version als Referenz; ein öffentliches Beispiel wird nicht ungeprüft eingefügt.
Sicherheitsfreigabe nicht voraussetzen
Die offizielle SFOS-22-Anleitung zum Anlegen einer statischen Multicast-Route nennt keine zusätzliche Firewall- oder NAT-Regel. Deshalb wird für dieses Beispiel nicht vorsorglich eine breite Any-Regel erstellt. Ob das installierte Build oder eine vorhandene Policy dennoch einen zusätzlichen Match verlangt, wird im Packet Capture anhand des tatsächlichen Paketstatus geprüft.
Zeigt die Firewall einen policybedingten Drop, wird nicht geraten: Zuerst werden Source 10.10.10.20, Gruppe 239.10.10.10, UDP 5000, die beteiligten Zonen und der angezeigte Regelkontext gesichert. Erst nach Bestätigung für das eingesetzte Build wird eine Freigabe auf genau diese Werte begrenzt und geloggt. Den allgemeinen Regelaufbau erklärt Sophos Firewall-Regeln sicher konfigurieren.
Datenstrom kontrolliert testen
Eine gespeicherte Route beweist noch nicht, dass der Receiver den Stream erhält. Die Abnahme folgt dem Paket von der Anwendung bis zum Client:
Auf
10.20.20.50die Receiver-Anwendung starten und die Gruppe239.10.10.10auf UDP5000abonnieren.Einen klar begrenzten Teststream von
10.10.10.20starten und Zeitpunkt sowie erwartete Dauer notieren.Unter Diagnostics > Packet capture mit diesem BPF-String filtern:
src host 10.10.10.20 and dst host 239.10.10.10 and udp port 5000In der Paketliste kontrollieren, ob der Stream an
Port2eintrifft und anPort3mit Status Forwarded erscheint. Bei einem Drop werden der angezeigte Status und Regelkontext notiert, ohne eine Regel auf Verdacht zu verbreitern.Auf dem Receiver prüfen, ob Pakete ankommen und die Anwendung den Inhalt verarbeitet.
Der Packet-Capture-Ablauf mit Interface, Regelkontext und Status steht unter Packet Capture auf Sophos Firewall verwenden.
In der Device Console lässt sich die statische Multicast-Routingtabelle zusätzlich lesend anzeigen. Der Pfad führt über 3. Route Configuration > 2. Configure Multicast Routing > 2. Configure Static-routes:
mroute show
Die Ausgabe muss die erwartete Source, Gruppe sowie Ein- und Ausgangsinterfaces zeigen. Der Befehl verändert die Konfiguration nicht.
Für tieferes Troubleshooting zeigt die aktuelle SFOS-22-Dokumentation mrouting.log. In der Advanced Shell werden die letzten Einträge nur gelesen:
tail -n 200 /log/mrouting.log
Weitere Dateien und Service-Zuordnungen stehen unter Sophos Firewall Service- und Logdateien.
Fehler nach Symptom eingrenzen
Die Route lässt sich nicht aktivieren oder speichern
- Source-IP, Gruppenbereich und Interfaces kontrollieren. Zulässig sind Gruppen von
224.0.2.0bis239.255.255.255. - Source und Destination Interface dürfen nicht identisch sein.
- Bei einer schon vorhandenen
(S,G)-Kombination auch das Destination Interface vergleichen. Für mehrere Ausgänge verlangt die CLI je einen eigenen Eintrag mit derselben Source und Gruppe.
Der Stream trifft ein, wird aber nicht weitergeleitet
- Stimmen reale Source-IP und Gruppe exakt mit der Route überein?
- Zeigt
mroute showdie erwarteten Interfaces? - Zeigt der Capture Forwarded oder einen Drop mit verwertbarem Regelkontext?
- Wurde
Port3wirklich als Destination Interface gewählt?
Der Stream verlässt die Firewall, kommt beim Receiver aber nicht an
- TTL des Senders prüfen. Globale Routingparameter werden nicht auf Verdacht verändert.
- VLAN, Switchport und IGMP Snooping im Receiver-Netz kontrollieren.
- Sicherstellen, dass
10.20.20.50die richtige Gruppe und den richtigen UDP-Port abonniert. - Lokale Host-Firewall und Anwendung auf dem Receiver prüfen.
- Einen Capture auf Receiver oder Switchport mit den SFOS-Zeitstempeln vergleichen.
Gerätesuche funktioniert nicht, der Stream aber schon
Discovery-Protokolle wie mDNS sind link-lokal und werden durch diese statische Route nicht reflektiert. Der eigentliche Datenstrom und die Gerätesuche müssen getrennt geprüft werden.
VPN und HA bewusst getrennt behandeln
Multicast über SSL VPN wird von Sophos nicht unterstützt. Statische Multicast-Routen über IPsec oder einen zuvor abgenommenen GRE-Tunnel sind möglich und verwenden eigene CLI-Formen. Für IPsec verlangt Sophos zusätzlich einen expliziten Unicast-Host mit /32 in der VPN-Konfiguration. Die öffentlich dokumentierten Beispiele enthalten mehrere uneinheitliche Schreibweisen; sie sollten deshalb nicht ungeprüft als Copy-and-paste-Befehle in eine Produktionsfirewall übernommen werden.
Bei Multicast über einen VPN-Tunnel ist ausserdem der Firmwarestand wichtig. Wiederholte Firewall-Crashes im zeitlichen Zusammenhang mit diesem Traffic behandelt IPsec-Troubleshooting für NC-180433. Der Fehler ist in SFOS 22.0 MR2 Build 546 behoben; ein normaler Paketverlust oder fehlender Stream beweist diesen Sonderfall nicht.
In Active-Active HA wird Multicast nicht zwischen beiden Nodes lastverteilt. Sophos schliesst Multicast ausserdem vom Session Failover aus. Bei einem Rollenwechsel ist deshalb mit einer Stream-Unterbrechung zu rechnen. Vor dem Failover werden Capture und Zeitstempel auf dem bisherigen aktiven Node gesichert; danach werden Route, Eingang, Ausgang und Receiver auf dem neuen aktiven Node erneut geprüft.
Sicher zurückrollen
Vor dem Rückbau werden Route, Interfaces und bisherige Testwerte dokumentiert. Danach:
- Den Teststream beenden.
- Die statische Multicast-Route im WebAdmin entfernen.
- Enable multicast forwarding nur deaktivieren, wenn keine andere statische Multicast-Route davon abhängt.
- Den vorherigen Zustand der betroffenen Anwendungen und Netze erneut prüfen.
Wurde die Beispielroute stattdessen über die CLI angelegt, kann sie mit dem oben gezeigten, für physische Interfaces offiziell dokumentierten mroute del entfernt und mit mroute show kontrolliert werden. Für Tunnelrouten wird kein unbestätigtes Löschbeispiel übernommen.
Häufige Fragen
Wann ist eine statische Multicast-Route besser als PIM-SM?
Wenn Sender, Gruppe und wenige Destination Interfaces dauerhaft feststehen, ist die statische Route meist einfacher. PIM-SM passt zu mehreren Multicast-Routern, dynamischen Pfaden und vielen wechselnden Gruppen.