PIM-SM op Sophos Firewall configureren en controleren

PIM-SM is geschikt wanneer Multicast over meerdere routers loopt en Receivers zich dynamisch bij groepen aansluiten of deze verlaten. In plaats van voor elke Source en elke uitgaande interface een vaste route te onderhouden, bouwt PIM-SM het benodigde Multicast-pad op via een Rendezvous Point, kortweg RP.

De korte procedure is als volgt:

Een back-up en onafhankelijke beheertoegang beschikbaar maken; daarna Source, groep, UDP-service, routers en Receiver-netwerken documenteren.
Op elke router de Unicast-bereikbaarheid van de RP en het Source-netwerk controleren.
Bestaande statische Multicast-routes veiligstellen en Enable multicast forwarding gecontroleerd uitschakelen.
Device Access controleren in de zones met echte PIM-Neighbors en Dynamic Routing alleen waar nodig gericht toestaan.
Onder Routing > Multicast (PIM-SM) PIM activeren op de betrokken IPv4-interfaces.
Op alle PIM-routers dezelfde statische RP en hetzelfde groepsbereik invoeren.
De Multicast-datastroom toestaan met nauw begrensde, gelogde IPv4-firewallregels.
Receiver Join, Neighbor, RP SET, Multicast State, Rule ID en pakketpad samen controleren.

⚠️ PIM-SM en Static Multicast Forwarding kunnen niet gelijktijdig op Sophos Firewall worden geconfigureerd. De omschakeling verandert het productieve Multicast-pad. Bestaande routes, groepen, Receivers en een terugweg moeten vooraf zijn gedocumenteerd.

Dit artikel behandelt dynamische IPv4-Multicast Routing met een statische RP. Een Bootstrap Router, kortweg BSR, verspreidt binnen een PIM-domein de informatie welke RP verantwoordelijk is voor welke groepen. Candidate RP wordt later toegelicht, maar niet gebruikt alsof het automatisch een Bootstrap-Router-oplossing vormt.

Wanneer PIM-SM de juiste keuze is

PIM-SM is vooral zinvol wanneer meerdere Multicast-routers deelnemen, Receivers zich in verschillende netwerken bevinden of groepslidmaatschappen vaak veranderen. De routers bouwen dan alleen State op waar een Sender of geïnteresseerde Receiver aanwezig is.

Voor één bekende Sender en enkele permanent vaste uitgaande interfaces blijft een statische Multicast-route meestal eenvoudiger. Deze heeft geen RP en geen PIM-buurschap nodig. PIM-SM is geen betere oplossing voor dezelfde kleine opzet, maar een ander bedrijfsmodel.

PIM-SM vervangt bovendien noch Unicast Routing noch firewallregels:

Unicast Routing bepaalt in welke richting Source en RP bereikbaar zijn.
PIM-SM bouwt daaruit de Multicast-distributieboom tussen routers.
IGMP meldt in het lokale Receiver-netwerk welke hosts een groep willen ontvangen.
Firewallregels staan de eigenlijke Multicast-datastroom tussen zones toe of blokkeren deze.

IGMP, RP en RPF begrijpelijk uitgelegd

Een Receiver verzendt in het lokale IPv4-netwerk een IGMP-lidmaatschapsmelding voor zijn groep. De laatste Multicast-router vertaalt deze interesse in een PIM Join richting RP. De RP is het gemeenschappelijke ontmoetingspunt waar Sender en Receiver elkaar aanvankelijk vinden. Afhankelijk van de opgebouwde State kan het datapad later overschakelen naar een kortere Source Tree; de RP hoeft daarom niet permanent elk datapakket door te sturen.

In de Multicast-tabel staat (*,G) voor de gemeenschappelijke State van een groep, onafhankelijk van een specifieke Source. (S,G) staat daarentegen voor de State van een concrete Source S en groep G. In het voorbeeld is dat (10.10.10.20, 239.10.10.10).

