Configurar y validar PIM-SM en Sophos Firewall

PIM-SM es adecuado cuando el tráfico multicast atraviesa varios routers y los receptores se unen a grupos o los abandonan dinámicamente. En lugar de mantener una ruta fija para cada origen e interfaz de salida, PIM-SM construye la ruta multicast necesaria mediante un Rendezvous Point, o RP.

El procedimiento breve es el siguiente:

Preparar una copia de seguridad y un acceso de gestión independiente; después, documentar el origen, el grupo, el servicio UDP, los routers y las redes de receptores.
Comprobar en cada router la accesibilidad unicast al RP y a la red de origen.
Inventariar las rutas multicast estáticas existentes y planificar la migración para una ventana de mantenimiento.
En Routing > Multicast (PIM-SM), activar PIM en las interfaces IPv4 implicadas.
Configurar el RP estático previsto y el rango de grupos en todos los routers PIM.
Controlar el flujo de datos multicast mediante reglas de firewall IPv4 restrictivas y con registro.
Comprobar conjuntamente la unión al grupo, la aplicación UDP, el vecino PIM, RP SET, el estado multicast, Rule ID y la ruta de los paquetes.

⚠️ El cambio de rutas multicast estáticas a PIM-SM modifica la ruta multicast de producción. Por tanto, se deben documentar las rutas, los grupos y los receptores existentes, además del plan de rollback. La ayuda de SFOS 22 describe Static Multicast Forwarding y PIM-SM por separado, pero no establece una regla general de coexistencia o exclusión. Compruebe la versión que se utiliza realmente durante una ventana de mantenimiento en lugar de dar por sentado que ambos pueden funcionar en paralelo.

Este artículo trata el enrutamiento multicast IPv4 dinámico con un RP estático. SFOS 22 admite PIM versión 2 y PIM-SM; Sophos documenta BSR para la selección dinámica del RP. El ejemplo utiliza deliberadamente un RP estático. Candidate RP y BSR solo se contextualizan más adelante.

Cuándo PIM-SM es la opción adecuada

PIM-SM resulta especialmente útil cuando intervienen varios routers multicast, los receptores se encuentran en redes distintas o las pertenencias a grupos cambian con frecuencia. Los routers solo crean estado donde existe un emisor o un receptor interesado.

Para un único emisor conocido y unas pocas interfaces de salida permanentemente fijas, una ruta multicast estática suele ser más sencilla. No necesita RP ni vecindad PIM. PIM-SM no es una opción mejor para la misma instalación pequeña, sino un modelo operativo diferente.

Además, PIM-SM no sustituye ni al enrutamiento unicast ni a las reglas de firewall:

El enrutamiento unicast determina en qué dirección son accesibles el origen y el RP.
PIM-SM utiliza esa información para construir el árbol de distribución multicast entre routers.
IGMP indica en la red local de receptores qué hosts desean recibir un grupo.
Las reglas de firewall permiten o bloquean el flujo de datos multicast real entre zonas.

Entender IGMP, RP y RPF

Un receptor envía en la red IPv4 local un informe de pertenencia IGMP para su grupo. El último router multicast traduce este interés en un PIM Join en dirección al RP. El RP es el punto de encuentro común mediante el cual emisores y receptores se encuentran inicialmente. Según el estado que se establezca, la ruta de datos puede cambiar posteriormente a un árbol de origen más corto; por tanto, el RP no tiene que reenviar de forma permanente todos los paquetes de datos.

En la tabla multicast, (*,G) representa el estado compartido de un grupo con independencia de un origen concreto. En cambio, (S,G) representa el estado para un origen específico S y un grupo G. En el ejemplo, es (10.10.10.20, 239.10.10.10).

El mecanismo de control decisivo se denomina Reverse Path Forwarding, o RPF. Para un paquete procedente del origen 10.10.10.20, el firewall comprueba por qué interfaz alcanzaría ese origen según la tabla de enrutamiento. Si el flujo multicast llega por otra interfaz, la ruta inversa no coincide y el estado o el flujo de datos pueden fallar.

