Sophos Firewall: reflector mDNS para detectar dispositivos entre VLANs

El reflector mDNS en SFOS 23 permite detectar dispositivos entre redes internas y VLANs seleccionadas. Por ejemplo, un cliente puede encontrar un receptor AirPlay en otra VLAN. El reflector transmite consultas de búsqueda y anuncios de servicios, pero no autoriza automáticamente el tráfico de aplicación posterior. La autorización para streaming, impresión o acceso remoto se planifica y comprueba por separado.

El procedimiento breve: en Network > mDNS, activar mDNS reflector, seleccionar de forma específica IP version, Allowed interfaces y Services, y aplicar con Apply. Después se prueban por separado el descubrimiento, el uso real y los límites entre redes que deben seguir bloqueados.

Esta guía describe la interfaz de SFOS 23. La guía existente de SFOS 22 para enrutamiento multicast estático sigue siendo un procedimiento distinto; no sustituye un reflector. La mera disponibilidad de documentación no demuestra el estado de publicación ni la idoneidad de una build concreta del firmware.

Distinguir entre descubrimiento y uso

mDNS, es decir, Multicast DNS, sirve junto con DNS-SD para descubrir servicios locales. Bonjour es el nombre que Apple da a los servicios Zero-Configuration correspondientes. En subredes separadas, esta búsqueda normalmente permanece dentro de cada segmento. El reflector conecta la capa de descubrimiento de las interfaces seleccionadas expresamente, sin convertir las redes en una VLAN común.

Esto tiene dos consecuencias diferentes:

• Un dispositivo puede hacerse visible aunque la conexión con su servicio siga bloqueada. La visibilidad no demuestra que exista una regla de firewall adecuada ni que el streaming funcione.
• Las redes seleccionadas reciben información adicional sobre los servicios ofrecidos. Incluso con el tráfico de aplicación bloqueado, esta visibilidad puede ser indeseable, por ejemplo, entre la red de invitados y la de administración.

Por tanto, Allowed interfaces es un límite de seguridad, no solo una selección técnica. El diálogo define las interfaces participantes, no un par dirigido de origen y destino. No se debe suponer que esto permite únicamente a los clientes de una VLAN ver los dispositivos de la otra. Services limita las categorías de servicios reflejadas; sin embargo, una categoría no autoriza todos los hosts ni todos los puertos de una aplicación.

Las interfaces WAN y VPN no son compatibles. Este ajuste no convierte automáticamente a un cliente VPN remoto en participante del descubrimiento local. Tampoco se admite otro protocolo de búsqueda por el mero hecho de que una aplicación utilice además mDNS.

Requisitos previos y ejemplo limitado

Antes del cambio se necesita:

• Una build de SFOS 23 con Network > mDNS, acceso a WebAdmin y un acceso de administración independiente.
• Interfaces internas ya configuradas, con las VLANs y redes correctamente asignadas. Las zonas e interfaces deben corresponder a la topología real.
• Un cliente y un proveedor de servicios conocido cuya búsqueda mDNS ya funcione dentro del mismo segmento.
• Una decisión sobre qué categorías de servicios pueden ser visibles entre segmentos, así como los puertos de aplicación necesarios según la aplicación y la versión del dispositivo utilizadas.
• Un backup de la configuración y una anotación del estado previo del reflector, la versión IP, las interfaces, las categorías y las reglas de aplicación existentes.

Para una prueba limitada de AirPlay se utilizan, por ejemplo:

• Cliente 10.20.20.50 en la VLAN de empleados 10.20.20.0/24, interfaz del firewall Port2.20, zona LAN.
• Receptor 10.30.30.20 en la VLAN multimedia 10.30.30.0/24, interfaz del firewall Port2.30, zona propia MEDIA.
• IP version: IPv4, porque esta prueba utiliza exclusivamente IPv4.
• Allowed interfaces: solo Port2.20 y Port2.30.
• Services: solo AirPlay.

Las direcciones, los IDs de VLAN, los nombres de interfaz y la zona de ejemplo MEDIA se sustituyen por los de la configuración propia. El reflector selecciona interfaces, no estos dos hosts individuales: otros dispositivos de las interfaces participantes también pueden intervenir en el descubrimiento dentro de las categorías elegidas. Para establecer un límite de confianza más preciso se necesita un diseño de segmentación adecuado, no solo reglas de aplicación más restrictivas.

En este ejemplo quedan excluidas las interfaces de invitados, administración y cualquier otra que no participe. Una primera prueba satisfactoria con dos interfaces es más concluyente que una autorización amplia en la que apenas se pueden relacionar causas y efectos.

Configurar el reflector mDNS

Guardar el estado previo y seleccionar la versión IP

