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:

Documentar la red de tránsito, las LAN locales, el peer, los prefijos esperados y la ruta de retorno.
Preparar una copia de seguridad de la configuración y un acceso de gestión independiente.
Comprobar la accesibilidad IP directa entre las direcciones de tránsito.
En Administration > Device access, permitir Dynamic Routing solo para la zona del peer o mediante una excepción restrictiva.
En Routing > RIP, seleccionar RIPv2 y dejar inicialmente sin cambios los temporizadores globales.
Añadir las redes de tránsito y las LAN locales en RIP Networks.
Establecer las interfaces LAN en Passive mode mediante Override interface configuration.
Hacer coincidir con el peer la versión y la autenticación de la interfaz de tránsito.
En Routing > Information > RIP, comprobar el estado y las rutas aprendidas.
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 que se conozcan todos los prefijos anunciados y sus rutas de retorno. Una redistribución amplia puede propagar involuntariamente rutas Connected o Static por todo el dominio de routing 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.

Los routers intercambian actualizaciones de routing periódicamente. El router receptor incorpora los cambios a su tabla de routing, incrementa la métrica de la ruta en 1 y utiliza al emisor como next hop.

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.

Bajo RIP version, SFOS ofrece estos tres ajustes:

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 pares utilizan RIPv2. Send V2 and receive both puede ser útil durante una transición controlada, pero sigue aceptando actualizaciones RIPv1. En cuanto todos los peers utilicen RIPv2, establecer en V2 tanto la versión de envío como la de recepción.

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.

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
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á reservado para documentación. Sustituya de forma coherente la red y las direcciones IP de tránsito, los prefijos LAN y los hosts de prueba por valores de su propio entorno. No use sin cambios las direcciones de documentación en producción. Las dos direcciones IP de tránsito deben ser accesibles 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, documente la interfaz, zona, rutas existentes, Route Precedence, métrica esperada y un host de prueba accesible. Una copia de seguridad actual de la configuración y una ruta de gestión independiente del nuevo routing permiten una reversión controlada.

Permitir Dynamic Routing de forma restrictiva

En Administration > Device access, compruebe primero para qué zonas se permite actualmente Dynamic Routing. En el ejemplo, permítalo solo para la zona de tránsito dedicada o mediante una excepción ACL específica para el peer.

La matriz Device Access se aplica a toda la zona. Para una zona de tránsito dedicada y de confianza, puede habilitar Dynamic Routing allí. Si el acceso debe limitarse a un peer o una red de tránsito concretos, deje desmarcada la casilla de la zona y cree en Local service ACL exception rule una excepción Allow restrictiva para el origen y el servicio. Habilitar simultáneamente el acceso para toda la zona anularía esa restricción. Device Access y Local Service ACL explica la distinción.

Este permiso afecta a los paquetes RIP destinados al firewall y no puede sustituirse por una regla de firewall normal. En cambio, el tráfico de datos entre 10.10.10.0/24 y 10.20.20.0/24 sigue necesitando reglas de firewall normales. Dynamic Routing no se habilita en la zona LAN solo porque la LAN se anuncie como RIP Network. Documente el estado efectivo de Device Access antes del cambio, sin presuponer una autorización general predeterminada.

Si ambos firewalls envían actualizaciones RIP por la interfaz de tránsito, pero solo Firewall A permite las actualizaciones entrantes, el aprendizaje de rutas es unilateral: A recibe las actualizaciones de B y aprende 10.20.20.0/24 a través de 198.51.100.2. B sigue enviando sus actualizaciones, pero descarta las entrantes de A porque en B falta el permiso para Dynamic Routing. Por tanto, B no aprende mediante RIP la ruta a 10.10.10.0/24 anunciada por A.

Se trata de una asimetría en el intercambio de información de routing (plano de control), no de una prueba de un fallo concreto del tráfico de datos. Compruebe ambos lados en Routing > Information > RIP > Routes y verifique el permiso efectivo de recepción en el firewall que no aprende rutas. Cualquier corrección debe limitarse a la zona real del peer o a una excepción ACL restrictiva; no habilite el acceso general desde WAN. Después, compruebe por separado Route Lookup, las reglas de firewall, NAT y las rutas reales de ida y retorno.

Configurar RIPv2 en WebAdmin

El ejemplo utiliza un segundo cortafuegos Sophos en el lado B. Cuando ambos equipos son Sophos Firewall, la configuración se replica en el peer; solo cambian la IP de tránsito y la LAN local. Si el peer es un router de otro fabricante, RIPv2, la red de tránsito, la LAN local, Passive mode y la autenticación se configuran mediante las funciones equivalentes de ese dispositivo.

1. Establecer los valores globales

Abrir los ajustes globales en Routing > RIP:

