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.
Inventorier les routes multicast statiques existantes et planifier la migration pendant une fenêtre de maintenance.
Sous Routing > Multicast (PIM-SM), activer PIM sur les interfaces IPv4 concernées.
Configurer le RP statique prévu et la plage de groupes sur tous les routeurs PIM.
Contrôler le flux de données multicast avec des règles firewall IPv4 restrictives et journalisées.
Vérifier ensemble l’adhésion au groupe, l’application UDP, le voisin PIM, le RP SET, l’état multicast, la Rule ID et le chemin des paquets.

⚠️ Le passage de routes multicast statiques à PIM-SM modifie le chemin multicast en production. Il faut donc documenter les routes, groupes et récepteurs existants ainsi que le plan de rollback. L’aide de SFOS 22 décrit séparément le Static Multicast Forwarding et PIM-SM, mais ne formule aucune règle générale de coexistence ou d’exclusion. Vérifier le build effectivement utilisé pendant une fenêtre de maintenance plutôt que de supposer un fonctionnement en parallèle.

Cet article traite du routage multicast IPv4 dynamique avec un RP statique. SFOS 22 prend en charge PIM version 2 et PIM-SM ; Sophos documente BSR pour la sélection dynamique du RP. L’exemple reste volontairement basé sur un RP statique. Candidate RP et BSR sont seulement remis en contexte plus loin.

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 exige au moins une interface PIM dotée d’une adresse IPv4. Elle cite comme compatibles les interfaces physiques, RED et les interfaces GRE ; 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 utilisés sans test 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.

Inventorier le Static Multicast Forwarding existant

Sous Routing > Static routes, documenter les routes multicast existantes, les applications dépendantes et les interfaces de destination. L’aide de SFOS 22 n’établit pas si Enable multicast forwarding et PIM-SM peuvent être configurés en parallèle sur chaque build. Ne modifier l’état existant que pendant la fenêtre de maintenance et consigner la réaction de l’interface.

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. Si SFOS impose de désactiver le forwarding statique avant d’activer PIM, cette étape fait partie de la migration planifiée et ne constitue pas une règle générale du produit supposée ici sans preuve.

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
Enregistrer. Seuls le voisin PIM, l’affectation du RP et l’état multicast permettront de confirmer le fonctionnement une fois la configuration terminée.

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. Sur le firewall B, la table de routage unicast doit indiquer Port4 et 10.255.0.1 comme chemin attendu ; sur le firewall A, la RP IP est une adresse de l’une de ses propres interfaces. 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 la configuration. Si SFOS refuse d’activer PIM, consulter le message de l’interface et l’état actuel de Enable multicast forwarding. Ne modifier cette option que si l’interface confirme réellement le conflit sur le build utilisé et si le plan de retour arrière est documenté.

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, jusqu’à huit indications de groupes ou de réseaux, une priorité de 1 à 255 avec la valeur par défaut 1 et un intervalle Advertisement de 30 à 180 secondes avec la valeur par défaut 60.

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. Les règles firewall générales de SFOS contrôlent le trafic entre zones et réseaux. Le modèle à deux règles ci-dessous est donc une configuration Avanet strictement limitée à cette topologie, et non un modèle PIM obligatoire documenté par Sophos.

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. Dans Packet Capture, examiner ensemble la Rule ID, le Status, la Reason ainsi que les interfaces d’entrée et de sortie. L’aide de SFOS 22 ne documente aucune signification générale pour la Rule ID 0 ; cette valeur seule ne prouve donc pas l’absence de correspondance avec une règle.

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. Le système d’exploitation doit rejoindre le groupe 239.10.10.10 et l’application doit en plus écouter 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 ; les PIM timers et les flag bits apportent un contexte de diagnostic supplémentaire.
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 système d’exploitation du récepteur a rejoint le bon groupe et que l’application écoute sur UDP 5000.
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 et les rapports ne sont pas synchronisés entre les nœuds HA. En cas de problème HA, sauvegarder les données du nœud qui traitait le trafic avant le changement. L’aide HA officielle ne documente aucun transfert d’état propre à PIM ; cet article n’en déduit aucune affirmation plus générale sur la synchronisation.

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.
Si le Static Multicast Forwarding a été désactivé pendant la migration, restaurer l’état précédent documenté avec ses routes.
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.