Het beslissende controlemechanisme heet Reverse Path Forwarding, kortweg RPF. Voor een pakket van Source 10.10.10.20 controleert de firewall via welke interface zij deze Source volgens de routingtabel zou bereiken. Komt de Multicast-stream via een andere interface binnen, dan klopt het terugpad niet en kan de State of datastroom mislukken.

PIM is weliswaar onafhankelijk van het gebruikte Unicast-routeringsprotocol, maar niet van werkende Unicast-routes. Statische routes, OSPF of BGP kunnen het RPF-pad leveren. Voor het volgende voorbeeld volstaan statische Unicast-routes; in grotere routeringsdomeinen kan OSPF dezelfde basis dynamisch leveren.

Voorbeeldtopologie plannen

Het voorbeeld verbindt een Sender achter Firewall A met een Receiver achter Firewall B:

Sender: 10.10.10.20
Source-netwerk op 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-netwerk op Firewall B: 10.20.20.0/24, interface Port3, zone LAN
Test Receiver: 10.20.20.50
Multicast-groep: 239.10.10.10
Application Service: UDP 5000
Statische RP: 10.255.0.1
Groepsbereik van de RP: 239.10.10.0/24

De adressen zijn private voorbeeldwaarden. Source, Receiver-netwerk, transitnetwerk, groep en service worden samen vervangen door de waarden van de echte toepassing. De RP 10.255.0.1 bevindt zich in dit voorbeeld op Firewall A en moet vanaf alle PIM-routers via Unicast bereikbaar zijn.

Het groepsbereik 239.10.10.0/24 is bewust smaller dan *. Een ster wijst alle groepen toe aan de RP en mag alleen worden gebruikt als het hele PIM-domein zo is ontworpen. Sophos documenteert maximaal acht groeps- of netwerkvermeldingen per RP.

Vóór de PIM-configuratie moeten de Unicast-routes aanwezig zijn. Firewall A krijgt een route naar 10.20.20.0/24 via 10.255.0.2; Firewall B een route naar 10.10.10.0/24 via 10.255.0.1. Voor RPF is vooral het pad van Firewall B terug naar de Source belangrijk. Onder Diagnostics > Tools > Route lookup moet een zoekopdracht voor 10.10.10.20 daarom Port4 en de verwachte Next Hop tonen. Deze Unicast-routes vervangen de PIM-distributieboom niet.

Hoe interfaces en zones voor zo’n transitverbinding netjes worden gescheiden, staat in Zones en interfaces op Sophos Firewall configureren.

PIM-SM veilig voorbereiden

Vóór het onderhoudsvenster worden de volgende punten vastgelegd:

Transit-IP’s en Unicast-routes zijn in beide richtingen getest.
Source, groep, UDP-poort en Receiver-toepassing zijn bekend.
De statische RP en het groepsbereik zijn voor alle routers identiek gedocumenteerd.
Bestaande statische Multicast-routes en Enable multicast forwarding zijn geïnventariseerd.
Er zijn een configuratieback-up en onafhankelijke beheertoegang beschikbaar.
Switches in het Receiver-netwerk gebruiken IGMP Snooping alleen met een duidelijke, werkende Querier-rol.

De actuele Sophos-documentatie noemt fysieke, RED- en GRE-interfaces voor PIM. Alias-, PPPoE- en Cellular-WAN-interfaces zijn uitgesloten. Andere interfacetypen zoals XFRM worden op de PIM-pagina niet uitdrukkelijk ondersteund en horen daarom niet zonder controle in deze basisopzet.

Dynamic Routing gericht controleren

PIM-berichten behoren tot de Control Plane van de firewall. De algemene SFOS-help groepeert routeringsprotocollen onder Administration > Device access > Dynamic Routing; de actuele PIM-pagina noemt deze afhankelijkheid echter niet expliciet.

Als er geen PIM-buurschap ontstaat, wordt daarom gecontroleerd of Dynamic Routing moet zijn toegestaan in de zone van de werkelijke Neighbor. In het voorbeeld bevat de aparte zone PIM-Transit alleen het transitnetwerk tussen beide firewalls. Als deze toegang voor de opzet nodig is, wordt ze op beide apparaten uitsluitend daar geactiveerd.

