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 BGP después de iniciar sesión por SSH. Los siguientes comandos no se ejecutan además sobre un entorno de ejemplo que ya esté completamente configurado. La ruta de menú es:

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

En Firewall A, el ejemplo completo es el siguiente:

enable
configure terminal
router bgp 65010
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
show running-config
write
end

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.

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.

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

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 > Routing. 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 fuentes de SFOS 22 revisadas no documentan ningún comando CLI completo para eliminar todo el proceso BGP. Por ello, no se deduce ni se recomienda tal comando. 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.