Zum Inhalt springen
Avanet

Sophos Firewall Multicast mit statischer Route einrichten und testen

Sophos Firewall

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:

  1. Source-IP, Multicast-Gruppe, UDP-Port, Eingangs- und Ausgangsinterface dokumentieren.
  2. Unter Routing > Static routes Enable multicast forwarding aktivieren.
  3. Unter Manage multicast route > Add die Source, Gruppe und Interfaces eintragen.
  4. Eine enge, geloggte IPv4-Firewall-Regel für den Datenstrom anlegen.
  5. Einen echten Receiver die Gruppe abonnieren lassen und den Stream starten.
  6. Route, Rule ID sowie Eingang und Ausgang mit mroute show, Log Viewer und Packet Capture prüfen.

⚠️ Statisches Multicast Forwarding und PIM-SM lassen sich auf der Sophos Firewall nicht gleichzeitig konfigurieren. Für statisches Multicast Forwarding muss PIM deaktiviert sein. Vor dem Umschalten muss geklärt sein, ob bereits PIM-SM oder eine andere statische Multicast-Route produktiv verwendet wird.

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.

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 hinter Port3.
  • Die Receiver-Anwendung kann die Gruppe 239.10.10.10 und UDP 5000 tatsä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

  1. Im WebAdmin Routing > Static routes öffnen.
  2. Unter Multicast forwarding setting Enable multicast forwarding auswählen.
  3. Auf Apply und danach OK klicken.

Kann die Option nicht aktiviert werden, zuerst prüfen, ob PIM-SM aktiv ist. Beide Verfahren lassen sich nicht parallel konfigurieren. PIM-SM nicht spontan abschalten, wenn seine bestehenden Nachbarn, Gruppen und Receiver noch nicht dokumentiert sind.

Source, Gruppe und Interfaces eintragen

  1. Unter Manage multicast route auf Add klicken.
  2. Bei Source IPv4 address 10.10.10.20 eintragen.
  3. Als Source interface Port2 wählen.
  4. Bei Multicast IPv4 address 239.10.10.10 eintragen.
  5. Als Destination interface Port3 wählen.
  6. 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.

Firewall-Regel eng begrenzen

Die Multicast-Route bestimmt den Pfad, erlaubt den Datenstrom aber nicht pauschal. Für die Weiterleitung von DMZ nach LAN wird eine eigene IPv4-Firewall-Regel angelegt:

  • Rule name: DMZ_to_LAN_Multicast_5000
  • Action: Accept
  • Log firewall traffic: aktiviert
  • Source zone: DMZ
  • Source network: Host 10.10.10.20
  • Destination zone: LAN
  • Destination network: Host 239.10.10.10
  • Services: eigener UDP-Service mit Destination Port 5000

Die Destination ist die Multicast-Gruppe, nicht das Receiver-Netz 10.20.20.0/24. Die Regel wird auf den echten Sender, die tatsächliche Gruppe und den benötigten Dienst begrenzt. Für dieses Beispiel wird keine breite Any-Regel und keine pauschale Freigabe von IGMP oder PIM verwendet.

Die Regel ist der enge Sollaufbau für diese Beispieltopologie; ihr tatsächlicher Match muss auf der eingesetzten SFOS-Version über die erwartete Rule ID bestätigt werden. Erscheint Rule 0, wird die Regel nicht unkontrolliert verbreitert, sondern mit Log Viewer und Packet Capture geprüft.

In diesem Beispiel ist kein SNAT vorgesehen, damit Source und (S,G)-Zuordnung erhalten bleiben. Existierende NAT-Regeln werden trotzdem auf einen unerwarteten Match geprüft. 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:

  1. Auf 10.20.20.50 die Receiver-Anwendung starten und die Gruppe 239.10.10.10 auf UDP 5000 abonnieren.

  2. Einen klar begrenzten Teststream von 10.10.10.20 starten und Zeitpunkt sowie erwartete Dauer notieren.

  3. Im Log Viewer prüfen, ob DMZ_to_LAN_Multicast_5000 beziehungsweise die erwartete Rule ID greift.

  4. 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 5000

  5. In der Paketliste kontrollieren, ob der Stream an Port2 eintrifft und an Port3 mit Status Forwarded erscheint.

  6. Auf dem Receiver prüfen, ob Pakete ankommen und die Anwendung den Inhalt verarbeitet.

Der Packet-Capture-Ablauf mit Interface, Rule ID 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

  • Prüfen, ob PIM-SM noch aktiv ist. Statisches Multicast Forwarding und PIM-SM lassen sich nicht gleichzeitig konfigurieren.
  • Source-IP, Gruppenbereich und Interfaces kontrollieren. Zulässig sind Gruppen von 224.0.2.0 bis 239.255.255.255.
  • Source und Destination Interface dürfen nicht identisch sein.
  • Bei einer schon vorhandenen Route prüfen, ob dieselbe (S,G)-Kombination bereits konfiguriert ist.

Der Stream trifft ein, wird aber nicht weitergeleitet

  • Stimmen reale Source-IP und Gruppe exakt mit der Route überein?
  • Zeigt mroute show die erwarteten Interfaces?
  • Matcht die vorgesehene Firewall-Regel, oder erscheint im Capture eine andere Rule ID beziehungsweise Rule 0?
  • Wurde Port3 wirklich als Destination Interface gewählt?
  • Verändert eine NAT-Regel die Source unerwartet?

Der Stream verlässt die Firewall, kommt beim Receiver aber nicht an

  • TTL des Senders und die globale Einstellung multicast-decrement-ttl prüfen. Die Einstellung nicht pauschal verändern.
  • VLAN, Switchport und IGMP Snooping im Receiver-Netz kontrollieren.
  • Sicherstellen, dass 10.20.20.50 die 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 einem HA-Cluster wird Multicast nicht zwischen beiden Nodes lastverteilt. Nach einem geplanten Failover werden Route, Rule ID, Eingang, Ausgang und Receiver erneut geprüft. Sophos dokumentiert keine Garantie für unterbrechungsfreies Multicast-Failover; deshalb gehört der Test in ein Wartungsfenster. Logs und Packet Captures werden auf dem jeweils aktiven Node gesichert.

Sicher zurückrollen

Vor dem Rückbau werden Route, Regelname und bisherige Testwerte dokumentiert. Danach:

  1. Den Teststream beenden.
  2. Die neue Firewall-Regel deaktivieren.
  3. Die statische Multicast-Route im WebAdmin entfernen.
  4. Enable multicast forwarding nur deaktivieren, wenn keine andere statische Multicast-Route davon abhängt.
  5. Den vorherigen Zustand der betroffenen Anwendungen und Netze erneut prüfen.

Ein CLI-Delete ist für diesen Rollback nicht nötig. So bleibt der Rückbau nachvollziehbar und vermeidet die uneinheitliche öffentlich dokumentierte Löschsyntax.

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.

Kann ich damit Bonjour, AirPlay oder Chromecast über VLANs finden?

Nicht mit dieser Route allein. mDNS verwendet 224.0.0.251, ist link-lokal und benötigt für die Weiterleitung zwischen VLANs eine dafür vorgesehene Reflection- oder Gateway-Funktion.

Warum braucht es zusätzlich eine Firewall-Regel?

Die Multicast-Route beschreibt, wo der Stream weitergeleitet wird. Die Firewall-Regel entscheidet weiterhin, ob genau diese Source, Gruppe und dieser UDP-Service zwischen den beteiligten Zonen passieren dürfen.