Configurar y comprobar OSPF en Sophos Firewall

OSPF intercambia automáticamente rutas IPv4 entre routers. Esto resulta útil cuando hay varias sedes, rutas redundantes o redes que cambian con frecuencia y mantenerlas mediante rutas estáticas se vuelve demasiado laborioso. Para un dominio de routing pequeño o existente con pocos routers, RIPv2 puede ser más sencillo; OSPF ofrece, en cambio, una convergencia más rápida y un modelo de rutas más escalable.

En el siguiente ejemplo, dos Sophos Firewall forman una adyacencia OSPF a través de una red de tránsito dedicada. Al final, el vecino aparece como Full, Firewall A conoce la LAN situada detrás de Firewall B y viceversa. Para IPv6, OSPFv3 se configura por separado.

⚠️ Las adyacencias OSPF solo deben establecerse en interfaces de tránsito o VPN dedicadas y de confianza. En el ejemplo, la LAN también se registra como OSPF Network para que SFOS anuncie su prefijo. Así, SFOS activa OSPF en la interfaz LAN y puede enviar OSPF Hellos salientes. Dynamic Routing permanece desactivado para la zona LAN, por lo que no permite paquetes OSPF entrantes; esto no impide los Hellos salientes. No active Redistribute connected hasta saber qué redes conectadas directamente anunciará.

Resumen del procedimiento

Para establecer una conexión OSPFv2 sencilla se necesitan estos pasos:

Asignar direcciones a las interfaces de tránsito y comprobar la conectividad IP directa.
En Administration > Device access, permitir Dynamic Routing para una zona de tránsito propia o mediante una Local Service ACL Exception estrictamente limitada.
En Routing > OSPF, introducir un Router ID único en cada firewall.
Crear Area 0.0.0.0 como Normal.
En Networks, asignar la red de tránsito local a Area 0.0.0.0.
Registrar la LAN correspondiente como segunda red OSPF o usar una redistribución verificada por separado.
En Routing > Information > OSPF, comprobar que el estado del vecino sea Full y que la ruta se haya aprendido.

Un Network de OSPF no es la red de destino remota. La entrada activa OSPF en las interfaces locales cuya dirección IP pertenece a esa red. La LAN remota solo aparece cuando el otro extremo la anuncia a través de OSPF.

Qué decide OSPF en el firewall

OSPF es un protocolo de enrutamiento interno de estado de enlace. Los routers vecinos intercambian información sobre las redes y rutas que pueden alcanzar, construyen con ella una Link-State Database y calculan el camino de menor coste. Se prefiere un Cost menor frente a uno mayor.

Por tanto, OSPF resuelve una tarea distinta de las reglas de firewall y SD-WAN:

OSPF aprende y distribuye redes de destino dentro del dominio de enrutamiento propio.
Una regla de firewall sigue decidiendo si el tráfico de datos puede pasar entre las zonas y redes implicadas.
NAT modifica las direcciones cuando es necesario, pero no forma parte de OSPF.
Una SD-WAN Route puede decidir adicionalmente según el origen, el servicio, la aplicación o la calidad del enlace.

Las rutas OSPF aparecen junto con las demás rutas unicast. El enrutamiento clásico selecciona primero el prefijo coincidente más largo. Para el mismo prefijo, SFOS compara la Administrative Distance de las distintas fuentes; entre rutas OSPF comparables, decide después la métrica OSPF. Por separado, la Route Precedence global determina si se evalúan primero el enrutamiento clásico, las SD-WAN Policy Routes o las rutas VPN. Antes de un cambio global, registre el orden con system route_precedence show.

OSPFv2 procesa IPv4. OSPFv3 cumple la misma función para IPv6, pero se configura por separado en Sophos Firewall.

Planificar la topología de ejemplo

Los valores del ejemplo representan dos sedes:

Firewall A: Router ID 192.0.2.10, IP de tránsito 198.51.100.1/30, LAN local 10.10.10.0/24
Firewall B: Router ID 192.0.2.20, 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
OSPF Area: 0.0.0.0

Las direcciones 192.0.2.0/24 y 198.51.100.0/24 son redes de documentación. Se deben sustituir por los valores reales del entorno.

El Router ID tiene el aspecto de una dirección IPv4, pero no es necesario que esté asignado a una interfaz. Lo importante es que sea único y se mantenga estable de forma permanente dentro del dominio OSPF. 0.0.0.0 no está permitido. Si no se especifica un valor propio, SFOS utiliza la dirección de interfaz más alta; elegir de forma consciente un Router ID evita que la identidad cambie inesperadamente después de modificar una interfaz.

Para este diseño sencillo basta con Backbone Area 0.0.0.0. Solo merece la pena utilizar varias Areas cuando se quiere dividir y resumir deliberadamente un dominio de enrutamiento más grande. Cada Area adicional necesita una conexión con Backbone Area.

Preparar OSPF de forma segura