Establecer RIP version en V2.
Mantener Default metric en su valor predeterminado actual 1.
Mantener Administrative distance en su valor predeterminado actual 120.
Mantener inicialmente Update, Timeout y Garbage en 30, 180 y 120 segundos.
Dejar Default information originate desactivado.
No activar ninguna redistribución.
Seleccione Apply para guardar los cambios.

Default information originate genera y anuncia una ruta predeterminada en el dominio RIP y está desactivado de forma predeterminada. 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.

El valor predeterminado de Default metric para las rutas redistribuidas es 1; el intervalo permitido es de 1 a 16. Administrative distance tiene un valor predeterminado de 120 y admite valores de 1 a 255. Mantenga ambos valores sin cambios salvo que el diseño de routing documente un motivo para modificarlos.

Administrative distance ayuda al router a elegir la mejor ruta entre fuentes de routing competidoras; la métrica RIP, en cambio, compara rutas dentro de RIP.

Los valores predeterminados de Update, Timeout y Garbage son 30, 180 y 120 segundos. Update determina el intervalo entre dos actualizaciones periódicas de routing. La documentación oficial de SFOS 22.0 indica de 5 a 2147483647 segundos para cada uno de estos tres temporizadores; la de SFOS 23.0 indica de 1 a 32767 segundos para cada uno y denomina Time-out a Timeout. Son valores documentados por versión, no una garantía de validación de entrada en una compilación probada. Este ejemplo conserva los valores predeterminados; elija otros solo cuando ambos peers compartan un diseño documentado de temporizadores y gestión de fallos.

Si la redistribución es necesaria de forma deliberada, activar solo las fuentes previstas en Routing > RIP: Redistribute connected para rutas conectadas directamente, Redistribute static para rutas estáticas, Redistribute OSPF para rutas OSPF y Redistribute BGP para rutas BGP. Establecer la métrica de rutas redistribuidas correspondiente a cada fuente activada; los cuatro campos admiten de 0 a 16, a diferencia de Default metric global. Elegir los valores según el diseño documentado de routing, sin copiar un valor genérico. Guardar con Apply y comprobar después los prefijos esperados e inesperados y la ruta de retorno como se describe más abajo. En el ejemplo, las cuatro fuentes permanecen desactivadas.

2. Añadir RIP Networks

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

198.51.100.0 con la máscara de subred 255.255.255.252
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

Bajo Routing > RIP > Override interface configuration, utilice Select interface para elegir la interfaz participante.

Send y Receive permiten, de forma independiente, V1, V2 o ambas versiones. La selección de cada interfaz prevalece sobre RIP version global. Send utiliza V2 de forma predeterminada; la versión de recepción V2 elegida más abajo es una configuración deliberada del ejemplo, no una afirmación sobre el valor predeterminado de Receive. Passive mode está desactivado de forma predeterminada y se activa expresamente para la LAN.

Para una conexión RIPv2 con autenticación deliberada, activar Authentication e introducir una contraseña; la configuración debe coincidir en ambos peers. Si se selecciona autenticación para una interfaz RIPv1, esta envía actualizaciones de routing, pero no acepta rutas. Al seleccionar ambas versiones, RIPv2 sigue funcionando con autenticación. Sophos recomienda configurar RIPv1 en una interfaz distinta de la utilizada para RIPv2 autenticado.

Para la interfaz de tránsito:

Send version: V2
Receive version: V2
Passive mode: desactivado
Split horizon: retener el estado anterior documentado; SFOS deshabilita esta opción por defecto
Poisoned reverse: solo disponible cuando Split Horizon está habilitado y desactivado por defecto
Authentication: comprobar el estado anterior efectivo y establecer deliberadamente ambos lados de forma idéntica

Para la interfaz LAN:

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

Guarde la selección con Save. RIPv2 admite texto plano y autenticación MD5. Plaintext no protege la contraseña. MD5 autentica las actualizaciones de enrutamiento, pero no encripta ni prefijos ni métricas. Por lo tanto, los segmentos de tránsito siguen limitados a los routers previstos. La ayuda pública de la CLI de SFOS 22 y la ayuda de WebAdmin ofrecen indicaciones contradictorias sobre el estado predeterminado de la autenticación. Por tanto, esta guía no presupone ningún valor predeterminado: compruebe ambas interfaces de tránsito y luego configúrelas de forma consciente e idéntica.

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 Firewall B, establezca la misma versión, temporizadores y autenticación. Utilice 198.51.100.0/30 y 10.20.20.0/24 como Networks, y haga que la interfaz de la LAN local sea 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.

Por qué esta guía utiliza WebAdmin para cambios

