Ir al contenido
Avanet

Cambiar de forma segura la route precedence en Sophos Firewall

La route precedence determina de forma global si Sophos Firewall evalúa primero las Static Routes, las SD-WAN Policy Routes o las rutas VPN. El orden se aplica cuando varias categorías coinciden con el mismo flujo. Una excepción importante: vpn antes de static solo desplaza las rutas estáticas o locales para destinos de la zona WAN.

Por qué es necesaria la route precedence

Sophos Firewall no mantiene Static, SD-WAN y VPN en una única lista de routing. Son categorías separadas, y varias categorías pueden contener al mismo tiempo un camino válido hacia el mismo destino. La route precedence determina en qué categoría se busca primero una ruta coincidente.

Un ejemplo típico: un cliente de la LAN debe llegar a la red remota 10.20.0.0/16 mediante un túnel IPsec policy-based. Al mismo tiempo, una ruta SD-WAN con destino Any también coincide con ese tráfico.

  • Con static sdwan_policyroute vpn, el firewall comprueba primero Static. Si no encuentra allí un camino coincidente, la ruta SD-WAN general coincide a continuación y el tráfico puede dirigirse al gateway WAN en lugar del túnel VPN.
  • Con static vpn sdwan_policyroute, el firewall comprueba las rutas VPN inmediatamente después de Static. La ruta a la red remota tiene así prioridad sobre la ruta SD-WAN general.

La red de ejemplo 10.20.0.0/16 se sustituye por la red remota real. Lo importante no es qué orden parece «mejor» en general, sino qué tipo de routing debe ganar para el flujo de paquetes concreto.

La route precedence solo ordena las categorías. No cambia el orden de las Static Routes o SD-WAN Routes individuales dentro de su categoría. Antes de modificarla, se deben responder tres preguntas:

  1. ¿Qué tráfico concreto toma actualmente el camino equivocado?
  2. ¿Cuáles de las tres categorías contienen una ruta coincidente?
  3. ¿Qué categoría debe tener prioridad para ese tráfico?

Si solo coincide una categoría, cambiar la route precedence no resolverá el problema. En ese caso se debe corregir la ruta afectada, la Policy SD-WAN, la configuración VPN, la regla NAT o el retorno. Además, la route precedence no permite tráfico entre zonas; sigue siendo necesaria una regla de firewall adecuada.

Mostrar y cambiar directamente la route precedence

Los comandos se ejecutan en Device Console, no en Advanced Shell. Después de iniciar sesión por SSH, se selecciona la opción de menú 4. Si aún no se ha configurado el acceso, consulta Conectar con Sophos Firewall mediante SSH.

Primero se anota el orden actual completo para preparar el comando de rollback. El valor predeterminado actual de Sophos no lo sustituye, ya que un firewall migrado o personalizado puede partir de un orden distinto.

⚠️ Importante: El cambio es global. Antes del comando set deben estar documentados el orden inicial y una vía de gestión independiente. Un orden inadecuado puede afectar al tráfico de producción y al acceso mediante WebAdmin y SSH.

El siguiente ejemplo establece Static primero, VPN en segundo lugar y SD-WAN al final:

system route_precedence show
system route_precedence set static vpn sdwan_policyroute
system route_precedence show

El primer comando muestra el orden actual, el segundo lo modifica y el tercero comprueba el resultado. La posición determina la prioridad. La salida final debe mostrar static, vpn, sdwan_policyroute exactamente en ese orden; después se prueba el flujo real.

El orden predeterminado actual de Sophos es:

system route_precedence set static sdwan_policyroute vpn

Este comando solo es un rollback si system route_precedence show mostraba exactamente ese orden antes del cambio.

WebAdmin también muestra el orden actual en Routing > SD-WAN routes, pero solo se puede modificar mediante Device Console.

Qué significan Static, SD-WAN y VPN

Los tres valores representan categorías de routing, no rutas individuales:

  • static incluye redes conectadas directamente, Unicast Routes, Dynamic Routes y SSL VPN.
  • sdwan_policyroute incluye las Policy Routes configuradas en Routing > SD-WAN routes.
  • vpn incluye las rutas IPsec policy-based generadas automáticamente. En SFOS 22.0 también incluye las rutas definidas con ipsec_route.

Las rutas IPsec policy-based y las entradas ipsec_route no aparecen en la tabla de routing de WebAdmin. Al analizar conflictos también hay que considerar la configuración VPN y las rutas creadas en Device Console. La guía sobre rutas IPsec en Sophos Firewall explica la clasificación completa.

SSL VPN pertenece a static, no a vpn. IPsec route-based mediante interfaces XFRM se controla mediante la ruta estática, dinámica o SD-WAN configurada. Son decisivos la interfaz XFRM, la ruta y su Administrative Distance, no solo la posición de vpn. Si ninguna ruta coincide, WAN Link Manager proporciona la ruta predeterminada.

Static, SD-WAN, VPN

system route_precedence set static sdwan_policyroute vpn

Este es el orden predeterminado y el punto de partida correcto para muchos entornos. Evita que rutas SD-WAN demasiado amplias anulen redes conectadas directamente, LAN, DMZ, VLAN y SSL VPN.

Static, VPN, SD-WAN

system route_precedence set static vpn sdwan_policyroute

Este orden mantiene Static en primer lugar, evalúa después las rutas VPN y utiliza SD-WAN al final. Resulta útil cuando las rutas estáticas y conectadas directamente deben conservar su prioridad mientras una ruta VPN policy-based competidora debe comprobarse antes que SD-WAN. Sophos también lo utiliza para el failover VPN route-based con dos conexiones a Internet y para MTA con varias conexiones WAN.

SD-WAN, Static, VPN

