Configurar y validar RIP en Sophos Firewall

RIP distribuye automáticamente rutas IPv4 entre routers. En Sophos Firewall, el protocolo es adecuado sobre todo para dominios de routing pequeños o existentes, en los que pocos routers deben intercambiar redes sin una selección de rutas compleja.

El procedimiento breve y seguro es el siguiente:

1. Documentar la red de tránsito, las LAN locales, el peer, los prefijos esperados y la ruta de retorno.
2. Preparar una copia de seguridad de la configuración y un acceso de gestión independiente.
3. Comprobar la accesibilidad IP directa entre las direcciones de tránsito.
4. En Administration > Device access, permitir Dynamic Routing solo para la zona del peer o mediante una excepción restrictiva.
5. En Routing > RIP, seleccionar RIPv2 y dejar inicialmente sin cambios los temporizadores globales.
6. Añadir las redes de tránsito y las LAN locales en RIP Networks.
7. Establecer las interfaces LAN en Passive mode mediante Override interface configuration.
8. Hacer coincidir con el peer la versión y la autenticación de la interfaz de tránsito.
9. En Routing > Information > RIP, comprobar el estado y las rutas aprendidas.
10. Probar Route Lookup, Firewall Rule ID y un servicio bidireccional real.

⚠️ Default information originate y la redistribución de Connected, Static, OSPF o BGP permanecen desactivados hasta conocer todos los prefijos anunciados y sus rutas de retorno. Una redistribución amplia puede propagar inesperadamente rutas de gestión, tránsito, blackhole u otras rutas internas por todo el dominio RIP.

Este procedimiento trata RIPv2 para IPv4 en Gateway Mode. RIPv1 solo se explica como caso de interoperabilidad heredada. Sophos Firewall no admite RIP en Transparent Mode.

Cuándo es adecuado RIP y cuándo no

RIP es un protocolo de vector de distancia. Evalúa una ruta según el número de saltos de router. Se prefiere la ruta con la métrica más baja. Se pueden alcanzar como máximo 15 saltos; la métrica 16 significa que el destino no es accesible.

Este modelo sencillo supone una ventaja cuando:

• solo participan unos pocos routers,
• la topología es pequeña y mayoritariamente estable,
• un peer existente solo admite RIP,
• el mantenimiento automático de rutas es más importante que la convergencia rápida y una política compleja.

Para una única ruta fija, una ruta estática suele ser más sencilla. Con varias rutas redundantes, convergencia rápida o redes internas más grandes, OSPF suele ser el protocolo más adecuado. BGP corresponde a diseños con sistemas autónomos, proveedores o una política de routing deliberada.

RIP no sustituye una regla de firewall ni supervisa la calidad de las aplicaciones. Una ruta SD-WAN es la capa adecuada para seleccionar por origen, servicio, aplicación, latencia, jitter o pérdida de paquetes.

Diferencias entre RIPv1 y RIPv2

Para configuraciones nuevas se utiliza RIPv2. Transmite máscaras de subred y admite autenticación. RIPv1 es classful, no transmite máscaras de subred y no admite autenticación en Sophos Firewall.

SFOS ofrece, entre otras, estas opciones globales:

• Send V2 and receive both: enviar RIPv2 y recibir RIPv1 y RIPv2
• V1: enviar y recibir RIPv1
• V2: enviar y recibir RIPv2

En el ejemplo, ambos peers utilizan RIPv2. Send V2 and receive both puede facilitar una transición controlada, pero amplía las entradas aceptadas. En cuanto todos los peers utilizan RIPv2, tanto el envío como la recepción se limitan a V2.

Comprender RIP Networks y Passive Mode

Una RIP Network no es la red de destino remota. La entrada activa RIP en las interfaces locales cuya dirección IP coincide con la red indicada. De esta forma, la red conectada directamente se incorpora al proceso RIP y puede anunciarse.

En el ejemplo se introducen en Firewall A tanto la red de tránsito 198.51.100.0/30 como la LAN local 10.10.10.0/24:

• La red de tránsito activa RIP en la interfaz orientada al peer.
• La LAN se anuncia como red local accesible.
• Passive mode en la interfaz LAN evita que el firewall envíe allí actualizaciones RIP.

Passive Mode no elimina la LAN del proceso de routing. Solo impide el envío de anuncios RIP a través de esa interfaz. Además, Dynamic Routing permanece desactivado en la zona de clientes para que estos no puedan enviar actualizaciones de routing al firewall.

