Ir al contenido
Avanet

Configurar y probar rutas SD-WAN en Sophos Firewall

Sophos Firewall

Con una ruta SD-WAN se controla por qué gateway pasa un flujo de tráfico definido en Sophos Firewall. Resulta útil con varias conexiones a Internet, MPLS, VPN IPsec route-based, VoIP o servicios cloud. La ruta debe definirse con precisión y probarse con tráfico real; de lo contrario, puede incluir redes internas o usar una IP pública incorrecta durante el failover.

Si Sophos Fusion (antes Sophos Central) debe generar los túneles basados en rutas y los trayectos entre sedes para varios firewalls administrados, debe utilizarse Configurar y comprobar un grupo de conexiones SD-WAN en Sophos Fusion. Este artículo explica la ruta SD-WAN local, que también sigue siendo importante para validar los trayectos distribuidos de forma centralizada.

Respuesta breve

Una ruta SD-WAN se crea aquí:

Routing > SD-WAN routes > IPv4 / IPv6 > Add

Antes deben estar claros cuatro puntos:

  • qué tráfico debe coincidir según incoming interface, source, destination y service
  • qué primary/backup gateway o SD-WAN profile se utilizará
  • si solo se permiten esos gateways y qué NAT corresponde
  • cómo comprobar la ruta, el gateway y el retorno con Log Viewer y Packet Capture

Para destinos IPv4 públicos no se debe usar Any de forma general. Siempre que sea posible, conviene utilizar Internet IPv4 group o destinos concretos. Si SD-WAN precede a Static en route precedence, una ruta amplia con Any también puede enviar tráfico interno al gateway WAN.

El vídeo complementa la guía para planificar, configurar y validar rutas SD-WAN en Sophos Firewall.

Uso y planificación

Cuándo conviene usar SD-WAN en lugar de una ruta estática

Una ruta estática basta cuando una red de destino siempre es accesible mediante un next hop fijo. Las rutas SD-WAN añaden criterios como source, service, usuario o aplicación y pueden seleccionar gateways según su disponibilidad o calidad.

Casos habituales:

  • dirigir determinados clientes o servicios por WAN2 y cambiar a WAN1 si falla
  • enviar VoIP o aplicaciones cloud por una ruta con baja latencia y poca pérdida de paquetes
  • utilizar MPLS, LTE/5G o un túnel IPsec route-based como ruta primaria o de respaldo
  • vincular tráfico a un proveedor cuya IP pública está autorizada en un sistema remoto

Ejemplo de planificación y requisitos

Antes de crear la ruta se describe un flujo concreto. Para tráfico de Microsoft 365, la planificación podría ser la siguiente:

  • Incoming interface: interfaz LAN interna
  • Source network: Client_Net_10.20.0.0_24
  • Destination: grupo de destinos de Microsoft 365 mantenido internamente o Internet IPv4 group
  • Services: HTTPS y, si hace falta, un grupo de servicios para UDP 3478-3481
  • Primary gateway: WAN2
  • Backup gateway: WAN1
  • Fallback: permitir la default route o activar Route only through specified gateways
  • NAT: MASQ o una IP SNAT fija adecuada para el gateway elegido
  • Test: IP de cliente, destino, gateway esperado y entrada de log esperada

También se necesitan reglas de firewall adecuadas, reglas NAT para el tráfico que deba traducirse, logging de firewall activado y acceso a Log viewer y Diagnostics > Packet capture. Los gateways WAN están en Network > WAN link manager; los custom gateways para MPLS, RED o XFRM se crean en Routing > Gateways.

El comportamiento general Active/Backup de la ruta WAN predeterminada se explica en Configurar el failover WAN en Sophos Firewall; para los fundamentos de interfaces y gateways, consultar Configurar zonas e interfaces de Sophos Firewall.

Con IPsec route-based, la dirección es importante: Un interfaz XFRM como Incoming interface coincide con tráfico que entra desde el túnel. Para tráfico de LAN a VPN se selecciona, en cambio, el gateway del interfaz XFRM como primary gateway o dentro de un SD-WAN profile. Los fundamentos están en Crear una ruta IPsec en Sophos Firewall.