PIM es independiente del protocolo de enrutamiento unicast utilizado, pero no de unas rutas unicast operativas. Las rutas estáticas, OSPF o BGP pueden proporcionar la ruta RPF. Para el siguiente ejemplo bastan rutas unicast estáticas; en dominios de enrutamiento más grandes, OSPF puede proporcionar dinámicamente la misma base.

Planificar la topología de ejemplo

El ejemplo conecta un emisor detrás del firewall A con un receptor detrás del firewall B:

Emisor: 10.10.10.20
Red de origen en el firewall A: 10.10.10.0/24, interfaz Port2, zona DMZ
Tránsito del firewall A: 10.255.0.1/30, interfaz Port4, zona PIM-Transit
Tránsito del firewall B: 10.255.0.2/30, interfaz Port4, zona PIM-Transit
Red de receptores en el firewall B: 10.20.20.0/24, interfaz Port3, zona LAN
Receptor de prueba: 10.20.20.50
Grupo multicast: 239.10.10.10
Servicio de la aplicación: UDP 5000
RP estático: 10.255.0.1
Rango de grupos del RP: 239.10.10.0/24

Las direcciones son valores privados de ejemplo. El origen, la red de receptores, la red de tránsito, el grupo y el servicio se sustituyen conjuntamente por los valores de la aplicación real. En este ejemplo, el RP 10.255.0.1 se encuentra en el firewall A y todos los routers PIM deben poder acceder a él mediante unicast.

El rango de grupos 239.10.10.0/24 es deliberadamente más restrictivo que *. Un asterisco asigna todos los grupos al RP y solo se debe utilizar si todo el dominio PIM está planificado de ese modo. Sophos documenta un máximo de ocho entradas de grupo o red por RP.

Las rutas unicast deben estar operativas antes de configurar PIM. El firewall A recibe una ruta a 10.20.20.0/24 mediante 10.255.0.2; el firewall B, una ruta a 10.10.10.0/24 mediante 10.255.0.1. Para RPF es especialmente importante la ruta de regreso del firewall B al origen. Por tanto, en Diagnostics > Tools > Route lookup, una consulta de 10.10.10.20 debe señalar a Port4 y al siguiente salto esperado. Estas rutas unicast no sustituyen el árbol de distribución PIM.

Configurar zonas e interfaces de Sophos Firewall explica cómo separar correctamente las interfaces y zonas para un tránsito de este tipo.

Preparar PIM-SM de forma segura

Antes de la ventana de mantenimiento se registran los siguientes puntos:

Las IP de tránsito y las rutas unicast se han probado en ambas direcciones.
Se conocen el origen, el grupo, el puerto UDP y la aplicación receptora.
El RP estático y su rango de grupos están documentados de forma idéntica para todos los routers.
Se han inventariado las rutas multicast estáticas existentes y Enable multicast forwarding.
Se dispone de una copia de seguridad de la configuración y de acceso de gestión independiente.
Los switches de la red de receptores utilizan IGMP Snooping solo con una función de querier aclarada y operativa.

La documentación actual de Sophos exige al menos una interfaz PIM con una dirección IPv4. Enumera como compatibles las interfaces físicas, RED y las interfaces GRE; se excluyen las interfaces Alias, PPPoE y Cellular WAN. Otros tipos de interfaces, como XFRM, no se confirman expresamente en la página de PIM y, por tanto, no deben utilizarse sin pruebas en esta configuración básica.

Comprobar Dynamic Routing de forma selectiva

Los mensajes PIM pertenecen al plano de control del firewall. La ayuda general de SFOS agrupa los protocolos de enrutamiento en Administration > Device access > Dynamic Routing; sin embargo, la página actual de PIM no indica expresamente esta dependencia.

Si no se establece ninguna vecindad PIM, se debe comprobar si Dynamic Routing tiene que estar permitido en la zona del vecino real. En el ejemplo, la zona propia PIM-Transit solo contiene la red de tránsito entre ambos firewalls. Si esta autorización es necesaria para la instalación, se activa en ambos dispositivos exclusivamente en esa zona.