Antes de configurar OSPF deben cumplirse los siguientes requisitos:

El firewall funciona en Gateway Mode. OSPF no está disponible en Transparent Mode.
Ambas IP de tránsito pertenecen a la misma red y pueden comunicarse directamente, por ejemplo mediante Ping.
La interfaz, la máscara de subred, la MTU y la zona están documentadas.
Router ID, Area, autenticación, Hello interval y Dead interval están coordinados en ambos lados.
Se dispone de una copia de seguridad de la configuración y de un acceso de administración independiente.
Se han planificado reglas de firewall y rutas de retorno adecuadas para ambas LAN.

Una VLAN de tránsito y una zona de tránsito propias facilitan la protección. Configurar zonas e interfaces de Sophos Firewall explica los fundamentos.

Habilitar Dynamic Routing de forma selectiva

En Administration > Device access, Dynamic Routing está desactivado de forma predeterminada para todas las zonas. Para el ejemplo, el servicio se activa únicamente en la zona de tránsito propia a la que está vinculada la red 198.51.100.0/30.

La casilla de Device Access se aplica a toda la zona. Por tanto, una zona de tránsito dedicada es la opción más clara. Si la interfaz comparte su zona, una Local service ACL exception rule puede restringir IP version, Source zone, Source networks and hosts, Destination host, servicio Dynamic Routing, Action y posición. Sin embargo, OSPFv2 usa los destinos multicast 224.0.0.5 y 224.0.0.6; la dirección de tránsito local no es necesariamente un Destination host funcional. Confirme la coincidencia multicast en la build SFOS instalada. Sin confirmación, la zona dedicada sigue siendo la opción segura.

Este permiso afecta a los paquetes OSPF destinados al propio firewall. No hace falta una regla de firewall normal para ellos. Sin embargo, el tráfico real entre 10.10.10.0/24 y 10.20.20.0/24 sigue necesitando reglas de firewall IPv4 adecuadas. Proteger Device Access en Sophos Firewall explica la separación entre los servicios locales y el tráfico reenviado.

Configurar OSPFv2 en WebAdmin

Los siguientes pasos se realizan en ambos firewalls. Solo cambian Router ID, la IP de tránsito y la LAN local.

1. Definir los ajustes globales

⚠️ Los valores del ejemplo son para una configuración inicial. No sustituir sin precaución el Router ID de un router existente: la ayuda de SFOS 23 advierte de que cambiarlo reinicia todas las sesiones OSPF. Esto no significa que las versiones anteriores estén exentas. Antes del cambio, asegurar una copia de seguridad y acceso de administración independiente, registrar vecinos y rutas y planificar una ventana de mantenimiento. Después, las adyacencias previstas deben volver a Full, los prefijos deseados estar presentes, los no deseados ausentes y las conexiones reales y sus rutas de retorno funcionar.

En Routing > OSPF se definen los valores globales:

Router ID: 192.0.2.10 en Firewall A, 192.0.2.20 en Firewall B
Default metric: mantener 20, salvo que exista un requisito específico para las rutas redistribuidas
ABR type: Standard para un diseño estándar nuevo
Auto-cost reference-bandwidth: mantener el valor predeterminado 100000 Mbps, mientras la planificación de costes no exija otro valor de referencia común
Default-information originate: Never, mientras el firewall no deba distribuir expresamente una Default Route a todos los vecinos OSPF
Redistribute connected, static, RIP y BGP: mantener desactivados inicialmente

A continuación, aplicar la configuración global con Apply.

Default metric es el valor de respaldo para las rutas redistribuidas cuando no se ha configurado una métrica específica para su tipo de ruta. Un Area Border Router (ABR) conecta otras áreas con el backbone y mantiene una base de datos de topología y datos de enrutamiento separados para cada área conectada. OSPFv2 ofrece Standard, Cisco, IBM y Shortcut en ABR type para garantizar la compatibilidad con el dominio existente; la elección debe ajustarse al diseño acordado.

Al migrar de una versión anterior a SFOS 19.5 o posterior, el antiguo valor predeterminado de Reference Bandwidth, 100, pasa a 100000 Mbps. Un valor personalizado se conserva sin cambios. Después de actualizar, comparar el valor real y los costes resultantes con la planificación de costes.

Un Autonomous System Boundary Router (ASBR) incorpora a OSPF rutas de otras fuentes de enrutamiento. Las métricas externas siguientes se refieren a este router.

La métrica predeterminada se aplica a rutas importadas en OSPF. Para rutas redistribuidas y la Default Route anunciada puede elegirse Metric type. External type 1 suma el coste interno hasta el ASBR y el externo. Con External type 2, primero se compara la métrica externa; si es igual, el camino interno hasta el ASBR sirve como desempate. El coste de interfaz determina la selección dentro de OSPF. Un coste menor gana.