Para un ejemplo más limitado de Teams, añadir el grupo ficticio Sales_Team en Users or groups y Teams_VoIP en Application objects. Sustituir ambos nombres por el grupo de usuarios propio y las aplicaciones realmente necesarias. Junto con la interfaz LAN, Client_Net_10.20.0.0_24, los destinos y los servicios previstos, esto dirige únicamente el flujo coincidente por WAN2/WAN1. Comprobar por separado una regla de autorización restringida de LAN a WAN para este origen, destinos y servicios, los permisos de usuario previstos y NAT en ambos caminos. La ruta SD-WAN no concede acceso; la prueba debe mostrar el usuario, la aplicación, Firewall Rule ID y NAT ID previstos.

MPLS entre una sucursal y la sede central

Un ejemplo acotado conecta 10.20.0.0/24 en la sucursal con los servidores web de la red central 10.30.0.0/24: la interfaz de entrada es la LAN de la sucursal, el primary gateway es MPLS-1, el backup es MPLS-2 y los servicios se limitan a los TCP 80/TCP 443 necesarios. El firewall central necesita la ruta de retorno correspondiente de 10.30.0.0/24 a 10.20.0.0/24 por sus propios gateways MPLS. Redes, interfaces, gateways y servicios son valores de ejemplo que deben adaptarse a la topología real. La regla de firewall independiente de la sucursal permite LAN hacia la zona MPLS real, aquí MPLS_DMZ, solo para estas redes y servicios; las reglas centrales también deben permitir el flujo previsto. Este diseño enrutado conserva las direcciones privadas originales sin SNAT. No es una norma NAT universal para toda instalación MPLS. Verificar ambos sentidos y la IP de origen sin modificar con tráfico real en los dos firewalls.

Configurar la ruta SD-WAN

Definir los criterios de coincidencia

Para IPv6, seleccionar hosts IP de destino concretos en lugar de un destino genérico Any. Si debe conservarse una ruta general Any, crear encima una ruta para los hosts IP de destino específicos y su gateway previsto; mantener también restringidos incoming interface, source y services. Antes de cambiar nada, registrar el orden instalado con system route_precedence show, la posición y los ajustes de la ruta, verificar un acceso de gestión independiente y planificar cómo restaurar esos valores. Una ruta más específica no justifica restablecer a ciegas la precedencia global.

  1. Abrir Routing > SD-WAN routes.
  2. Seleccionar IPv4 o IPv6 y hacer clic en Add.
  3. Introducir un nombre inequívoco como Clients_M365_WAN2.
  4. Seleccionar el Incoming interface por el que entra el tráfico que se desea controlar.
  5. Opcionalmente, seleccionar un valor DSCP si los paquetes entrantes están marcados de forma fiable.
  6. Definir Source networks y añadir Users or groups si es necesario.
  7. Limitar Destination networks tanto como sea posible.
  8. Limitar Services a los protocolos y puertos necesarios.
  9. Opcionalmente, seleccionar Application objects.
  10. En Link selection settings, elegir un SD-WAN profile o primary/backup gateways.
  11. Activar o desactivar de forma consciente Route only through specified gateways.
  12. Guardar la ruta y colocarla en la posición correcta; gana la primera ruta SD-WAN que coincida.
  13. Probarla con un cliente y un destino definidos.

Los Application Objects requieren una Web Protection License activa. La primera conexión se enruta según destination IP, puerto, protocolo e incoming interface mediante otra ruta SD-WAN coincidente o, si no la hay, por la default route. El Application Object solo se aplica a conexiones posteriores una vez detectada la aplicación. Los datos de clasificación tienen una TTL de 3600 segundos desde el inicio de la sesión. Para Micro Apps, solo DPI Engine Mode admite todas las aplicaciones; Web Proxy Mode solo admite Pattern Applications y Synchronized Security Applications.

En un clúster HA, SFOS sincroniza esta caché de Application Routing por el enlace HA dedicado mediante multicast 226.1.1.1 en el puerto 4455. Un reinicio del firewall borra los datos de clasificación. Después de un reinicio o de un problema de HA, no basta con comprobar el estado del túnel o del gateway; hay que generar de nuevo una primera conexión de aplicación y otra posterior.

Crear un Application Object

