Configurer et tester le multicast statique sur Sophos Firewall

Une route multicast statique transfère le flux de données d’un émetteur connu vers un groupe multicast fixe par des interfaces sélectionnées. Elle convient, par exemple, à un flux vidéo, audio ou de télémétrie dont la source, le groupe et les réseaux de récepteurs restent fixes.

Cette procédure traite le routage multicast IPv4 statique. Le multicast IPv6 n’est pas couvert par ce guide.

La procédure courte est la suivante :

Documenter l’IP source, le groupe multicast, le port UDP ainsi que les interfaces d’entrée et de sortie.
Sous Routing > Static routes, activer Enable multicast forwarding.
Sous Manage multicast route > Add, saisir la source, le groupe et les interfaces.
Faire rejoindre le groupe par un récepteur réel et démarrer le flux.
Vérifier la route ainsi que l’entrée et la sortie avec mroute show et Packet Capture.

⚠️ Enable multicast forwarding est un paramètre global. Avant de l’activer, inventorier les configurations PIM-SM existantes, les routes multicast statiques et les flux qui en dépendent. Tester d’abord la modification avec un flux de test limité ; en cas de comportement inattendu, l’annuler avant d’ajouter d’autres Destination Interfaces.

Comprendre le multicast, IGMP et la route statique

En unicast, un hôte envoie vers une seule adresse de destination. En multicast, la source envoie une fois vers une adresse de groupe, et plusieurs récepteurs peuvent rejoindre le même flux. Le firewall ne copie pas le flux vers des réseaux quelconques, mais uniquement vers les Destination Interfaces indiquées dans la route multicast.

L’exemple utilise la combinaison fixe de l’émetteur 10.10.10.20 et du groupe 239.10.10.10. Cette combinaison est généralement appelée Source and Group, abrégée (S,G). Si l’application change son IP source ou son groupe, la route ne correspond plus.

IGMP indique dans le segment IPv4 local qu’un récepteur souhaite rejoindre ou quitter un groupe multicast. Un switch avec IGMP Snooping peut ainsi envoyer le flux uniquement vers les ports auxquels des récepteurs intéressés sont raccordés. La route Sophos statique n’en déduit cependant aucune nouvelle Destination Interface : Port3 reste configuré de façon fixe même lorsqu’aucun récepteur n’y écoute actuellement.

PIM-SM répond à un autre besoin. Il construit dynamiquement des chemins multicast entre plusieurs routeurs multicast et nécessite une conception planifiée du Rendezvous Point et du routage unicast. Pour un seul émetteur connu et quelques interfaces de récepteurs fixes, la route statique est généralement plus claire. Avec plusieurs routeurs, des groupes changeants ou de nombreux chemins multicast, PIM-SM nécessite une conception dédiée.

Une route multicast statique n’est pas non plus une route unicast statique normale. Elle n’utilise aucun Next Hop classique et apparaît dans une zone distincte.

mDNS correspond à un autre cas d’usage

mDNS pour Bonjour, AirPlay ou de nombreuses recherches Chromecast utilise l’adresse link-local 224.0.0.251. Sophos autorise les groupes de 224.0.2.0 à 239.255.255.255 dans une route multicast statique. mDNS se trouve hors de cette plage et n’est pas transféré par les routeurs comme un trafic multicast normal.

Ce guide ne remplace donc pas un réflecteur mDNS ni une passerelle de découverte. Un flux multimédia peut fonctionner en multicast alors que la découverte automatique des appareils entre les VLANs ne fonctionne toujours pas.

Planifier la topologie d’exemple

L’exemple utilise les valeurs suivantes :

Émetteur : 10.10.10.20
Source Interface: Port2
Source Zone: DMZ
Groupe multicast : 239.10.10.10
Service applicatif : UDP 5000
Destination Interface: Port3
Destination Zone: LAN
Réseau de récepteurs : 10.20.20.0/24
Récepteur de test : 10.20.20.50

10.10.10.20 et 10.20.20.0/24 sont des valeurs d’exemple privées. 239.10.10.10 appartient à la plage multicast à portée administrative et convient à un exemple local contrôlé. Dans l’environnement réel, remplacer ensemble la source, le groupe, le port et les interfaces par les valeurs de l’application et de la topologie. Le groupe ne doit pas être modifié arbitrairement : l’émetteur et les récepteurs doivent utiliser la même adresse et le même service.

L’application doit également envoyer avec une TTL suffisante. En routage normal, la TTL est réduite d’une unité à chaque hop. Si l’application envoie avec TTL 1, le flux ne peut pas atteindre un autre segment lorsque la décrémentation de TTL est active.

Avant la modification, les points suivants doivent être établis :