Default-information originate: Always no debe utilizarse como un interruptor rápido de conmutación por error de Internet. De este modo, el firewall anunciaría una Default Route aunque no dispusiera de una. Regular solo la anuncia cuando existe una Default Route en la tabla de enrutamiento.

2. Crear Backbone Area

En la sección Areas, hacer clic en Add y establecer los valores siguientes:

Area: 0.0.0.0
Type: Normal

Area cost solo puede configurarse para tipos de área distintos de Normal; no está disponible para el área backbone del ejemplo. En un área Normal, Virtual links > Add permite añadir un enlace virtual para conectar al backbone un área sin conexión física a él. Es un cambio multiárea planificado, no un sustituto de la comprobación de la topología física.

En Area se selecciona Authentication Type Text o MD5. Si el otro extremo admite MD5, es preferible a la variante de texto sin cifrar. La Key ID correspondiente y la clave se introducen más adelante en la interfaz de tránsito. MD5 autentica los paquetes OSPF, pero no cifra la información de enrutamiento intercambiada.

Después, guardar Area con Save.

Para este diseño sencillo, Area 0.0.0.0 permanece como Normal. Una Stub Area no recibe rutas externas al AS, mientras que Stub no-summary también suprime las rutas de resumen normales, excepto la ruta predeterminada. Una NSSA puede introducir en el dominio OSPF sus propias rutas externas como LSA de tipo 7; NSSA no-summary combina esta función con una restricción de resúmenes más estricta. Un Virtual Link solo está disponible en una Normal Area. No se debe cambiar el tipo de Area como medida rápida de diagnóstico, ya que ambos extremos y todo el diseño del Area deben coincidir.

3. Añadir la red de tránsito

En la sección Networks, hacer clic en Add:

IPv4/Netmask: 198.51.100.0/30
Area: 0.0.0.0

En Firewall A, la dirección 198.51.100.1 coincide con este Network; en Firewall B, coincide 198.51.100.2. De este modo, OSPF se ejecuta en las respectivas interfaces de tránsito y ambos firewalls pueden formar una adyacencia.

Guardar la entrada de Network con Save.

Una red OSPF siempre se refiere a una red local: SFOS activa OSPF en cada interfaz cuya dirección coincide con la entrada y anuncia su prefijo. Para la LAN, este ejemplo también utiliza una entrada de red en el paso 5, porque así en WebAdmin se puede seleccionar y eliminar exactamente el prefijo deseado. La desventaja es que, de esta manera, la interfaz LAN también se convierte en parte de OSPF. Una redistribución filtrada evita esto, pero bajo SFOS 22 requiere una configuración de CLI revisada por separado junto con su reversión.

4. Sobrescribir los valores de interfaz solo deliberadamente

En Override interface configuration se puede seleccionar la interfaz de tránsito. Los valores predeterminados son adecuados para muchas conexiones Ethernet:

Hello interval: 10 segundos
Dead interval: 40 segundos
Retransmit interval: 5 segundos
Transmit delay: 1 segundo
Interface cost: Auto
Router priority: 1

Hello interval controla el intervalo entre los paquetes Hello utilizados para descubrir vecinos. Dead interval determina cuánto se espera sin recibir un Hello antes de declarar que un vecino no está disponible. SFOS establece Dead automáticamente en cuatro veces Hello; después de cambiar Hello, comprobar que el valor calculado está dentro del rango permitido y coincide con los vecinos. Dead también puede modificarse manualmente. Retransmit interval controla la retransmisión de Link-State Advertisements (LSA); Transmit delay tiene en cuenta el retardo de transmisión y propagación de una actualización de estado de enlace.

DR significa Designated Router y BDR, Backup Designated Router. En la elección se prefiere la Router Priority más alta; en caso de empate, gana el Router ID más alto.

Hello y Dead deben ser idénticos en todos los routers del segmento. Retransmit Interval y Transmit Delay se establecen localmente. Cost y Router Priority pueden diferir de forma intencionada: Cost determina la ruta de datos preferida, mientras que Priority influye en la elección de DR y BDR en redes de difusión. Una Priority de 0 excluye la interfaz de esta elección.

Si la Priority es la misma, decide Router ID, pero un router nuevo con mayor prioridad no sustituye automáticamente al DR ya elegido. Definir manualmente un Cost resulta útil cuando se quiere preferir una de varias rutas. Con Auto, SFOS calcula el Cost a partir de la Reference Bandwidth global y la velocidad de interfaz configurada. Si se modifica la velocidad del enlace en Network > Interfaces, OSPF solo aplica el nuevo Auto Cost después de reiniciar el firewall.

Para la autenticación MD5, seleccionar Authentication Type MD5 en Area. Después, introducir la misma Key ID de 0 a 255 y la misma clave en la interfaz de tránsito de ambos lados.

Si se elige Text para OSPFv2, introducir una contraseña de autenticación en la interfaz y coordinarla con el otro extremo. Esto no se aplica a OSPFv3, que no admite autenticación.

Aplicar los valores modificados de la interfaz con Save.