El motor DPI puede reclasificar una aplicación dentro de la misma conexión, por ejemplo al pasar de una web a su chat. La nueva decisión se aplica a conexiones posteriores; no garantiza que se redirija la conexión actual. Si no comienza otra sesión dentro de la TTL de 3600 segundos desde el inicio de la sesión, se eliminan los detalles de sesión almacenados.

Los Application Objects pueden incluir aplicaciones web, micro apps, Synchronized Security Applications descubiertas en endpoints, aplicaciones personalizadas y categorías de aplicaciones. Elegir el tipo según la detección necesaria y respetar las restricciones de licencia y DPI/proxy anteriores; una categoría completa es más amplia que una sola aplicación necesaria.

Un Application Object agrupa únicamente las aplicaciones que deben utilizar la misma ruta SD-WAN. Se abre Applications > Application object, se selecciona Add, se asigna un nombre y se limitan los resultados mediante Category, Risk, Characteristics, Technology, Classification o la búsqueda por nombre. Después se marcan las aplicaciones realmente necesarias y se guarda el objeto. Sophos actualiza dinámicamente la lista de aplicaciones disponible mediante actualizaciones IPS y Synchronized Application Control; por eso conviene revisar la selección tras cambios de patrones o aplicaciones.

El filtro Technology distingue entre browser-based, client-server, network protocol, P2P y synchronized application control. En Classification están disponibles new, sanctioned, unsanctioned y tolerated. Estos criterios facilitan la selección, pero no demuestran que la ruta posterior funcione. Para comprobarlo se necesita primero la conexión de clasificación y después una nueva conexión de prueba.

Para Microsoft 365, un único objeto colectivo suele ser demasiado amplio. Un objeto como Teams_VoIP puede contener solo las aplicaciones de Teams destinadas a la comunicación en tiempo real, mientras OneDrive o SharePoint utiliza otra ruta. A continuación, el objeto guardado se selecciona en el campo Application objects de la ruta SD-WAN.

Elegir gateway o SD-WAN profile

Los primary/backup gateways son suficientes para una ruta preferida y un fallback. Un SD-WAN profile separa dos decisiones: Routing strategy elige el camino mediante First available gateway o Load balancing; el Service Level Agreement (SLA) opcional añade mediciones de calidad a esa estrategia. Por tanto, Best quality y Custom SLA no son otras dos estrategias de routing.

Configurar un SD-WAN profile en Routing > SD-WAN profiles > Add de este modo:

  1. Introducir nombre y descripción y elegir First available gateway o Load balancing en Routing strategy.
  2. Asignar entre dos y ocho gateways y arrastrarlos al orden deseado. Gateway weights solo aparece con load balancing; pesos diferentes pueden representar distintas capacidades de enlace.
  3. Para load balancing, elegir Round-robin o un Session persistence type adecuado. La persistencia puede basarse en source IP, destination IP, source y destination o una conexión individual.
  4. Activar SLA solo si latencia, jitter o pérdida de paquetes deben influir en la selección. Best quality compara un único criterio. Custom SLA comprueba latencia, jitter y pérdida de paquetes frente a los límites configurados.
  5. Activar Health check, elegir Ping o TCP en Protocol e introducir hasta dos Probe targets. Con TCP, añadir también un puerto en el que el destino responda de forma fiable. SFOS fuerza Health Check cuando SLA está activo.
  6. Ajustar Interval between checks, Response time-out, Deactivate gateway after, Activate gateway after y Sample size for SLA al servicio. Los valores cortos reaccionan antes, pero pueden cambiar innecesariamente durante pérdidas transitorias; los valores mayores son más estables, pero detectan una avería real más tarde.
  7. Guardar el profile, seleccionarlo en la ruta SD-WAN y verificar el camino con tráfico real.

Los dos Probe Targets forman una única prueba de disponibilidad: SFOS considera activo el gateway si al menos uno responde. Si falla el primero, pasa al segundo y continúa utilizándolo mientras responda. El regreso del primero por sí solo no provoca un cambio inmediato. Por ello, los destinos deben estar detrás del gateway y representar el camino relevante; un ping correcto no demuestra que funcionen DNS, TLS o toda la aplicación.

Con Best quality, el failback solo se produce cuando el gateway original es mejor por 10 ms de latencia o 5 ms de jitter; no existe un margen equivalente para la pérdida de paquetes. En Routing > SD-WAN profiles, un profile activo significa que al menos un gateway está disponible. Link status resume la configuración, Historical performance abre las mediciones y Object usage muestra qué rutas usan el profile. Comprobar estas dependencias antes de modificar o eliminar el profile.

