Sophos Firewall PIM-SM konfigurieren und prüfen

PIM-SM passt, wenn Multicast über mehrere Router läuft und Receiver Gruppen dynamisch abonnieren oder verlassen. Statt für jede Source und jedes Ausgangsinterface eine feste Route zu pflegen, baut PIM-SM den benötigten Multicast-Pfad über einen Rendezvous Point, kurz RP, auf.

Der kurze Weg lautet:

Backup und unabhängigen Managementzugang bereitstellen; danach Source, Gruppe, UDP-Dienst, Router und Receiver-Netze dokumentieren.
Auf jedem Router die Unicast-Erreichbarkeit zum RP und zum Source-Netz prüfen.
Vorhandene statische Multicast-Routen inventarisieren und den Wechsel im Wartungsfenster planen.
Unter Routing > Multicast (PIM-SM) PIM auf den beteiligten IPv4-Interfaces aktivieren.
Auf allen PIM-Routern den geplanten statischen RP und Gruppenbereich hinterlegen.
Den Multicast-Nutzdatenstrom mit engen, geloggten IPv4-Firewall-Regeln steuern.
Gruppenbeitritt, UDP-Anwendung, PIM-Nachbar, RP SET, Multicast-State, Rule ID und Paketpfad gemeinsam prüfen.

⚠️ Der Wechsel von statischen Multicast-Routen zu PIM-SM verändert den produktiven Multicast-Pfad. Dokumentiere deshalb bestehende Routen, Gruppen, Empfänger und den Rollback-Plan. Die SFOS-22-Hilfe beschreibt statisches Multicast Forwarding und PIM-SM getrennt, nennt aber keine allgemeine Koexistenz- oder Ausschlussregel. Prüfe den tatsächlich verwendeten Build im Wartungsfenster, statt eine parallele Nutzung vorauszusetzen.

Dieser Artikel behandelt dynamisches IPv4-Multicast-Routing mit einem statischen RP. SFOS 22 unterstützt PIM Version 2 und PIM-SM; für die dynamische RP-Auswahl dokumentiert Sophos BSR. Das Beispiel bleibt bewusst beim statischen RP. Candidate RP und BSR werden später nur eingeordnet.

Wann PIM-SM die richtige Wahl ist

PIM-SM lohnt sich vor allem, wenn mehrere Multicast-Router beteiligt sind, Receiver in verschiedenen Netzen liegen oder sich Gruppenmitgliedschaften häufig ändern. Die Router bauen dann nur dort State auf, wo ein Sender oder ein interessierter Receiver existiert.

Für einen einzelnen bekannten Sender und wenige dauerhaft feste Ausgangsinterfaces bleibt eine statische Multicast-Route meist einfacher. Sie braucht keinen RP und keine PIM-Nachbarschaft. PIM-SM ist kein besserer Schalter für denselben kleinen Aufbau, sondern ein anderes Betriebsmodell.

PIM-SM ersetzt zudem weder Unicast Routing noch Firewall-Regeln:

Unicast Routing bestimmt, in welcher Richtung Source und RP erreichbar sind.
PIM-SM baut daraus den Multicast-Verteilbaum zwischen Routern.
IGMP meldet im lokalen Receiver-Netz, welche Hosts eine Gruppe empfangen möchten.
Firewall-Regeln erlauben oder blockieren den eigentlichen Multicast-Datenstrom zwischen Zonen.

IGMP, RP und RPF verständlich erklärt

Ein Receiver sendet im lokalen IPv4-Netz eine IGMP-Mitgliedschaftsmeldung für seine Gruppe. Der letzte Multicast-Router übersetzt dieses Interesse in einen PIM Join in Richtung RP. Der RP ist der gemeinsame Treffpunkt, über den Sender und Receiver einander zunächst finden. Je nach aufgebautem State kann der Datenpfad später auf einen kürzeren Source Tree wechseln; der RP muss deshalb nicht dauerhaft jedes Nutzdatenpaket weiterleiten.

In der Multicast-Tabelle steht (*,G) für den gemeinsamen State einer Gruppe unabhängig von einer bestimmten Source. (S,G) bezeichnet dagegen den State für eine konkrete Source S und Gruppe G. Im Beispiel ist das (10.10.10.20, 239.10.10.10).

Der entscheidende Kontrollmechanismus heisst Reverse Path Forwarding, kurz RPF. Für ein Paket der Source 10.10.10.20 prüft die Firewall, über welches Interface sie diese Source laut Routingtabelle erreichen würde. Kommt der Multicast-Stream über ein anderes Interface an, passt der Rückwärtspfad nicht und der State oder Datenfluss kann scheitern.