5. Anunciar solo las LAN necesarias

En el ejemplo, Firewall A debe anunciar 10.10.10.0/24 y Firewall B, 10.20.20.0/24. Existen dos métodos fundamentalmente distintos:

Un OSPF Network toma la interfaz local correspondiente en OSPF y anuncia su prefijo.
Redistribution asume rutas de otra fuente de enrutamiento en OSPF.

Hacer clic en Routing > OSPF > Networks sobre Add y asignar la LAN correspondiente al área 0.0.0.0: en Firewall A 10.10.10.0/24, en Firewall B 10.20.20.0/24. Guardar la entrada con Save. Dynamic Routing permanece desactivado para la zona LAN; el servicio solo está permitido para la zona de tránsito o la excepción cerrada de ACL de servicio local. Después, la contraparte debe aprender exactamente esta LAN. Una red local no deseada sirve como control negativo y no debe aparecer en su tabla de enrutamiento OSPF.

Esta variante es adecuada siempre que las interfaces LAN puedan formar parte de OSPF de manera consciente. Si OSPF no debe activarse allí en general o si los prefijos a distribuir provienen de Static, RIP o BGP, la redistribución es el método más adecuado. Sin embargo, la opción Redistribute connected en el WebAdmin asume todas las redes conectadas directamente. En un firewall productivo, esto también puede incluir redes WAN, de gestión, DMZ, VPN y otras VLAN. Por lo tanto, la casilla no debe activarse sin consideración.

En Remote Access SSL VPN, Redistribute connected solo importa la subred dinámica de clientes. Una subred SSL VPN asignada de forma estática no se inyecta automáticamente y, si realmente se necesita, debe configurarse como OSPF Network independiente y comprobarse por separado.

WebAdmin no permite filtrar las Connected Routes por prefijo individual. La ayuda de línea de comandos de SFOS 22 muestra una ACL con Route Map para este fin, pero solo documenta un ejemplo de exclusión y no el rollback completo de una lista de permitidos en producción. Sin un procedimiento de rollback verificado en la versión de SFOS utilizada, no se puede extraer de ahí una receta segura para copiar y pegar. Quien necesite redistribución selectiva debe planificar la ACL y la Route Map como un cambio de enrutamiento independiente, confirmar la sintaxis y el rollback para la compilación instalada y comprobar en el otro extremo tanto el prefijo deseado como al menos una red que expresamente no deba anunciarse.

La opción global WebAdmin Redistribute connected permanece desactivada en una variante filtrada por CLI. Después de cambios posteriores en la configuración global de OSPF, show running-config debe ser verificada nuevamente, porque WebAdmin puede eliminar configuraciones avanzadas de CLI que sean contradictorias y cambios en log-adjacency-changes. También Redistribute static solo se activará después de un inventario completo de las rutas estáticas existentes.

Configurar y revertir OSPF en la CLI

Desde SFOS 23.0: los nombres de Access Lists, Prefix Lists y Route Maps deben ser únicos entre todos los protocolos de enrutamiento dinámico, porque comparten una configuración integrada. Al actualizar desde una versión anterior hacia SFOS 23.0 o posterior, Sophos Firewall añade automáticamente prefijos de protocolo a los nombres de Route Maps, Prefix Lists y Access Lists si existe un conflicto de nombres y actualiza todas las referencias a las configuraciones renombradas. Antes de una redistribución selectiva o del rollback, comparar los nombres de objetos y las referencias guardados antes de la actualización con la configuración actual; no asumir que un nombre antiguo sigue identificando la asociación actual. Después del cambio o del rollback, comprobar en el otro extremo que los prefijos deseados estén presentes y los expresamente prohibidos estén ausentes. Inventariar nombres y referencias de todos los protocolos antes de elegir nombres o planificar el rollback. Retirar solo las referencias de este cambio; no eliminar indiscriminadamente objetos compartidos. Los demás protocolos deben conservar sus vecinos y rutas previstos. No se ofrece una receta de filtrado ejecutable sin confirmar sintaxis y rollback.

SFOS 22, solo OSPFv2/IPv4: la CLI de OSPF se encuentra en 3. Route Configuration > 1. Configure Unicast Routing > 2. Configure OSPF. La configuración mínima siguiente para Firewall A reproduce la red de tránsito y el anuncio LAN del ejemplo WebAdmin. Se conserva la secuencia documentada de SFOS 22 con exit y write en el contexto global ospf(config)#.

⚠️ Antes de ospf router-id en un router existente, aplicar las mismas comprobaciones previas que en WebAdmin: según la ayuda de SFOS 23, cambiar el Router ID reinicia todas las sesiones OSPF. No sustituirlo por el valor de ejemplo. Asegurar copia de seguridad y acceso de administración independiente, registrar vecinos y rutas y usar una ventana de mantenimiento; comprobar después adyacencias Full, prefijos deseados/no deseados y tráfico real.

