Configurar y comprobar BGP en Sophos Firewall

BGP intercambia rutas seleccionadas entre routers. En Sophos Firewall resulta especialmente útil para varias sedes, conexiones redundantes y VPN de AWS o Azure. Para una sola red de destino con un next hop fijo, una ruta estática suele ser más sencilla.

En el siguiente ejemplo, dos Sophos Firewalls establecen una sesión eBGP mediante una red de tránsito. Al final, el Neighbor se encuentra en Established, Firewall A conoce la LAN situada detrás de Firewall B y viceversa.

⚠️ Dynamic Routing solo debería ser accesible para el peer previsto. Cambiar el Router ID interrumpe todas las sesiones BGP; cambiar el Local AS también elimina todos los Neighbors y Networks configurados. Por tanto, ambas modificaciones deben realizarse en una ventana de mantenimiento planificada y con un backup actualizado.

BGP en siete pasos

Para una configuración IPv4 sencilla se necesitan estos pasos:

1. Definir las IP de tránsito, los ASN local y remoto y las redes que se van a anunciar.
2. Comprobar la conectividad IP directa entre los dos peers BGP.
3. En Administration > Device access, autorizar Dynamic Routing solo para la zona del peer o mediante una Local Service ACL Exception restrictiva; comprobar por separado las reglas de firewall necesarias para el diseño.
4. Definir Router ID y Local AS en Routing > BGP.
5. Añadir la IP del peer como Neighbor con el Remote AS.
6. Introducir únicamente los prefijos locales necesarios en Networks.
7. En Routing > Information > BGP-IPv4, comprobar el estado Established, la ruta aprendida y después el tráfico real.

Qué decide BGP en el firewall

BGP responde a la pregunta de qué redes son accesibles mediante qué router. Para ello, cada participante necesita varios valores claramente diferenciados:

• El Local AS identifica el sistema autónomo propio. Dos ASN distintos forman una conexión eBGP; el mismo ASN en ambos lados sería iBGP.
• El Remote AS es el ASN del peer.
• El Router ID identifica al router BGP dentro de la topología BGP. Tiene el aspecto de una dirección IPv4, pero no tiene que ser una dirección de interfaz y debería permanecer único y estable.
• Un Neighbor es la dirección IPv4 o IPv6 de la contraparte con la que se establece la sesión BGP. En el ejemplo es la IP de tránsito.
• Un Network es un prefijo local que el firewall debe anunciar al peer.

BGP no autoriza el tráfico de usuario ni lo cifra. Dynamic Routing en Device Access o una Local Service ACL controla el servicio BGP local. El tráfico que el firewall reenvía mediante rutas aprendidas necesita además reglas de firewall adecuadas, una ruta de retorno operativa y, según el diseño, una configuración NAT deliberada.

Para routing dinámico dentro de un único dominio de routing interno, OSPF suele ser la opción más natural. BGP resulta más adecuado entre distintos sistemas autónomos, con proveedores cloud o cuando las rutas deben controlarse de forma selectiva mediante políticas.

Planificar la topología de ejemplo

El ejemplo utiliza dos sedes:

• Firewall A: Local AS 65010, Router ID 192.0.2.10, IP de tránsito 198.51.100.1/30, LAN 10.10.10.0/24
• Firewall B: Local AS 65020, Router ID 192.0.2.20, IP de tránsito 198.51.100.2/30, LAN 10.20.20.0/24
• Red de tránsito: 198.51.100.0/30

Los rangos 192.0.2.0/24 y 198.51.100.0/24 son redes de documentación. Deben sustituirse por los valores reales del entorno. Los dos ASN privados son apropiados para un ejemplo interno; en una conexión con AWS, Azure o un proveedor se utilizan los valores de ASN y peer definidos por la contraparte.

El Router ID debe elegirse de forma consciente y mantenerse único y estable. Con Automatic, SFOS utiliza la IP de interfaz más alta. Si esta cambia posteriormente, la identidad del router también puede cambiar de forma inesperada. Un valor manual evita esta dependencia.

Preparar BGP de forma segura

