Configurar y probar multicast estático en Sophos Firewall
Una ruta multicast estática reenvía el flujo de datos de un emisor conocido a un grupo multicast fijo a través de interfaces seleccionadas. Es adecuada, por ejemplo, para un flujo de vídeo, audio o telemetría cuyo origen, grupo y redes de receptores permanecen fijos.
Este procedimiento trata el enrutamiento multicast IPv4 estático. El multicast IPv6 no forma parte de esta guía.
El procedimiento breve es el siguiente:
- Documentar la IP de origen, el grupo multicast, el puerto UDP y las interfaces de entrada y salida.
- En Routing > Static routes, activar Enable multicast forwarding.
- En Manage multicast route > Add, introducir el origen, el grupo y las interfaces.
- Hacer que un receptor real se una al grupo e iniciar el flujo.
- Comprobar la ruta, así como la entrada y la salida, con
mroute showy Packet Capture.
⚠️ Enable multicast forwarding es un ajuste global. Antes de activarlo, se deben inventariar las configuraciones PIM-SM existentes, las rutas multicast estáticas y los flujos que dependen de ellas. El cambio se comprueba primero con un flujo de prueba limitado; si se produce un comportamiento inesperado, se revierte antes de añadir más Destination Interfaces.
Entender multicast, IGMP y la ruta estática
Con unicast, un host envía a una sola dirección de destino. Con multicast, el origen envía una vez a una dirección de grupo y varios receptores pueden unirse al mismo flujo. El firewall no copia el flujo a redes arbitrarias, sino únicamente a las Destination Interfaces indicadas en la ruta multicast.
El ejemplo utiliza la combinación fija del emisor 10.10.10.20 y el grupo 239.10.10.10. Esta combinación se denomina habitualmente Source and Group, abreviada como (S,G). Si la aplicación cambia su IP de origen o el grupo, la ruta deja de coincidir.
IGMP indica en el segmento IPv4 local que un receptor quiere unirse a un grupo multicast o abandonarlo. De este modo, un switch con IGMP Snooping puede enviar el flujo solo a los puertos con receptores interesados. Sin embargo, la ruta estática de Sophos no aprende nuevas Destination Interfaces a partir de IGMP: Port3 permanece configurado de forma fija aunque no haya ningún receptor escuchando en ese momento.
PIM-SM resuelve otra tarea. Crea dinámicamente rutas multicast entre varios routers multicast y requiere un diseño planificado del Rendezvous Point y del enrutamiento unicast. Para un único emisor conocido y unas pocas interfaces de receptores fijas, la ruta estática suele ser más clara. Con varios routers, grupos cambiantes o muchas rutas multicast, PIM-SM requiere un diseño específico.
Una ruta multicast estática tampoco es una ruta unicast estática normal. No utiliza un next hop clásico y aparece en un área propia.
mDNS es otro caso de uso
mDNS para Bonjour, AirPlay o muchas búsquedas de Chromecast utiliza la dirección link-local 224.0.0.251. Sophos permite grupos de 224.0.2.0 a 239.255.255.255 en una ruta multicast estática. mDNS queda fuera de este rango y los routers no lo reenvían como tráfico multicast normal.
Por tanto, esta guía no sustituye un reflector mDNS ni un Discovery Gateway. Un flujo multimedia puede funcionar mediante multicast mientras que la detección automática de dispositivos entre VLANs sigue sin funcionar.
A partir de SFOS 23, esta tarea independiente de descubrimiento se configura mediante el reflector mDNS en Network > mDNS. La selección de interfaces internas y categorías de servicios, así como la autorización separada del tráfico de aplicación, forman parte de este procedimiento propio; esto no sustituye la ruta multicast estática descrita aquí.
Planificar la topología de ejemplo
El ejemplo utiliza estos valores:
- Emisor:
10.10.10.20 - Source Interface:
Port2 - Source Zone:
DMZ - Grupo multicast:
239.10.10.10 - Servicio de aplicación: UDP
5000 - Destination Interface:
Port3 - Destination Zone:
LAN - Red de receptores:
10.20.20.0/24 - Receptor de prueba:
10.20.20.50
10.10.10.20 y 10.20.20.0/24 son valores privados de ejemplo. 239.10.10.10 pertenece al rango multicast de ámbito administrativo y es adecuado para un ejemplo local controlado. En el entorno real, se deben sustituir conjuntamente el origen, el grupo, el puerto y las interfaces por los valores de la aplicación y la topología. El grupo no debe cambiarse de forma arbitraria: el emisor y los receptores deben utilizar la misma dirección y el mismo servicio.
La aplicación también debe enviar con una TTL suficiente. En el enrutamiento normal, la TTL se reduce en uno en cada hop. Si la aplicación envía con TTL 1, el flujo no alcanza otro segmento mientras esté activa la reducción de TTL.
Antes del cambio, deben estar claros estos puntos:
- El firewall funciona en Gateway Mode.
- El emisor alcanza
Port2y los receptores están detrás dePort3. - La aplicación receptora puede unirse realmente al grupo
239.10.10.10en UDP5000. - Están documentados PIM-SM, otras rutas multicast y sus dependencias.
- Se conocen los switches, las VLANs y los ajustes de IGMP Snooping en la red de receptores.
- Existe un backup de la configuración y un acceso de administración independiente.
Configurar zonas e interfaces en Sophos Firewall explica cómo se relacionan las interfaces, VLANs y zonas.
Crear la ruta multicast estática
Activar Multicast Forwarding
- En WebAdmin, abrir Routing > Static routes.
- En Multicast forwarding setting, seleccionar Enable multicast forwarding.
- Hacer clic en Apply y después en OK.
Si la opción no se puede activar, se comprueba la configuración multicast existente. Una configuración PIM-SM existente no se modifica de forma improvisada: la ayuda actual de SFOS 22 no documenta en las páginas correspondientes una regla general de coexistencia, por lo que son determinantes el comportamiento de la build instalada y el diseño de red aprobado.
Introducir el origen, el grupo y las interfaces
- En Manage multicast route, hacer clic en Add.
- En Source IPv4 address, introducir
10.10.10.20. - Seleccionar
Port2como Source interface. - En Multicast IPv4 address, introducir
239.10.10.10. - Seleccionar
Port3como Destination interface. - Guardar con Save.
WebAdmin puede guardar varias Destination Interfaces en una ruta. Sin embargo, cada interfaz adicional amplía el área a la que se reenvía el flujo. Solo debe seleccionarse si realmente hay receptores y la autorización de seguridad también es adecuada. Source Interface y Destination Interface no pueden ser idénticas.
Utilizar la CLI como vía alternativa controlada
En Device Console, la ruta es 3. Route Configuration > 2. Configure Multicast Routing. Multicast Forwarding debe estar activo antes de añadir la primera ruta. Puede activarse en Gateway Mode y Transparent Mode, pero las rutas Multicast estáticas solo se configuran en Gateway Mode. En la opción 1, este comando activa el reenvío global:
enable multicast-forwarding
⚠️ Según Sophos, los comandos incompletos de Device Console pueden hacer que
access_serverdeje de responder. Por ello, se debe completar la sintaxis con?o Tab para la build instalada y ejecutar el comando completo solo después.
En 2. Configure Static-routes se puede crear una ruta entre dos interfaces estáticas y comprobarla de inmediato:
mroute add input-interface Port2 source-ip 10.10.10.20 dest-ip 239.10.10.10 output-interface Port3
mroute show
La CLI requiere una entrada mroute add separada para cada interfaz de salida. Solo ofrece interfaces estáticas, mientras que WebAdmin también puede mostrar interfaces dinámicas como DHCP y PPPoE. Las interfaces de entrada y salida deben ser diferentes; una interfaz no Ethernet como IPsec0 no pertenece a esta forma basada en puertos.
Para retirar de forma específica una ruta física, Sophos indica los valores por posición. Primero se comprueban los nombres de interfaz con mroute show:
mroute del Port2 10.10.10.20 239.10.10.10 Port3
mroute show
Sophos publica formas input-tunnel y output-tunnel separadas para rutas IPsec y GRE, pero los ejemplos no mantienen una escritura uniforme. La finalización de comandos de la versión SFOS instalada es la referencia y no se debe pegar un ejemplo público sin comprobarlo.
No presuponer la autorización de seguridad
La guía oficial de SFOS 22 para crear una ruta multicast estática no indica que sea necesaria una regla de firewall o NAT adicional. Por ello, en este ejemplo no se crea de forma preventiva una regla amplia Any. Si la build instalada o una política existente requiere aun así una coincidencia adicional, se comprueba en Packet Capture mediante el estado real del paquete.
Si el firewall muestra un descarte causado por una política, no se hacen suposiciones: primero se registran el origen 10.10.10.20, el grupo 239.10.10.10, UDP 5000, las zonas implicadas y el contexto de regla mostrado. Solo después de confirmarlo para la build utilizada se limita la autorización exactamente a estos valores y se activa su registro. Configurar reglas de Sophos Firewall de forma segura explica la estructura general de las reglas.
Probar el flujo de datos de forma controlada
Una ruta guardada no demuestra que el receptor reciba el flujo. La validación sigue el paquete desde la aplicación hasta el cliente:
En
10.20.20.50, iniciar la aplicación receptora y unirse al grupo239.10.10.10en UDP5000.Iniciar un flujo de prueba claramente limitado desde
10.10.10.20y anotar la hora de inicio y la duración prevista.En Diagnostics > Packet capture, filtrar con esta expresión BPF:
src host 10.10.10.20 and dst host 239.10.10.10 and udp port 5000En la lista de paquetes, comprobar si el flujo entra por
Port2y aparece enPort3con el estado Forwarded. Si se produce un descarte, se anotan el estado mostrado y el contexto de regla sin ampliar una regla por mera sospecha.En el receptor, comprobar que llegan paquetes y que la aplicación procesa el contenido.
Utilizar Packet Capture en Sophos Firewall explica el procedimiento de Packet Capture con interfaz, contexto de regla y estado.
La tabla de enrutamiento multicast estático también se puede mostrar en modo de solo lectura en la Device Console. La ruta es 3. Route Configuration > 2. Configure Multicast Routing > 2. Configure Static-routes:
mroute show
La salida debe mostrar el origen, el grupo y las interfaces de entrada y salida esperados. El comando no modifica la configuración.
Para una solución de problemas más profunda, la documentación actual de SFOS 22 indica mrouting.log. En la Advanced Shell, solo se leen las últimas entradas:
tail -n 200 /log/mrouting.log
En Archivos de servicio y log de Sophos Firewall se enumeran otros archivos y asignaciones de servicios.
Delimitar errores según el síntoma
La ruta no se puede activar o guardar
- Comprobar la IP de origen, el rango del grupo y las interfaces. Se permiten grupos de
224.0.2.0a239.255.255.255. - Source Interface y Destination Interface no pueden ser idénticas.
- Si ya existe una combinación
(S,G), comparar también la Destination Interface. Para varias salidas, la CLI exige una entrada propia para cada una con el mismo origen y grupo.
El flujo entra, pero no se reenvía
- ¿Coinciden exactamente la IP de origen real y el grupo con la ruta?
- ¿Muestra
mroute showlas interfaces esperadas? - ¿Muestra la captura Forwarded o un descarte con un contexto de regla que pueda analizarse?
- ¿Está
Port3realmente seleccionado como Destination Interface?
El flujo sale del firewall, pero no llega al receptor
- Comprobar la TTL del emisor. No cambiar parámetros globales de enrutamiento por mera sospecha.
- Comprobar la VLAN, el puerto del switch e IGMP Snooping en la red de receptores.
- Asegurarse de que
10.20.20.50se une al grupo y puerto UDP correctos. - Comprobar el firewall local del host y la aplicación del receptor.
- Comparar una captura en el receptor o el puerto del switch con los timestamps de SFOS.
La detección de dispositivos no funciona, pero el flujo sí
Los protocolos de descubrimiento como mDNS son link-local y esta ruta estática no los refleja. El flujo de datos real y la detección de dispositivos se deben comprobar por separado.
Tratar VPN y HA por separado
Sophos no admite multicast mediante SSL VPN. Las rutas multicast estáticas mediante IPsec o un túnel GRE validado previamente son posibles y utilizan formas CLI propias. Para IPsec, Sophos también exige un host unicast explícito con /32 en la configuración VPN. Los ejemplos documentados públicamente contienen varias notaciones inconsistentes, por lo que no deben copiarse sin verificar en un firewall de producción.
La versión del firmware también es importante cuando multicast atraviesa un túnel VPN. Solución de problemas IPsec para NC-180433 trata los bloqueos repetidos del firewall que coinciden con este tráfico. El problema está corregido en SFOS 22.0 MR2 Build 546; una pérdida normal de paquetes o la ausencia del flujo no demuestran este caso concreto.
En HA Active-Active, el tráfico multicast no se distribuye entre ambos nodos. Sophos también excluye multicast del Session Failover. Por ello, cabe esperar una interrupción del flujo cuando cambien los roles. Antes del failover se guardan la captura y los timestamps del nodo que estaba activo; después se vuelven a comprobar la ruta, la entrada, la salida y el receptor en el nuevo nodo activo.
Realizar un rollback seguro
Antes del rollback, se documentan la ruta, las interfaces y los valores de prueba anteriores. Después:
- Detener el flujo de prueba.
- Eliminar la ruta multicast estática en WebAdmin.
- Desactivar Enable multicast forwarding solo si ninguna otra ruta multicast estática depende de esta opción.
- Volver a comprobar el estado anterior de las aplicaciones y redes afectadas.
Si la ruta de ejemplo se creó mediante la CLI, se puede eliminar con el comando mroute del mostrado anteriormente, documentado oficialmente para interfaces físicas, y comprobar con mroute show. No se incluye ningún ejemplo de eliminación sin confirmar para rutas de túnel.
Preguntas frecuentes
¿Cuándo es mejor una ruta multicast estática que PIM-SM?
La ruta estática suele ser más sencilla cuando el emisor, el grupo y unas pocas Destination Interfaces permanecen fijos. PIM-SM es adecuado para varios routers multicast, rutas dinámicas y muchos grupos cambiantes.