enable
configure terminal
router ospf
ospf router-id 192.0.2.10
network 198.51.100.0/30 area 0
network 10.10.10.0/24 area 0
log-adjacency-changes
exit
write
show running-config
end

SFOS 23, solo OSPFv2/IPv4: 3. Route Configuration > 1. Configure Unicast Routing abre la consola de enrutamiento común en router# (EXEC). configure terminal lleva a router(config)# (configuración global), y router ospf a router(config-ospf)#. Desde router#, introducir estos comandos sin los indicadores mostrados:

router# configure terminal
router(config)# router ospf
router(config-ospf)# ospf router-id 192.0.2.10
router(config-ospf)# network 198.51.100.0/30 area 0
router(config-ospf)# network 10.10.10.0/24 area 0
router(config-ospf)# log-adjacency-changes
router(config-ospf)# end
router# show running-config
router# write

end vuelve directamente a EXEC. La ayuda de configuración de SFOS 23 muestra allí show running-config y write, aunque su nota exige genéricamente do write. El ejemplo de filtrado muestra específicamente router(config)# do write después de salir de OSPF con exit. Esta tensión documental no demuestra que EXEC write no guarde: aquí se sigue el ejemplo de configuración con modos explícitos, no un write sin calificar en modo de configuración de SFOS 23.

show running-config muestra el estado en ejecución, no una prueba de guardado. Tras write en SFOS 23, comprobar la confirmación para el archivo integrado /conf/routing/frr.conf; el ejemplo de filtrado de SFOS 22 aún cita /conf/routing/ospfd.conf. No editar el archivo a mano. Según Sophos, los cambios CLI deben guardarse para aparecer en WebAdmin y persistir tras reiniciar el firewall o el demonio. Comprobar la confirmación y los valores WebAdmin previstos; aquí no se exige reiniciar y no se ha realizado esa prueba para este artículo. Si falta la confirmación, consultar con Sophos antes de otros cambios. Después, comprobar vecinos, rutas y tráfico.

En el firewall B se utilizan en su lugar el ID de router 192.0.2.20 y la red LAN 10.20.20.0/24.

La ID del router debe ser única, no puede ser 0.0.0.0 y no necesita ser una dirección IP realmente asignada. Sin una configuración manual, SFOS utiliza la IP de interfaz más alta. La ID del área puede ingresarse como un número de 0 a 4294967295 o en notación IPv4. SFOS guarda la red normalizada según la máscara; por eso, de 198.51.100.1/30 se obtiene 198.51.100.0/30. Exactamente este valor guardado es el que más tarde se utiliza para control y eliminación. log-adjacency-changes registra cambios de vecinos sin modo de depuración y se establece de manera predeterminada en una configuración de WebAdmin.

Distinguir Network, proceso OSPF y Default Route

SFOS 22, OSPFv2/IPv4: para retirar solo un Network, aplicar no a su línea normalizada en show running-config, bajo router ospf. Antes de retirar la red de tránsito, asegurar rutas alternativas, copia de seguridad y acceso de administración independiente y planificar una ventana de mantenimiento: se perderá la adyacencia de ese segmento.

enable
configure terminal
router ospf
no network 198.51.100.0/30 area 0
exit
write
show running-config
end

Esto hace que OSPF termine en las interfaces correspondientes y los anuncios afectados desaparezcan. En cambio, no router ospf elimina la configuración de enrutamiento OSPFv2. Antes de este paso destructivo, se guardan la configuración completa en ejecución, una copia de seguridad y rutas alternativas; el comando debe ejecutarse en una ventana de mantenimiento y no es un interruptor de encendido/apagado temporal.

SFOS 23, OSPFv2/IPv4: iniciar la misma retirada del Network en router# de la consola común. La descripción general de SFOS 23 documenta no network en router(config-ospf)#; seguir después el mismo flujo de comprobación y guardado en EXEC:

router# configure terminal
router(config)# router ospf
router(config-ospf)# no network 198.51.100.0/30 area 0
router(config-ospf)# end
router# show running-config
router# write

Después deben faltar exactamente el Network previsto y su anuncio; los vecinos restantes, rutas alternativas, acceso de administración y tráfico deben funcionar según lo planificado. Comprobar también la confirmación de guardado. Para revertir este cambio concreto, restaurar la entrada network … area … registrada previamente en el contexto OSPF de la versión correspondiente, guardar y comprobar de nuevo.

Para eliminar todo el proceso, SFOS 22 indica ospf(config)# no router ospf, mientras que la descripción general de SFOS 23 muestra router(config-ospf)# no router ospf. Es un cambio de indicador documentado, no un fallo de comando demostrado. Este contexto de SFOS 23 no se ha confirmado aquí en un dispositivo. Por tanto, no se ofrece un procedimiento ejecutable de eliminación del proceso de SFOS 23 hasta que Sophos confirme el contexto y la restauración para la build instalada; no deducir otro modo. No eliminar indiscriminadamente ACL, Prefix Lists o Route Maps compartidas.