1. En WebAdmin, abrir Network > mDNS y anotar los ajustes existentes. Un reflector desactivado puede conservar una configuración anterior; por ello, antes de activarlo también se debe comprobar la selección guardada.
2. Activar mDNS reflector. El estado predeterminado documentado es Off.
3. En IP version, seleccionar la opción realmente necesaria: IPv4 refleja solo mDNS IPv4, IPv6 solo mDNS IPv6 y Dual ambas versiones.

En el ejemplo se mantiene IPv4. Dual no es una solución general para corregir problemas: amplía el descubrimiento a ambas versiones IP. Si más adelante se utilizan servicios IPv6, también se deben planificar deliberadamente la conectividad y las reglas de aplicación para IPv6, y comprobarlas por separado.

Limitar las interfaces y las categorías de servicios

1. En Allowed interfaces, seleccionar Port2.20 y Port2.30. Solo las interfaces seleccionadas participan en las consultas de búsqueda y los anuncios reflejados; se admite un máximo de 16 interfaces.
2. En Services, seleccionar AirPlay.
3. Antes de aplicar, comprobar que no se haya incluido por error ninguna interfaz de invitados, WAN, VPN o administración en la selección prevista.
4. Hacer clic en Apply. El firewall refleja inmediatamente el tráfico de descubrimiento compatible entre las interfaces seleccionadas.

Además de AirPlay, se pueden seleccionar AirDrop, Apple File Share, Chromecast, IoT Smart Home, Printer, Remote Desktop, Scanner, Sonos y Spotify Connect. La selección se adapta a las necesidades reales. Una categoría de servicios no sustituye la comprobación de si la aplicación concreta tiene otros requisitos además del descubrimiento.

⚠️ Any procesa todas las categorías de servicios mDNS, incluidas las que no aparecen enumeradas individualmente. Esto puede generar tráfico de red adicional y afectar al rendimiento del sistema. También amplía los servicios visibles. No se debe cambiar a Any solo porque falte un dispositivo; primero se comprueban su descubrimiento y la categoría adecuada.

Autorizar el tráfico de aplicación por separado

Para el uso posterior se crea una regla de firewall específica o se comprueba una regla existente que ya sea adecuada. En la prueba, el nombre de la regla es, por ejemplo, AirPlay-Test-Client-zu-Media, el origen es el host 10.20.20.50 en LAN y el destino es el host 10.30.30.20 en MEDIA. Los servicios corresponden a los puertos TCP/UDP confirmados para este dispositivo y esta aplicación; se activa el registro para la validación.

Aquí no se proporciona deliberadamente una lista universal de puertos AirPlay para copiar. Antes de autorizar el tráfico deben estar definidas las funciones del dispositivo y los sentidos de conexión necesarios. La falta de información del fabricante no se suple con Any. Si la aplicación necesita además una conexión iniciada por el proveedor del servicio, esta se justifica por separado y se autoriza de forma restrictiva. La respuesta normal a una conexión existente no es automáticamente un motivo para crear una regla amplia en sentido contrario.

Tampoco tiene sentido configurar, por mera sospecha, una autorización UDP general como sustituto de la configuración del reflector. La selección de descubrimiento y la regla de aplicación resuelven tareas diferentes. Los cambios se limitan a la prueba documentada; no se modifican de paso otras reglas, NAT ni rutas multicast.

Demostrar el éxito mediante tres comprobaciones separadas

1. Descubrimiento en las interfaces seleccionadas

Después de Apply, volver a comprobar la versión IP, la selección de interfaces y las categorías guardadas. A continuación, reiniciar la búsqueda de dispositivos de la aplicación en el cliente de prueba. Se espera encontrar el receptor conocido de la VLAN multimedia, no solo una entrada de una búsqueda anterior.

Si el resultado no está claro, iniciar en Diagnostics > Packet capture una captura breve y limitada en el tiempo. Como filtro BPF para mDNS se puede utilizar:

udp port 5353

El filtro es solo una ayuda para la observación y no modifica ninguna autorización. Para la prueba IPv4 se espera tráfico mDNS con la dirección multicast local 224.0.0.251. Se comparan la interfaz y los timestamps: ¿se origina la búsqueda en la red del cliente y se observa también el tráfico de descubrimiento correspondiente en la interfaz multimedia seleccionada? El contenido de los paquetes y una captura en el cliente ayudan a comprobar si realmente se anuncia el servicio esperado. Un solo paquete o un determinado estado de paquete no demuestran por sí solos que la búsqueda haya funcionado. Packet Capture en Sophos Firewall explica el procedimiento.

2. Utilizar el servicio real

Seleccionar el receptor descubierto e iniciar una prueba breve de AirPlay. El éxito significa que la función deseada funciona en el receptor, no simplemente que aparece su nombre. En el log de la regla o en una captura separada del par de hosts 10.20.20.50 y 10.30.30.20, se comprueban la dirección de destino, los puertos, la dirección de la conexión y la regla correspondiente.