La autorización de la matriz se aplica a toda la zona. Si la misma zona contiene otras redes que no son de confianza, la casilla permanece desactivada y una Local Service ACL Exception estricta permite Dynamic Routing únicamente desde los vecinos previstos. Una excepción adicional no restringe una autorización de zona que ya esté activa.

Este nivel de Device Access está destinado al tráfico de control de enrutamiento. Si la versión instalada requiere esta autorización para PIM, no afecta al flujo reenviado ni sustituye su regla de firewall. Proteger Device Access en Sophos Firewall explica ambos niveles de acceso.

Inventariar el Static Multicast Forwarding existente

En Routing > Static routes, se documentan las rutas multicast existentes, las aplicaciones dependientes y las interfaces de destino. La ayuda de SFOS 22 no confirma si Enable multicast forwarding y PIM-SM pueden configurarse en paralelo en todas las versiones. Por tanto, el estado existente solo se modifica durante la ventana de mantenimiento y se registra la respuesta de la interfaz.

No se deben eliminar preventivamente las rutas multicast estáticas existentes. Se conservan como plantilla de rollback documentada hasta que PIM-SM se haya validado por completo. Si SFOS exige desactivar el forwarding estático antes de activar PIM, este paso forma parte de la migración planificada y no constituye una regla general del producto que aquí se presuponga sin pruebas.

Configurar PIM-SM

Los siguientes pasos se realizan en el firewall A y en el firewall B.

Activar PIM y las interfaces implicadas

Abrir Routing > Multicast (PIM-SM).
Activar Enable PIM.
En PIM-enabled interface, seleccionar solo las interfaces IPv4 que intervienen en la ruta multicast:
- Firewall A: Port2 y Port4
- Firewall B: Port4 y Port3
Guardar. Solo después de completar la configuración, el vecino PIM, la asignación del RP y el estado multicast permiten confirmar si la instalación funciona.

PIM no se activa de forma general en todas las interfaces LAN o WAN. Cada interfaz adicional amplía el plano de control y puede permitir nuevos vecinos o rutas multicast.

Configurar el RP estático y el rango de grupos

En RP settings, se activa la opción y se introduce la misma asignación estática en ambos firewalls:

RP IP: 10.255.0.1
Multicast group: 239.10.10.0/24

La RP IP es una dirección unicast. En el firewall B, la tabla de enrutamiento unicast debe mostrar Port4 y 10.255.0.1 como la ruta prevista; en el firewall A, la RP IP es una dirección de una interfaz propia. Guardar un valor no es suficiente: en Routing > Information > PIM-SM > RP SET, el grupo debe aparecer posteriormente asignado a este RP.

Guardar la configuración. Si SFOS no permite activar PIM, comprobar el mensaje de la interfaz y el estado actual de Enable multicast forwarding. Esta opción solo se modifica si la interfaz confirma realmente el conflicto en la versión utilizada y se ha documentado el plan de reversión.

Cuándo es apropiado Candidate RP

Candidate RP es adecuado para un dominio PIM existente en el que ya se hayan planificado la función BSR y el procedimiento de selección de RP. Para ello, SFOS proporciona una IP de interfaz como Candidate RP IP, hasta ocho entradas de grupo o red, una prioridad de 1 a 255 con el valor predeterminado 1 y un intervalo de anuncio de 30 a 180 segundos con el valor predeterminado 60.

Sin embargo, configurar Candidate RP por sí solo no convierte automáticamente el firewall en un BSR operativo ni garantiza la selección de RP deseada. Sophos no documenta en WebAdmin una configuración completa del Bootstrap Router. Por tanto, Candidate RP solo se utiliza cuando se conoce la función BSR y se puede comprobar la asignación resultante entre grupos y RP en RP SET. Para este ejemplo manejable, Static RP resulta más fácil de entender.

Crear reglas de firewall para el flujo de datos

La vecindad PIM no proporciona una autorización de seguridad general. Las reglas generales de firewall de SFOS controlan el tráfico entre zonas y redes. Por tanto, el siguiente modelo de dos reglas es una configuración de Avanet estrictamente limitada a esta topología, no una plantilla PIM obligatoria documentada por Sophos.