ospf push-default-route-to-kernel realiza una tercera tarea separada: una ruta por defecto aprendida a través de OSPF se incorpora en la tabla de enrutamiento del kernel. El comando no anuncia ninguna ruta por defecto a los vecinos y, por lo tanto, no es lo mismo que Default-information originate. Previamente se aseguran las rutas por defecto existentes, la precedencia de rutas, el camino de retorno de gestión y la búsqueda de rutas. La eliminación oficialmente documentada se realiza en el indicador OSPF con no ospf push-default-route-to-kernel; después de eso, se vuelven a comprobar la tabla de enrutamiento, la búsqueda de rutas, el acceso de gestión y el tráfico real.

Los cambios globales en WebAdmin pueden eliminar ajustes de CLI incompatibles. Después de cada cambio se vuelven a comprobar show running-config, vecinos, rutas aprendidas y la configuración guardada.

Comprobar y validar OSPF

Una adyacencia por sí sola no demuestra que se pueda alcanzar la LAN deseada. Por eso, la validación abarca desde el nivel OSPF hasta el flujo real de paquetes.

En Routing > Information > OSPF > Neighbors, el otro extremo debe aparecer con su Router ID. Full indica que la información de estado de enlace relevante se ha intercambiado por completo.
Bajo Routes, el Firewall A debe ver 10.20.20.0/24 a través de 198.51.100.2. El Firewall B espera 10.10.10.0/24 a través de 198.51.100.1. Un prefijo de prueba no autorizado, en cambio, no debe aparecer.
Bajo Interface se controlan el área, ID del enrutador, costo, temporizador, tipo de red y MTU. Database muestra la base de datos de estado de enlace; Border routers ayuda a revisar entradas de ABR y ASBR en diseños de múltiples áreas.
En Diagnostics > Tools > Route lookup, comprobar un destino concreto, por ejemplo 10.20.20.10 en Firewall A.
A continuación, probar una conexión real entre un host de cada LAN. Log Viewer y Packet Capture deben mostrar la regla de firewall esperada, la interfaz de tránsito y el tráfico de retorno.

Para los dos últimos pasos puede resultar útil Probar una regla de Sophos Firewall con Log Viewer y Packet Capture.

Para una comprobación SSH adicional, SFOS 22 usa 3. Route Configuration > 1. Configure Unicast Routing > 2. Configure OSPF; SFOS 23 usa 3. Route Configuration > 1. Configure Unicast Routing para abrir la consola común. En SFOS 23, volver a router# con end y ejecutar allí show running-config. Muestra la configuración en ejecución, no una prueba de guardado; la confirmación separada se explica arriba. Vecino, base de datos, interfaces y rutas calculadas se comprueban de manera fiable en SFOS 22 bajo Routing > Information > OSPF; por eso, este artículo no menciona comandos de visualización de demonios de enrutamiento no documentados.

En Advanced Shell, los registros de OSPF y del kernel ofrecen contexto adicional. El acceso se realiza mediante 5. Device Management > 3. Advanced Shell:

cd /log
tail -f ospfd.log

La salida continua se detiene con Ctrl+C. Después se puede comprobar el segundo registro:

tail -f zebra.log

ospfd.log muestra los eventos de OSPF. zebra.log ayuda a comprobar si una ruta aprendida dinámicamente se ha incorporado al kernel. Para no seguir el registro en directo, se puede utilizar, por ejemplo, less /log/ospfd.log. Archivos de servicio y registro de Sophos Firewall relaciona otros archivos con los servicios responsables.

Delimitar los errores sistemáticamente

No aparece ningún vecino

Primero se comprueba la conectividad directa de las IP de tránsito. Después, la interfaz de tránsito debe estar activa, OSPF Network debe coincidir con la IP de interfaz local y Dynamic Routing debe estar habilitado en la zona correcta. Area, máscara de subred, Authentication Type, Key ID, clave, Hello y Dead deben coincidir en ambos lados. Los Router ID duplicados también impiden establecer correctamente una adyacencia.

El vecino permanece en Init o 2-Way

Init significa que llegan paquetes Hello, pero la comunicación aún no se ha confirmado en ambas direcciones. Device Access, los filtros asimétricos, la asignación de interfaces y la ruta de retorno son los primeros puntos que se deben comprobar.

2-Way es normal entre dos routers de una red de difusión si ninguno de ellos es DR ni BDR. En el ejemplo, con exactamente dos routers OSPF y Priority 1, ambos participantes se convierten en DR y BDR; por eso, su adyacencia debe alcanzar el estado Full. Si permanece en 2-Way, hay que comprobar Router Priority, Network Type y el otro extremo.

El vecino permanece en ExStart, Exchange o Loading