Si el descubrimiento funciona, pero el uso no, la selección del reflector se mantiene inicialmente sin cambios. Ahora se comprueban las reglas de aplicación, los puertos reales, el enrutamiento, los firewalls locales de los dispositivos y la propia aplicación. Ampliar el reflector no corrige un servicio de aplicación bloqueado.

3. Comprobar los límites no autorizados

Mediante una nueva búsqueda en un segmento de prueba excluido, comprobar que el servicio no se hace visible a través de este reflector. Además, verificar que las conexiones no autorizadas siguen bloqueadas. Las cachés existentes y otros gateways de descubrimiento pueden distorsionar el resultado; una entrada visible sin tráfico de red nuevo correspondiente no es prueba suficiente de una reflexión no deseada.

En HA, los ajustes del reflector se sincronizan entre los dispositivos. La función de SFOS 23 también admite el descubrimiento durante el failover. Esto no garantiza sesiones de aplicación sin interrupciones. Se aprovecha una prueba de HA ya planificada para volver a comprobar el descubrimiento y el uso después del cambio de roles; no se provoca un failover en producción únicamente para seguir esta guía.

Delimitar los errores de forma específica

Falta Network > mDNS o falta una interfaz

Comprobar la versión de SFOS instalada y la configuración real de las interfaces. Esta guía requiere la interfaz de SFOS 23. Las interfaces WAN y VPN están excluidas. Si falta una interfaz interna o no se puede guardar una selección, se documentan la build, el tipo de interfaz y el mensaje exacto; no se debe superar el límite de 16 interfaces. No se debe eludir el problema mediante una ruta multicast estática ni mediante un cambio de shell no documentado.

No se encuentra el servicio

Primero comprobar en el segmento local del proveedor si su descubrimiento funciona. Si ya falla allí, los siguientes elementos que se deben investigar son el dispositivo, la aplicación, el aislamiento de clientes WLAN o los filtros de red locales, no el reflector. Si funciona localmente, se comprueban la versión IP, ambas interfaces seleccionadas, la categoría de servicios y el resultado realmente guardado después de Apply.

Después, comparar la captura breve de mDNS en ambos lados. Si la consulta de búsqueda no aparece en la interfaz del cliente, comprobar el cliente y el recorrido de red. Si la consulta está presente, pero no hay un anuncio de servicio adecuado, investigar el proveedor. Si existe un anuncio adecuado, pero no hay descubrimiento en el cliente, comprobar el recorrido de red de vuelta al cliente. Los cambios se realizan de uno en uno y después se repite la misma prueba.

El servicio es visible, pero no funciona

Capturar el tráfico de aplicación por separado e investigar un descarte a partir de los hosts, los puertos y el contexto de regla. Ampliar la autorización solo con valores cuya necesidad esté demostrada, sin abrir todos los servicios entre ambas VLANs. Una dirección anunciada que el cliente no pueda alcanzar también puede impedir el uso; comprobar la dirección de destino real y su ruta de enrutamiento.

Aparecen demasiados servicios o una carga adicional

Comprobar si Services está configurado en Any, si hay categorías no deseadas y si Allowed interfaces incluye segmentos adicionales. Revertir cualquier ampliación involuntaria al estado previo anotado. Si el problema comenzó inmediatamente después de la activación, desactivar el reflector de forma controlada y repetir la misma prueba limitada. No introducir reinicios de servicios ni reflectores adicionales por mera sospecha.

Si el problema persiste, guardar para la escalación la build, la versión IP, las interfaces participantes, las categorías, las direcciones de host anonimizadas, los timestamps y capturas breves de ambos lados. Los datos de clientes y los payloads de paquetes innecesarios no deben incluirse en un ejemplo público de soporte.

Realizar un rollback seguro

1. Finalizar la prueba y documentar el resultado y los últimos ajustes guardados.
2. Si el reflector estaba desactivado anteriormente, volver a desactivarlo en Network > mDNS y aplicar con Apply. Si ya estaba activo, restaurar y aplicar en su lugar la versión IP y la selección de interfaces y categorías anotadas previamente; no desactivar indiscriminadamente otros servicios dependientes.
3. Desactivar únicamente la regla de aplicación añadida para esta prueba o revertir el cambio documentado en una regla existente.
4. Volver a abrir los ajustes y comprobar el descubrimiento, los servicios existentes y las conexiones que deben seguir bloqueadas mediante una nueva búsqueda.

Al desactivarlo, se conserva la configuración del reflector; al volver a activarlo, se utiliza de nuevo la selección anterior. Por tanto, desactivarlo no elimina los límites de confianza guardados. Antes de cualquier reactivación posterior, volver a comprobar las interfaces y las categorías. Las entradas de descubrimiento ya existentes en el cliente pueden seguir apareciendo después del rollback, y una aplicación que ya está en funcionamiento no demuestra que se siga reflejando el nuevo tráfico de descubrimiento.