De toegang in de matrix geldt voor de volledige zone. Liggen in dezelfde zone andere, niet-vertrouwde netwerken, dan blijft het selectievakje uit en staat een nauw begrensde Local Service ACL Exception Dynamic Routing alleen toe vanaf de voorziene Neighbors. Een extra Exception maakt een al actieve zonetoegang niet smaller.

Deze Device-Access-laag is bedoeld voor routeringsverkeer op de Control Plane. Als de toegang voor PIM op de gebruikte build nodig is, geldt ze niet voor de doorgestuurde stream en vervangt ze de firewallregel voor die stream niet. De twee toegangslagen worden uitgelegd in Device Access op Sophos Firewall beveiligen.

Static Multicast Forwarding gecontroleerd vervangen

Onder Routing > Static routes worden bestaande Multicast-routes, afhankelijke toepassingen en doelinterfaces gedocumenteerd. Enable multicast forwarding wordt pas tijdens het onderhoudsvenster uitgeschakeld. Daarna kan PIM-SM worden geactiveerd.

Bestaande statische Multicast-routes niet uit voorzorg verwijderen. Ze blijven als gedocumenteerde Rollback-voorbeelden beschikbaar totdat PIM-SM volledig is gevalideerd.

PIM-SM configureren

De volgende stappen worden uitgevoerd op Firewall A en Firewall B.

PIM en de betrokken interfaces activeren

Open Routing > Multicast (PIM-SM).
Activeer Enable PIM.
Selecteer onder PIM-enabled interface alleen de IPv4-interfaces die bij het Multicast-pad horen:
- Firewall A: Port2 en Port4
- Firewall B: Port4 en Port3
Beschouw de wijziging nog niet als geslaagd; Neighbor en State worden pas na de volledige RP-configuratie gecontroleerd.

PIM wordt niet algemeen op alle LAN- of WAN-interfaces geactiveerd. Elke extra interface breidt de Control Plane uit en kan nieuwe Neighbors of Multicast-paden mogelijk maken.

Statische RP en groepsbereik invoeren

Onder RP settings wordt de optie geactiveerd en op beide firewalls dezelfde statische toewijzing ingevoerd:

RP IP: 10.255.0.1
Multicast group: 239.10.10.0/24

De RP IP is een Unicast-adres. Het moet vanuit beide firewalls via het geplande PIM-pad bereikbaar zijn. Een opgeslagen waarde volstaat niet: onder Routing > Information > PIM-SM > RP SET moet de groep later daadwerkelijk aan deze RP zijn toegewezen.

Sla de configuratie vervolgens op. Als PIM niet kan worden geactiveerd, controleer dan eerst of Enable multicast forwarding nog actief is.

Wanneer Candidate RP zinvol is

Candidate RP past bij een bestaand PIM-domein waarin de BSR-rol en de RP-selectie al zijn ontworpen. SFOS biedt daarvoor een interface-IP als Candidate RP IP, een groepslijst, een prioriteit van 1 tot 255 en een Advertisement Interval van 30 tot 180 seconden.

De Candidate-RP-configuratie alleen maakt de firewall echter niet automatisch tot een werkende BSR en garandeert niet de gewenste RP-selectie. Sophos documenteert in WebAdmin geen volledige opzet van de Bootstrap Router. Candidate RP wordt daarom pas gebruikt wanneer de BSR-rol bekend is en de resulterende Group-to-RP Mapping onder RP SET kan worden gecontroleerd. Voor dit overzichtelijke voorbeeld blijft Static RP beter navolgbaar.

Firewallregels voor de datastroom maken

Het PIM-buurschap biedt geen algemene beveiligingstoegang. De stream heeft op elke router een nauw begrensde IPv4-firewallregel nodig voor de betreffende zoneovergang.