En estos estados, la sincronización de Link-State Database ha comenzado, pero no se completa. Las causas habituales son valores de MTU distintos, Network Types incompatibles, Router ID duplicados o conexiones inestables. En Routing > Information > OSPF > Interface se muestran MTU, MTU Mismatch Detection, Network Type y los temporizadores para compararlos.

El vecino está Full, pero falta la LAN remota

Entonces funciona la vecindad, pero la LAN no se anuncia. Con el método de red utilizado en este ejemplo, la ruta conectada debe estar presente en el firewall emisor y en router ospf debe aparecer la entrada correspondiente network … area …. show running-config muestra el valor normalizado en la configuración en ejecución, no su estado de guardado.

Si en su lugar se utiliza la redistribución, la fuente de enrutamiento elegida así como, en su caso, ACL, mapa de rutas y redistribute … route-map deben coincidir con el prefijo deseado. En Redistribute connected, además, se debe controlar la lista completa de todas las rutas conectadas anunciadas.

Si después de actualizar a SFOS 22 falta precisamente una red situada detrás de un túnel IPsec policy-based, la causa puede ser la dependencia de redistribute kernel. Tanto el túnel como el Neighbor OSPF pueden seguir apareciendo en buen estado; SFOS 22: rutas IPsec y redistribute kernel explica la comprobación y el diseño de destino XFRM route-based.

La ruta existe, pero el tráfico no funciona

OSPF ha cumplido su función cuando existe la ruta con el Next Hop correcto. A partir de ahí, los errores suelen encontrarse en la regla de firewall, NAT, Route Precedence, la ruta de retorno o el sistema de destino. En redes entre sedes con enrutamiento normal, por lo general no hace falta SNAT, porque ambos firewalls deben conocer las LAN mediante OSPF.

OSPF a través de IPsec route-based

OSPF también puede ejecutarse a través de una interfaz XFRM de un túnel IPsec de sitio a sitio basado en ruta. Para que SFOS cree las interfaces XFRM, la subred local y la remota deben ser Any en ambos lados. La configuración IPv4, IPv6 o dual determina las versiones de IP utilizadas; en el caso de dual, se deben crear manualmente reglas de firewall separadas para IPv4 e IPv6. Con selectores de tráfico específicos no se crea una interfaz XFRM direccionable a la que se puedan asignar direcciones IP o rutas.

Para esta variante se aplican además los requisitos siguientes:

Dynamic Routing se permite para la zona VPN en Administration > Device access.
La red de tránsito XFRM se introduce como OSPF Network.
El tráfico de datos necesita reglas de firewall IPv4 o IPv6 adecuadas para la zona VPN.
Hello, Dead, autenticación y MTU deben coincidir con el otro extremo.
El tipo de red OSPF mostrado se compara en ambos lados. Una desviación puede impedir la formación de la vecindad y debe aclararse en el diseño de los dos extremos.

Un túnel IPsec en verde y un vecino OSPF en estado Full son comprobaciones independientes. Solo la ruta aprendida y un flujo de paquetes real confirman que toda la configuración funciona.

La asistencia oficial de HA no garantiza la preservación del estado de Adyacencia OSPF. Por lo tanto, en un clúster HA, un failover planificado forma parte de la prueba de aceptación de la topología concreta. Después, en el nodo activo se comprueba si los vecinos, las rutas y ospfd.log y zebra.log muestran nuevamente el estado esperado.

OSPFv3 para IPv6

Límite de la ayuda CLI de SFOS 23: la ayuda de configuración añade router ospf6 y afirma que los mismos pasos valen para OSPFv3, pero continúa con comandos Router ID y Network de OSPF IPv4. La ayuda de filtrado añade ACL IPv6, pero conserva match ip address y router ospf en la secuencia posterior. Esto no acredita un procedimiento IPv6 completo y fiable para matching, redistribución y rollback. Los ejemplos CLI anteriores solo se aplican a OSPFv2/IPv4. Para IPv6 se mantiene el procedimiento WebAdmin basado en interfaces que sigue; usar un procedimiento CLI IPv6 solo tras la confirmación de Sophos para la build instalada. No sustituir tokens de comandos IPv4 ni tomar comandos upstream FRR como prueba de compatibilidad con Sophos.

Bajo Routing > OSPFv3, el enrutamiento IPv6 se configura independientemente de OSPFv2. La ID del enrutador sigue siendo un valor único en notación IPv4. Aunque SFOS muestra 0 para Default metric, utiliza el valor no modificable 20; ABR type está fijado en Standard. La Auto-cost reference-bandwidth está establecida por defecto en 100000 Mbps. Para Default-information originate existen, al igual que en OSPFv2, Never, Regular y Always; en el WebAdmin se pueden redistribuir rutas IPv6 Conectadas y BGP.

