SFOS 22: redistribute kernel ya no anuncia rutas IPsec

Después de actualizar a SFOS 22, el túnel IPsec puede seguir activo y el Neighbor OSPF o BGP puede continuar en buen estado. Aun así, las redes situadas detrás de un túnel IPsec policy-based pueden desaparecer de repente de los routers vecinos.

El desencadenante habitual es redistribute kernel: hasta SFOS 21.5, las rutas VPN policy-based utilizadas en este procedimiento podían incorporarse desde la tabla de routing del kernel. Con SFOS 22.0 GA, el firewall procesa estas rutas internamente en el backend de VPN. Por eso, redistribute kernel ya no puede encontrarlas.

⚠️ No se debe crear una ruta estática dummy, null o blackhole únicamente para que el prefijo vuelva a aparecer en OSPF o BGP. En función de Route Precedence, una ruta de este tipo puede asumir el propio data path y desviar el tráfico de producción del túnel o descartarlo.

Respuesta rápida: qué hacer ahora

Si después de la actualización falta una red VPN que antes se anunciaba, primero hay que comprobar si se cumplen todos estos puntos:

1. El firewall se actualizó desde SFOS 21.5 o una versión anterior a SFOS 22.
2. El túnel afectado es policy-based.
3. OSPF o BGP incorporaba hasta ahora las redes VPN mediante redistribute kernel.
4. El Neighbor permanece en Full o Established, pero el prefijo esperado falta en el lado receptor.

Si es así, una nueva entrada ipsec_route no es la solución: en SFOS 22 tampoco genera una ruta normal del kernel. Para un diseño comprensible a largo plazo, se recomienda IPsec route-based Any-to-Any con interfaces XFRM direccionadas y una configuración OSPF o BGP explícita.

La comprobación de actualización a SFOS 22 ayuda con la preparación. La configuración del túnel se explica en Configurar una VPN IPsec Site-to-Site.

Por qué falta la ruta después de la actualización

Una ruta del kernel es una entrada en la tabla de routing normal del sistema operativo. Los servicios de routing pueden adoptar estas entradas como fuente y anunciarlas a los vecinos, por ejemplo mediante redistribute kernel.

SFOS 22 trata IPsec policy-based de otro modo: el recorrido de los paquetes se determina mediante una búsqueda interna en el backend con marcas, zonas y flags. Por eso, el túnel puede reenviar el tráfico correctamente aunque la red VPN asociada no aparezca como una ruta normal del kernel.

Esto explica el comportamiento aparentemente contradictorio:

• El túnel IPsec está activo.
• OSPF se encuentra en Full o BGP en Established.
• El tráfico directo a través del túnel puede seguir funcionando.
• Sin embargo, el prefijo VPN remoto ya no se incorpora desde la tabla de routing del kernel a OSPF o BGP.

El cambio no afecta a OSPF o BGP en general. Solo afecta a un diseño que dependía de las rutas IPsec policy-based como rutas del kernel.

Reconocer la dependencia antes de actualizar

Antes de actualizar, no basta con comprobar que el túnel existente aparezca en verde. Lo decisivo es saber de dónde obtiene OSPF o BGP el prefijo que debe anunciar.

Como ejemplo se utiliza la red VPN remota 10.60.0.0/16. Se trata de un valor específico del entorno que debe sustituirse por la red que se anuncia realmente.

Registrar el estado del firewall y de la VPN

En 4. Device Console, primero se documentan Route Precedence y las rutas IPsec manuales:

system route_precedence show
system ipsec_route show

La salida responde a dos preguntas diferentes: Route Precedence muestra el orden global de las clases de routing. system ipsec_route show muestra las asignaciones manuales a túneles policy-based. Ninguno de los dos comandos demuestra por sí solo que OSPF o BGP anuncie realmente el prefijo.

En SFOS 21.5 también se puede registrar en Advanced Shell si la red del ejemplo aparece en la tabla de routing utilizada para IPsec policy-based:

ip route show table 220 | grep '10.60.0.0/16'

El comando es de solo lectura; el prefijo de búsqueda debe adaptarse a la red real. En SFOS 22, la ausencia de resultados para IPsec policy-based es normal y no demuestra que el propio túnel esté averiado.

Documentar OSPF o BGP por separado

En la CLI de routing correspondiente se guarda la configuración en ejecución. Para OSPF también resultan útiles estos comandos de solo lectura:

show running-config
show ip ospf neighbor
show ip ospf route

Para BGP se documentan la configuración y los prefijos BGP conocidos:

show running-config
show ip bgp

En el router receptor también se registra si aprende 10.60.0.0/16 y qué next hop utiliza. Solo así se puede reconocer después de la actualización si el problema afecta al túnel, a la relación de routing o al anuncio del prefijo.

Los procedimientos completos de comprobación se explican en Configurar y comprobar OSPF y Configurar y comprobar BGP.

Elegir un diseño de destino seguro

Routing dinámico mediante una interfaz XFRM

Si las redes remotas deben aprenderse o redistribuirse dinámicamente, IPsec route-based Any-to-Any es el diseño de destino más comprensible:

1. Ambos extremos del túnel utilizan Route-based (Tunnel interface) con subredes Any-to-Any.
2. Las interfaces XFRM creadas automáticamente reciben direcciones IP únicas de una red de tránsito propia.
3. OSPF o BGP establece la relación mediante estas direcciones de tránsito.
4. Las redes previstas se anuncian explícitamente en el protocolo de routing o se redistribuyen desde una ruta que exista realmente y esté limitada con filtros estrictos.
5. Las reglas de firewall permiten el tráfico de datos entre las zonas LAN y VPN.

De este modo, la ruta deja de ser un efecto secundario del túnel policy-based. XFRM, el protocolo de routing y los prefijos anunciados pueden comprobarse y modificarse por separado.

La migración se prepara en una ventana de mantenimiento. No deben mantenerse activas sin control conexiones policy-based y route-based con los mismos prefijos, ya que la superposición de selectores y rutas puede distorsionar la prueba.

Mantener IPsec policy-based por el momento

No es necesario migrar de inmediato todas las conexiones existentes. Sin embargo, si el túnel sigue siendo policy-based, el anuncio de prefijos requiere un diseño específico para la topología y planificado de forma consciente. Los procedimientos públicos documentados para SFOS 22 no incluyen ningún comando de sustitución general que vuelva a exponer las rutas VPN del backend como rutas del kernel para OSPF o BGP.

redistribute static solo es apropiado si la ruta estática es el data path correcto y la redistribución queda limitada a los prefijos previstos mediante ACL o Route Map. Una ruta adicional creada únicamente como fuente para la redistribución no constituye un procedimiento estándar seguro.

Modificar system route_precedence tampoco recupera la ruta del kernel ausente. El orden se aplica globalmente y puede cambiar otras rutas static, SD-WAN y VPN. Si es necesario modificarlo por un conflicto de routing concreto, Cambiar Route Precedence con seguridad explica las comprobaciones y el rollback.

Validar la migración y el funcionamiento

Una prueba correcta consta de varios niveles independientes:

1. La interfaz XFRM está activa y configurada con la IP de tránsito prevista.
2. OSPF alcanza Full o BGP Established.
3. Solo se anuncian los prefijos previstos y se aprenden en el extremo remoto.
4. Route Lookup y Routing Information muestran la ruta planificada para un destino concreto.
5. Log Viewer y Packet Capture muestran la regla de firewall prevista, así como las interfaces de entrada y salida.
6. Un servicio real funciona en ambas direcciones y utiliza la ruta de retorno correcta.
7. Con conexiones WAN redundantes o HA, se prueba por separado un failover controlado.

Route Lookup comprueba el recorrido de reenvío local, pero no el anuncio del prefijo a un Neighbor OSPF o BGP. Por eso deben evaluarse conjuntamente Route Lookup, el prefijo recibido, el Neighbor de routing, el flujo de paquetes y una prueba real de la aplicación.

Delimitar los errores de forma sistemática

El Neighbor está activo, pero falta el prefijo VPN

Primero se comprueba en show running-config si la red llegaba hasta ahora a OSPF o BGP únicamente mediante redistribute kernel. Después se determina el tipo de túnel y el build de SFOS. Si se trata de IPsec policy-based en SFOS 22, la entrada ausente desde el kernel es la explicación más probable; el Neighbor no tiene por qué fallar.

El prefijo se anuncia, pero el tráfico no funciona

En ese caso, la falta de redistribución del kernel ya no es la causa inmediata. Hay que comprobar por separado Route Lookup, las reglas de firewall, NAT, la ruta de retorno, la dirección XFRM y los Traffic Selectors. Un prefijo anunciado no demuestra que los recorridos de ida y vuelta sean correctos.

ipsec_route existe, pero OSPF o BGP no incorpora la red

Este comportamiento es normal en SFOS 22. system ipsec_route show muestra la asignación manual del túnel configurada, pero no confirma ni una ruta normal del kernel ni un data path funcional. Por tanto, otra ipsec_route para la misma red no recupera redistribute kernel. Crear una ruta IPsec en Sophos Firewall explica la clasificación exacta y la sintaxis segura de Add/Delete.

El tráfico falla después de añadir una ruta estática de sustitución

La nueva ruta puede sobreponerse al recorrido VPN real. Hay que revertir el cambio con el comando y el plan de mantenimiento documentados previamente, comprobar Route Precedence y repetir la última prueba correcta. No se deben modificar al mismo tiempo otros ajustes de routing, NAT y VPN.

Volver atrás de forma segura

Antes de la migración se guardan la conexión policy-based, la configuración de routing, Route Precedence, las reglas y los prefijos recibidos. Durante el rollback solo se revierte el recorrido que se ha modificado:

• eliminar de forma controlada los nuevos anuncios y filtros OSPF o BGP,
• eliminar las rutas XFRM solo cuando el data path anterior vuelva a estar activo y comprobado,
• restaurar exactamente la Route Precedence original si se ha modificado,
• eliminar por completo las rutas auxiliares artificiales,
• volver a comprobar el túnel, el estado del Neighbor, los prefijos y el tráfico real.

El rollback solo termina cuando el acceso de administración y las conexiones de producción vuelven a funcionar mediante el recorrido de origen documentado.

FAQ