Antes de configurar, deben cumplirse los siguientes requisitos:

• El firewall funciona en Gateway Mode. BGP no está disponible en Transparent Mode.
• Las dos IP de tránsito pueden comunicarse directamente. En un túnel XFRM, la interfaz del túnel también debe estar up.
• Local AS, Remote AS, IP de los peers y prefijos permitidos se han acordado con la contraparte.
• La tabla de routing local y los Networks previstos están documentados para poder comprobar de forma selectiva cada anuncio después de la configuración.
• Hay disponibles un backup de configuración actualizado y un acceso de gestión independiente.
• Se han planificado las reglas de firewall y las rutas de retorno para el posterior tráfico de usuario.

Configurar zonas e interfaces en Sophos Firewall explica los fundamentos de la interfaz de tránsito y la zona. Antes de modificar un entorno de routing productivo, también debería estar disponible un backup actualizado del firewall fuera de la appliance.

Autorizar Dynamic Routing de forma selectiva

En Administration > Device access, Dynamic Routing está desactivado de forma predeterminada para todas las zonas. Si existe una red dedicada exclusivamente al tránsito, el servicio puede activarse en esa zona.

Si la interfaz del peer comparte su zona LAN o WAN con otras redes, una Local Service ACL Exception para la IP concreta del peer o la red de tránsito es más restrictiva que habilitar toda la zona. En Administration > Device access > Local service ACL exception rule > Add, se crea para ello una regla Accept con IP version, Source zone, Source networks and hosts, Destination hosts, el servicio Dynamic Routing y la Rule position adecuada. Después se prueba el acceso desde la IP permitida del peer y desde un origen no autorizado.

La ayuda de Sophos BGP requiere además reglas de firewall para el tráfico BGP entrante y saliente. Al mismo tiempo, la ayuda de Acceso a dispositivos establece que los servicios locales no están controlados por reglas de firewall. Estas afirmaciones no se corresponden de forma inequívoca. Por lo tanto, deben tratarse por separado la ACL de servicio local para el servicio BGP local, las reglas requeridas por el diseño del túnel o del proveedor y las reglas normales para el tráfico de usuarios enrutados. De ello no se deduce que deba crearse una regla general de cualquiera a cualquiera para TCP 179. Proteger el acceso al dispositivo en Sophos Firewall explica la capa de acceso local con más detalle.

Configurar BGP en WebAdmin

Los siguientes pasos se realizan en ambos firewalls. Solo se intercambian los valores locales y remotos.

1. Definir Router ID y Local AS

En Routing > BGP, introducir en Global configuration los siguientes valores para Firewall A:

Si ya existe una configuración BGP, hay que documentar el estado actual antes de aplicar cambios: modificar el Router ID reinicia todas las sesiones BGP; modificar el Local AS elimina todos los Neighbors y Networks. Estos cambios solo se aplican en una ventana de mantenimiento planificada.

• Router ID assignment: Manual
• Router ID: 192.0.2.10
• Local AS: 65010

En Firewall B también se utiliza Manual, junto con 192.0.2.20 y 65020. A continuación, aplicar la configuración global.

Local AS acepta valores de 1 a 4294967295. Para entornos internos sin ASN público, Sophos indica el rango privado de 64512 a 65535.

2. Añadir el peer como Neighbor

En Routing > BGP > Neighbors, hacer clic en Add e introducir en Firewall A:

• IP version: IPv4
• IP address: 198.51.100.2
• Remote AS: 65020

Firewall B utiliza 198.51.100.1 como Neighbor y 65010 como Remote AS. Guardar cada entrada con Save.

La dirección del Neighbor no es la LAN remota ni el Router ID, sino la IP de tránsito directamente accesible del peer. Si esta IP no es accesible o los ASN están intercambiados, la sesión no puede alcanzar Established.

3. Anunciar la LAN local

En Routing > BGP > Networks, hacer clic en Add. Firewall A anuncia:

• IP version: IPv4
• IP address: 10.10.10.0
• Subnet mask: 255.255.255.0 (/24)