PIM ist zwar unabhängig vom verwendeten Unicast-Routingprotokoll, aber nicht unabhängig von funktionierenden Unicast-Routen. Statische Routen, OSPF oder BGP können den RPF-Pfad liefern. Für das folgende Beispiel genügen statische Unicast-Routen; in grösseren Routing-Domains kann OSPF dieselbe Grundlage dynamisch bereitstellen.

Beispieltopologie planen

Das Beispiel verbindet einen Sender hinter Firewall A mit einem Receiver hinter Firewall B:

Sender: 10.10.10.20
Source-Netz an Firewall A: 10.10.10.0/24, Interface Port2, Zone DMZ
Firewall A Transit: 10.255.0.1/30, Interface Port4, Zone PIM-Transit
Firewall B Transit: 10.255.0.2/30, Interface Port4, Zone PIM-Transit
Receiver-Netz an Firewall B: 10.20.20.0/24, Interface Port3, Zone LAN
Testreceiver: 10.20.20.50
Multicast-Gruppe: 239.10.10.10
Anwendungsdienst: UDP 5000
Statischer RP: 10.255.0.1
Gruppenbereich des RP: 239.10.10.0/24

Die Adressen sind private Beispielwerte. Source, Receiver-Netz, Transitnetz, Gruppe und Dienst werden gemeinsam durch die Werte der realen Anwendung ersetzt. Der RP 10.255.0.1 liegt in diesem Beispiel auf Firewall A und muss von allen PIM-Routern per Unicast erreichbar sein.

Der Gruppenbereich 239.10.10.0/24 ist absichtlich enger als *. Ein Stern ordnet dem RP alle Gruppen zu und sollte nur verwendet werden, wenn das gesamte PIM-Domain genau so geplant ist. Pro RP dokumentiert Sophos maximal acht Gruppen- oder Netzangaben.

Vor der PIM-Konfiguration müssen die Unicast-Routen stehen. Firewall A erhält eine Route zu 10.20.20.0/24 über 10.255.0.2; Firewall B eine Route zu 10.10.10.0/24 über 10.255.0.1. Für RPF ist besonders der Pfad von Firewall B zurück zur Source wichtig. Unter Diagnostics > Tools > Route lookup muss eine Abfrage für 10.10.10.20 deshalb auf Port4 und den erwarteten Next Hop zeigen. Diese Unicast-Routen ersetzen den PIM-Verteilbaum nicht.

Wie Interfaces und Zonen für einen solchen Transit sauber getrennt werden, erklärt Sophos Firewall Zonen und Interfaces konfigurieren.

PIM-SM sicher vorbereiten

Vor dem Wartungsfenster werden diese Punkte festgehalten:

Transit-IPs und Unicast-Routen sind in beide Richtungen getestet.
Source, Gruppe, UDP-Port und Receiver-Anwendung sind bekannt.
Der statische RP und sein Gruppenbereich sind für alle Router identisch dokumentiert.
Vorhandene statische Multicast-Routen und Enable multicast forwarding sind inventarisiert.
Ein Konfigurationsbackup und ein unabhängiger Managementzugang sind vorhanden.
Switches im Receiver-Netz verwenden IGMP Snooping nur mit einer geklärten, funktionierenden Querier-Rolle.

Die aktuelle Sophos-Dokumentation verlangt mindestens ein IPv4-gebundenes PIM-Interface. Sie nennt physische, RED- und GRE-Interfaces als unterstützt; Alias-, PPPoE- und Cellular-WAN-Interfaces sind ausgeschlossen. Andere Interface-Typen wie XFRM werden auf der PIM-Seite nicht positiv bestätigt und gehören deshalb nicht ungeprüft in diesen Basisaufbau.

Dynamic Routing gezielt prüfen

PIM-Nachrichten gehören zur Control-Plane der Firewall. Die allgemeine SFOS-Hilfe fasst Routingprotokolle unter Administration > Device access > Dynamic Routing zusammen; die aktuelle PIM-Seite nennt diese Abhängigkeit jedoch nicht ausdrücklich.

Entsteht keine PIM-Nachbarschaft, wird deshalb geprüft, ob Dynamic Routing in der Zone des tatsächlichen Nachbarn erlaubt sein muss. Im Beispiel enthält die eigene Zone PIM-Transit nur das Transitnetz zwischen den beiden Firewalls. Ist die Freigabe für diesen Aufbau erforderlich, wird sie auf beiden Geräten ausschliesslich dort aktiviert.