La Default metric global es la métrica inicial de las rutas redistribuidas. El valor predeterminado es 1. Administrative distance decide entre fuentes de routing que compiten entre sí; Sophos utiliza de forma predeterminada 120 para RIP. Estos valores no se modifican sin un motivo documentado.

Los temporizadores predeterminados son:

• Update: 30 segundos
• Timeout: 180 segundos
• Garbage: 120 segundos

Los temporizadores se coordinan en todos los peers. Unos valores acortados de forma agresiva pueden hacer que las rutas se eliminen y se vuelvan a aprender innecesariamente durante pérdidas de paquetes o cargas elevadas.

Planificar la topología de ejemplo

El ejemplo completo conecta dos LAN:

• Firewall A: IP de tránsito 198.51.100.1/30, LAN local 10.10.10.0/24
• Router o Firewall B: IP de tránsito 198.51.100.2/30, LAN local 10.20.20.0/24
• Red de tránsito: 198.51.100.0/30
• Cliente de prueba A: 10.10.10.10
• Servidor de prueba B: 10.20.20.10

198.51.100.0/24 está reservada para documentación. En un entorno real, se sustituyen conjuntamente las direcciones de tránsito, las interfaces, las zonas y los prefijos LAN. Las dos IP de tránsito deben poder alcanzarse directamente.

Firewall A debe aprender 10.20.20.0/24 a través de 198.51.100.2. El peer debe aprender 10.10.10.0/24 a través de 198.51.100.1. Solo esta ruta de ida y vuelta permite tráfico enrutado sin source NAT.

Antes del cambio se documentan la interfaz, la zona, las rutas existentes, Route Precedence, la métrica esperada y un host de prueba accesible. Una copia de seguridad de la configuración actual y una ruta de gestión independiente del nuevo routing facilitan la recuperación.

Permitir Dynamic Routing de forma restrictiva

En Administration > Device access, Dynamic Routing está desactivado de forma predeterminada para todas las zonas. En el ejemplo solo se permite en la zona de la interfaz de tránsito.

La matriz de Device Access se aplica a toda la zona. Si otras interfaces no fiables comparten esa zona, es mejor una Local Service ACL Exception restrictiva para la red de tránsito y el peer previsto. Device Access y Local Service ACL explica esta separación.

Este permiso afecta a los paquetes RIP dirigidos al firewall. El flujo de datos entre 10.10.10.0/24 y 10.20.20.0/24 sigue necesitando reglas de firewall normales. Dynamic Routing no se activa en la zona LAN únicamente porque la LAN se anuncie como RIP Network.

Configurar RIPv2 en WebAdmin

La configuración se refleja en ambos peers. Solo cambian la IP de tránsito y la LAN local.

1. Establecer los valores globales

Abrir los ajustes globales en Routing > RIP:

1. Establecer RIP version en V2.
2. Mantener Default metric en su valor predeterminado actual 1.
3. Mantener Administrative distance en su valor predeterminado actual 120.
4. Mantener inicialmente Update, Timeout y Garbage en 30, 180 y 120 segundos.
5. Dejar Default information originate desactivado.
6. No activar ninguna redistribución.
7. Guardar los cambios.

Default information originate anuncia una ruta predeterminada en el dominio RIP. Solo es adecuado si este firewall debe ser deliberadamente la salida para todos los destinos desconocidos y se han planificado tanto la ruta de retorno como el caso de fallo.

2. Añadir RIP Networks

En Routing > RIP > RIP Networks > Add, introducir estas redes locales en Firewall A:

1. 198.51.100.0 con la máscara de subred 255.255.255.252
2. 10.10.10.0 con la máscara de subred 255.255.255.0

En el peer B, introducir la misma red de tránsito y 10.20.20.0/24.

Antes de guardar, comprobar qué interfaz local coincide con cada Network. Una Network demasiado amplia puede activar RIP en interfaces adicionales e incorporar más redes conectadas directamente al proceso.

3. Establecer Interface Overrides

En Routing > RIP > Override interface configuration, seleccionar las interfaces participantes.

Para la interfaz de tránsito:

• Send version: V2
• Receive version: V2
• Passive mode: desactivado
• Split horizon: adecuado para el diseño de peer y hub
• Authentication: idéntica en ambos lados cuando se utiliza

Para la interfaz LAN:

• Send version: V2
• Receive version: V2
• Passive mode: activado

