Configurer et vérifier PIM-SM sur Sophos Firewall

PIM-SM convient lorsque le multicast traverse plusieurs routeurs et que des récepteurs rejoignent ou quittent dynamiquement des groupes. Au lieu de maintenir une route fixe pour chaque source et chaque interface de sortie, PIM-SM construit le chemin multicast nécessaire via un Rendezvous Point, ou RP.

La procédure courte est la suivante :

Préparer un backup et un accès de gestion indépendant, puis documenter la source, le groupe, le service UDP, les routeurs et les réseaux de récepteurs.
Vérifier sur chaque routeur la joignabilité unicast du RP et du réseau source.
Sauvegarder les routes multicast statiques existantes et désactiver de manière contrôlée Enable multicast forwarding.
Vérifier Device Access dans les zones contenant de véritables voisins PIM et n’autoriser Dynamic Routing de manière ciblée que si nécessaire.
Sous Routing > Multicast (PIM-SM), activer PIM sur les interfaces IPv4 concernées.
Configurer le même RP statique et la même plage de groupes sur tous les routeurs PIM.
Autoriser le flux de données multicast avec des règles firewall IPv4 restrictives et journalisées.
Vérifier ensemble l’adhésion du récepteur, le Neighbor, le RP SET, l’état multicast, la Rule ID et le chemin des paquets.

⚠️ PIM-SM et le Static Multicast Forwarding ne peuvent pas être configurés simultanément sur Sophos Firewall. Le basculement modifie le chemin multicast en production. Les routes, groupes et récepteurs existants ainsi qu’un chemin de retour doivent être documentés au préalable.

Cet article traite du routage multicast IPv4 dynamique avec un RP statique. Dans un domaine PIM, un Bootstrap Router, ou BSR, distribue l’information indiquant quel RP est responsable de quels groupes. Candidate RP est présenté plus loin, mais n’est pas utilisé comme une prétendue solution automatique de Bootstrap Router.

Quand PIM-SM est le bon choix

PIM-SM est surtout utile lorsque plusieurs routeurs multicast participent, que les récepteurs se trouvent dans différents réseaux ou que les adhésions aux groupes changent fréquemment. Les routeurs ne créent alors un état que là où un émetteur ou un récepteur intéressé existe.

Pour un seul émetteur connu et quelques interfaces de sortie fixes, une route multicast statique reste généralement plus simple. Elle ne nécessite ni RP ni voisinage PIM. PIM-SM n’est pas simplement une meilleure option pour la même petite topologie, mais un autre modèle d’exploitation.

PIM-SM ne remplace par ailleurs ni le routage unicast ni les règles firewall :

Unicast Routing détermine dans quelle direction la source et le RP sont joignables.
PIM-SM construit à partir de ces informations l’arbre de distribution multicast entre les routeurs.
IGMP indique dans le réseau local des récepteurs quels hôtes souhaitent recevoir un groupe.
Les règles firewall autorisent ou bloquent le flux de données multicast réel entre les zones.

Comprendre IGMP, RP et RPF

Dans son réseau IPv4 local, un récepteur envoie un message d’adhésion IGMP pour son groupe. Le dernier routeur multicast traduit cet intérêt en un PIM Join en direction du RP. Le RP est le point de rencontre commun par lequel émetteurs et récepteurs se trouvent initialement. Selon l’état créé, le chemin des données peut ensuite basculer vers un Source Tree plus court ; le RP ne doit donc pas nécessairement transférer durablement chaque paquet de données.

Dans la table multicast, (*,G) représente l’état partagé d’un groupe indépendamment d’une source particulière. (S,G) représente en revanche l’état d’une source précise S et d’un groupe G. Dans l’exemple, il s’agit de (10.10.10.20, 239.10.10.10).

Le mécanisme de contrôle déterminant s’appelle Reverse Path Forwarding, ou RPF. Pour un paquet provenant de la source 10.10.10.20, le firewall vérifie par quelle interface il atteindrait cette source selon sa table de routage. Si le flux multicast arrive par une autre interface, le chemin de retour ne correspond pas et l’état ou le flux de données peut échouer.

PIM est indépendant du protocole de routage unicast utilisé, mais pas de routes unicast fonctionnelles. Des routes statiques, OSPF ou BGP peuvent fournir le chemin RPF. Pour l’exemple suivant, des routes unicast statiques suffisent ; dans les grands domaines de routage, OSPF peut fournir dynamiquement la même base.

Planifier la topologie d’exemple

L’exemple relie un émetteur derrière le firewall A à un récepteur derrière le firewall B :