A diferencia de OSPFv2, no se registra primero una red. Bajo Interfaces se selecciona la interfaz habilitada para IPv6 y se asigna a un área. Para una configuración simple, aquí también se utiliza el Área 0.0.0.0. Hello y Dead deben coincidir en el segmento; Cost, Retransmit, Transmit Delay y Router Priority se configuran según la topología propia. SFOS solo admite una instancia de OSPFv3 por interfaz. La Instance ID es configurable; su valor predeterminado es 0.

Primero, en Routing > OSPFv3 > Interfaces and areas > Areas, hacer clic en Add, introducir Area en notación IPv4, elegir Type según el diseño y guardar con Save. Para el ejemplo sencillo, el área es 0.0.0.0. Después, en Routing > OSPFv3 > Interfaces and areas > Interfaces, hacer clic en Add, seleccionar Interface e introducir la misma Area, también en notación IPv4.

Los valores predeterminados de OSPFv3 son Hello 10, Dead 40, Retransmit 5 y Transmit delay 1 segundo, y Router priority 1. Los propósitos de los campos, el cálculo automático de Dead y la comprobación del rango permitido se aplican como se explica en el paso de interfaz de OSPFv2. La elección DR/BDR también prefiere la prioridad más alta y, en caso de empate, el Router ID más alto; 0 excluye la interfaz de la elección. Interface cost puede mantenerse en Auto o configurarse manualmente desmarcando la casilla; se prefieren valores menores. Auto utiliza Reference Bandwidth y la velocidad configurada de la interfaz. Al cambiar la velocidad configurada del enlace, el nuevo Auto Cost también se aplica únicamente después de reiniciar el firewall. Guardar la configuración de interfaz con Save.

Las Areas OSPFv3 adicionales pueden crearse como Stub, Stub no-summary, NSSA o NSSA no-summary. Las variantes se diferencian por los LSA externos y de resumen que transportan; una NSSA también puede entregar al ABR LSA de tipo 7 procedentes de su propia redistribución. Estos tipos de Area pertenecen a un diseño multiárea coordinado y no a un intento de reparación improvisado.

Stub no transporta LSA de tipo 4 ni 5 y no permite enlaces virtuales. Stub no-summary suprime además los LSA de tipo 3, excepto la ruta de resumen predeterminada, y tampoco permite enlaces virtuales. NSSA no recibe LSA externos de tipo 5 de otras áreas; sus propios LSA de tipo 7 circulan dentro de la NSSA y el ABR los convierte en LSA de tipo 5 para el backbone. NSSA no-summary suprime los tipos 4 y 5 y el tipo 3 salvo la ruta de resumen predeterminada, pero mantiene el tipo 7 y su conversión en el ABR. Estas propiedades no significan que SFOS ofrezca redistribución RIP o estática en WebAdmin para OSPFv3.

En la configuración global de OSPFv3, seleccionar solo los anuncios necesarios y establecer su métrica y Metric type. El significado de E1/E2 y los efectos de Never, Regular y Always se explican en el paso global de OSPFv2; la advertencia sobre Always también se aplica aquí. Aplicar con Apply. Esto puede eliminar cambios personalizados en log-adjacency-changes; después, volver a comprobar la configuración en ejecución y guardada, los vecinos, los prefijos IPv6 deseados y no deseados en Routing > Information > OSPFv3 y el tráfico IPv6 real.

Actualmente, Sophos Firewall no admite autenticación para OSPFv3. Por tanto, el intercambio solo debe realizarse mediante enlaces de confianza o ya protegidos. Una configuración OSPFv2 existente no anuncia redes IPv6 y el tráfico de datos IPv6 necesita reglas de firewall IPv6 propias.

Redistribute connected también registra todas las redes IPv6 directamente conectadas en OSPFv3 y, por lo tanto, no debe activarse de forma general. Según Sophos, en Remote Access SSL VPN solo se inyecta la subred dinámica, no la estática. La ayuda de SFOS-22 menciona para la subred estática una «red OSPF», aunque OSPFv3 en WebAdmin se configura a través de interfaces y no mediante una lista de redes. De esta contradicción no se puede derivar un procedimiento seguro; el anuncio de un prefijo IPv6 estático para SSL VPN debe aclararse para la versión instalada con Sophos.

La validación se realiza en Routing > Information > OSPFv3; si se producen errores, ospf6d.log proporciona contexto específico del protocolo.

Revertir el cambio de forma segura

Antes de eliminar OSPF, debe existir una ruta alternativa o una ventana de mantenimiento planificada para cada red de destino aprendida. En el ejemplo, primero se elimina la entrada de la red LAN, luego la red de tránsito y, por último, se desactiva Dynamic Routing para la zona de tránsito. Si la LAN se redistribuye en su lugar, primero se revierte esa redistribución. A continuación, se vuelven a comprobar la consulta de rutas, la tabla de enrutamiento y el acceso de gestión.

Si solo se revierte un Cost, un temporizador o un filtro incorrecto, se debe cambiar únicamente ese ajuste. Así se puede determinar si se ha visto afectada la adyacencia OSPF, el anuncio de rutas o solamente el tráfico de datos.