Op Firewall A ziet de gewenste configuratie er als volgt uit:

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: aangepaste UDP-service met Destination Port 5000
Action: Accept
Log firewall traffic: ingeschakeld

Op Firewall B wordt een tweede regel gemaakt van PIM-Transit naar LAN, met dezelfde Source, groep en UDP-service. Voor de test is geen SNAT voorzien, zodat Source en (S,G) behouden blijven.

De regels gelden voor de Multicast-datastroom. PIM-Hellos en IGMP-lidmaatschapsmeldingen worden niet gecombineerd met een brede Any-regel. Of het groepsobject op de gebruikte build zoals verwacht matcht, wordt aan de hand van de Rule ID gecontroleerd. Als Rule 0 verschijnt, wordt de regel niet ongecontroleerd verruimd, maar wordt het pakketpad onderzocht.

De algemene opzet staat in Sophos Firewall-regels veilig configureren.

PIM-SM van Neighbor tot Receiver valideren

Een zichtbaar PIM-buurschap is slechts het eerste deel van de validatie:

Onder Routing > Information > PIM-SM > Interface table moet op de transitinterface de andere firewall als Neighbor verschijnen.
Onder RP SET moet 239.10.10.0/24 naar 10.255.0.1 wijzen.
Start op 10.20.20.50 de Receiver-toepassing en abonneer deze op 239.10.10.10 via UDP 5000.
Start een in tijd begrensde teststream vanaf 10.10.10.20.
Zoek onder Multicasting routing table naar de (*,G)- of (S,G)-State voor de groep. Incoming en Outgoing Interfaces moeten bij de topologie passen.
Controleer in Log Viewer op beide firewalls de verwachte Rule ID.
Controleer onder Diagnostics > Packet capture met het volgende BPF-filter:
```
src host 10.10.10.20 and dst host 239.10.10.10 and udp port 5000
```
De stream moet op Firewall A binnenkomen op Port2 en uitgaan op Port4. Op Firewall B komt de stream binnen op Port4 en wordt deze doorgestuurd via Port3. Controleer daarna de daadwerkelijke inhoud op de Receiver.

De procedure voor Packet Capture met interface, Rule ID, Status en Reason staat in Packet Capture op Sophos Firewall gebruiken.

Voor verkeer op de Control Plane kunnen tijdens een beperkte test ook de volgende BPF-filters worden gebruikt:

ip proto 103

103 staat voor PIM. IGMP gebruikt IP-protocol 2:

ip proto 2

De filters tonen of er PIM- en IGMP-pakketten aanwezig zijn. Ze bewijzen op zichzelf noch de juiste RP noch een werkende datastroom.

In de Advanced Shell biedt pimd.log aanvullende context. De volgende commando’s lezen alleen:

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

Een lege grep-treffer bewijst geen fout; de actuele State in WebAdmin en het echte pakketpad blijven doorslaggevend. Verdere routerings- en logbestanden staan in Sophos Firewall-service- en logbestanden.

Fouten per symptoom beperken

Er verschijnt geen PIM-Neighbor

Controleer de directe bereikbaarheid van de transit-IP’s 10.255.0.1 en 10.255.0.2.
Controleer of Port4 op beide firewalls als PIM-enabled interface is geselecteerd.
Controleer Dynamic Routing in de juiste transitzone of in de passende Local Service ACL Exception.
Controleer met ip proto 103 of PIM-pakketten de transitinterface bereiken en verlaten.
Zorg dat een interfacetype wordt gebruikt dat Sophos voor PIM documenteert.

Neighbor is aanwezig, maar RP SET ontbreekt of is onjuist

Vergelijk op alle routers de RP IP en het groepsbereik teken voor teken.
Controleer de Unicast-bereikbaarheid van 10.255.0.1.
Controleer bij Candidate RP eerst de daadwerkelijke BSR-rol. Een geconfigureerde kandidatuur alleen volstaat niet.
Verruim het bereik niet naar * voordat duidelijk is waarom de concrete groep niet wordt toegewezen.