RIPv2 admite autenticación mediante texto sin cifrar y MD5. El texto sin cifrar no protege la contraseña. MD5 autentica las actualizaciones de routing, pero no cifra ni los prefijos ni las métricas. Por ello, los segmentos de tránsito permanecen limitados a los routers previstos. Para diseños nuevos, con mayor protección o de mayor tamaño, suele ser más adecuado un protocolo de routing más moderno sobre un transporte controlado.

Split horizon impide normalmente que una ruta aprendida a través de una interfaz vuelva a anunciarse por la misma interfaz. Poisoned reverse puede anunciarla allí expresamente con la métrica 16 como no accesible. Estas opciones solo se modifican cuando lo exige la topología hub, spoke o multiacceso y se prueban junto con el peer.

4. Reflejar la configuración en el peer

En Router o Firewall B se establecen la misma versión, los mismos temporizadores y la misma autenticación. Se utilizan 198.51.100.0/30 y 10.20.20.0/24 como Networks, y la interfaz hacia la LAN receptora se configura como pasiva.

Una configuración unilateral no es suficiente. Sin el anuncio de la red de retorno, Firewall A puede aprender la LAN remota, pero las respuestas no encuentran la ruta de vuelta.

Reglas de firewall, NAT y Route Precedence

Para la prueba, ambos firewalls necesitan reglas restrictivas y con registro para los servicios realmente necesarios entre 10.10.10.0/24 y 10.20.20.0/24. Crear correctamente reglas de firewall explica el funcionamiento de las reglas.

En una red de sedes con routing normal, source NAT permanece desactivado. Ambos lados deben ver la dirección de origen real y conocer la ruta de retorno mediante RIP. SNAT puede ocultar rutas de retorno ausentes y dificultar el análisis posterior y el control de acceso.

Una ruta RIP aprendida no gana necesariamente de forma automática. Los prefijos más largos tienen prioridad; después también importan la fuente de routing, Administrative Distance y la Route Precedence global. Si compite una ruta estática, SD-WAN o VPN, Diagnostics > Tools > Route lookup muestra la ruta realmente seleccionada. Route Precedence no se modifica globalmente para una única prueba RIP.

Validar RIP y la ruta de datos real

La validación separa el intercambio de routing, la ruta seleccionada y el flujo de datos.

Comprobar Routes y Status

En Routing > Information > RIP > Routes, Firewall A debe mostrar la red 10.20.20.0/24 con el next hop 198.51.100.2 y una métrica plausible. El peer B debe conocer 10.10.10.0/24 a través de 198.51.100.1.

En Routing > Information > RIP > Status, comparar:

• las interfaces participantes
• las versiones RIP enviadas y recibidas
• los temporizadores Update, Timeout y Garbage
• las fuentes de routing y la redistribución
• Bad Packets y Bad Routes
• la autenticación o Key Chain utilizada

Una entrada visible confirma el intercambio RIP, pero todavía no que se seleccione esa ruta ni que pase el tráfico de datos.

Probar Route Lookup y el tráfico

1. En Firewall A, comprobar el destino 10.20.20.10 en Diagnostics > Tools > Route lookup. El next hop y la interfaz deben corresponder a la ruta de tránsito.
2. En el peer B, comprobar el destino 10.10.10.10.
3. Desde el cliente 10.10.10.10, iniciar una conexión real permitida al servidor 10.20.20.10.
4. En Log viewer, comprobar el origen, el destino, el servicio, Firewall Rule ID, Action y cualquier NAT Rule ID.
5. En Diagnostics > Packet capture, confirmar que la solicitud y la respuesta atraviesan las interfaces previstas.

El procedimiento completo se explica en Probar una regla de firewall con Log Viewer y Packet Capture.

Para una prueba de control plane de solo lectura, se pueden filtrar brevemente los paquetes RIP en Device Console:

tcpdump 'udp port 520'

La salida se detiene con Ctrl+C. Se esperan actualizaciones entre las dos direcciones de tránsito. En cambio, los paquetes RIP procedentes de una LAN de clientes indican en este ejemplo un límite incorrecto de interfaz o Device Access.

En Advanced Shell, los logs aportan contexto adicional:

cd /log
tail -f ripd.log

ripd.log muestra eventos específicos del protocolo. zebra.log ayuda a determinar si una ruta aprendida dinámicamente se ha instalado en el stack de routing. La salida en directo se detiene con Ctrl+C; después puede utilizarse tail -f zebra.log. Archivos de servicio y log de Sophos Firewall clasifica otros archivos.

Delimitar los errores sistemáticamente

No aparece ninguna ruta RIP