En Firewall B se introducen en su lugar 10.20.20.0 y 255.255.255.0 (/24).

La entrada Network define el prefijo que BGP debe anunciar; no sustituye ni la ruta local ni una regla de firewall. Después de guardarla, hay que comprobar tanto la sesión como el prefijo anunciado y el recibido por el peer. Solo deben incluirse los prefijos necesarios.

Entender los Neighbors y las redes IPv6

SFOS también admite IPv6 en Neighbors y Networks. El ejemplo anterior se limita deliberadamente a IPv4; para IPv6 se introducen por separado la versión IP, una dirección IPv6 del peer directamente accesible y el prefijo IPv6.

WebAdmin añade automáticamente la separación necesaria. En una configuración solo por CLI, los defaults son asimétricos: los Networks IPv4 se activan inicialmente para todos los Neighbors, incluidos los IPv6. Los Networks IPv6 no se activan para ningún Neighbor. Para un Neighbor IPv6 se establecen explícitamente estos estados:

address-family ipv4 unicast
no neighbor <ipv6-neighbor> activate
exit
address-family ipv6 unicast
neighbor <ipv6-neighbor> activate

Para reproducir los defaults de WebAdmin en CLI, Sophos también indica no bgp ebgp-requires-policy y bgp log-neighbor-changes. show running-config solo muestra valores que difieren del default; una Router ID automática y, por ejemplo, maximum-paths ibgp 16 no aparecen necesariamente. IPv4 e IPv6 se validan por separado en Routing > Information > BGP-IPv4 y BGP-IPv6, con sus reglas IPv6 y rutas de retorno.

Comprobar y aceptar BGP

Una sesión establecida no confirma por sí sola que el flujo de paquetes funcione. Por eso, la validación se realiza en varios niveles:

1. En Routing > Information > BGP-IPv4 > Neighbors, el peer debe aparecer en estado Established.
2. En Routes, Firewall A debe mostrar el prefijo 10.20.20.0/24; Firewall B debe mostrar 10.10.10.0/24.
3. En Summary, comprobar la sesión y el número de prefijos recibidos.
4. En Diagnostics > Tools > Route lookup, comprobar en Firewall A, por ejemplo, el destino 10.20.20.10.
5. A continuación, probar un servicio real entre un host de cada LAN. Log Viewer y Packet Capture deben mostrar la regla esperada, la interfaz de tránsito correcta y el tráfico de retorno.

Un Neighbor en Established solo demuestra que el intercambio BGP funciona. La ruta aprendida, un Route Lookup correcto y una conexión real son necesarios para validar toda la configuración. Probar una regla de Sophos Firewall con Log Viewer y Packet Capture ayuda a comprobar el flujo de paquetes.

El mismo ejemplo mediante CLI

Como alternativa a WebAdmin, la misma configuración básica puede introducirse en la CLI de routing después de iniciar sesión por SSH. No ejecutar los siguientes comandos en un entorno de ejemplo ya configurado. Guardar el estado actual antes de modificarlo; cambiar el ASN elimina Neighbors y Networks y requiere un backup y una ventana de mantenimiento. El acceso depende de la versión de SFOS.

SFOS 22: La siguiente ruta de menú abre bgp>. Solo este acceso empieza con enable:

3. Route Configuration > 1. Configure Unicast Routing > 3. Configure BGP

En Firewall A sin ASN asignado todavía:

enable
configure terminal
router bgp 65010

SFOS 23: 3. Route Configuration > 1. Configure Unicast Routing abre directamente router#; no se utiliza ni la tercera selección de menú ni enable. Para asignar el ASN por primera vez en Firewall A:

configure terminal
router bgp 65010

Si el ASN ya está asignado en SFOS 23, utilizar en su lugar router bgp sin ASN después de configure terminal para seleccionar la configuración existente. router bgp 65010 sirve para la asignación inicial o un cambio de ASN planificado, no para una reasignación sin control.

Después de una sola de estas secuencias de acceso, continuar en el modo de configuración BGP:

no bgp ebgp-requires-policy
bgp log-neighbor-changes
bgp router-id 192.0.2.10
neighbor 198.51.100.2 remote-as 65020
address-family ipv4 unicast
network 10.10.10.0/24
exit
end
show running-config
write

En Firewall B se sustituyen Local AS, Router ID, Neighbor, Remote AS y Network por 65020, 192.0.2.20, 198.51.100.1, 65010 y 10.20.20.0/24, respectivamente.

show running-config sirve para la comprobación. write guarda la configuración CLI de forma permanente, muestra las entradas en WebAdmin y las conserva después de un reinicio. Sin write, el cambio no está completamente finalizado.

end sale del modo de configuración antes de estos dos comandos. Para SFOS 23, Sophos documenta la confirmación de guardado esperada Integrated configuration saved to /conf/routing/frr.conf; no es una salida observada aquí en una appliance. Después, comparar la configuración y las entradas de WebAdmin con los valores previstos.

La comprobación adicional documentada oficialmente es:

show ip bgp

Muestra los prefijos BGP conocidos y la información de sus rutas. El estado del Neighbor y el Summary se comprueban de forma fiable en Routing > Information > BGP-IPv4.

⚠️ No mezclar sin control configuraciones avanzadas de CLI y WebAdmin. Editar un Neighbor en WebAdmin puede eliminar valores adicionales de CLI, como una contraseña de Neighbor o un Route Map. En cuanto se utilicen estos ajustes, guardar primero show running-config y continuar administrando la configuración BGP mediante CLI.

SFOS 23.0: BFD experimental para BGP

Bidirectional Forwarding Detection (BFD) supervisa la accesibilidad de un Neighbor BGP mediante sus propios paquetes de control. Esto permite que el firewall detecte un fallo antes que con los temporizadores de BGP por sí solos. Este procedimiento opcional no forma parte de la configuración básica de BGP anterior y no debe aplicarse a versiones anteriores de SFOS.

⚠️ En SFOS 23.0, BFD es experimental. El uso documentado corresponde a BGP en despliegues Standalone; esto no implica que esté aprobado para clústeres HA ni para otros protocolos de routing. Para otros protocolos es necesario consultar a Sophos Support. Avanet recomienda empezar en un entorno de pruebas aislado. BFD no debe activarse en producción sin un procedimiento de reversión confirmado para la compilación instalada.

Alcance y preparación

Sophos enumera como casos de uso de BFD los Neighbors BGP-IPv4 y BGP-IPv6, así como eBGP, iBGP, eBGP multihop y Neighbors Route Reflector. El siguiente ejemplo se limita al Neighbor IPv4 198.51.100.2 ya configurado en Firewall A. No supone ninguna garantía adicional para un servicio VPN cloud concreto ni para una topología multihop determinada.

Antes de empezar, la sesión BGP, los prefijos esperados y el tráfico de las aplicaciones deben funcionar sin BFD. La contraparte debe estar preparada para BFD; las direcciones de los peers, la accesibilidad y los temporizadores se acuerdan con su administrador. Registrar la compilación actual de SFOS, guardar show running-config, el estado del Neighbor y el resultado de Route Lookup, y disponer de un backup, una ventana de mantenimiento y un acceso de gestión independiente. Antes de realizar cambios, confirmar con Sophos Support el procedimiento específico para esa compilación que permita eliminar la vinculación BFD del Neighbor, cualquier perfil de peer adicional y el servicio. La guía de BFD no documenta comandos completos de eliminación o parada para ello.

Si el Neighbor supervisado deja de ser accesible, el firewall elimina inmediatamente de la tabla de routing todas las rutas aprendidas de él. El tráfico solo puede pasar a una ruta alternativa si esta existe; de lo contrario, las redes afectadas pierden su ruta. Cuando el Neighbor vuelve a estar disponible, Sophos describe la restauración de las rutas y el retorno a la ruta original. Por eso se comprueban tanto el fallo como la recuperación, incluida la ruta que se selecciona realmente.

Iniciar el servicio y supervisar el Neighbor