Le firewall fonctionne en Gateway Mode.
L’émetteur atteint Port2 et les récepteurs se trouvent derrière Port3.
L’application réceptrice peut réellement rejoindre le groupe 239.10.10.10 sur UDP 5000.
Le PIM-SM existant, les autres routes multicast et leurs dépendances sont documentés.
Les switches, les VLANs et les paramètres IGMP Snooping du réseau de récepteurs sont connus.
Un backup de la configuration et un accès de gestion indépendant sont disponibles.

Configurer les zones et interfaces Sophos Firewall explique le lien entre les interfaces, les VLANs et les zones.

Créer la route multicast statique

Activer Multicast Forwarding

Dans WebAdmin, ouvrir Routing > Static routes.
Sous Multicast forwarding setting, sélectionner Enable multicast forwarding.
Cliquer sur Apply, puis sur OK.

Si l’option ne peut pas être activée, vérifier la configuration multicast existante. Une configuration PIM-SM existante ne doit pas être modifiée sans planification : les pages concernées de l’aide actuelle de SFOS 22 ne documentent aucune règle générale de coexistence. Le comportement de la build installée et la conception réseau approuvée sont donc déterminants.

Saisir la source, le groupe et les interfaces

Sous Manage multicast route, cliquer sur Add.
Sous Source IPv4 address, saisir 10.10.10.20.
Sélectionner Port2 comme Source interface.
Sous Multicast IPv4 address, saisir 239.10.10.10.
Sélectionner Port3 comme Destination interface.
Enregistrer avec Save.

WebAdmin peut enregistrer plusieurs Destination Interfaces dans une route. Chaque interface supplémentaire étend toutefois la zone vers laquelle le flux est transféré. Elle ne doit être sélectionnée que si des récepteurs y sont réellement présents et si l’autorisation de sécurité correspondante est également prévue. Source Interface et Destination Interface ne doivent pas être identiques.

Utiliser la CLI comme solution de repli contrôlée

Dans Device Console, le chemin est 3. Route Configuration > 2. Configure Multicast Routing. Multicast Forwarding doit être actif avant l’ajout de la première route. Il peut être activé en Gateway Mode et en Transparent Mode, mais les routes Multicast statiques ne peuvent être configurées qu’en Gateway Mode. Sous l’option 1, cette commande active le transfert global :

enable multicast-forwarding

⚠️ Selon Sophos, des commandes Device Console incomplètes peuvent empêcher access_server de répondre. Compléter la syntaxe avec ? ou Tab en fonction de la build installée, puis exécuter la commande complète seulement après cette vérification.

Sous 2. Configure Static-routes, une route entre deux interfaces statiques peut être ajoutée puis vérifiée immédiatement :

mroute add input-interface Port2 source-ip 10.10.10.20 dest-ip 239.10.10.10 output-interface Port3
mroute show

La CLI nécessite une entrée mroute add distincte pour chaque interface de sortie. Elle propose uniquement les interfaces statiques, tandis que WebAdmin peut également afficher des interfaces dynamiques comme DHCP et PPPoE. Les interfaces d’entrée et de sortie doivent être différentes ; une interface non Ethernet telle que IPsec0 n’appartient pas à cette forme basée sur les ports.

Pour supprimer de façon ciblée une route physique, Sophos indique les valeurs par position. Vérifier d’abord les noms des interfaces avec mroute show :

mroute del Port2 10.10.10.20 239.10.10.10 Port3
mroute show

Sophos publie des formes input-tunnel et output-tunnel distinctes pour les routes IPsec et GRE, mais les exemples n’utilisent pas partout la même écriture. L’autocomplétion des commandes de la version SFOS installée fait référence ; ne pas coller un exemple public sans vérification.

Ne pas présumer qu’une autorisation de sécurité est nécessaire

La procédure officielle de SFOS 22 pour créer une route multicast statique ne mentionne aucune règle firewall ou NAT supplémentaire. Cet exemple ne crée donc pas, par précaution, de règle large Any. Packet Capture permet de déterminer, à partir de l’état réel des paquets, si la build installée ou une policy existante exige néanmoins une correspondance supplémentaire.

Si le firewall affiche un drop lié à une policy, ne pas procéder par supposition. Relever d’abord la source 10.10.10.20, le groupe 239.10.10.10, UDP 5000, les zones concernées et le contexte de règle affiché. Ce n’est qu’après confirmation pour la build utilisée qu’une autorisation doit être limitée précisément à ces valeurs et journalisée. Configurer les règles Sophos Firewall de manière sûre explique la structure générale des règles.

Tester le flux de données de manière contrôlée

Une route enregistrée ne prouve pas que le récepteur reçoit le flux. La validation suit le paquet de l’application jusqu’au client :

Sur 10.20.20.50, démarrer l’application réceptrice et rejoindre le groupe 239.10.10.10 sur UDP 5000.
Démarrer un flux de test clairement limité depuis 10.10.10.20, puis noter son heure de début et sa durée attendue.
Sous Diagnostics > Packet capture, filtrer avec cette expression BPF :
```
src host 10.10.10.20 and dst host 239.10.10.10 and udp port 5000
```
Dans la liste des paquets, vérifier que le flux arrive sur Port2 et apparaît sur Port3 avec l’état Forwarded. En cas de drop, noter l’état affiché et le contexte de règle sans élargir une règle sur la base d’une supposition.
Sur le récepteur, vérifier que les paquets arrivent et que l’application traite le contenu.