Si Route only through specified gateways está activo, el firewall descarta el tráfico cuando los caminos indicados no están disponibles. Sin esta opción, comprueba otras rutas SD-WAN y después la default route. Si se elimina un backup gateway, Sophos Firewall lo cambia a None; al eliminar el primary gateway o el SD-WAN profile también se elimina la ruta y puede asumir la default route.

Con Load balancing y Best quality, el tráfico solo se reparte si al menos dos gateways comparten el mejor rendimiento para el criterio seleccionado; no todo gateway accesible cumple ese requisito. Con Custom SLA, se reparte entre los gateways que cumplen los límites SLA configurados. Un camino accesible que incumple el SLA no equivale a un gateway inaccesible; esto no establece una regla universal de fallback cuando ningún gateway cumple el SLA.

Gateway weights define una proporción de solicitudes: en el ejemplo documentado, 3:1 significa tres de cada cuatro solicitudes por el primer gateway y una por el segundo. Elegir los pesos según la capacidad y los recursos del enlace; no garantizan la misma proporción de bytes, un rendimiento determinado ni la agregación de enlaces.

En Custom SLA, Maximum latency y Maximum jitter se expresan en milisegundos y Maximum packet loss en puntos porcentuales. Interval between checks define el intervalo entre sondas y Response time-out el tiempo de respuesta permitido. Deactivate gateway after cuenta intentos de sondeo fallidos consecutivos; Activate gateway after, respuestas correctas consecutivas. Sample size for SLA define el número de muestras de sondeo utilizadas para determinar el rendimiento medio del gateway. Elegir estos valores para el servicio propio, sin convertir un ejemplo temporal aislado en un valor predeterminado universal.

Coordinar route precedence y NAT

El orden predeterminado documentado es Static → SD-WAN → VPN. No tiene por qué ser el estado de una instalación existente: seguir comprobando system route_precedence show antes de decidir y no aplicar ese orden automáticamente.

Route precedence determina el orden entre Static, SD-WAN y VPN. Las redes conectadas directamente y SSL VPN pertenecen a la categoría Static. El orden actual se ve en Routing > SD-WAN routes o en Device Console; los cambios y el rollback se explican en Cambiar de forma segura la route precedence de Sophos Firewall.

Routing elige el camino; NAT modifica direcciones. Por ello, el tráfico de Internet por WAN2 puede necesitar MASQ o una IP SNAT fija en ese camino. En redes internas y VPN, NAT suele ser indeseado. Las relaciones se explican en Entender NAT en Sophos Firewall: SNAT, DNAT, MASQ, PAT.

DNAT a un servidor detrás de IPsec route-based

Una publicación DNAT pública puede apuntar a un servidor interno que no está conectado localmente, sino detrás de un firewall remoto a través de IPsec route-based. En este caso especial, DNAT y la ruta SD-WAN deben reconocer el mismo flujo entrante antes de la traducción, y la ruta de retorno debe volver a pasar por el firewall que publica el servicio.

El procedimiento fiable de SFOS 22 consta de cinco partes relacionadas:

  1. En Hosts and services > IP host, crear un objeto IP exacto para el servidor remoto.
  2. En Routing > Gateways, crear un gateway con la IP del gateway remoto y la interfaz XFRM correspondiente. Como destino de monitorización se utiliza un host estable y accesible detrás de este gateway.
  3. Hacer que la regla DNAT coincida con la interfaz WAN pública y el servicio ofrecido externamente, y seleccionar el servidor remoto como Translated destination. El ejemplo de Sophos utiliza MASQ para que las respuestas vuelvan al firewall que publica el servicio; sin embargo, el servidor deja de ver la IP original del cliente.
  4. En la ruta SD-WAN, introducir la misma interfaz WAN pública en Destination networks y el puerto externo en Services. Con PAT, se trata expresamente del puerto externo, no del puerto de destino interno traducido. Como primary gateway se selecciona el gateway de la interfaz XFRM.
  5. Comprobar una regla de firewall restringida para la publicación y probar el flujo desde una red externa. NAT Rule ID, Firewall Rule ID, la ruta SD-WAN, el gateway XFRM elegido, los caminos de ida y vuelta y la IP de origen visible en el servidor deben coincidir con el diseño.