El servicio BFD está desactivado de forma predeterminada. Los siguientes comandos modifican el funcionamiento del routing; antes de ejecutarlos, deben estar disponibles el estado inicial guardado y el procedimiento de reversión confirmado. Acceder por CLI a 5. Device Management > 3. Advanced shell e iniciar allí el servicio:

service -ds nosync bfdd:start

Después, en la misma Advanced Shell, acceder a la CLI de routing con vtysh:

vtysh

En la CLI de routing, añadir la vinculación BFD al Neighbor ya existente en Firewall A. Router ID, Local AS, Remote AS y Networks permanecen sin cambios:

configure terminal
router bgp
neighbor 198.51.100.2 bfd
end
write

Sustituir 198.51.100.2 por la dirección real del Neighbor, no por su LAN ni por su Router ID. En Firewall B, la dirección correspondiente del ejemplo es 198.51.100.1. La contraparte se configura siguiendo la documentación de su propio producto. Si el Neighbor BGP todavía no existe, completar primero la configuración básica de BGP de este artículo; BFD no la sustituye. write guarda la configuración de routing, pero no demuestra que la sesión BFD funcione ni que el servicio se inicie automáticamente después de un reinicio.

Cambiar los temporizadores solo cuando esté justificado

Para la primera prueba, Avanet recomienda los valores predeterminados documentados: Detect multiplier 3, Transmit interval 300 ms y Receive interval 300 ms. Los intervalos muy cortos o un multiplicador sensible pueden aumentar la carga de procesamiento. Estos valores no garantizan un tiempo fijo de conmutación.

Los temporizadores se definen en la configuración de BFD, no en el comando del Neighbor BGP. Si se necesita un perfil de peer explícito, este bloque muestra en la CLI de routing los valores predeterminados documentados para el mismo peer del ejemplo:

configure terminal
bfd
peer 198.51.100.2
 detect-multiplier 3
 transmit-interval 300
 receive-interval 300
end
write

peer inicia la supervisión del peer con los temporizadores predeterminados; este bloque adicional no es necesario si solo se quiere configurar la vinculación BGP. Para detect-multiplier, Sophos documenta el rango 1–155; para ambos intervalos, 10–4294967 ms. El valor Transmit indica el intervalo mínimo de envío sin jitter, mientras que el valor Receive indica el intervalo mínimo de recepción esperado. La contraparte calcula su tiempo de detección a partir del multiplicador local y del mayor valor entre el intervalo de envío local y el intervalo de recepción remoto. Por ello, deben coordinarse ambos lados en lugar de limitarse a elegir el menor valor local posible. Añadir temporizadores directamente después de neighbor … bfd no es una sintaxis válida.

Validar conjuntamente BFD, las rutas y la aplicación

En la CLI de routing, estas dos comprobaciones son de solo lectura:

show bfd peers
show bfd peers brief

Para el peer previsto, se espera Status: up. La salida detallada debe mostrar temporizadores locales y remotos adecuados, además de Diagnostics: ok y Remote diagnostics: ok; la vista resumida relaciona la dirección del peer con su estado. A continuación, volver a comprobar la sesión BGP en Routing > Information > BGP-IPv4 o BGP-IPv6, los prefijos esperados, Route Lookup y el tráfico real de las aplicaciones. BFD en estado up no confirma por sí solo que la ruta BGP sea correcta ni que funcione el flujo de datos.

Realizar una prueba de fallo únicamente en un entorno de pruebas autorizado o durante una ventana de mantenimiento planificada, sin poner en riesgo el acceso de gestión independiente. Antes de empezar, registrar los prefijos aprendidos del Neighbor supervisado y la ruta alternativa prevista. Durante el fallo controlado del peer, las rutas afectadas deben desaparecer y, si existe una ruta alternativa, esta y el tráfico de las aplicaciones deben funcionar. Tras la recuperación, volver a comprobar BFD en estado up, BGP, los prefijos restaurados, la ruta seleccionada y la aplicación. Aquí no se presenta ninguna salida de un dispositivo ni ninguna conmutación correcta como si ya se hubieran probado.

Aislar errores y revertir el cambio

