Sophos Firewall : réflecteur mDNS pour la découverte des appareils entre VLANs

Le réflecteur mDNS dans SFOS 23 permet de découvrir les appareils entre des réseaux internes et des VLANs sélectionnés. Un client peut ainsi, par exemple, trouver un récepteur AirPlay dans un autre VLAN. Le réflecteur transmet les requêtes de découverte et les annonces de services, mais pas automatiquement le trafic applicatif qui suit. L’autorisation pour le streaming, l’impression ou l’accès à distance doit être planifiée et vérifiée séparément.

La procédure rapide : sous Network > mDNS, activer mDNS reflector, sélectionner précisément IP version, Allowed interfaces et Services, puis appliquer avec Apply. Tester ensuite séparément la découverte, l’utilisation réelle et les frontières réseau qui doivent rester bloquées.

Ce guide décrit l’interface de SFOS 23. Le guide existant pour SFOS 22 sur le routage multicast statique reste une procédure différente ; il ne remplace pas un réflecteur. La disponibilité d’une documentation ne prouve à elle seule ni le statut de publication ni l’adéquation d’une build de firmware donnée.

Distinguer la découverte de l’utilisation

mDNS, ou Multicast DNS, sert avec DNS-SD à la découverte locale des services. Bonjour est le nom utilisé par Apple pour les services Zero Configuration correspondants. Dans des sous-réseaux distincts, cette découverte reste normalement limitée à chaque segment. Le réflecteur relie la couche de découverte des interfaces explicitement sélectionnées, sans réunir les réseaux dans un même VLAN.

Cela a deux conséquences distinctes :

• Un appareil peut devenir visible alors que la connexion à son service est encore bloquée. Sa visibilité ne prouve ni l’existence d’une règle firewall adaptée ni le bon fonctionnement du streaming.
• Les réseaux sélectionnés reçoivent des informations supplémentaires sur les services proposés. Même si le trafic applicatif est bloqué, cette visibilité peut être indésirable, par exemple entre le réseau invité et le réseau d’administration.

Allowed interfaces constitue donc une frontière de sécurité, et pas seulement une sélection technique. La boîte de dialogue définit les interfaces participantes, et non une paire orientée de source vers destination. Il ne faut pas supposer que seuls les clients d’un VLAN verront les appareils de l’autre. Services limite les catégories de services reflétées ; une catégorie n’autorise toutefois pas tous les hôtes ou tous les ports d’une application.

Les interfaces WAN et VPN ne sont pas prises en charge. Ce paramètre n’intègre pas automatiquement un client VPN distant à la découverte locale. Un autre protocole de découverte n’est pas non plus pris en charge du seul fait qu’une application utilise également mDNS.

Prérequis et exemple limité

Avant la modification, il faut disposer des éléments suivants :

• Une build SFOS 23 avec Network > mDNS, un accès WebAdmin et un accès de gestion indépendant.
• Des interfaces internes déjà configurées, avec les VLANs et les réseaux correctement associés. Les zones et interfaces doivent correspondre à la topologie réelle.
• Un client et un fournisseur de service connu dont la découverte mDNS fonctionne déjà dans le même segment.
• Une décision sur les catégories de services qui peuvent être visibles entre segments, ainsi que les ports applicatifs nécessaires selon l’application et la version de l’appareil utilisées.
• Un backup de la configuration et une note indiquant l’état précédent du réflecteur, la version IP, les interfaces, les catégories et les règles applicatives existantes.

Pour un test AirPlay limité, utiliser par exemple :

• Le client 10.20.20.50 dans le VLAN des collaborateurs 10.20.20.0/24, avec l’interface firewall Port2.20 et la zone LAN.
• Le récepteur 10.30.30.20 dans le VLAN multimédia 10.30.30.0/24, avec l’interface firewall Port2.30 et sa propre zone MEDIA.
• IP version: IPv4, car ce test utilise exclusivement IPv4.
• Allowed interfaces: uniquement Port2.20 et Port2.30.
• Services: uniquement AirPlay.

Remplacer les adresses, les identifiants de VLAN, les noms d’interfaces et la zone d’exemple MEDIA par les valeurs de votre configuration. Le réflecteur sélectionne des interfaces, et non ces deux hôtes individuels : d’autres appareils sur les interfaces participantes peuvent également prendre part à la découverte dans les catégories sélectionnées. Pour établir une frontière de confiance plus fine, il faut une conception de segmentation adaptée, et pas simplement des règles applicatives plus restrictives.

Les interfaces invitées, de gestion et les autres interfaces non concernées restent exclues de cet exemple. Un premier test réussi avec deux interfaces est plus probant qu’une autorisation large dans laquelle les causes et les effets deviennent difficiles à distinguer.

Configurer le réflecteur mDNS

Consigner l’état initial et choisir la version IP