MASQ no es aquí una opción cosmética. En el ejemplo documentado resuelve la ruta de retorno, pero oculta al servidor de destino la IP real del cliente. Si el sitio remoto dispone de una ruta de retorno verificada hacia las redes originales de los clientes y se debe conservar la IP original, hace falta un diseño de routing planificado y probado por separado. El procedimiento general de publicación y protección se explica en Publicar un servidor mediante DNAT en Sophos Firewall.

Varios servidores remotos pueden utilizar la misma ruta SD-WAN si son accesibles por el mismo gateway y se distinguen de forma inequívoca por la dirección WAN o el puerto TCP externo. Si utilizan gateways diferentes, se configuran rutas SD-WAN separadas. Si coincide un puerto, un objeto WAN o un gateway incorrecto, no se amplía la ruta a Any; primero se demuestra el flujo previo a DNAT con Log Viewer y Packet Capture.

Probar y aceptar la ruta

Comprobar la lista de rutas y el estado de los gateways

En Routing > SD-WAN routes se puede buscar por nombre de ruta, objeto o valor de objeto; por ejemplo, 443 encuentra las rutas que usan el servicio HTTPS. Arrastrar y soltar cambia el orden. Es una modificación del tráfico porque SFOS evalúa de arriba abajo y se detiene en la primera coincidencia.

En More options se puede activar o desactivar una ruta, editarla o clonarla, restablecer su contador de datos o eliminarla. Antes de restablecerlo, anotar el contador y la hora. Una ruta clonada es independiente: comprobar nombre, criterios, posición, gateway y NAT antes de guardarla o activarla y verificar después su estado On/Off real.

La información emergente del icono en la columna Active muestra estados como In use, Available, Unavailable, In use, but SLA isn't met o Available and SLA isn't met. Que un gateway o profile esté disponible no demuestra ni que esta ruta haya coincidido ni que funcione el camino de retorno.

Con selección directa primary/backup, el icono Active distingue tres estados: al menos un gateway es accesible y la ruta está activa; la ruta no está activa y Route only through specified gateways está desactivado; o no está activa y la opción está activada. En este último caso, el tráfico sigue descartándose si los caminos indicados son inaccesibles, en lugar de utilizar otros gateways. Leer conjuntamente la información emergente y la casilla, sin equipararlas a un estado SLA de un profile.

Prueba estándar con tráfico real

  1. Elegir un cliente de prueba con IP conocida y un destino inequívoco.
  2. Activar logging en la regla de firewall correspondiente.
  3. Iniciar una conexión real.
  4. En Log viewer, comprobar source, destination, service, rule ID, NAT ID y gateway.
  5. Comprobar el traffic count de la ruta SD-WAN: OUT cuenta requests e IN replies solo si source y destination coinciden en la dirección correspondiente.
  6. En System services > Log settings, activar el tipo SD-WAN y revisar el módulo SD-WAN en Log Viewer para eventos de profile, SLA y route.
  7. Si quedan dudas, configurar en Diagnostics > Packet capture un filtro preciso para cliente, destino y puerto.

El Policy tester no tiene en cuenta las rutas SD-WAN. Puede comprobar coincidencias de políticas, pero no confirma ni la ruta SD-WAN elegida ni el gateway real. Para un análisis completo, consulta Probar reglas de Sophos Firewall con Log Viewer, Policy Test y Packet Capture.

Para ver logs de profile y ruta dentro de la vista de firewall, seleccionar el módulo Firewall en Log viewer, abrir la selección ampliada con el botón de expansión junto a la lista de módulos, marcar los logs SD-WAN necesarios y pulsar Apply. Esto complementa la vista del módulo SD-WAN independiente.

Evaluar SD-WAN performance

En los gráficos de calidad, el eje x muestra el tiempo; el eje y muestra latencia y jitter en milisegundos y pérdida de paquetes en puntos porcentuales. Assigned weights for load balancing abre los pesos asignados a los gateways. Las mediciones y los pesos no constituyen una aceptación de la aplicación.