• El peer no aparece o permanece down: Comprobar el inicio del servicio y la vinculación BFD en show running-config; después, comparar la dirección real del peer, la accesibilidad y la configuración BFD de la contraparte. Utilizar show bfd peers para registrar los diagnósticos locales y remotos, así como los temporizadores. No añadir una autorización amplia Any-to-Any como solución genérica; si los requisitos de acceso no están claros, consultar a Sophos Support.
• BFD deja de funcionar después de un cambio: Los cambios en ajustes relacionados, como la dirección de destino o Remote Gateway, pueden eliminar los ajustes de BFD. Comparar la configuración con el estado guardado, volver a configurar BFD para el Neighbor afectado y realizar de nuevo la validación completa.
• Sesión inestable o mayor carga después de cambiar los temporizadores: Volver a establecer los valores documentados previamente en el mismo contexto de peer BFD y guardarlos con write. Si el estado inicial era el perfil predeterminado, el bloque anterior muestra 3 y 300 ms. Después, comprobar los diagnósticos de ambos peers, las rutas BGP y el tráfico antes de modificar otros valores.
• Reversión completa: Aplicar únicamente el plan de reversión confirmado previamente para esta compilación y, después, comparar la configuración BGP sin BFD con el estado inicial guardado. Ni un comando no inventado ni una parada genérica del servicio sustituyen ese plan. Eliminar todo el Neighbor BGP no sería una reversión equivalente de BFD, ya que también se perderían sus rutas. La reversión solo se da por terminada cuando la sesión BGP, los prefijos necesarios, el acceso de gestión y la aplicación vuelvan al estado previsto.

Weight, MED y Route Precedence global

La Route Precedence global ordena las categorías static, sdwan_policyroute y vpn. Debe distinguirse de los atributos que BGP utiliza para seleccionar sus propias rutas. system route_precedence show muestra el valor global actual; solo debe cambiarse cuando estas tres categorías compitan realmente. Ajustar la prioridad de enrutamiento en Sophos Firewall explica el proceso completo de comprobación y reversión.

Administrative Distance es uno de los factores utilizados para decidir entre distintos protocolos de routing. Dentro de BGP se evalúan los atributos BGP. Sophos indica, por ejemplo, que se prefiere un Weight más alto; entre rutas comparables se prefiere un MED más bajo.

Esto es especialmente importante cuando el mismo prefijo se obtiene mediante redistribute ospf y, además, de un Neighbor BGP. La ruta redistribuida que se genera localmente tiene de forma predeterminada un Weight de 32768, mientras que la ruta aprendida del Neighbor tiene un Weight de 0. Sin un ajuste deliberado, gana por tanto la ruta redistribuida. Si se quiere dar preferencia a la ruta del peer, debe asignársele un Weight superior y comprobar después la ruta resultante.

Utilizar MED para varias rutas de entrada

SFOS 23: comprobar los nombres previamente. Antes de crear o reutilizar Access Lists, Prefix Lists o Route Maps, inventariar sus nombres en todos los protocolos de routing dinámico. Se guardan en un único archivo de configuración y los nombres deben ser únicos entre protocolos. Evitar colisiones y comprobar las vinculaciones previstas de Neighbor y políticas frente a la configuración actual y la guardada. Este requisito no sustituye al plan de reversión MED confirmado para la compilación instalada que se exige a continuación; la configuración MED ejecutable sigue suspendida hasta confirmar ese plan.

Actualización a SFOS 23.0: A partir de esta versión, todos los protocolos de routing dinámico utilizan una configuración integrada. Al actualizar desde una versión anterior, el firewall añade automáticamente prefijos de protocolo a los nombres de Route Maps, Prefix Lists y Access Lists, pero solo si existe un conflicto de nombres. También actualiza automáticamente todas las referencias a las configuraciones renombradas. Esto no significa que se cambie el nombre de todos los objetos.