Émetteur : 10.10.10.20
Réseau source sur le firewall A : 10.10.10.0/24, interface Port2, zone DMZ
Transit du firewall A : 10.255.0.1/30, interface Port4, zone PIM-Transit
Transit du firewall B : 10.255.0.2/30, interface Port4, zone PIM-Transit
Réseau des récepteurs sur le firewall B : 10.20.20.0/24, interface Port3, zone LAN
Récepteur de test : 10.20.20.50
Groupe multicast : 239.10.10.10
Service applicatif : UDP 5000
RP statique : 10.255.0.1
Plage de groupes du RP : 239.10.10.0/24

Ces adresses sont des valeurs d’exemple privées. La source, le réseau des récepteurs, le réseau de transit, le groupe et le service doivent être remplacés ensemble par les valeurs de l’application réelle. Dans cet exemple, le RP 10.255.0.1 se trouve sur le firewall A et doit être joignable en unicast depuis tous les routeurs PIM.

La plage 239.10.10.0/24 est volontairement plus restrictive que *. Un astérisque affecte tous les groupes au RP et ne devrait être utilisé que si l’ensemble du domaine PIM est conçu ainsi. Sophos documente au maximum huit indications de groupes ou de réseaux par RP.

Les routes unicast doivent être en place avant la configuration de PIM. Le firewall A reçoit une route vers 10.20.20.0/24 via 10.255.0.2 ; le firewall B une route vers 10.10.10.0/24 via 10.255.0.1. Pour RPF, le chemin de retour du firewall B vers la source est particulièrement important. Sous Diagnostics > Tools > Route lookup, une recherche pour 10.10.10.20 doit donc indiquer Port4 et le Next Hop attendu. Ces routes unicast ne remplacent pas l’arbre de distribution PIM.

Configurer les zones et interfaces Sophos Firewall explique comment séparer proprement les interfaces et les zones pour un tel transit.

Préparer PIM-SM en toute sécurité

Avant la fenêtre de maintenance, consigner les points suivants :

Les adresses IP de transit et les routes unicast sont testées dans les deux sens.
La source, le groupe, le port UDP et l’application réceptrice sont connus.
Le RP statique et sa plage de groupes sont documentés de manière identique pour tous les routeurs.
Les routes multicast statiques existantes et Enable multicast forwarding ont été inventoriés.
Un backup de la configuration et un accès de gestion indépendant sont disponibles.
Les switches du réseau des récepteurs utilisent IGMP Snooping uniquement avec un rôle de Querier clarifié et fonctionnel.

La documentation Sophos actuelle cite les interfaces physiques, RED et les interfaces GRE pour PIM. Les interfaces Alias, PPPoE et Cellular WAN sont exclues. D’autres types d’interfaces tels que XFRM ne sont pas confirmés explicitement sur la page PIM et ne doivent donc pas être intégrés sans vérification dans cette configuration de base.

Vérifier Dynamic Routing de manière ciblée

Les messages PIM appartiennent au Control Plane du firewall. L’aide générale de SFOS regroupe les protocoles de routage sous Administration > Device access > Dynamic Routing ; la page PIM actuelle ne mentionne cependant pas explicitement cette dépendance.

Si aucun voisinage PIM ne se forme, vérifier par conséquent si Dynamic Routing doit être autorisé dans la zone du voisin réel. Dans l’exemple, la zone dédiée PIM-Transit contient uniquement le réseau de transit entre les deux firewalls. Si cette autorisation est nécessaire pour cette topologie, elle est activée sur les deux appareils exclusivement dans cette zone.

L’autorisation dans la matrice s’applique à toute la zone. Si la même zone contient d’autres réseaux non fiables, la case reste désactivée et une Local Service ACL Exception restrictive autorise Dynamic Routing uniquement depuis les voisins prévus. Une exception supplémentaire ne restreint pas une autorisation de zone déjà active.

Ce niveau Device Access est destiné au trafic de contrôle de routage. Si l’autorisation PIM est nécessaire sur la version utilisée, elle ne concerne pas le flux transféré et ne remplace pas sa règle firewall. Sécuriser Device Access sur Sophos Firewall explique ces deux niveaux d’accès.

Remplacer de manière contrôlée le Static Multicast Forwarding

Sous Routing > Static routes, documenter les routes multicast existantes, les applications dépendantes et les interfaces de destination. Enable multicast forwarding n’est désactivé que pendant la fenêtre de maintenance. PIM-SM peut ensuite être activé.

Ne pas supprimer préventivement les routes multicast statiques existantes. Elles restent un modèle de rollback documenté jusqu’à la validation complète de PIM-SM.

Configurer PIM-SM

Les étapes suivantes sont exécutées sur le firewall A et le firewall B.

Activer PIM et les interfaces concernées

Ouvrir Routing > Multicast (PIM-SM).
Activer Enable PIM.
Sous PIM-enabled interface, sélectionner uniquement les interfaces IPv4 participant au chemin multicast :
- Firewall A : Port2 et Port4
- Firewall B : Port4 et Port3
Ne pas considérer encore la modification comme réussie ; Neighbor et State ne seront vérifiés qu’après la configuration complète du RP.