En Diagnostics > SD-WAN performance se selecciona el SD-WAN profile utilizado. También se puede abrir Routing > SD-WAN profiles, seleccionar el profile y hacer clic en Historical performance dentro de Status. Para cada gateway, la vista muestra el total de conexiones, los datos transferidos, los pesos asignados de load balancing, así como latencia, jitter y pérdida de paquetes para Live, 24h, 48h, Week o Month.

Según Sophos, No data to display significa que todavía ninguna ruta utiliza el profile seleccionado o que no circula tráfico por una ruta de este tipo. Por tanto, el mensaje no demuestra un fallo de medición. Primero se genera un flujo controlado por la ruta prevista y se confirma con Log Viewer o Packet Capture.

Reset data transfer and connection count modifica los contadores. Antes de restablecerlos se documentan los valores y la hora. Incluso un gráfico sin anomalías no demuestra que la regla de firewall, NAT, la aplicación y la ruta de retorno funcionen; estos niveles siguen formando parte de la prueba real.

Probar failover y failback de forma segura

Antes de cualquier cambio, anotar la posición y el estado On/Off de la ruta, sus primary/backup gateways o el profile utilizado, el orden de gateways del profile, los valores de SLA y Health Check y la traducción NAT esperada. El rollback consiste en restaurar exactamente esos valores y volver a comprobar estado, logs y tráfico real.

La prueba controlada de fallo se realiza en una ventana de mantenimiento, con un rollback documentado y un camino de gestión independiente hacia el firewall. Antes se comprueban en Device Console los valores actuales de estado, que son de solo lectura:

system route_precedence show
show routing reroute-connection
show routing reroute-snat-connection

Después se inicia tráfico real de la aplicación, se provoca de forma controlada el fallo del primary gateway y se comprueban el camino, las sesiones, la public source IP y el retorno. Para esta prueba no se deben eliminar el primary gateway ni el SD-WAN profile, porque esto elimina la ruta y solo prueba el fallback a la default route. Editar la ruta o el profile, o cambiar Route Precedence, también puede redirigir conexiones existentes y no debe formar parte de la misma prueba de referencia. Con selección directa primary/backup, las conexiones nuevas vuelven al primary cuando regresa; las conexiones existentes permanecen normalmente en el backup gateway.

reroute-connection está activo de forma predeterminada y afecta a conexiones sin SNAT. Las conexiones SNAT no se redirigen de forma predeterminada; incluso con reroute-snat-connection activado por separado, solo funciona si ambos caminos usan la misma source IP traducida. Con MASQ o diferentes direcciones de Override Source Translation, la conexión SNAT no se redirige y la sesión existente se interrumpe cuando falla el camino.

Cambiar el rerouting de forma deliberada

Estos ajustes modifican el tráfico; no son requisitos para la prueba de referencia. Cambiarlos solo durante una ventana de mantenimiento con acceso de gestión independiente verificado y rollback documentado: primero guardar los dos estados de rerouting mostrados arriba y comprobar que ambos caminos usan la misma IP de origen traducida para SNAT. En Device Console están disponibles las siguientes alternativas; ejecutar únicamente el comando necesario para el cambio previsto, no todos en secuencia:

  • Activar sin SNAT: set routing reroute-connection enable; desactivar: set routing reroute-connection disable.
  • Activar para SNAT: set routing reroute-snat-connection enable; desactivar: set routing reroute-snat-connection disable.

Después comprobar con show routing reroute-connection y show routing reroute-snat-connection, y probar por separado sesiones, IP de origen y ambos sentidos del tráfico. Para revertir, restaurar cada ajuste modificado a su estado enable/disable registrado y repetir las comprobaciones de estado y tráfico real. Estos comandos documentados y este rollback no se han probado aquí en un firewall; activar el rerouting SNAT no elimina las restricciones de MASQ/IP.

Delimitar problemas de forma sistemática