Después de actualizar, comparar los nombres de objetos y las referencias guardados previamente con el show running-config actual y registrar la correspondencia entre los nombres antiguos y los actuales. Comprobar que las vinculaciones previstas de Neighbor y Route Map siguen apuntando a las políticas correctas, incluidas las vinculaciones MED existentes. No restaurar a ciegas los nombres antiguos. En Routing > Information > BGP-IPv4 > Routes y con show ip bgp en el peer, comprobar que están presentes los prefijos de red esperados, que faltan los no permitidos y que se selecciona la ruta prevista; comprobar también la ruta realmente utilizada mediante Route Lookup. Esta comprobación no sustituye al plan de reversión MED exigido a continuación para la compilación instalada ni levanta la suspensión de la configuración MED.

El Multi-Exit Discriminator (MED) indica a un AS vecino directo cuál de varias rutas de entrada al AS local debe preferir. Un MED inferior es mejor y el default es 0. Por tanto, se anuncia un valor superior en la ruta menos deseada. Por defecto, MED solo se compara cuando el mismo prefijo se aprende por varios enlaces desde el mismo AS vecino.

MED no es transitivo. Si el AS receptor reenvía la ruta a otro AS, el valor vuelve a 0. BGP también evalúa antes Weight, Local Preference, origen local, longitud de AS Path y Origin Type. MED solo decide si esos atributos son iguales. Un valor configurado no demuestra que gane la ruta deseada.

Sophos establece MED mediante un Route Map de salida con un número de secuencia fijo y lo vincula a un Neighbor concreto en la IPv4 Address Family. out modifica el anuncio enviado a ese peer; no fuerza directamente la ruta de salida del tráfico de datos de Sophos Firewall. La página oficial de SFOS 22 documenta la configuración, pero no una reversión completa. Por ello, el cambio solo debe implementarse después de confirmar por separado los comandos exactos de eliminación para la compilación instalada y de registrarlos como plan de recuperación junto con el show running-config guardado previamente.

Después de un cambio autorizado, show ip bgp en el router receptor debe mostrar el MED esperado y la ruta preferida. En un peer Sophos, la ruta también aparece en Routing > Information > BGP-IPv4 > Routes. Sin esta comparación del antes y el después, este apartado es una ayuda para tomar decisiones, no un cambio de producción listo para ejecutar.

BGP mediante IPsec route-based y VPN cloud

BGP puede funcionar mediante una interfaz XFRM direccionada de un túnel IPsec site-to-site route-based. Ambas interfaces XFRM reciben IP de tránsito adecuadas. Dynamic Routing se autoriza de forma selectiva para la zona VPN; las reglas para el tráfico de usuario siguen siendo necesarias.

En conexiones cloud, los valores no se eligen libremente:

• Para AWS Site-to-Site VPN, las direcciones inside del túnel, el Remote AS y los demás valores proceden de la configuración de AWS. Los dos túneles AWS se comprueban por separado.
• En Azure VPN Gateway, la IP XFRM local debe coincidir con la IP del peer BGP prevista; el ASN local y el de Azure deben ser distintos.

Un túnel IPsec en verde y un Neighbor BGP en Established son dos comprobaciones distintas. Después deben funcionar los prefijos esperados y el tráfico real de las aplicaciones.

Aislar errores de forma sistemática

Neighbor permanece en Active o no aparece

Active no significa que la sesión funcione. El firewall sigue intentando establecer una conexión BGP. Primero se comprueban la accesibilidad directa de la IP del peer, el estado de la interfaz y del túnel, Local AS, Remote AS y la IP del Neighbor. Después se verifica si Dynamic Routing está autorizado en la zona correcta o mediante una Local Service ACL Exception adecuada.

Con XFRM también hay que comprobar que ambas direcciones del túnel sean correctas y que el túnel IPsec esté up. En configuraciones cloud y XFRM también se comprueban las reglas previstas por el diseño VPN correspondiente. Si sus servicios están restringidos, deben incluir TCP 179 entre las dos IP de los peers. Device Access o la Local Service ACL para el servicio BGP local se mantienen separados de esas reglas.

Neighbor está Established, pero falta la red remota