Die Matrixfreigabe gilt für die gesamte Zone. Liegen in derselben Zone weitere, nicht vertrauenswürdige Netze, bleibt die Checkbox aus und eine eng begrenzte Local Service ACL Exception erlaubt Dynamic Routing nur von den vorgesehenen Nachbarn. Eine zusätzliche Exception verengt eine bereits aktivierte Zonenfreigabe nicht.

Diese Device-Access-Ebene ist für Routing-Control-Traffic bestimmt. Sofern die Freigabe für PIM auf dem eingesetzten Build erforderlich ist, betrifft sie nicht den weitergeleiteten Stream und ersetzt dessen Firewall-Regel nicht. Die beiden Zugriffsebenen erklärt Device Access auf Sophos Firewall absichern.

Bestehendes statisches Multicast Forwarding erfassen

Unter Routing > Static routes dokumentierst du vorhandene Multicast-Routen, abhängige Anwendungen und Zielinterfaces. Die SFOS-22-Hilfe belegt nicht, ob Enable multicast forwarding und PIM-SM auf jedem Build parallel konfiguriert werden können. Ändere den bestehenden Zustand deshalb erst im Wartungsfenster und halte die Reaktion der Oberfläche fest.

Lösche bestehende statische Multicast-Routen nicht vorsorglich. Sie bleiben als dokumentierte Rollback-Vorlage erhalten, bis PIM-SM vollständig abgenommen ist. Muss SFOS das statische Forwarding vor dem Aktivieren von PIM abschalten, ist dieser Schritt Teil des geplanten Wechsels und keine allgemeine, hier unbelegt vorausgesetzte Produktregel.

PIM-SM konfigurieren

Die folgenden Schritte führst du auf Firewall A und Firewall B aus.

PIM und die beteiligten Interfaces aktivieren

Routing > Multicast (PIM-SM) öffnen.
Enable PIM aktivieren.
Unter PIM-enabled interface nur die am Multicast-Pfad beteiligten IPv4-Interfaces wählen:
- Firewall A: Port2 und Port4
- Firewall B: Port4 und Port3
Speichern. Ob der Aufbau funktioniert, zeigen erst PIM-Nachbar, RP-Zuordnung und Multicast-State nach der vollständigen Konfiguration.

PIM wird nicht pauschal auf allen LAN- oder WAN-Interfaces aktiviert. Jedes zusätzliche Interface erweitert die Control-Plane und kann neue Nachbarn oder Multicast-Pfade ermöglichen.

Statischen RP und Gruppenbereich hinterlegen

Unter RP settings wird die Option aktiviert und auf beiden Firewalls dieselbe statische Zuordnung eingetragen:

RP IP: 10.255.0.1
Multicast group: 239.10.10.0/24

Die RP IP ist eine Unicast-Adresse. Auf Firewall B muss die Unicast-Routingtabelle dafür Port4 und 10.255.0.1 als erwarteten Pfad liefern; auf Firewall A ist die RP-IP eine eigene Interface-Adresse. Ein gespeicherter Wert genügt nicht: Unter Routing > Information > PIM-SM > RP SET muss die Gruppe später tatsächlich diesem RP zugeordnet sein.

Speichere die Konfiguration. Wenn SFOS PIM nicht aktivieren lässt, prüfe die Meldung der Oberfläche und den aktuellen Zustand von Enable multicast forwarding. Ändere diese Option nur, wenn die Oberfläche den Konflikt auf dem verwendeten Build tatsächlich bestätigt und der Rollback-Plan dokumentiert ist.

Wann Candidate RP sinnvoll ist

Candidate RP passt zu einer bestehenden PIM-Domain, in der BSR-Rolle und RP-Auswahlverfahren bereits geplant sind. SFOS bietet dafür eine Interface-IP als Candidate RP IP, bis zu acht Gruppen- oder Netzangaben, eine Priorität von 1 bis 255 mit Default 1 und ein Advertisement-Intervall von 30 bis 180 Sekunden mit Default 60.

Die Candidate-RP-Konfiguration allein macht die Firewall jedoch nicht automatisch zu einem funktionierenden BSR und garantiert keine gewünschte RP-Auswahl. Sophos dokumentiert im WebAdmin keinen vollständigen Aufbau des Bootstrap Routers. Deshalb wird Candidate RP erst verwendet, wenn die BSR-Rolle bekannt ist und das resultierende Group-to-RP-Mapping im RP SET kontrolliert werden kann. Für das überschaubare Beispiel bleibt Static RP nachvollziehbarer.

Firewall-Regeln für den Datenstrom anlegen