La ruta no coincide

  • Comparar incoming interface, source network, destination y service con el flujo real.
  • Comprobar el orden; gana la primera ruta SD-WAN que coincida.
  • Para Application Objects, comprobar licencia, detección DPI y una segunda conexión después de la clasificación.
  • No usar el traffic count como única prueba, porque requests y replies solo se cuentan si coinciden los criterios de source y destination.
  • Con Direct Web Proxy no basta con HTTP/HTTPS como service: Se utiliza Any o un service para el puerto configurado en Web > General settings > Web proxy listening port. En este caso especial, source network e incoming interface no coinciden para reply packets; el retorno del proxy también necesita un WAN default gateway o una ruta estática adecuada.
  • En una ruta SD-WAN migrada desde SFOS 17.5 o anterior, comprobar si se eliminó su regla de firewall original. Estas rutas migradas permanecen vinculadas a la regla antigua y también se eliminan al borrar esa regla.
  • En IPv6, Dead Gateway Detection de las rutas SD-WAN no supervisa tráfico de red de terceros como SNMP. La ausencia de una medición de terceros no es, por tanto, una prueba fiable del estado de DGD.

Configurar Direct Web Proxy con un archivo PAC describe el listener, distribución a clientes, regla de protección y prueba con tráfico real.

Los reply packets y el system-generated traffic tienen sus propios switches y reglas de coincidencia. Estos casos se explican en Comprobar SD-WAN routing para reply packets y system traffic en Sophos Firewall.

Web Admin y SSH dejan de ser accesibles tras una nueva ruta

Un escenario documentado combina cuatro ajustes: SD-WAN precede a Static, una nueva ruta para una red de origen interna concreta tiene destination Any, el routing SD-WAN para tráfico generado por el sistema está activado y también lo está para reply packets. En ese caso puede perderse el acceso de gestión desde la red interna afectada, mientras sigue siendo posible desde otras subredes. No son condiciones necesarias para toda interrupción de gestión.

Mediante un acceso alternativo verificado previamente, comprobar source, destination y precedencia de la ruta, junto con estos valores de solo lectura en Device Console:

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

Primero verificar que la gestión desde una subred no afectada esté realmente permitida y sea accesible. Después limitar el destino de forma deliberada o restaurar uno de los ajustes modificados a su valor original documentado. No realizar un restablecimiento global a ciegas: guardar antes posición, ajustes y precedencia, planificar el rollback y volver a comprobar Web Admin, SSH y el tráfico afectado. Sin un acceso alternativo seguro, no continuar el cambio remotamente.

El tráfico toma el camino equivocado

  • Para destinos IPv4 públicos, sustituir Any por Internet IPv4 group o destinos concretos.
  • Comprobar route precedence, especialmente si afecta a redes internas, SSL VPN o IPsec policy-based.
  • Comprobar el estado de gateway y SLA, así como los Health Check Targets.
  • Comparar la regla NAT y la source IP traducida con el gateway realmente utilizado.
  • Comprobar si se eliminó un primary gateway o SD-WAN profile y con él la ruta.

La aplicación o la respuesta falla tras el failover

Primero se comprueba con Packet Capture si el paquete sale por el gateway esperado y si regresa la respuesta. Después se revisan NAT, listas de IP públicas permitidas, Session Persistence, MTU/MSS y el estado del camino VPN o MPLS. SIP/RTP, portales bancarios y APIs con source IP fija deben probarse especialmente con tráfico real de la aplicación.

Si el problema comenzó inmediatamente después de actualizar a SFOS 22.0 GA, primero hay que comprobar la build instalada. SFOS 22.0 MR1 Build 490 corrige NC-173667, que provocaba la desconexión aleatoria de una ruta SD-WAN, y NC-177603, por el que el audio VoIP a través de una VPN route-based solo funcionaba en una dirección después de actualizar a 22.0 GA. Si ya está instalada MR1 o una build posterior, no debe atribuirse el fallo únicamente a la versión del firmware; hay que repetir la prueba con tráfico real descrita anteriormente y verificar la ruta, las sesiones, NAT y ambos sentidos del tráfico.

Operación y documentación

Para cada ruta SD-WAN en producción se documentan finalidad, incoming interface, source/destination, services, gateway o profile, fallback, expectativa NAT, cliente de prueba, destino de prueba, owner y fecha de revisión. Después de cambios de proveedor, VPN, interfaz o servicio cloud se vuelven a comprobar coincidencia, logs y failover.

Una ruta solo se considera aceptada cuando:

  • los criterios de coincidencia solo incluyen el tráfico planificado
  • la regla de firewall, NAT y route precedence corresponden al diseño
  • Log Viewer y Packet Capture confirman el camino esperado
  • failover, failback y public source IP reaccionan según lo documentado
  • se han registrado un responsable y una próxima fecha de revisión