La configuración prevista en el firewall A es la siguiente:

Rule name: DMZ_to_PIM_Multicast_5000
Source zone: DMZ
Source network: Host 10.10.10.20
Destination zone: PIM-Transit
Destination network: Host 239.10.10.10
Services: un servicio UDP específico con Destination Port 5000
Action: Accept
Log firewall traffic: activado

En el firewall B, se crea una segunda regla de PIM-Transit a LAN con el mismo origen, grupo y servicio UDP. Para la prueba no se utiliza SNAT, de modo que se conserven el origen y (S,G).

Las reglas se aplican al flujo de datos multicast. Los PIM Hellos y los informes de pertenencia IGMP no se mezclan en una regla amplia Any. En Packet Capture, se evalúan conjuntamente Rule ID, el estado, el motivo y las interfaces entrante y saliente. La ayuda de SFOS 22 no documenta un significado general para Rule ID 0; por tanto, este valor por sí solo no demuestra que ninguna regla haya coincidido.

Configurar reglas seguras en Sophos Firewall explica el procedimiento general.

Validar PIM-SM desde el vecino hasta el receptor

Una vecindad PIM visible solo es la primera parte de la validación:

En Routing > Information > PIM-SM > Interface table, el otro firewall debe aparecer como vecino en la interfaz de tránsito.
En RP SET, 239.10.10.0/24 debe señalar a 10.255.0.1.
En 10.20.20.50, iniciar la aplicación receptora. El sistema operativo debe unirse al grupo 239.10.10.10 y la aplicación debe escuchar además en UDP 5000.
Iniciar un flujo de prueba de duración limitada desde 10.10.10.20.
En Multicasting routing table, buscar el estado (*,G) o (S,G) del grupo. Las interfaces entrante y saliente deben coincidir con la topología; los PIM timers y los flag bits aportan contexto adicional para el diagnóstico.
Comprobar en Log Viewer la Rule ID esperada en ambos firewalls.
En Diagnostics > Packet capture, comprobar con el siguiente filtro BPF:
```
src host 10.10.10.20 and dst host 239.10.10.10 and udp port 5000
```
El flujo debe entrar en el firewall A por Port2 y salir por Port4. En el firewall B, debe recibirse por Port4 y reenviarse por Port3. Después se comprueba el contenido real en el receptor.

Utilizar Packet Capture en Sophos Firewall explica el procedimiento de Packet Capture con interfaz, Rule ID, estado y motivo.

Durante una prueba limitada, también se pueden utilizar los siguientes filtros BPF para el tráfico de control:

ip proto 103

103 representa PIM. IGMP utiliza el protocolo IP 2:

ip proto 2

Los filtros muestran si hay paquetes PIM e IGMP. Por sí solos no demuestran que el RP sea correcto ni que el flujo de datos funcione.

En la Advanced Shell, pimd.log proporciona contexto adicional. Los siguientes comandos solo leen datos:

tail -n 200 /log/pimd.log
grep '239.10.10.10' /log/pimd.log | tail -n 100

Un resultado vacío de grep no demuestra un error; el estado actual en WebAdmin y la ruta real de los paquetes siguen siendo decisivos. Archivos de servicio y log de Sophos Firewall explica otros archivos de enrutamiento y log.

Delimitar errores según el síntoma

No aparece ningún vecino PIM

Comprobar la accesibilidad directa entre las IP de tránsito 10.255.0.1 y 10.255.0.2.
Comprobar que Port4 esté seleccionado como PIM-enabled interface en ambos firewalls.
Comprobar Dynamic Routing en la zona de tránsito correcta o en la Local Service ACL Exception correspondiente.
Utilizar ip proto 103 para comprobar si los paquetes PIM llegan a la interfaz de tránsito y la abandonan.
Asegurarse de que se utilice un tipo de interfaz documentado por Sophos para PIM.

El vecino está presente, pero RP SET falta o es incorrecto