La sesión funciona, pero el prefijo no se anuncia o no se acepta. En el firewall emisor, compruebe la entrada Network, su versión IP y su máscara de prefijo, además de show running-config. A continuación, use Routes y Summary en el peer para comprobar si el prefijo llega o si una política lo rechaza.

Si después de actualizar a SFOS 22 falta una red situada detrás de un túnel IPsec policy-based, la causa puede ser la dependencia anterior de redistribute kernel. La sesión BGP puede permanecer en Established; SFOS 22: rutas IPsec y redistribute kernel explica el cambio entre versiones y el diseño de destino XFRM route-based.

La ruta BGP es visible, pero no se utiliza

Primero se utiliza Route Lookup para comprobar qué ruta gana para una IP de destino concreta. Una ruta más específica tiene prioridad sobre un prefijo más amplio. Si compiten varias fuentes, se evalúan por separado Administrative Distance y los atributos BGP, y solo después la categoría global de Route Precedence.

La ruta es correcta, pero el tráfico no funciona

BGP ha completado su tarea cuando la ruta correcta está instalada. A partir de ahí, los errores suelen encontrarse en la regla de firewall, NAT, la ruta de retorno o el sistema de destino. En redes de sedes con routing normal, con frecuencia no se necesita SNAT porque ambos lados deben conocer los prefijos LAN reales.

Los ajustes avanzados desaparecieron después de editar en WebAdmin

WebAdmin solo muestra los valores básicos. Si se guardó allí un Neighbor después de una configuración avanzada mediante CLI, es posible que se hayan eliminado la contraseña, el Route Map o los defaults modificados. Aplicar Global configuration también elimina los cambios en bgp log-neighbor-changes y no bgp ebgp-requires-policy. Comparar la configuración guardada, restaurar los valores mediante CLI y guardarlos con write.

Identificar los logs de BGP y routing

La referencia de logs de SFOS 22 asigna BGP y BGPv6 al archivo bgpd.log. zebra.log registra la instalación de rutas dinámicas IPv4 e IPv6 en el kernel; para IPsec route-based, xfrmi.log corresponde a la interfaz de túnel XFRM. Así se pueden separar las clases de error: primero se comprueban la sesión BGP y el anuncio; después, su incorporación a la tabla de routing del sistema y, si procede, el estado del túnel. Servicios y archivos de log de Sophos Firewall explica cómo acceder a ellos y describe otros archivos. Para esta validación no se necesitan comandos de live shell sin documentar.

Revertir el cambio de forma segura

Antes de eliminar BGP debe existir una ruta alternativa o una ventana de mantenimiento para cada red de destino aprendida. Primero se eliminan los Networks y Neighbors afectados. La configuración global de BGP solo se modifica si ningún otro peer depende de ella. Dynamic Routing solo debe desactivarse cuando la zona ya no necesite ningún otro servicio de routing dinámico.

En WebAdmin, elimine primero los anuncios que ya no sean necesarios en Routing > BGP > Networks y después los peers afectados en Neighbors. Compruebe tras cada paso que las rutas alternativas previstas estén activas. Mantenga sin cambios Router ID y Local AS mientras otras conexiones BGP dependan de ellos; cambiar Local AS eliminaría todos los Neighbors y Networks restantes.

Las páginas generales de BGP revisadas para SFOS 22 y 23 sí muestran una sintaxis para desactivar la configuración de routing BGP. Sin embargo, esto no valida el contexto completo de ejecución ni una reversión segura para la compilación instalada. La sintaxis anómala de la fuente no se reproduce como comando ejecutable ni se corrige silenciosamente; tampoco se deduce una parada confirmada del daemon ni la eliminación del proceso. No se recomienda ningún comando CLI destructivo. Quien utilice políticas avanzadas mediante CLI necesita, antes de revertirlas, los comandos de eliminación confirmados para la compilación instalada y el bloque de configuración anterior guardado.

Después se vuelven a comprobar Routing Information, Route Lookup, el acceso de gestión y el tráfico real. Un rollback solo está completo cuando la sesión BGP ha desaparecido y todas las redes de destino necesarias siguen accesibles mediante la ruta alternativa prevista.