RP SET klopt, maar er ontstaat geen Multicast State

Controleer of de Receiver daadwerkelijk op de juiste groep en UDP-poort is geabonneerd.
Zoek met ip proto 2 naar IGMP Reports en Queries in het Receiver-netwerk.
Controleer bij IGMP Snooping de Querier-rol in het VLAN. Wijzig IGMP-timers niet op goed geluk; voor de basisprocedure is geen timerwijziging nodig.
Controleer of de Sender daadwerkelijk naar 239.10.10.10:5000 verzendt.

State is aanwezig, maar de Incoming Interface is onjuist

Voer op elke firewall een Route Lookup uit naar Source 10.10.10.20 en RP 10.255.0.1.
Controleer statische, OSPF-, SD-WAN- en VPN-routes op een onverwacht beter pad.
Wijzig de globale Route Precedence niet voordat het onjuiste RPF-pad met de routingtabel en een Capture is aangetoond.
Documenteer asymmetrische terugwegen en parallelle verbindingen afzonderlijk.

De stream verlaat de firewall, maar bereikt de Receiver niet

Controleer op beide firewalls Rule ID, Status en Outgoing Interface.
Controleer switchpoort, VLAN en IGMP Snooping in het Receiver-netwerk.
Controleer de lokale hostfirewall en Receiver-toepassing.
Vergelijk een Capture op de Receiver of switchpoort met de SFOS-tijdstempels.

HA- en interfacebeperkingen in acht nemen

In Active-Active HA wordt Multicast niet verdeeld over beide nodes. UDP-, Broadcast- en Multicast-sessies worden bij een Failover niet overgenomen. Een gecontroleerde rolwisseling kan de stream daarom onderbreken; daarna worden Neighbor, RP SET, RPF, Multicast State, regels en Receiver opnieuw gecontroleerd.

De logs worden per node opgeslagen. Bij een HA-probleem worden de gegevens van de node die vóór de wisseling actief was veiliggesteld. Een hitless synchronisatie van de PIM State wordt niet verondersteld.

Dit basisartikel gebruikt fysieke interfaces. Sophos noemt daarnaast RED en GRE als geschikt voor PIM. Dat bevestigt PIM niet rechtstreeks op XFRM-, IPsec- of SSL-VPN-interfaces. Een versleuteld of providerafhankelijk Multicast-ontwerp vereist daarom een afzonderlijk geteste architectuur.

Veilig terugdraaien

De Rollback vindt plaats tijdens het onderhoudsvenster:

Beëindig de teststream en documenteer de laatste werkende of foutieve State.
Schakel de nieuw gemaakte Multicast-firewallregels uit.
Schakel PIM op beide firewalls uit.
Verwijder Dynamic Routing alleen uit de transitzone als geen ander routeringsprotocol ervan afhankelijk is.
Activeer Static Multicast Forwarding alleen opnieuw als de vorige toestand en bijbehorende routes volledig zijn gedocumenteerd.
Controleer beheertoegang, Unicast-routes en de eerder productieve toepassingen opnieuw.

Voor deze Rollback zijn geen herstarts van PIM-services, Debug-schakelaars of niet-gedocumenteerde Advanced-Shell-commando’s nodig.

Veelgestelde vragen

Vervangt PIM-SM IGMP of de firewallregel?

Nee. IGMP meldt de interesse van Receivers in het lokale netwerk, PIM-SM verbindt de betrokken Multicast-routers en de firewallregel staat de concrete datastroom tussen zones toe. Alle drie de lagen moeten bij hetzelfde ontwerp passen.

Waarom beïnvloedt een Unicast-route het Multicast-pad?

PIM-SM gebruikt RPF. Aan de hand van de routeringsinformatie controleert de firewall via welke interface Source of RP bereikbaar zou zijn. Als deze route naar de verkeerde interface wijst, klopt het verwachte terugpad niet en kan de Multicast State onjuist of onvolledig blijven.