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.
Créer une règle firewall IPv4 restrictive et journalisée pour le flux de données.
Faire rejoindre le groupe par un récepteur réel et démarrer le flux.
Vérifier la route, la Rule ID, l’entrée et la sortie avec mroute show, Log Viewer et Packet Capture.

⚠️ Static Multicast Forwarding et PIM-SM ne peuvent pas être configurés simultanément sur Sophos Firewall. PIM doit être désactivé pour Static Multicast Forwarding. Avant de basculer, vérifier si PIM-SM ou une autre route multicast statique est déjà utilisé en production.

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 d’abord si PIM-SM est actif. Les deux méthodes ne peuvent pas être configurées en parallèle. Ne pas désactiver PIM-SM sans avoir préalablement documenté ses voisins, groupes et récepteurs existants.

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.

Restreindre précisément la règle firewall

La route multicast détermine le chemin, mais elle n’autorise pas à elle seule le flux de données. Pour le transfert de DMZ vers LAN, créer une règle firewall IPv4 dédiée :

Rule name: DMZ_to_LAN_Multicast_5000
Action: Accept
Log firewall traffic: activé
Source zone: DMZ
Source network: Host 10.10.10.20
Destination zone: LAN
Destination network: Host 239.10.10.10
Services: un service UDP dédié avec Destination Port 5000

La destination est le groupe multicast, et non le réseau de récepteurs 10.20.20.0/24. La règle est limitée à l’émetteur réel, au groupe effectif et au service nécessaire. Cet exemple n’utilise aucune règle large Any ni autorisation générale d’IGMP ou de PIM.

La règle représente la configuration cible restrictive pour cette topologie d’exemple ; sa correspondance réelle doit être confirmée sur la version SFOS utilisée grâce à la Rule ID attendue. Si Rule 0 apparaît, ne pas élargir la règle sans contrôle, mais l’analyser avec Log Viewer et Packet Capture.

Cet exemple ne prévoit aucun SNAT afin de conserver la source et l’association (S,G). Les règles NAT existantes sont néanmoins vérifiées pour détecter une correspondance inattendue. 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.
Dans Log Viewer, vérifier si DMZ_to_LAN_Multicast_5000 ou la Rule ID attendue correspond.
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.
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, la Rule ID 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 si PIM-SM est encore actif. Static Multicast Forwarding et PIM-SM ne peuvent pas être configurés simultanément.
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 une route existe déjà, vérifier si la même combinaison (S,G) est déjà configurée.

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 règle firewall prévue correspond-elle, ou la capture affiche-t-elle une autre Rule ID ou Rule 0 ?
Port3 est-il réellement sélectionné comme Destination Interface ?
Une règle NAT modifie-t-elle la source de manière inattendue ?

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

Vérifier la TTL de l’émetteur et le paramètre global multicast-decrement-ttl. Ne pas modifier ce paramètre de manière générale.
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.

Dans un cluster HA, le multicast n’est pas réparti entre les deux nœuds. Après un basculement planifié, vérifier à nouveau la route, la Rule ID, l’entrée, la sortie et le récepteur. Sophos ne documente aucune garantie de basculement multicast sans interruption ; le test doit donc avoir lieu dans une fenêtre de maintenance. Enregistrer les logs et les Packet Captures sur le nœud actuellement actif.

Effectuer un rollback sûr

Avant le rollback, documenter la route, le nom de la règle et les valeurs de test précédentes. Ensuite :

Arrêter le flux de test.
Désactiver la nouvelle règle firewall.
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.

Aucune commande CLI de suppression n’est nécessaire pour ce rollback. Le rollback reste ainsi traçable et évite la syntaxe de suppression documentée publiquement de manière incohérente.

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.

Cette route permet-elle de trouver des appareils Bonjour, AirPlay ou Chromecast entre des VLANs ?

Pas à elle seule. mDNS utilise 224.0.0.251, est link-local et nécessite une fonction de réflexion ou de passerelle dédiée pour le transfert entre VLANs.

Pourquoi une règle firewall supplémentaire est-elle nécessaire ?

La route multicast indique où le flux est transféré. La règle firewall détermine toujours si cette source, ce groupe et ce service UDP précis peuvent passer entre les zones concernées.