Cambiar de forma segura la route precedence en Sophos Firewall

La route precedence determina si Sophos Firewall evalúa primero las Static Routes, las SD-WAN Policy Routes o las rutas VPN. La configuración es global y puede afectar de inmediato al tráfico de producción y al acceso administrativo.

Respuesta breve

El orden predeterminado es:

1. static
2. sdwan_policyroute
3. vpn

Este orden resulta adecuado para muchos entornos porque las redes conectadas directamente y las rutas estáticas no quedan anuladas por una ruta SD-WAN demasiado amplia. Solo debe cambiarse cuando varios tipos de routing compiten por el mismo destino en el flujo de paquetes concreto.

Antes de cada cambio se debe documentar el orden actual, garantizar un acceso de gestión independiente, comprobar las rutas afectadas y preparar el rollback exacto. Una ruta SD-WAN normal se explica en Configurar y probar una ruta SD-WAN en Sophos Firewall.

¿Qué orden es el adecuado?

Orden predeterminado y diferencia entre versiones

El orden predeterminado es idéntico en SFOS 21.5 y 22.0. Sin embargo, ha cambiado la clasificación de ipsec_route:

• SFOS 21.5: static incluye redes conectadas directamente, ipsec_route, Unicast Routes, Dynamic Routes y SSL VPN. Las rutas IPsec policy-based generadas automáticamente pertenecen a vpn.
• SFOS 22.0: static incluye redes conectadas directamente, Unicast Routes, Dynamic Routes y SSL VPN. vpn incluye las rutas IPsec policy-based generadas automáticamente e ipsec_route.

Esto es importante en las actualizaciones: Una recomendación para ipsec_route en SFOS 21.5 no debe aplicarse sin cambios a SFOS 22.0. En SFOS 22.0, el firewall procesa internamente las rutas IPsec policy-based. Las rutas VPN policy-based generadas automáticamente y las definidas con ipsec_route no aparecen en la tabla de routing. ipsec_route no es necesario para el tráfico generado por el sistema. Una ruta IPsec manual solo tiene sentido en el caso especial correspondiente y dependiente de la versión.

En firewalls migrados cuenta la salida real, no el valor predeterminado documentado. Por ejemplo, una migración puede conservar sdwan_policyroute vpn static. Además, las rutas SD-WAN migradas pueden seguir vinculadas al ID de su regla de firewall original y desaparecer al eliminar dicha regla.

Static primero

static sdwan_policyroute vpn suele ser el punto de partida correcto para LAN, DMZ, VLAN, SSL VPN y rutas normales de Internet mediante SD-WAN. Las redes conectadas directamente se tratan como rutas estáticas.

Esto protege los destinos internos frente a rutas SD-WAN demasiado amplias. Si sdwan_policyroute precede a static y una ruta SD-WAN utiliza un destino como Any, el tráfico interno o administrativo puede dirigirse de forma inesperada al gateway WAN.

SD-WAN primero

sdwan_policyroute static vpn es adecuado cuando el policy routing debe tener prioridad de forma consciente sobre las rutas estáticas. Debe planificarse con orígenes, destinos y servicios concretos. Las rutas SD-WAN solo se aplican a reply packets y al tráfico generado por el sistema si están activadas las opciones CLI correspondientes.

Comprobar SD-WAN routing para reply packets y system traffic en Sophos Firewall explica ambas opciones en detalle.

VPN primero

vpn static sdwan_policyroute es una excepción específica, por ejemplo para escenarios L2TP documentados. La prioridad de vpn sobre static solo se aplica al tráfico cuya ruta competidora conduce a la zona WAN. No es una solución general para cualquier túnel IPsec.

Las conexiones SSL VPN pertenecen a la categoría static, no a vpn. IPsec route-based mediante interfaces XFRM se controla a través de la ruta estática, dinámica o SD-WAN configurada. Por tanto, son decisivos la interfaz XFRM, la ruta, los criterios SD-WAN, NAT, la regla de firewall y el retorno.

Un cambio global no es apropiado si solo se enruta mal una red de destino. Una ruta estática o SD-WAN más específica, la configuración VPN o un ipsec_route aplicado según la versión suele ser una solución más precisa.

Preparar el cambio de forma segura

Los comandos se ejecutan en Device Console, no en Advanced Shell. Si aún no se ha configurado el acceso, consulta Conectar con Sophos Firewall mediante SSH. SSH solo debe permitirse desde redes de confianza.

Preparación:

1. Garantizar y probar activamente una vía independiente de acceso al firewall antes del cambio, por ejemplo una consola local, una interfaz de gestión dedicada o una vía administrativa confirmada como no afectada.
2. Anotar origen, destino, servicio, zona e interfaces implicadas.
3. Comprobar rutas estáticas, SD-WAN Policy Routes, rutas VPN e interfaces XFRM.
4. Identificar rutas SD-WAN amplias con Any y reglas migradas.
5. Comprobar NAT, la regla de firewall y el retorno del sistema remoto.
6. Definir la ventana de mantenimiento, la prueba de aceptación y el rollback.

⚠️ Importante: La route precedence es global. No cambiar al mismo tiempo reglas de routing, NAT, firewall y SD-WAN, porque después no se puede atribuir el efecto de forma fiable.

Mostrar el orden actual y documentarlo exactamente:

system route_precedence show

Registrar la salida completa junto con la fecha, el motivo, las redes afectadas y el comportamiento esperado. Antes del cambio se prepara el comando exacto de rollback a partir de los tres valores.