Comparar carácter por carácter la RP IP y el rango de grupos en todos los routers.
Comprobar la accesibilidad unicast a 10.255.0.1.
Con Candidate RP, aclarar primero la función BSR real. Una candidatura configurada por sí sola no es suficiente.
No ampliar el rango a * hasta saber por qué no se asigna el grupo concreto.

RP SET es correcto, pero no se crea ningún estado multicast

Comprobar si el sistema operativo del receptor se ha unido al grupo correcto y si la aplicación escucha en UDP 5000.
Utilizar ip proto 2 para buscar IGMP Reports y Queries en la red de receptores.
Con IGMP Snooping, comprobar la función de querier en la VLAN. No modificar los temporizadores IGMP sin una causa demostrada; el procedimiento básico no requiere ajustarlos.
Comprobar si el emisor transmite realmente a 239.10.10.10:5000.

Hay estado, pero la interfaz entrante es incorrecta

Ejecutar Route Lookup para el origen 10.10.10.20 y el RP 10.255.0.1 en cada firewall.
Comprobar las rutas estáticas, OSPF, SD-WAN y VPN por si existe una ruta mejor inesperada.
No modificar la Route Precedence global hasta demostrar la ruta RPF incorrecta mediante la tabla de enrutamiento y un capture.
Documentar por separado las rutas de retorno asimétricas y las conexiones paralelas.

El flujo sale del firewall, pero no llega al receptor

Comprobar Rule ID, el estado y la interfaz saliente en ambos firewalls.
Comprobar el puerto del switch, la VLAN e IGMP Snooping en la red de receptores.
Comprobar el firewall local del host y la aplicación receptora.
Comparar un capture en el receptor o el puerto del switch con las marcas de tiempo de SFOS.

Tener en cuenta HA y las limitaciones de interfaces

En HA Active-Active, el tráfico multicast no se distribuye entre ambos nodos. Las sesiones UDP, broadcast y multicast no se conservan durante un failover. Por tanto, un cambio controlado de funciones puede interrumpir el flujo; después se vuelven a comprobar el vecino, RP SET, RPF, el estado multicast, las reglas y el receptor.

Los logs y los informes no se sincronizan entre los nodos HA. En caso de un problema de HA, se guardan los datos del nodo que procesaba el tráfico antes del cambio. La ayuda oficial de HA no documenta una transferencia de estado específica de PIM; el artículo no deduce de ello ninguna afirmación más amplia sobre la sincronización.

Este artículo básico utiliza interfaces físicas. Sophos también enumera RED y GRE como compatibles con PIM. Esto no confirma PIM directamente en interfaces XFRM, IPsec o SSL VPN. Por tanto, un diseño multicast cifrado o dependiente de un proveedor requiere una arquitectura separada y probada.

Realizar un rollback seguro

El rollback se realiza durante la ventana de mantenimiento:

Detener el flujo de prueba y documentar el último estado operativo o fallido.
Desactivar las reglas de firewall multicast nuevas.
Desactivar PIM en ambos firewalls.
Eliminar Dynamic Routing de la zona de tránsito solo si ningún otro protocolo de enrutamiento depende de él.
Si se desactivó Static Multicast Forwarding durante la migración, restaurar el estado anterior documentado junto con sus rutas.
Volver a comprobar el acceso de gestión, las rutas unicast y las aplicaciones que funcionaban anteriormente.

Para este rollback no se necesitan reinicios del servicio PIM, interruptores de depuración ni comandos no documentados de Advanced Shell.

Preguntas frecuentes

¿Sustituye PIM-SM a IGMP o a la regla de firewall?

No. IGMP indica el interés de los receptores en la red local, PIM-SM conecta los routers multicast implicados y la regla de firewall permite el flujo de datos concreto entre zonas. Los tres niveles deben corresponder al mismo diseño.

¿Por qué afecta una ruta unicast a la ruta multicast?

PIM-SM utiliza RPF. A partir de su información de enrutamiento, el firewall comprueba por qué interfaz alcanzaría el origen o el RP. Si esta ruta señala a la interfaz incorrecta, la ruta inversa esperada no coincide y el estado multicast puede quedar incorrecto o incompleto.