Die PIM-Nachbarschaft ist keine pauschale Sicherheitsfreigabe. Allgemeine SFOS-Firewall-Regeln steuern den Verkehr zwischen Zonen und Netzen. Das folgende Zwei-Regel-Modell ist deshalb eine eng begrenzte Avanet-Konfiguration für diese Topologie, keine von Sophos dokumentierte PIM-Pflichtvorlage.

Auf Firewall A lautet der Sollaufbau:

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

Auf Firewall B wird eine zweite Regel von PIM-Transit nach LAN mit derselben Source, Gruppe und demselben UDP-Service angelegt. Für den Test ist kein SNAT vorgesehen, damit Source und (S,G) erhalten bleiben.

Die Regeln gelten für den Multicast-Nutzdatenstrom. PIM-Hellos und IGMP-Mitgliedschaftsmeldungen werden nicht mit einer breiten Any-Regel vermischt. Prüfe im Packet Capture Rule ID, Status, Reason sowie Ein- und Ausgangsinterface gemeinsam. Die SFOS-22-Hilfe dokumentiert keine allgemeine Bedeutung von Rule ID 0; dieser Wert allein beweist daher kein fehlendes Regel-Match.

Den allgemeinen Aufbau erklärt Sophos Firewall-Regeln sicher konfigurieren.

PIM-SM vom Neighbor bis zum Receiver abnehmen

Eine sichtbare PIM-Nachbarschaft ist nur der erste Teil der Abnahme:

Unter Routing > Information > PIM-SM > Interface table muss am Transit-Interface die jeweils andere Firewall als Neighbor erscheinen.
Unter RP SET muss 239.10.10.0/24 auf 10.255.0.1 zeigen.
Auf 10.20.20.50 die Empfängeranwendung starten. Das Betriebssystem muss der Gruppe 239.10.10.10 beitreten; die Anwendung muss zusätzlich auf UDP 5000 lauschen.
Einen zeitlich begrenzten Teststream von 10.10.10.20 starten.
Unter Multicasting routing table nach (*,G)- oder (S,G)-State für die Gruppe suchen. Incoming und Outgoing Interfaces müssen zur Topologie passen; PIM timers und flag bits liefern zusätzlichen Diagnosekontext.
Im Log Viewer auf beiden Firewalls die erwartete Rule ID kontrollieren.

Unter Diagnostics > Packet capture mit folgendem BPF-Filter prüfen:

src host 10.10.10.20 and dst host 239.10.10.10 and udp port 5000

Der Stream muss auf Firewall A an Port2 ein- und an Port4 austreten. Auf Firewall B wird er an Port4 empfangen und an Port3 weitergeleitet. Danach wird der tatsächliche Inhalt auf dem Receiver geprüft.

Der Packet-Capture-Ablauf mit Interface, Rule ID, Status und Reason steht unter Packet Capture auf Sophos Firewall verwenden.

Für Control-Traffic lassen sich während eines begrenzten Tests zusätzlich diese BPF-Filter verwenden:

ip proto 103

103 steht für PIM. IGMP verwendet IP-Protokoll 2:

ip proto 2

Die Filter zeigen, ob PIM- und IGMP-Pakete vorhanden sind. Sie beweisen allein weder den richtigen RP noch einen funktionierenden Nutzdatenstrom.

In der Advanced Shell liefert pimd.log weiteren Kontext. Die folgenden Befehle lesen nur:

tail -n 200 /log/pimd.log
grep '239.10.10.10' /log/pimd.log | tail -n 100

Ein leerer grep-Treffer beweist keinen Fehler; der aktuelle State im WebAdmin und der echte Paketpfad bleiben massgebend. Weitere Routing- und Logdateien erklärt Sophos Firewall Service- und Logdateien.

Fehler nach Symptom eingrenzen

Kein PIM-Neighbor erscheint

Direkte Erreichbarkeit der Transit-IPs 10.255.0.1 und 10.255.0.2 prüfen.
Kontrollieren, ob Port4 auf beiden Firewalls als PIM-enabled interface gewählt ist.
Dynamic Routing in der richtigen Transit-Zone beziehungsweise der passenden Local Service ACL Exception prüfen.
Mit ip proto 103 kontrollieren, ob PIM-Pakete das Transit-Interface erreichen und verlassen.
Sicherstellen, dass ein von Sophos für PIM dokumentierter Interface-Typ verwendet wird.

Neighbor ist vorhanden, aber RP SET fehlt oder ist falsch