PIM n’est pas activé globalement sur toutes les interfaces LAN ou WAN. Chaque interface supplémentaire étend le Control Plane et peut permettre de nouveaux voisins ou chemins multicast.

Configurer le RP statique et la plage de groupes

Sous RP settings, activer l’option et saisir la même affectation statique sur les deux firewalls :

RP IP: 10.255.0.1
Multicast group: 239.10.10.0/24

La RP IP est une adresse unicast. Elle doit être joignable depuis les deux firewalls via le chemin PIM prévu. Une valeur enregistrée ne suffit pas : sous Routing > Information > PIM-SM > RP SET, le groupe doit ensuite être réellement affecté à ce RP.

Enregistrer ensuite la configuration. Si PIM ne peut pas être activé, vérifier d’abord si Enable multicast forwarding est toujours actif.

Quand Candidate RP est pertinent

Candidate RP convient à un domaine PIM existant dans lequel le rôle BSR et le processus de sélection du RP sont déjà planifiés. SFOS propose pour cela une adresse IP d’interface comme Candidate RP IP, une liste de groupes, une priorité de 1 à 255 et un intervalle Advertisement de 30 à 180 secondes.

La seule configuration de Candidate RP ne transforme toutefois pas automatiquement le firewall en BSR fonctionnel et ne garantit pas la sélection souhaitée du RP. Sophos ne documente pas une configuration complète du Bootstrap Router dans WebAdmin. Candidate RP ne doit donc être utilisé que lorsque le rôle BSR est connu et que le Group-to-RP Mapping résultant peut être contrôlé dans RP SET. Pour cet exemple limité, Static RP reste plus compréhensible.

Créer les règles firewall pour le flux de données

Le voisinage PIM ne fournit aucune autorisation de sécurité générale. Sur chaque routeur, le flux nécessite une règle firewall IPv4 restrictive pour le passage entre les zones concernées.

Sur le firewall A, la configuration cible est la suivante :

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: service UDP personnalisé avec Destination Port 5000
Action: Accept
Log firewall traffic: activé

Sur le firewall B, créer une seconde règle de PIM-Transit vers LAN avec la même source, le même groupe et le même service UDP. Aucun SNAT n’est prévu pour le test afin de préserver la source et (S,G).

Les règles s’appliquent au flux de données multicast. Les PIM Hellos et les messages d’adhésion IGMP ne sont pas mélangés dans une large règle Any. Vérifier au moyen de la Rule ID que l’objet de groupe correspond comme prévu sur la version utilisée. Si la Rule 0 apparaît, ne pas élargir la règle sans contrôle, mais analyser le chemin des paquets.

Configurer des règles Sophos Firewall sécurisées explique la structure générale.

Valider PIM-SM du Neighbor au récepteur

Un voisinage PIM visible n’est que la première partie de la validation :

Sous Routing > Information > PIM-SM > Interface table, l’autre firewall doit apparaître comme Neighbor sur l’interface de transit.
Sous RP SET, 239.10.10.0/24 doit pointer vers 10.255.0.1.
Sur 10.20.20.50, démarrer l’application réceptrice et rejoindre 239.10.10.10 sur UDP 5000.
Démarrer un flux de test limité dans le temps depuis 10.10.10.20.
Sous Multicasting routing table, rechercher un état (*,G) ou (S,G) pour le groupe. Incoming et Outgoing Interfaces doivent correspondre à la topologie.
Contrôler dans le Log Viewer des deux firewalls la Rule ID attendue.
Sous Diagnostics > Packet capture, vérifier avec le filtre BPF suivant :
```
src host 10.10.10.20 and dst host 239.10.10.10 and udp port 5000
```
Le flux doit entrer sur Port2 du firewall A et sortir par Port4. Sur le firewall B, il est reçu sur Port4 et transféré par Port3. Vérifier ensuite le contenu réel sur le récepteur.

Le déroulement de Packet Capture avec Interface, Rule ID, Status et Reason est décrit sous Utiliser Packet Capture sur Sophos Firewall.

Pour le trafic de contrôle, les filtres BPF suivants peuvent également être utilisés pendant un test limité :

ip proto 103

103 correspond à PIM. IGMP utilise le protocole IP 2 :

ip proto 2

Les filtres montrent si des paquets PIM et IGMP sont présents. À eux seuls, ils ne prouvent ni que le RP est correct ni que le flux de données fonctionne.

Dans l’Advanced Shell, pimd.log fournit un contexte supplémentaire. Les commandes suivantes sont en lecture seule :

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

Une recherche grep vide ne prouve pas une erreur ; l’état actuel dans WebAdmin et le chemin réel des paquets restent déterminants. Fichiers de service et journaux Sophos Firewall explique d’autres fichiers de routage et de log.