1. Dans WebAdmin, ouvrir Network > mDNS et consigner les paramètres existants. Un réflecteur désactivé peut conserver une ancienne configuration ; vérifier donc également la sélection enregistrée avant de l’activer.
2. Activer mDNS reflector. L’état par défaut documenté est Off.
3. Sous IP version, choisir la variante réellement nécessaire : IPv4 reflète uniquement le mDNS IPv4, IPv6 uniquement le mDNS IPv6, et Dual les deux versions.

Pour cet exemple, conserver IPv4. Dual n’est pas une option de réparation universelle : elle étend la découverte aux deux versions IP. Si des services IPv6 sont utilisés ultérieurement, leur accessibilité et les règles applicatives IPv6 doivent également être planifiées explicitement et vérifiées séparément.

Limiter les interfaces et les catégories de services

1. Sous Allowed interfaces, sélectionner Port2.20 et Port2.30. Seules les interfaces sélectionnées participent aux requêtes de découverte et aux annonces reflétées ; au maximum 16 interfaces sont prises en charge.
2. Sous Services, sélectionner AirPlay.
3. Avant d’appliquer, vérifier qu’aucune interface invitée, WAN, VPN ou de gestion n’a été incluse par erreur dans la sélection prévue.
4. Cliquer sur Apply. Le firewall reflète immédiatement le trafic de découverte pris en charge entre les interfaces sélectionnées.

Outre AirPlay, les catégories AirDrop, Apple File Share, Chromecast, IoT Smart Home, Printer, Remote Desktop, Scanner, Sonos et Spotify Connect sont disponibles. Adapter la sélection aux besoins réels. Une catégorie de services ne dispense pas de vérifier si l’application concernée a d’autres prérequis en plus de la découverte.

⚠️ Any traite toutes les catégories de services mDNS, y compris celles qui ne sont pas répertoriées individuellement. Cela peut générer du trafic réseau supplémentaire et affecter les performances du système. Cette option étend également les services visibles. Ne pas passer à Any simplement parce qu’un appareil manque ; vérifier d’abord sa découverte et la catégorie appropriée.

Autoriser séparément le trafic applicatif

Pour l’utilisation ultérieure, créer une règle firewall ciblée ou vérifier une règle existante adaptée. Dans le test, le nom de la règle est par exemple AirPlay-Test-Client-zu-Media, la source est l’hôte 10.20.20.50 dans LAN et la destination est l’hôte 10.30.30.20 dans MEDIA. Les Services correspondent aux ports TCP/UDP confirmés pour cet appareil et cette application ; activer la journalisation pour la validation.

Aucune liste universelle de ports AirPlay à copier n’est volontairement fournie ici. Les fonctions des appareils et les sens de connexion nécessaires doivent être établis avant l’autorisation. L’absence d’indication du fabricant ne doit pas être compensée par Any. Si l’application nécessite également une connexion initiée par le fournisseur de service, la justifier séparément et l’autoriser de manière restrictive. La réponse normale à une connexion existante ne justifie pas automatiquement une règle inverse large.

Il n’est pas davantage pertinent de créer, sur la base d’une supposition, une autorisation UDP générale pour remplacer la configuration du réflecteur. La sélection de découverte et la règle applicative remplissent des fonctions différentes. Les modifications restent limitées au test documenté ; les autres règles, le NAT et les routes multicast ne sont pas modifiés au passage.

Démontrer le résultat avec trois vérifications distinctes

1. Découverte sur les interfaces sélectionnées

Après Apply, vérifier à nouveau la version IP, la sélection d’interfaces et les catégories enregistrées. Relancer ensuite la recherche d’appareils de l’application sur le client de test. Le résultat attendu est le récepteur connu du VLAN multimédia, et non simplement une entrée issue d’une recherche précédente.

Si le résultat est incertain, démarrer une courte capture limitée dans le temps sous Diagnostics > Packet capture. Le filtre BPF suivant convient pour mDNS :

udp port 5353

Ce filtre est uniquement une aide à l’observation et ne modifie aucune autorisation. Pour le test IPv4, on attend du trafic mDNS avec l’adresse multicast locale 224.0.0.251. Comparer les interfaces et les horodatages : la recherche est-elle générée dans le réseau du client et observe-t-on le trafic de découverte correspondant sur l’interface multimédia sélectionnée ? Le contenu des paquets et une capture côté client permettent de vérifier si le service attendu est réellement annoncé. Un paquet isolé ou un état de paquet particulier ne prouve pas, à lui seul, que la découverte a réussi. Packet Capture sur Sophos Firewall explique la procédure.

2. Utiliser le service réel

Sélectionner le récepteur découvert et lancer un court test AirPlay. La réussite signifie que la fonction souhaitée fonctionne sur le récepteur, et pas simplement que son nom apparaît. Dans le journal de la règle ou dans une capture distincte de la paire d’hôtes 10.20.20.50 et 10.30.30.20, vérifier l’adresse de destination, les ports, le sens de connexion et la règle correspondante.