Primero se comprueba la accesibilidad directa entre las direcciones de tránsito. Después, Dynamic Routing debe estar activado en la zona correcta del peer, una RIP Network debe coincidir con la interfaz local y deben existir versiones de envío y recepción compatibles. Si se utiliza autenticación, el método y el secreto deben coincidir.

tcpdump 'udp port 520' diferencia los paquetes ausentes de las actualizaciones rechazadas o inutilizables. Si aumentan los contadores Bad Packets o Bad Routes en Status, se comparan la versión, la autenticación, la subred y la configuración del peer.

La ruta aparece en RIP, pero no se utiliza

En ese caso, el intercambio del protocolo funciona. Route Lookup muestra si gana un prefijo más específico, una ruta estática, SD-WAN, VPN u otra Administrative Distance. La métrica RIP por sí sola no decide entre todas las fuentes de routing.

No se elimina la Route Precedence global ni una ruta productiva existente antes de documentar su efecto sobre otras redes.

El tráfico solo funciona en una dirección

El peer necesita la ruta de retorno y ambos firewalls necesitan reglas adecuadas. También se comprueban NAT, las rutas asimétricas y el gateway del host. Una ruta de ida existente no demuestra la ruta de retorno.

La ruta desaparece y vuelve a aparecer

Un enlace de tránsito inestable, la pérdida de paquetes, reinicios del peer, temporizadores diferentes o errores de autenticación pueden activar el timeout. Se comparan los valores Update, Timeout y Garbage en ambos lados. Los temporizadores no se acortan por sospecha; primero se demuestra la ruta de paquetes y el estado del peer.

Se anuncian redes inesperadas

Se comprueban individualmente RIP Networks, Default information originate y cada opción de redistribución. Redistribute connected puede incluir más interfaces que la LAN planificada. Redistribute static también puede distribuir rutas blackhole o de gestión. La función permanece desactivada hasta disponer de una lista completa de prefijos y una estrategia de filtrado.

Probar HA y el failover de forma controlada

En un clúster HA, después de un failover planificado se vuelve a comprobar en el Primary actual:

• RIP Status y las interfaces participantes
• las rutas aprendidas y su antigüedad
• Route Lookup para ambas LAN
• ripd.log y zebra.log en el nodo que procesó el evento
• una nueva conexión de prueba bidireccional

La prueba se realiza en una ventana de mantenimiento. Este artículo no promete ni una convergencia RIP sin interrupciones ni la conservación de las sesiones existentes. Los logs se almacenan por nodo de procesamiento y, por tanto, se recopilan de ambos appliances cuando sea necesario.

Revertir el cambio de forma segura

Antes de eliminar RIP debe existir una ruta alternativa o una ventana de mantenimiento planificada para cada red de destino aprendida.

La reversión se realiza en orden inverso:

1. Desactivar la redistribución recién activada y Default information originate si formaban deliberadamente parte de la prueba.
2. Eliminar las RIP Networks locales.
3. Devolver los Interface Overrides al estado anterior documentado.
4. Revertir los ajustes RIP globales.
5. Eliminar Dynamic Routing de la zona de tránsito o la excepción ACL solo si ningún vecino OSPF, BGP o PIM también la necesita.
6. Activar de forma controlada la ruta estática o dinámica alternativa.
7. Volver a comprobar Route Lookup, las reglas, el acceso de gestión y el tráfico real.

No se eliminan RIP y la ruta de sustitución al mismo tiempo. Se mantiene abierta una sesión de administrador existente hasta confirmar la ruta de retorno.

Lista de comprobación

• Gateway Mode, interfaces, zonas y direcciones de tránsito están documentados.
• Hay una copia de seguridad y un acceso de gestión independiente.
• Las dos IP de tránsito pueden alcanzarse directamente.
• Dynamic Routing solo está permitido para la zona del peer o una excepción restrictiva.
• Ambos lados utilizan valores RIPv2 y de autenticación compatibles.
• RIP Networks solo coinciden con las interfaces locales previstas.
• Las interfaces LAN de clientes utilizan Passive Mode.
• Default Route Origination y la redistribución solo están activadas de forma deliberada.
• Routes y Status muestran los prefijos, next hops y temporizadores esperados.
• Route Lookup confirma las rutas de ida y retorno seleccionadas.
• Las reglas de firewall son restrictivas, tienen registro y no incluyen SNAT involuntario.
• Un servicio real funciona de forma bidireccional.
• El rollback y la prueba HA están documentados.

FAQ