Ir al contenido
Avanet

Configurar y probar multicast estático en Sophos Firewall

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:

  1. Documentar la IP de origen, el grupo multicast, el puerto UDP y las interfaces de entrada y salida.
  2. En Routing > Static routes, activar Enable multicast forwarding.
  3. En Manage multicast route > Add, introducir el origen, el grupo y las interfaces.
  4. Crear una regla de firewall IPv4 estricta y con logging para el flujo de datos.
  5. Hacer que un receptor real se una al grupo e iniciar el flujo.
  6. Comprobar la ruta, Rule ID, entrada y salida con mroute show, Log Viewer y Packet Capture.

⚠️ Static Multicast Forwarding y PIM-SM no se pueden configurar simultáneamente en Sophos Firewall. Para Static Multicast Forwarding, PIM debe estar desactivado. Antes de cambiar, se debe comprobar si PIM-SM u otra ruta multicast estática ya se utilizan en producción.

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.

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 Port2 y los receptores están detrás de Port3.
  • La aplicación receptora puede unirse realmente al grupo 239.10.10.10 en UDP 5000.
  • 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

  1. En WebAdmin, abrir Routing > Static routes.
  2. En Multicast forwarding setting, seleccionar Enable multicast forwarding.
  3. Hacer clic en Apply y después en OK.

Si la opción no se puede activar, se debe comprobar primero si PIM-SM está activo. Ambos métodos no se pueden configurar en paralelo. PIM-SM no debe desactivarse sin documentar antes sus vecinos, grupos y receptores existentes.

Introducir el origen, el grupo y las interfaces

  1. En Manage multicast route, hacer clic en Add.
  2. En Source IPv4 address, introducir 10.10.10.20.
  3. Seleccionar Port2 como Source interface.
  4. En Multicast IPv4 address, introducir 239.10.10.10.
  5. Seleccionar Port3 como Destination interface.
  6. 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 regla de seguridad también se aplica. Source Interface y Destination Interface no pueden ser idénticas.

Limitar estrictamente la regla de firewall

La ruta multicast determina el camino, pero no permite por sí sola el flujo de datos. Para reenviar de DMZ a LAN, se crea una regla de firewall IPv4 específica:

  • Rule name: DMZ_to_LAN_Multicast_5000
  • Action: Accept
  • Log firewall traffic: activado
  • Source zone: DMZ
  • Source network: Host 10.10.10.20
  • Destination zone: LAN
  • Destination network: Host 239.10.10.10
  • Services: un servicio UDP propio con Destination Port 5000

El destino es el grupo multicast, no la red de receptores 10.20.20.0/24. La regla se limita al emisor real, al grupo efectivo y al servicio necesario. En este ejemplo no se utiliza una regla amplia Any ni una autorización general de IGMP o PIM.

La regla es la configuración de destino estricta para esta topología de ejemplo; su match real se debe confirmar en la versión de SFOS instalada mediante la Rule ID esperada. Si aparece Rule 0, no se amplía la regla sin control, sino que se analiza con Log Viewer y Packet Capture.

En este ejemplo no se utiliza SNAT para conservar el origen y la asignación (S,G). Aun así, se comprueba si alguna regla NAT existente produce un match inesperado. 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:

  1. En 10.20.20.50, iniciar la aplicación receptora y unirse al grupo 239.10.10.10 en UDP 5000.

  2. Iniciar un flujo de prueba claramente limitado desde 10.10.10.20 y anotar la hora de inicio y la duración prevista.

  3. En Log Viewer, comprobar si coincide DMZ_to_LAN_Multicast_5000 o la Rule ID esperada.

  4. 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 5000

  5. En la lista de paquetes, comprobar si el flujo entra por Port2 y aparece en Port3 con el estado Forwarded.

  6. 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, Rule ID 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 si PIM-SM sigue activo. Static Multicast Forwarding y PIM-SM no se pueden configurar simultáneamente.
  • Comprobar la IP de origen, el rango del grupo y las interfaces. Se permiten grupos de 224.0.2.0 a 239.255.255.255.
  • Source Interface y Destination Interface no pueden ser idénticas.
  • Si ya existe una ruta, comprobar si la misma combinación (S,G) ya está configurada.

El flujo entra, pero no se reenvía

  • ¿Coinciden exactamente la IP de origen real y el grupo con la ruta?
  • ¿Muestra mroute show las interfaces esperadas?
  • ¿Coincide la regla de firewall prevista o muestra la captura otra Rule ID o Rule 0?
  • ¿Está Port3 realmente seleccionado como Destination Interface?
  • ¿Modifica una regla NAT el origen de forma inesperada?

El flujo sale del firewall, pero no llega al receptor

  • Comprobar la TTL del emisor y el ajuste global multicast-decrement-ttl. No cambiar el ajuste de forma generalizada.
  • Comprobar la VLAN, el puerto del switch e IGMP Snooping en la red de receptores.
  • Asegurarse de que 10.20.20.50 se 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 un clúster HA, multicast no se distribuye entre ambos nodos. Tras un failover planificado, se vuelven a comprobar la ruta, Rule ID, entrada, salida y receptor. Sophos no documenta ninguna garantía de failover multicast sin interrupciones; por tanto, la prueba debe realizarse en una ventana de mantenimiento. Los logs y Packet Captures se guardan en el nodo activo en ese momento.

Realizar un rollback seguro

Antes del rollback, se documentan la ruta, el nombre de la regla y los valores de prueba anteriores. Después:

  1. Detener el flujo de prueba.
  2. Desactivar la nueva regla de firewall.
  3. Eliminar la ruta multicast estática en WebAdmin.
  4. Desactivar Enable multicast forwarding solo si ninguna otra ruta multicast estática depende de esta opción.
  5. Volver a comprobar el estado anterior de las aplicaciones y redes afectadas.

No se necesita un comando CLI de eliminación para este rollback. Así se mantiene un rollback trazable y se evita la sintaxis de eliminación documentada públicamente de forma inconsistente.

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.

¿Permite encontrar dispositivos Bonjour, AirPlay o Chromecast entre VLANs?

No. Esta ruta por sí sola no basta. mDNS utiliza 224.0.0.251, es link-local y necesita una función específica de reflexión o gateway para el reenvío entre VLANs.

¿Por qué se necesita una regla de firewall adicional?

La ruta multicast indica dónde se reenvía el flujo. La regla de firewall sigue determinando si este origen, grupo y servicio UDP concretos pueden pasar entre las zonas participantes.