Ir al contenido
Avanet

SFOS 22: rutas IPsec policy-based en OSPF y BGP

Después de actualizar a SFOS 22, un túnel IPsec policy-based puede seguir funcionando mientras falta un prefijo VPN que antes se anunciaba mediante OSPF o BGP. La adyacencia de routing también puede permanecer en Full o Established.

Sophos documenta que SFOS 22 deja de crear las antiguas rutas VPN de IPsec policy-based y de usar ipsec0 en la ruta de transmisión. Si al mismo tiempo desaparece un prefijo OSPF o BGP, considere la relación con la redistribución una inferencia operativa observada: la KBA no describe redistribute kernel, OSPF ni BGP. Por tanto, la ausencia de un prefijo no significa automáticamente que el túnel haya fallado.

⚠️ No cree una ruta dummy, null, blackhole ni otra ruta auxiliar únicamente para anunciar el prefijo. Puede alterar el data path. Antes de modificar producción, aclare el diseño concreto con Sophos Support o en una ventana planificada de diseño y mantenimiento.

Diagnóstico rápido

Investigue este patrón de actualización a SFOS 22 cuando se cumplan todos estos puntos:

  1. El problema comenzó con la actualización a SFOS 22.
  2. El túnel es policy-based.
  3. OSPF o BGP utilizaba antes redistribute kernel para el prefijo VPN.
  4. El túnel y el Neighbor están activos, pero el router receptor no tiene el prefijo.

Si el túnel es route-based o la adyacencia ha fallado, investigue en su lugar el fallo correspondiente del túnel o del routing.

Por qué las vistas de routing habituales no bastan

La KBA indica que SFOS 22 deja de crear las antiguas rutas VPN policy-based. Por separado, describe las rutas ipsec_route como parte de la clase de precedencia vpn en SFOS 22 y como ausentes de la tabla de routing. No indica cómo trata la redistribución OSPF o BGP ninguno de los casos.

Evalúe por separado tres estados:

  • VPN: ¿Está activa la conexión IPsec y circula el tráfico?
  • Protocolo de routing: ¿Está activo el Neighbor OSPF o BGP?
  • Anuncio: ¿Aprende el router remoto exactamente el prefijo esperado?

Una VPN en verde no demuestra que se anuncie la ruta. A la inversa, la ausencia de una ruta en la vista de routing habitual no demuestra que un túnel policy-based esté averiado en SFOS 22.

Identificar el flujo VPN en la salida de conntrack

SFOS 22 ya no utiliza ipsec0 en la ruta de transmisión ni crea las antiguas rutas VPN. Para la conexión concreta que se está probando, utilice en su lugar los valores de conntrack: el tráfico hacia la VPN tiene mark=0x0, outzone=5 y el flag 74; el tráfico desde la VPN tiene mark=0x0, inzone=5 y el flag 75. La zona 5 es la zona VPN y el flag puede aparecer junto con otros valores en flagvalues.

Estos valores identifican la dirección de una conexión VPN observada, pero no demuestran un anuncio OSPF o BGP. En SFOS 22 también es normal que Packet Capture no muestre ipsec0 en la ruta de transmisión y que Route Lookup en Diagnostics > Tools pueda mostrar la interfaz WAN. Correlacione un flujo de prueba bien delimitado en conntrack y Packet Capture en lugar de considerar una sola vista como indicio de fallo.

Comprobar de forma segura y solo de lectura

Registrar los datos del firewall y de la VPN

  1. Registre la versión y el build de SFOS.
  2. En Site-to-site VPN > IPsec, registre el estado de la conexión, el tipo de túnel y las subredes locales y remotas configuradas.
  3. En Routing > Routing information, ejecute Route Lookup para un destino concreto teniendo en cuenta la limitación de visualización de las rutas VPN policy-based y ipsec_route.
  4. En 4. Device Console, muestre la configuración documentada:
system route_precedence show
system ipsec_route show

Estos comandos no realizan cambios. Route Precedence muestra el orden global de las clases de ruta; system ipsec_route show enumera las rutas IPsec manuales. Ninguno de los dos comandos demuestra por sí solo que OSPF o BGP anuncie un prefijo.

Con acceso de solo lectura a Advanced Shell, recopile también las vistas de rutas y conexiones que utiliza la KBA:

route -n
ip route show
conntrack -L

Limite la revisión de conntrack a los extremos y al intervalo temporal de la prueba. Estas salidas pueden confirmar la ausencia de la ruta antigua o de ipsec0 e identificar el flujo VPN probado; no demuestran redistribución ni anuncio.

Comprobar la prioridad de ipsec_route antes de cambiarla