Utiliser Packet Capture sur Sophos Firewall explique la procédure Packet Capture avec l’interface, le contexte de règle et l’état.

La table de routage multicast statique peut également être affichée en lecture seule dans la Device Console. Le chemin est 3. Route Configuration > 2. Configure Multicast Routing > 2. Configure Static-routes :

mroute show

La sortie doit afficher la source, le groupe ainsi que les interfaces d’entrée et de sortie attendus. La commande ne modifie pas la configuration.

Pour un dépannage plus approfondi, la documentation actuelle de SFOS 22 indique mrouting.log. Dans l’Advanced Shell, lire uniquement les dernières entrées :

tail -n 200 /log/mrouting.log

Les autres fichiers et associations de services figurent dans Fichiers de service et logs Sophos Firewall.

Délimiter l’erreur selon le symptôme

La route ne peut pas être activée ou enregistrée

Vérifier l’IP source, la plage du groupe et les interfaces. Les groupes autorisés vont de 224.0.2.0 à 239.255.255.255.
Source Interface et Destination Interface ne doivent pas être identiques.
Si la combinaison (S,G) existe déjà, comparer également la Destination Interface. Pour plusieurs sorties, la CLI exige une entrée distincte avec la même source et le même groupe pour chacune d’elles.

Le flux arrive, mais n’est pas transféré

L’IP source réelle et le groupe correspondent-ils exactement à la route ?
mroute show affiche-t-il les interfaces attendues ?
La capture affiche-t-elle Forwarded ou un drop accompagné d’un contexte de règle exploitable ?
Port3 est-il réellement sélectionné comme Destination Interface ?

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

Vérifier la TTL de l’émetteur. Ne pas modifier les paramètres globaux de routage sur la base d’une supposition.
Vérifier le VLAN, le port du switch et IGMP Snooping dans le réseau de récepteurs.
Vérifier que 10.20.20.50 rejoint le groupe et le port UDP corrects.
Vérifier le firewall local de l’hôte et l’application sur le récepteur.
Comparer une capture sur le récepteur ou le port du switch avec les horodatages SFOS.

La découverte des appareils échoue, mais le flux fonctionne

Les protocoles de découverte tels que mDNS sont link-local et ne sont pas reflétés par cette route statique. Tester séparément le flux de données réel et la découverte des appareils.

Traiter séparément le VPN et la HA

Sophos ne prend pas en charge le multicast via SSL VPN. Les routes multicast statiques via IPsec ou un tunnel GRE préalablement validé sont possibles et utilisent des formes CLI spécifiques. Pour IPsec, Sophos exige également un hôte unicast explicite avec /32 dans la configuration VPN. Les exemples documentés publiquement contiennent plusieurs notations incohérentes ; ils ne doivent donc pas être copiés sans vérification dans un firewall de production.

La version du firmware est également importante lorsque le multicast traverse un tunnel VPN. Le dépannage IPsec pour NC-180433 couvre les plantages répétés du firewall qui coïncident avec ce trafic. Le problème est corrigé dans SFOS 22.0 MR2 Build 546 ; une perte normale de paquets ou un flux absent ne prouve pas ce cas particulier.

En HA Active-Active, le multicast n’est pas réparti entre les deux nœuds. Sophos exclut également le multicast du Session Failover. Une interruption du flux est donc à prévoir lors d’un changement de rôle. Avant le failover, enregistrer la capture et les horodatages sur le nœud actif jusque-là ; vérifier ensuite à nouveau la route, l’entrée, la sortie et le récepteur sur le nouveau nœud actif.

Effectuer un rollback sûr

Avant le rollback, documenter la route, les interfaces et les valeurs de test précédentes. Ensuite :

Arrêter le flux de test.
Supprimer la route multicast statique dans WebAdmin.
Désactiver Enable multicast forwarding uniquement si aucune autre route multicast statique n’en dépend.
Vérifier à nouveau l’état précédent des applications et réseaux concernés.

Si la route d’exemple a plutôt été créée via la CLI, la supprimer avec la commande mroute del officiellement documentée ci-dessus pour les interfaces physiques, puis contrôler le résultat avec mroute show. Aucun exemple de suppression non confirmé n’est repris pour les routes via tunnel.

Questions fréquentes

Quand une route multicast statique est-elle préférable à PIM-SM ?

La route statique est généralement plus simple lorsque l’émetteur, le groupe et quelques Destination Interfaces restent fixes. PIM-SM convient à plusieurs routeurs multicast, à des chemins dynamiques et à de nombreux groupes changeants.