Auf allen Routern RP IP und Gruppenbereich Zeichen für Zeichen vergleichen.
Unicast-Erreichbarkeit von 10.255.0.1 prüfen.
Bei Candidate RP zuerst die tatsächliche BSR-Rolle klären. Eine konfigurierte Kandidatur allein reicht nicht.
Nicht mit * verbreitern, bevor klar ist, warum die konkrete Gruppe nicht zugeordnet wird.

RP SET stimmt, aber es entsteht kein Multicast-State

Prüfen, ob das Betriebssystem des Empfängers der richtigen Gruppe beigetreten ist und die Anwendung auf UDP 5000 lauscht.
Mit ip proto 2 nach IGMP Reports und Queries im Receiver-Netz suchen.
Bei IGMP Snooping die Querier-Rolle im VLAN prüfen. IGMP-Timer nicht auf Verdacht verändern; der Basisablauf benötigt keine Timer-Anpassung.
Kontrollieren, ob der Sender tatsächlich an 239.10.10.10:5000 sendet.

State ist vorhanden, aber das Incoming Interface ist falsch

Auf jeder Firewall Route Lookup zur Source 10.10.10.20 und zum RP 10.255.0.1 ausführen.
Statische, OSPF-, SD-WAN- und VPN-Routen auf einen unerwarteten besseren Pfad prüfen.
Die globale Route Precedence nicht verändern, bevor der falsche RPF-Pfad mit Routingtabelle und Capture belegt ist.
Asymmetrische Rückwege und Parallelverbindungen getrennt dokumentieren.

Der Stream verlässt die Firewall, erreicht den Receiver aber nicht

Auf beiden Firewalls Rule ID, Status und Outgoing Interface prüfen.
Switchport, VLAN und IGMP Snooping im Receiver-Netz kontrollieren.
Lokale Host-Firewall und Receiver-Anwendung prüfen.
Einen Capture auf Receiver oder Switchport mit den SFOS-Zeitstempeln vergleichen.

HA und Interface-Grenzen berücksichtigen

In Active-Active HA wird Multicast nicht zwischen beiden Nodes lastverteilt. UDP-, Broadcast- und Multicast-Sessions werden beim Failover nicht übernommen. Ein kontrollierter Rollenwechsel kann deshalb den Stream unterbrechen; danach werden Neighbor, RP SET, RPF, Multicast-State, Regeln und Receiver erneut geprüft.

Logs und Reports werden zwischen HA-Nodes nicht synchronisiert. Sichere bei einem HA-Problem deshalb die Daten des Nodes, der den Verkehr vor dem Wechsel verarbeitet hat. Die offizielle HA-Hilfe dokumentiert keinen PIM-spezifischen State-Transfer; der Artikel leitet daraus keine weitergehende Synchronisationsaussage ab.

Dieser Basisartikel verwendet physische Interfaces. Sophos nennt zusätzlich RED und GRE als PIM-fähig. Das ist keine Bestätigung für PIM direkt auf XFRM-, IPsec- oder SSL-VPN-Interfaces. Ein verschlüsseltes oder providerabhängiges Multicast-Design benötigt deshalb eine separate, getestete Architektur.

Sicher zurückrollen

Führe den Rückbau im Wartungsfenster aus:

Teststream beenden und den letzten funktionierenden beziehungsweise fehlerhaften State dokumentieren.
Die neu angelegten Multicast-Firewall-Regeln deaktivieren.
PIM auf beiden Firewalls deaktivieren.
Dynamic Routing in der Transit-Zone nur entfernen, wenn kein anderes Routingprotokoll davon abhängt.
Falls du statisches Multicast Forwarding beim Wechsel deaktiviert hast, stelle den dokumentierten vorherigen Zustand samt Routen wieder her.
Managementzugang, Unicast-Routen und die zuvor produktiven Anwendungen erneut prüfen.

Keine PIM-Service-Restarts, Debug-Schalter oder undokumentierten Advanced-Shell-Kommandos sind für diesen Rollback nötig.

Häufige Fragen

Ersetzt PIM-SM IGMP oder die Firewall-Regel?

Nein. IGMP meldet Receiver-Interesse im lokalen Netz, PIM-SM verbindet die beteiligten Multicast-Router und die Firewall-Regel erlaubt den konkreten Nutzdatenstrom zwischen Zonen. Alle drei Ebenen müssen zum selben Design passen.

Warum beeinflusst eine Unicast-Route den Multicast-Pfad?

PIM-SM verwendet RPF. Die Firewall prüft anhand ihrer Routinginformationen, über welches Interface Source oder RP erreichbar wären. Zeigt diese Route auf das falsche Interface, passt der erwartete Rückwärtspfad nicht und der Multicast-State kann falsch oder unvollständig bleiben.