Isoler les erreurs selon le symptôme

Aucun PIM Neighbor n’apparaît

Vérifier la joignabilité directe des adresses de transit 10.255.0.1 et 10.255.0.2.
Vérifier que Port4 est sélectionné comme PIM-enabled interface sur les deux firewalls.
Vérifier Dynamic Routing dans la bonne zone de transit ou dans la Local Service ACL Exception correspondante.
Utiliser ip proto 103 pour contrôler si les paquets PIM atteignent et quittent l’interface de transit.
S’assurer qu’un type d’interface documenté par Sophos pour PIM est utilisé.

Neighbor est présent, mais RP SET manque ou est incorrect

Comparer caractère par caractère la RP IP et la plage de groupes sur tous les routeurs.
Vérifier la joignabilité unicast de 10.255.0.1.
Avec Candidate RP, clarifier d’abord le rôle BSR réel. Une candidature configurée ne suffit pas.
Ne pas élargir à * avant de comprendre pourquoi le groupe précis n’est pas affecté.

RP SET est correct, mais aucun état multicast n’apparaît

Vérifier que le récepteur a réellement rejoint le bon groupe et le bon port UDP.
Rechercher avec ip proto 2 les IGMP Reports et Queries dans le réseau des récepteurs.
En présence d’IGMP Snooping, vérifier le rôle de Querier dans le VLAN. Ne pas modifier les timers IGMP au hasard ; la procédure de base ne nécessite aucun ajustement des timers.
Vérifier que l’émetteur envoie réellement vers 239.10.10.10:5000.

L’état existe, mais l’Incoming Interface est incorrecte

Exécuter sur chaque firewall un Route Lookup vers la source 10.10.10.20 et le RP 10.255.0.1.
Rechercher dans les routes statiques, OSPF, SD-WAN et VPN un meilleur chemin inattendu.
Ne pas modifier la Route Precedence globale avant d’avoir démontré le mauvais chemin RPF avec la table de routage et une capture.
Documenter séparément les chemins de retour asymétriques et les connexions parallèles.

Le flux quitte le firewall, mais n’atteint pas le récepteur

Contrôler sur les deux firewalls la Rule ID, le Status et l’Outgoing Interface.
Vérifier le port du switch, le VLAN et IGMP Snooping dans le réseau des récepteurs.
Vérifier le firewall local de l’hôte et l’application réceptrice.
Comparer une capture sur le récepteur ou le port du switch avec les horodatages SFOS.

Tenir compte des limites HA et des interfaces

Dans un HA Active-Active, le multicast n’est pas réparti entre les deux nœuds. Les sessions UDP, Broadcast et Multicast ne sont pas reprises lors du failover. Un changement de rôle contrôlé peut donc interrompre le flux ; Neighbor, RP SET, RPF, état multicast, règles et récepteur doivent ensuite être vérifiés à nouveau.

Les logs sont propres à chaque nœud. En cas de problème HA, sauvegarder les données du nœud actif avant le changement. Une synchronisation hitless de l’état PIM n’est pas présumée.

Cet article de base utilise des interfaces physiques. Sophos cite également RED et GRE comme compatibles PIM. Cela ne confirme pas PIM directement sur des interfaces XFRM, IPsec ou SSL VPN. Une conception multicast chiffrée ou dépendante d’un opérateur nécessite donc une architecture distincte et testée.

Effectuer un rollback sûr

Le retour arrière s’effectue pendant la fenêtre de maintenance :

Arrêter le flux de test et documenter le dernier état fonctionnel ou défectueux.
Désactiver les nouvelles règles firewall multicast.
Désactiver PIM sur les deux firewalls.
Supprimer Dynamic Routing dans la zone de transit uniquement si aucun autre protocole de routage n’en dépend.
Réactiver le Static Multicast Forwarding uniquement si l’état précédent et ses routes sont intégralement documentés.
Vérifier de nouveau l’accès de gestion, les routes unicast et les applications précédemment en production.

Aucun redémarrage du service PIM, commutateur de debug ou commande Advanced Shell non documentée n’est nécessaire pour ce rollback.

Questions fréquentes

PIM-SM remplace-t-il IGMP ou la règle firewall ?

Non. IGMP signale l’intérêt des récepteurs dans le réseau local, PIM-SM relie les routeurs multicast concernés et la règle firewall autorise le flux de données précis entre les zones. Les trois niveaux doivent correspondre à la même conception.

Pourquoi une route unicast influence-t-elle le chemin multicast ?

PIM-SM utilise RPF. À partir de ses informations de routage, le firewall vérifie par quelle interface la source ou le RP serait joignable. Si cette route indique la mauvaise interface, le chemin de retour attendu ne correspond pas et l’état multicast peut rester incorrect ou incomplet.