El orden actual también se muestra aquí en WebAdmin:

Routing > SD-WAN routes

Se modifica mediante Device Console. Si interviene SD-WAN, registrar también previamente el estado del tráfico generado por el sistema y los reply packets:

show routing sd-wan-policy-route system-generate-traffic
show routing sd-wan-policy-route reply-packet

Estos valores no deben confundirse con el efecto de la route precedence. Se produce una combinación especialmente crítica cuando sdwan_policyroute precede a static, una ruta SD-WAN coincidente utiliza el destino Any y SD-WAN está activo tanto para el tráfico generado por el sistema como para los reply packets. En ese caso, WebAdmin y SSH pueden dejar de ser accesibles desde la subred interna afectada, aunque el firewall siga accesible desde otras subredes.

Cambiar la route precedence

La sintaxis siempre incluye los tres valores:

system route_precedence set [sdwan_policyroute] [static] [vpn]

Establecer el orden predeterminado:

system route_precedence set static sdwan_policyroute vpn

Si este orden ya está activo, probablemente el error se encuentre en route lookup, criterios SD-WAN, configuración VPN, NAT, la regla de firewall o el retorno.

⚠️ Antes de SD-WAN-First: Comprobar si rutas SD-WAN amplias incluyen redes internas o el acceso de gestión. Ejecutar el comando únicamente con una vía de recuperación preparada.

Evaluar primero las SD-WAN Policy Routes:

system route_precedence set sdwan_policyroute static vpn

⚠️ Antes de VPN-First: Usar este orden solo para un caso especial VPN confirmado. No resuelve una ruta ausente, traffic selectors incorrectos, NAT o problemas de retorno.

Evaluar primero las rutas VPN:

system route_precedence set vpn static sdwan_policyroute

Probar y revertir el cambio

Después del cambio, confirmar primero que está activo el orden esperado:

system route_precedence show

A continuación, probar el flujo de paquetes afectado:

• Probar la aplicación, la conexión TCP o el ping al destino.
• Filtrar Log Viewer por origen, destino y regla de firewall.
• Ejecutar Packet Capture en las interfaces de entrada y salida.
• Comprobar route lookup y la ruta SD-WAN afectada.
• Comprobar NAT y la IP de origen traducida.
• Confirmar el retorno del sistema remoto.
• Probar WebAdmin y SSH desde las redes administrativas relevantes.

Un estado VPN en verde o una ruta existente no demuestran que el flujo funcione. Los pasos prácticos están en Probar reglas de Sophos Firewall con Log Viewer y Packet Capture y Usar Packet Capture en Sophos Firewall WebAdmin.

Si hay varios sitios o rutas afectados, probar al menos un cliente por cada red relevante, un destino de servidor y las vías Remote Access o VPN afectadas.

Para el rollback se establece exclusivamente el orden original completo documentado previamente. No puede deducirse solo del primer valor, porque existen seis combinaciones posibles. Usar el comando preparado con este patrón:

system route_precedence set <primer valor> <segundo valor> <tercer valor>

Sustituir los placeholders por los tres valores de la salida guardada. A continuación, volver a comprobar:

system route_precedence show

Repetir después las mismas pruebas funcionales, de routing y de gestión. Si el error original reaparece tras el rollback, probablemente intervino la route precedence. Si nada cambia, la causa está en otro punto.

Errores frecuentes

La ruta SD-WAN es demasiado amplia

Una ruta SD-WAN con rangos de red grandes o el destino Any puede abarcar más tráfico del previsto. Si SD-WAN precede a Static, destinos internos y accesos de gestión pueden dirigirse de forma inesperada al gateway WAN. Reply packets y tráfico generado por el sistema resultan afectados si están activas las opciones SD-WAN correspondientes.

El estado VPN se confunde con el routing

Un túnel activo solo confirma la negociación. No demuestra que routing, traffic selectors, reglas de firewall, NAT y retorno sean correctos. Con IPsec route-based se comprueban primero la interfaz XFRM y la ruta; con IPsec policy-based también el tratamiento de ipsec_route según la versión. Troubleshooting de VPN IPsec en Sophos Firewall guía el análisis.

NAT se pasa por alto

Routing determina el camino del paquete; NAT modifica su dirección de origen o destino. Si la ruta es correcta pero el retorno falla, NAT o la ruta de retorno suelen ser la causa. Consulta Entender NAT en Sophos Firewall.

Se realizan varios cambios al mismo tiempo

Si se modifican simultáneamente route precedence, SD-WAN, NAT, reglas de firewall y parámetros VPN, ya no es posible separar claramente causa y efecto. Es mejor realizar un cambio, una prueba completa y después el siguiente cambio.

Lista de verificación

• Route precedence actual documentada.
• Versión SFOS y clasificación de ipsec_route consideradas.
• Orígenes, destinos, redes y servicios afectados anotados.
• Static, SD-WAN, VPN y XFRM comprobados.
• Redes conectadas directamente y vías de gestión consideradas.
• Rutas SD-WAN amplias con Any identificadas.
• Estado de System Traffic y reply packets registrado.
• NAT, reglas de firewall y retorno comprobados.
• Acceso de gestión independiente y rollback preparados.
• Cambio realizado de forma aislada.
• Aplicación, Log Viewer, Packet Capture y acceso de gestión probados.

Preguntas frecuentes