system route_precedence set sdwan_policyroute static vpn

Esta variante solo debe usarse cuando el Policy Routing tenga que imponerse de forma deliberada a las rutas estáticas. Hay que tener especial cuidado con una ruta SD-WAN cuyo destino sea Any: También puede abarcar redes internas o el acceso de gestión y enviar ese tráfico hacia el gateway WAN. Por tanto, una ruta SD-WAN debe utilizar destinos lo más concretos posible y probarse.

VPN, Static, SD-WAN

system route_precedence set vpn static sdwan_policyroute

Colocar VPN primero es una excepción específica, no una solución general para problemas de IPsec. Para L2TP Remote Access, vpn debe ir primero; static y sdwan_policyroute pueden seguir en cualquier orden. Sin embargo, vpn antes de static solo prioriza VPN sobre Static cuando la ruta estática competidora conduce a la zona WAN. Para destinos en otras zonas, el firewall continúa utilizando la ruta estática o local.

El diseño policy-based que encamina el tráfico de Internet de una sucursal por la central también requiere exactamente este orden. Combina selectores Any, una regla VPN-to-WAN, MASQ y una decisión separada para el tráfico generado por el sistema.

Cambiar la route precedence de forma segura

Antes de un cambio en producción se deben preparar tanto el comando como el flujo de paquetes afectado:

  1. Guardar el orden actual completo con system route_precedence show y utilizarlo para preparar el comando de rollback.
  2. Identificar origen, destino, servicio, zona e interfaces implicadas. Comprobar Static Routes, SD-WAN Routes, rutas VPN e interfaces XFRM que cubran destinos competidores.
  3. Probar una vía independiente de acceso al firewall, como una consola local, una interfaz de gestión separada o una vía administrativa no afectada.
  4. Cambiar únicamente la route precedence. No modificar al mismo tiempo reglas de NAT, firewall, VPN y SD-WAN, para que causa y efecto sigan siendo identificables.

Si interviene SD-WAN, también se debe comprobar si está activado para el tráfico generado por el sistema o los reply packets:

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

Estas opciones no cambian el orden. Amplían el tráfico al que se aplican las SD-WAN Routes: el routing de Reply Packets no se aplica si la ida solo usó la ruta predeterminada de WAN Link Manager. Para tráfico generado por el sistema, usar solo redes de destino y servicios, porque Incoming Interface y Source Network no se conocen. Al menos un gateway de WAN Link Manager debe estar Active; no bastan gateways que estén únicamente en Backup. El tráfico RED generado por el sistema mediante UDP 3410 queda fuera del routing SD-WAN por ser Layer 2. Comprobar SD-WAN routing para Reply Packets y System Traffic en Sophos Firewall explica los detalles.

Después del comando set, se confirma primero el orden con system route_precedence show. A continuación, se prueba el caso concreto:

  • Probar la aplicación, una conexión TCP o el ping al destino.
  • Comprobar Route Lookup, Log Viewer y Packet Capture cuando sea necesario.
  • Comprobar NAT y el retorno del sistema remoto.
  • Probar WebAdmin y SSH desde las redes de gestión relevantes.

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

Rollback

Para el rollback se restablece exactamente el orden inicial registrado antes del cambio:

system route_precedence set <erster Wert> <zweiter Wert> <dritter Wert>

Se deben sustituir los tres placeholders. El estado anterior no puede deducirse solo del primer valor, porque existen seis órdenes posibles. Después se repiten system route_precedence show y las mismas pruebas funcionales y de gestión.

Si el cambio no resuelve el problema

  • Solo está afectada una red de destino: Una ruta estática más específica, una ruta SD-WAN más limitada o una configuración VPN corregida suelen ser más precisas que un cambio global.
  • El túnel VPN está en verde, pero el tráfico toma el camino equivocado: Con IPsec route-based se comprueban primero la interfaz XFRM y la ruta. Con IPsec policy-based también se revisan los Traffic Selectors y el tratamiento de ipsec_route según la versión. Consulta la guía de troubleshooting de VPN IPsec.
  • El camino de ida es correcto, pero el de retorno no: Routing determina el camino, mientras que NAT modifica la dirección de origen o destino. Comprobar la ruta de retorno y la configuración NAT.
  • Un firewall migrado muestra un orden inesperado: La salida de system route_precedence show es la referencia, no el valor predeterminado actual. Las rutas SD-WAN migradas también pueden seguir vinculadas a su regla de firewall original y desaparecer al eliminarla.
  • WebAdmin o SSH no están disponibles después de un cambio en SD-WAN: A menudo coinciden tres condiciones: SD-WAN precede a Static, una ruta SD-WAN coincidente utiliza Any y System Traffic o Reply Packets están activados para SD-WAN. Restablecer el orden inicial mediante la vía de gestión preparada y limitar la ruta SD-WAN.
  • Una solicitud SSL VPN llega al destino interno, pero la respuesta no llega al cliente: SSL VPN pertenece a static. Si SD-WAN aparece antes, una ruta SD-WAN amplia puede desviar del túnel la respuesta dirigida al rango de asignación. Limitar específicamente la ruta; el procedimiento completo se explica en Configurar y probar SSL VPN Remote Access.

Preguntas frecuentes

¿Por qué no aparece la ruta VPN competidora en la tabla de routing?

Las rutas IPsec policy-based y las entradas ipsec_route no se muestran allí. Antes de cambiar la route precedence, revisa también la configuración IPsec y las rutas creadas en Device Console.

¿Sustituye la route precedence a una regla de firewall?

No. Elige entre categorías de routing competidoras. El tráfico sigue necesitando una regla de firewall adecuada y, según el diseño, NAT y un retorno que funcione.