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.
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 IP directamente accesible del peer con la que se establece la sesión BGP.
• Un Network es un prefijo local que el firewall debe anunciar al peer.

BGP no autoriza el tráfico de usuario ni lo cifra. La propia sesión BGP se establece mediante TCP 179 y se autoriza hacia el firewall mediante Device Access o una Local Service ACL. El tráfico de usuario que utiliza una ruta aprendida sigue necesitando reglas de firewall adecuadas, una ruta de retorno funcional 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.
• Las redes que se van a anunciar ya existen como rutas coincidentes en la tabla de routing local.
• 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 segura que habilitar toda la zona. En Administration > Device access > Local service ACL exception rule > Add, se crea una regla Accept para la zona del peer, la IP concreta del peer o una red de tránsito restrictiva, la dirección necesaria del firewall y el servicio Dynamic Routing. Después se prueba el acceso desde la IP permitida del peer y desde un origen no autorizado.

Device Access solo controla la conexión BGP hacia el firewall. Las conexiones productivas entre las dos LAN siguen necesitando reglas de firewall normales. Proteger Device Access en Sophos Firewall explica esta separación.

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).

Un Network no crea una ruta. El prefijo exacto ya debe existir en la tabla de routing local, por ejemplo como red conectada directamente o ruta estática. Si falta o la máscara no coincide, la sesión BGP puede permanecer en Established, pero el Network no se anuncia.

Solo deben introducirse los prefijos realmente necesarios. Una redistribución general de rutas conectadas o estáticas también puede incluir redes WAN, de gestión o blackhole y solo debe utilizarse en producción con un filtrado comprobado.

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
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.

Route Precedence y selección de rutas BGP

system route_precedence no decide entre BGP y una ruta estática. El ajuste global solo ordena las categorías static, sdwan_policyroute y vpn; BGP y otras rutas dinámicas pertenecen en este contexto a la categoría static.

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.

La secuencia global actual se muestra en 4. Device Console:

system route_precedence show

Solo debería modificarse cuando realmente compitan categorías de routing. Ajustar la prioridad de routing en Sophos Firewall explica las relaciones y ofrece ejemplos seguros.

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, el Network debe existir en la tabla de routing local con exactamente la misma máscara. Después se comprueban Networks, filtros y show running-config. Una ruta local ausente debe corregirse y no ocultarse desactivando BGP Network Import Check.

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. Comparar la configuración guardada, restaurar los valores mediante CLI y guardarlos con write.

Comprobar logs de BGP y routing

En 5. Device Management > 3. Advanced Shell, dos archivos de log muestran los distintos niveles:

tail -f /log/bgpd.log

bgpd.log registra eventos BGP y BGPv6. La salida en directo se detiene con Ctrl+C. Si BGP conoce una ruta pero esta no aparece en el sistema, se continúa con:

tail -f /log/zebra.log

Para leer sin seguir el log en directo puede utilizarse, por ejemplo:

less /log/bgpd.log

En IPsec route-based, /log/xfrmi.log también puede explicar el estado de la interfaz XFRM. Servicios y archivos de log de Sophos Firewall clasifica otros archivos.

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.

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.