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.
Guardar las rutas multicast estáticas existentes y desactivar Enable multicast forwarding de forma controlada.
Comprobar Device Access en las zonas con vecinos PIM reales y permitir Dynamic Routing de forma específica solo cuando sea necesario.
En Routing > Multicast (PIM-SM), activar PIM en las interfaces IPv4 implicadas.
Configurar el mismo RP estático y rango de grupos en todos los routers PIM.
Permitir el flujo de datos multicast mediante reglas de firewall IPv4 restrictivas y con registro.
Comprobar conjuntamente la unión del receptor, el vecino, RP SET, el estado multicast, Rule ID y la ruta de los paquetes.

⚠️ PIM-SM y Static Multicast Forwarding no se pueden configurar simultáneamente en Sophos Firewall. El cambio modifica la ruta multicast de producción. Antes se deben documentar las rutas, los grupos y los receptores existentes, además de una vía de retorno.

Este artículo trata el enrutamiento multicast IPv4 dinámico con un RP estático. En un dominio PIM, un Bootstrap Router, o BSR, distribuye la información que determina qué RP es responsable de cada grupo. Candidate RP se explica más adelante, pero no se utiliza como una supuesta solución automática de Bootstrap Router.

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 enumera interfaces físicas, RED e interfaces GRE para PIM. 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 incluirse en esta configuración básica sin una validación previa.

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.

Sustituir Static Multicast Forwarding de forma controlada

En Routing > Static routes, se documentan las rutas multicast existentes, las aplicaciones dependientes y las interfaces de destino. Enable multicast forwarding solo se desactiva durante la ventana de mantenimiento. Después se puede activar PIM-SM.

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.

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
No considerar todavía que el cambio se ha completado correctamente; el vecino y el estado solo se comprueban después de configurar todo el RP.

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. Desde ambos firewalls debe ser accesible a través de la ruta PIM prevista. Guardar un valor no es suficiente: en Routing > Information > PIM-SM > RP SET, el grupo debe aparecer posteriormente asignado a este RP.

A continuación, guardar la configuración. Si PIM no se puede activar, comprobar primero si Enable multicast forwarding sigue activo.

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, una lista de grupos, una prioridad de 1 a 255 y un intervalo de anuncio de 30 a 180 segundos.

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. En cada router, el flujo necesita una regla de firewall IPv4 restrictiva para el cruce de zonas correspondiente.

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. Mediante Rule ID se comprueba si el objeto de grupo coincide según lo previsto en la versión instalada. Si aparece Rule 0, la regla no se amplía sin control, sino que se analiza la ruta de los paquetes.

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 y unirse a 239.10.10.10 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.
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 receptor se ha unido realmente al grupo y al puerto UDP correctos.
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 se almacenan localmente en cada nodo. En caso de un problema de HA, se guardan los datos del nodo que estaba activo antes del cambio. No se presupone una sincronización sin interrupciones del estado PIM.

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.
Volver a activar Static Multicast Forwarding únicamente si el estado anterior y sus rutas están documentados por completo.
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.