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:

1. Backup und unabhängigen Managementzugang bereitstellen; danach Source, Gruppe, UDP-Dienst, Router und Receiver-Netze dokumentieren.
2. Auf jedem Router die Unicast-Erreichbarkeit zum RP und zum Source-Netz prüfen.
3. Vorhandene statische Multicast-Routen sichern und Enable multicast forwarding kontrolliert deaktivieren.
4. Device Access in den Zonen mit echten PIM-Nachbarn prüfen und Dynamic Routing nur bei Bedarf gezielt erlauben.
5. Unter Routing > Multicast (PIM-SM) PIM auf den beteiligten IPv4-Interfaces aktivieren.
6. Auf allen PIM-Routern denselben statischen RP und Gruppenbereich hinterlegen.
7. Den Multicast-Nutzdatenstrom mit engen, geloggten IPv4-Firewall-Regeln erlauben.
8. Receiver-Join, Neighbor, RP SET, Multicast-State, Rule ID und Paketpfad gemeinsam prüfen.

⚠️ PIM-SM und statisches Multicast Forwarding lassen sich auf Sophos Firewall nicht gleichzeitig konfigurieren. Das Umschalten verändert den produktiven Multicast-Pfad. Vorher müssen bestehende Routen, Gruppen, Receiver und ein Rückweg dokumentiert sein.

Dieser Artikel behandelt dynamisches IPv4-Multicast-Routing mit einem statischen RP. Ein Bootstrap Router, kurz BSR, verteilt in einer PIM-Domain die Information, welcher RP für welche Gruppen zuständig ist. Candidate RP wird später eingeordnet, aber nicht als vermeintlich automatische Bootstrap-Router-Lösung verwendet.

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 nennt physische, RED- und GRE-Interfaces für PIM. 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.

Statisches Multicast Forwarding kontrolliert ablösen

Unter Routing > Static routes werden vorhandene Multicast-Routen, abhängige Anwendungen und Zielinterfaces dokumentiert. Enable multicast forwarding wird erst im Wartungsfenster deaktiviert. Danach lässt sich PIM-SM aktivieren.

Bestehende statische Multicast-Routen nicht vorsorglich löschen. Sie bleiben als dokumentierte Rollback-Vorlage erhalten, bis PIM-SM vollständig abgenommen ist.

PIM-SM konfigurieren

Die folgenden Schritte werden auf Firewall A und Firewall B ausgeführt.

PIM und die beteiligten Interfaces aktivieren

1. Routing > Multicast (PIM-SM) öffnen.
2. Enable PIM aktivieren.
3. Unter PIM-enabled interface nur die am Multicast-Pfad beteiligten IPv4-Interfaces wählen:
   • Firewall A: Port2 und Port4
   • Firewall B: Port4 und Port3
4. Die Änderung noch nicht als Erfolg werten; Neighbor und State werden erst nach der vollständigen RP-Konfiguration geprüft.

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. Sie muss aus Sicht beider Firewalls über den vorgesehenen PIM-Pfad erreichbar sein. Ein gespeicherter Wert genügt nicht: Unter Routing > Information > PIM-SM > RP SET muss die Gruppe später tatsächlich diesem RP zugeordnet sein.

Die Konfiguration anschliessend speichern. Wenn PIM nicht aktiviert werden kann, zuerst prüfen, ob Enable multicast forwarding noch aktiv ist.

Wann Candidate RP sinnvoll ist

Candidate RP passt zu einem bestehenden PIM-Domain, in dem die BSR-Rolle und das RP-Auswahlverfahren bereits geplant sind. SFOS bietet dafür eine Interface-IP als Candidate RP IP, eine Gruppenliste, eine Priorität von 1 bis 255 und ein Advertisement-Intervall von 30 bis 180 Sekunden.

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 transportiert keine pauschale Sicherheitsfreigabe. Der Stream benötigt auf jedem Router eine enge IPv4-Firewall-Regel für die jeweilige Zonenquerung.

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. Ob das Gruppenobjekt auf dem eingesetzten Build wie erwartet matcht, wird über die Rule ID geprüft. Erscheint Rule 0, wird die Regel nicht unkontrolliert erweitert, sondern der Paketpfad analysiert.

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:

1. Unter Routing > Information > PIM-SM > Interface table muss am Transit-Interface die jeweils andere Firewall als Neighbor erscheinen.

2. Unter RP SET muss 239.10.10.0/24 auf 10.255.0.1 zeigen.

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

4. Einen zeitlich begrenzten Teststream von 10.10.10.20 starten.

5. Unter Multicasting routing table nach (*,G)- oder (S,G)-State für die Gruppe suchen. Incoming und Outgoing Interfaces müssen zur Topologie passen.

6. Im Log Viewer auf beiden Firewalls die erwartete Rule ID kontrollieren.

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

8. 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 der Receiver die richtige Gruppe und den richtigen UDP-Port wirklich abonniert.
• 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.

Die Logs liegen node-lokal. Bei einem HA-Problem werden die Daten des vor dem Wechsel aktiven Nodes gesichert. Eine hitless Synchronisierung des PIM-State wird nicht vorausgesetzt.

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

Der Rückbau erfolgt im Wartungsfenster:

1. Teststream beenden und den letzten funktionierenden beziehungsweise fehlerhaften State dokumentieren.
2. Die neu angelegten Multicast-Firewall-Regeln deaktivieren.
3. PIM auf beiden Firewalls deaktivieren.
4. Dynamic Routing in der Transit-Zone nur entfernen, wenn kein anderes Routingprotokoll davon abhängt.
5. Statisches Multicast Forwarding nur wieder aktivieren, wenn der vorherige Zustand und seine Routen vollständig dokumentiert sind.
6. 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.