El acceso documentado a la CLI varía según la versión: la ayuda de SFOS 22.0 indica 3. Route Configuration > 1. Configure Unicast Routing > 1. Configure RIP, el indicador rip> y, a continuación, enable. La ayuda de SFOS 23.0 indica en cambio 3. Route Configuration > 1. Configure Unicast Routing, el indicador router# y, a continuación, router#configure terminal. La entrada router rip de la tabla es un comando CLI, no una selección adicional del menú. Se trata de una comparación de los accesos documentados, no de una secuencia de configuración ejecutable.

La ayuda pública de la CLI de SFOS 22 contiene comandos de autenticación concatenados incorrectamente y no documenta todos los comandos necesarios para guardar y validar. La ayuda de SFOS 23.0 también sigue siendo ambigua sobre los contextos de la CLI para la autenticación y el ejemplo MD5. La corrección de los ejemplos de texto claro no convierte automáticamente los demás comandos en una secuencia fiable. Esta guía no deduce de ese material ni sintaxis sin verificar ni pasos para cambiar de contexto o guardar.

Por tanto, la configuración y la reversión se realizan mediante los campos documentados de WebAdmin. Utilice la CLI únicamente para diagnósticos de soporte de solo lectura documentados para la versión de SFOS instalada.

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.

Dentro de RIP, SFOS conserva la ruta con la métrica más baja para un destino. Eso por sí solo no prueba que este camino es también la ruta activa en todo el sistema. Cuando una ruta estática, SD-WAN o VPN compite, utilice Diagnostics > Tools > Route lookup para comprobar la ruta seleccionada. No cambie globalmente Route Precedence para una sola prueba RIP.

Validar RIP y la ruta de datos real

La validación trata tres preguntas por separado: ¿Se intercambian rutas, se selecciona la ruta correcta y funciona el tráfico 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
From, Tag, y Time
los filtros de actualización entrantes y salientes, si están configurados
el nombre de la Key-chain, si está configurada
Bad Packets y Bad Routes

Una ruta RIP visible confirma el intercambio de rutas, pero no que SFOS la seleccione ni que el tráfico de datos circule por ella. La vista Status no demuestra qué secreto se utiliza; este debe gestionarse y verificarse de forma controlada en ambos peers.

Probar Route Lookup y el tráfico

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.
En el peer B, comprobar el destino 10.10.10.10.
Desde el cliente 10.10.10.10, iniciar una conexión real permitida al servidor 10.20.20.10.
En Log viewer, comprobar el origen, el destino, el servicio, Firewall Rule ID, Action y cualquier NAT Rule ID.
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.

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.

Si los contadores Bad Packets o Bad Routes suben bajo Status, compare la versión, autenticación, subred y configuración de pares. Si los contadores permanecen sin cambios y las vistas diagnósticas no muestran tráfico RIP del par, compruebe la asignación de la interfaz y Local Service ACL primero. Cambie los valores globales de RIP solo después de esas comprobaciones.

La ruta aparece en RIP, pero no se utiliza

El intercambio de protocolo funciona. Route Lookup muestra qué camino es realmente activo. La métrica RIP compara los caminos RIP; por sí misma, no decide entre todas las fuentes de enrutamiento.

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

Si no llegan actualizaciones antes de que expire el valor Timeout configurado, la ruta deja de ser válida; durante el período Garbage, SFOS la anuncia con métrica 16 y después la elimina. Compare la accesibilidad, el estado del peer y los valores Update, Timeout y Garbage de ambos lados antes de cambiar un temporizador.

Se anuncian redes inesperadas

Compruebe RIP Networks, Default information originate y cada opción de redistribución individualmente. La redistribución puede incluir más rutas Connected o Static que las LANs destinadas a este ejemplo. Déjela desactivada hasta que se conozca cada prefijo que deba distribuirse.

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 comienza por la ruta de sustitución, no por eliminar las rutas RIP activas:

Habilitar la ruta estática o dinámica alternativa y validarla con Route Lookup, acceso de gestión y tráfico bidireccional real.
Desactivar la redistribución recién habilitada y Default information originate si eran deliberadamente parte de la prueba; luego comprobar los prefijos esperados de nuevo.
Retirar las RIP Networks locales una a una y comprobar las rutas de ida y retorno después de cada paso.
Restaure los Interface Overrides y la configuración global de RIP al estado anterior documentado.
Elimine por último Dynamic Routing de la zona de tránsito o la excepción ACL, y solo si ningún vecino OSPF, BGP o PIM necesita también esa autorización.
Por último, vuelva a comprobar Route Lookup, reglas, acceso de gestión y 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.

Verificación de aprobación

Ambos firewalls muestran las rutas RIP esperadas con el next hop correcto y una métrica plausible.
Route Lookup confirma los caminos de avance y retorno previstos.
No aparecen prefijos inesperados o redistribución no deseada.
Se aplican reglas de firewall restrictivas y registradas sin SNAT no deseado.
Un servicio real funciona de forma bidireccional.
La ruta de sustitución y el procedimiento de reversión están documentados y son ejecutables.