En SFOS 21.5, una ruta añadida con ipsec_route pertenecía a la clase static; en SFOS 22 pertenece a la clase vpn. Con static sdwan_policyroute vpn, una ruta de política SD-WAN que coincida con los selectores VPN puede capturar el tráfico después de la actualización. Si el diseño revisado requiere que gane la VPN, Sophos documenta static vpn sdwan_policyroute como orden de destino y system route_precedence set static vpn sdwan_policyroute como comando que realiza el cambio.

No aplique ese comando basándose únicamente en este diagnóstico: Route Precedence es global y puede afectar a otro tráfico. Registre primero system route_precedence show, las políticas SD-WAN coincidentes, los caminos de ida y retorno y un punto de reversión. Después, utilice Cambiar Route Precedence de forma segura para las comprobaciones previas, el cambio controlado, la validación y la reversión.

Comprobar OSPF o BGP por separado

Utilice en la CLI de routing correspondiente los comandos de visualización documentados por Sophos:

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

Ejecute solo los comandos del protocolo utilizado. Registre también el prefijo y el next hop en el router receptor. Consulte Configurar y comprobar OSPF y Configurar y comprobar BGP para ver las comprobaciones completas.

Tomar la decisión de diseño

Se requiere routing dinámico

Para routing dinámico, Sophos documenta IPsec route-based Any-to-Any. Este diseño crea interfaces XFRM que pueden recibir direcciones y utilizarse para OSPF o BGP. De este modo, la adyacencia y los prefijos anunciados son elementos explícitos del diseño y no efectos secundarios de una ruta VPN policy-based.

Se trata de una dirección de diseño, no de un procedimiento universal de migración. El direccionamiento, los filtros de routing, las reglas de firewall, NAT, el camino de retorno, la redundancia y el peer dependen de la topología. Planifique el cambio con Sophos Support o en una ventana de diseño y mantenimiento antes de modificar producción. Los fundamentos del túnel se explican en Configurar una VPN IPsec Site-to-Site.

Debe mantenerse IPsec policy-based

La KBA no documenta la redistribución OSPF o BGP ni un comando que ponga la antigua ruta VPN a disposición de esos protocolos. Otra ipsec_route, un cambio de Route Precedence o una ruta estática artificial no sustituyen un diseño de routing revisado.

Si debe mantenerse IPsec policy-based, diseñe con Sophos Support la vía de anuncio específica de la topología. La comprobación de actualización a SFOS 22 y Crear una ruta IPsec en Sophos Firewall aportan contexto útil.

Antes de un cambio en producción

Facilite al menos estos datos para una sesión de soporte o diseño:

  • versión y build de SFOS, tipo de túnel y estado de HA;
  • prefijos locales y remotos anonimizados;
  • configuración OSPF o BGP anterior y estado del Neighbor;
  • prefijos esperados y recibidos con sus next hops;
  • resultados relevantes de Route Lookup, Log Viewer y Packet Capture;
  • requisitos de camino de retorno, NAT, failover y ventana de mantenimiento.

No cambie simultáneamente VPN, routing, NAT y reglas de firewall sin definir puntos de prueba y restauración. Tras aprobar el diseño, compruebe por separado cada nivel previsto: túnel/XFRM, Neighbor, prefijos anunciados, caminos de ida y retorno y un servicio real.

Distinguir los síntomas

Neighbor activo, prefijo ausente

Compare el tipo de túnel, el build de SFOS y show running-config. La ausencia de la antigua ruta VPN, una adyacencia activa y un prefijo no recibido son observaciones independientes. Compruebe en la configuración de routing y en el router receptor si la redistribución dependía de esa ruta.

Prefijo presente, tráfico afectado

En ese caso, la redistribución ausente no es la causa inmediata. Investigue por separado Route Lookup, las reglas, NAT y el camino de retorno.

ipsec_route presente, prefijo ausente

system ipsec_route show solo confirma la asignación manual. No confirma una ruta normal del kernel ni un anuncio OSPF o BGP.

No existe una secuencia universal de reversión

Sin la topología concreta no existe una secuencia segura para coexistencia, conmutación, retirada o failover. Esos pasos pertenecen al plan de cambios acordado con Sophos Support; este artículo no proporciona deliberadamente una secuencia de comandos.

FAQ

¿Restaura ipsec_route la ruta del kernel ausente en SFOS 22?

La KBA citada no lo establece. Documenta el comportamiento de visualización y precedencia de ipsec_route, pero no la redistribución. system ipsec_route show solo confirma la asignación manual; compruebe el prefijo anunciado en el router receptor.

¿Debe migrarse inmediatamente a IPsec route-based Any-to-Any?

No. Es la dirección de diseño documentada para routing dinámico, no una instrucción independiente de la topología. Un cambio en producción requiere un diseño revisado, una ventana de mantenimiento y, para este caso de actualización, coordinación con Sophos Support.