Si la découverte réussit mais que l’utilisation échoue, laisser dans un premier temps la sélection du réflecteur inchangée. Vérifier alors les règles applicatives, les ports réels, le routage, les firewalls locaux des appareils et l’application elle-même. Élargir le réflecteur ne corrige pas un service applicatif bloqué.

3. Contrôler les frontières non autorisées

Effectuer une nouvelle recherche dans un segment de test exclu pour vérifier que le service n’y devient pas visible par l’intermédiaire de ce réflecteur. Tester également que les connexions non autorisées restent bloquées. Les caches existants et d’autres passerelles de découverte peuvent fausser le résultat ; un affichage sans nouveau trafic réseau correspondant ne constitue pas une preuve suffisante d’une réflexion indésirable.

En HA, les paramètres du réflecteur sont synchronisés entre les appareils. La fonction de SFOS 23 prend également en charge la découverte lors d’un failover. Cela ne garantit pas des sessions applicatives sans interruption. Profiter d’un test HA déjà prévu pour vérifier à nouveau la découverte et l’utilisation après le changement de rôle ; ne pas déclencher de failover en production uniquement pour ce guide.

Cibler le dépannage

Network > mDNS ou une interface n’apparaît pas

Vérifier la version SFOS installée et la configuration réelle des interfaces. Ce guide suppose l’interface de SFOS 23. Les interfaces WAN et VPN sont exclues. Si une interface interne manque ou si une sélection ne peut pas être enregistrée, documenter la build, le type d’interface et le message exact ; la limite de 16 interfaces ne doit pas être dépassée. Ne pas contourner cette situation avec une route multicast statique ou une modification Shell non documentée.

Le service n’est pas trouvé

Vérifier d’abord dans le segment local du fournisseur si sa découverte fonctionne. Si elle échoue déjà à cet endroit, les prochains éléments à examiner sont l’appareil, l’application, l’isolation des clients Wi-Fi ou les filtres réseau locaux, et non le réflecteur. Si elle fonctionne localement, contrôler la version IP, les deux interfaces sélectionnées, la catégorie de services et le résultat réellement enregistré après Apply.

Comparer ensuite les courtes captures mDNS des deux côtés. Si la requête de découverte est déjà absente sur l’interface du client, vérifier le client et le chemin réseau. Si la requête est présente mais qu’aucune annonce de service correspondante n’apparaît, examiner le fournisseur. Si une annonce correspondante est présente mais que la découverte échoue sur le client, vérifier le chemin réseau de retour vers le client. Effectuer les modifications une par une, puis répéter le même test après chacune.

Le service est visible, mais ne fonctionne pas

Capturer séparément le trafic applicatif et examiner un drop à partir des hôtes, des ports et du contexte de règle. Compléter l’autorisation uniquement avec les valeurs dont la nécessité est démontrée, sans ouvrir tous les services entre les deux VLANs. Une adresse annoncée mais inaccessible au client peut également empêcher l’utilisation ; vérifier l’adresse de destination réelle et son chemin de routage.

Trop de services ou une charge supplémentaire apparaissent

Vérifier si Services est défini sur Any, si des catégories indésirables sont sélectionnées et si Allowed interfaces inclut des segments supplémentaires. Annuler toute extension involontaire en rétablissant l’état initial consigné. Si la perturbation a commencé immédiatement après l’activation, désactiver le réflecteur de manière contrôlée et répéter le même test limité. Ne pas redémarrer des services ni ajouter des réflecteurs sur la base d’une supposition.

Si le problème persiste, conserver pour l’escalade la build, la version IP, les interfaces concernées, les catégories, les adresses d’hôtes anonymisées, les horodatages et de courtes captures des deux côtés. Les données des clients et les charges utiles de paquets inutiles n’ont pas leur place dans un exemple public destiné au support.

Effectuer un retour arrière sûr

1. Terminer le test et documenter le résultat ainsi que les derniers paramètres enregistrés.
2. Si le réflecteur était auparavant désactivé, le désactiver à nouveau sous Network > mDNS et appliquer avec Apply. S’il était déjà actif, rétablir plutôt la version IP, la sélection d’interfaces et de catégories précédemment consignées, puis appliquer ; ne pas désactiver globalement les autres services qui en dépendent.
3. Désactiver uniquement la règle applicative ajoutée pour ce test, ou annuler la modification documentée d’une règle existante.
4. Ouvrir à nouveau les paramètres et vérifier la découverte, les services préexistants ainsi que les connexions qui doivent rester bloquées, en effectuant une nouvelle recherche.

La configuration du réflecteur est conservée lors de sa désactivation ; lors de sa réactivation, la sélection précédente est réutilisée. La désactivation ne supprime donc pas les frontières de confiance enregistrées. Vérifier à nouveau les interfaces et les catégories avant toute réactivation ultérieure. Les entrées de découverte déjà présentes sur le client peuvent encore être affichées après le retour arrière, et une application déjà en cours d’exécution ne prouve pas que les nouvelles requêtes de découverte continuent d’être reflétées.