Ir al contenido
Avanet
Iniciar sesion

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 interfaz de entrada, origen, destino y servicio
  • qué primary/backup gateway o perfil SD-WAN 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: una 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 de la interfaz XFRM como primary gateway o dentro de un perfil SD-WAN. 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.

Dos WAN con prioridades opuestas

Para la LAN 10.20.0.0/24, los destinos públicos seleccionados deben usar preferentemente WAN1, y los demás destinos IPv4 públicos, WAN2. Cada línea sirve de respaldo a la otra. Este ejemplo de planificación complementa el procedimiento SFOS-22; la documentación SFOS-23-EAP confirma el mecanismo de los perfiles, pero no supone una aprobación para cualquier build.

⚠️ Las nuevas rutas y su orden cambian la ruta de datos. Antes, guardar posiciones de rutas, estados On/Off, valores de perfiles, NAT y la Route Precedence actual, y comprobar un acceso de administración independiente. Realizar pruebas de fallo solo durante una ventana de mantenimiento autorizada; no borrar ni modificar gateways o perfiles compartidos para simular fallos.

  1. En Routing > SD-WAN profiles > Add, crear dos perfiles independientes con Routing strategy: First available gateway: Ziele_WAN1_WAN2 con el orden WAN1, WAN2, e Internet_WAN2_WAN1 con WAN2, WAN1. Los nombres, la LAN y los gateways son valores de ejemplo adaptables. Activar Health check en ambos; dejar SLA desactivado para esta selección basada solo en disponibilidad. Elegir destinos de sondeo, protocolo y contadores según el procedimiento de comprobación de estado descrito abajo, sin aceptar ciegamente los valores predeterminados. Los destinos deben detectar también un fallo más allá del gateway del proveedor, no solo su conectividad local.
  2. En Routing > SD-WAN routes > IPv4 > Add, crear la ruta específica LAN_Ziele_WAN1: Incoming interface es la interfaz LAN real, Source networks el objeto de 10.20.0.0/24, Destination networks el grupo actualizado de destinos públicos seleccionados y Services únicamente los servicios necesarios. Seleccionar Ziele_WAN1_WAN2. Para dominios, considerar primero los límites de los hosts y grupos FQDN; un dominio no garantiza un rango IP de destino exclusivo.
  3. Debajo, crear LAN_Internet_WAN2 con la misma interfaz LAN y red de origen, Destination networks: Internet IPv4 group, los servicios de Internet autorizados e Internet_WAN2_WAN1. La ruta específica debe quedar por encima de la ruta general de Internet. No usar una ruta global Any; los destinos internos y VPN no pertenecen a esta salida de Internet.
  4. Definir conscientemente Route only through specified gateways en ambas rutas: en este ejemplo está activado para que ningún otro camino tome el relevo si fallan los dos previstos. Comprobar por separado los permisos de firewall y MASQ/SNAT para las dos WAN. Si el extremo remoto requiere una IP pública fija, también debe permitir la IP de respaldo.

Para validar, crear una conexión nueva a un destino específico y a otro destino público: inicialmente se esperan WAN1 y WAN2, respectivamente. Después, probar por separado ambos fallos aguas arriba en un entorno autorizado, incluso manteniendo activa la interfaz física: si falla WAN1, las nuevas conexiones de ambas clases deben funcionar por WAN2; si solo falla WAN2, por WAN1. Tras cada recuperación, comparar las conexiones nuevas con la prioridad prevista y observar las sesiones existentes por separado. Documentar ruta, gateway y SNAT/IP pública en los logs o Packet Capture, y volver a comprobar DNS, HTTPS y el acceso de administración interno. Esto no implica un tiempo fijo de conmutación ni continuidad de las sesiones existentes.

Ante un camino inesperado, no ampliar criterios: comparar primero coincidencias de ruta, orden, estado y NAT. Para revertir, desactivar las rutas nuevas o restaurar los valores anteriores documentados de rutas, perfiles y NAT, incluido su orden; después, repetir las comprobaciones de estado y de ambos flujos. Sin una simulación de fallo aislable, esa parte de la validación queda pendiente. Los límites detallados de sesiones y SNAT se explican más abajo en Probar failover y failback de forma segura.

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 perfil SD-WAN 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 perfil SD-WAN

Los primary/backup gateways son suficientes para una ruta preferida y un fallback. Un perfil SD-WAN 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 perfil SD-WAN 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 IP de origen, IP de destino, origen y destino 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. Estos ajustes tienen funciones distintas: Interval between checks y Response time-out regulan el sondeo; Deactivate gateway after cuenta intentos fallidos y Activate gateway after respuestas correctas. Sample size for SLA fija el número de muestras para el rendimiento medio del gateway. Ajustar por separado la detección de fallos y la reactivación; los cinco valores no forman un único temporizador de failover.
  7. Guardar el perfil, 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 perfil 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 perfil. Comprobar estas dependencias antes de modificar o eliminar el perfil.

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 perfil SD-WAN 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.

Round-robin reparte las solicitudes por orden entre los gateways elegibles. Con tres gateways disponibles, de igual peso y sin restricciones SLA, el ejemplo usa el primero, segundo, tercero y de nuevo el primero. Session persistence type mantiene las sesiones relacionadas en el mismo gateway según la clave elegida, por ejemplo para banca o carritos de compra. Un único flujo de prueba no muestra el reparto de muchas sesiones independientes.

Cuando ningún gateway cumple el Custom SLA

El descarte por gateways inaccesibles no demuestra un bloqueo estricto por SLA de caminos que siguen accesibles. Sin pruebas específicas de la build, no garantizar ni la continuación de Load balancing ni el uso exclusivo de First available gateway para este caso.

  1. Documentar build SFOS, perfil, Routing strategy, orden de gateways, pesos, session persistence, límites SLA, probe targets y Route only through specified gateways.
  2. Usar Link status, Historical performance y logs SD-WAN para distinguir caminos accesibles fuera del SLA de caminos realmente inaccesibles.
  3. Probar solo con un flujo autorizado y aislado, en una ventana de mantenimiento y con acceso de gestión independiente. No modificar perfiles de producción compartidos para simular fallos ni eliminar gateways o perfiles. Crear conexiones nuevas y demostrar gateway, IP SNAT y resultado de la aplicación con Log Viewer y Packet Capture; evaluar por separado las sesiones existentes.
  4. Restaurar los valores de prueba modificados al estado inicial documentado y repetir las comprobaciones de estado y tráfico real. Sin prueba autorizada, la selección sigue sin resolverse; para aclararla por build se necesitan configuración, mediciones, fechas y horas y logs junto con la build.

Un resultado para una build y un perfil no es una garantía general de failover.

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

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 origen, destino, servicio, ID de regla, ID de NAT y gateway.
  5. Comprobar el contador de tráfico de la ruta SD-WAN: OUT cuenta las solicitudes e IN las respuestas solo si el origen y el destino corresponden a la dirección respectiva.
  6. En System services > Log settings, activar el tipo SD-WAN y revisar el módulo SD-WAN en Log Viewer para eventos de perfiles, SLA y rutas.
  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 registros de perfiles y rutas 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 perfil SD-WAN utilizado. También se puede abrir Routing > SD-WAN profiles, seleccionar el perfil 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 perfil 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 perfil utilizado, el orden de gateways del perfil, 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 gateway principal y se comprueban el camino, las sesiones, la IP pública de origen y el retorno. Para esta prueba no se deben eliminar el gateway principal ni el perfil SD-WAN, porque esto elimina la ruta y solo prueba el recurso a la ruta predeterminada. Editar la ruta o el perfil, 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 de gateway principal y de respaldo, las conexiones nuevas vuelven al gateway principal cuando este se recupera; las conexiones existentes permanecen normalmente en el gateway de respaldo.

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 IP de origen 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. Activar el rerouting SNAT no elimina las restricciones de MASQ/IP.

Delimitar problemas de forma sistemática

La ruta no coincide

  • Comparar interfaz de entrada, red de origen, destino y servicio 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 contador de tráfico como única prueba, porque las solicitudes y las respuestas solo se cuentan si coinciden los criterios de origen y destino.
  • Con Direct Web Proxy no basta con que el servicio coincida con HTTP/HTTPS: se utiliza Any o un servicio para el puerto configurado en Web > General settings > Web proxy listening port. En este caso especial, la red de origen y la interfaz de entrada no se usan como criterios de coincidencia para los paquetes de respuesta; el retorno del proxy también necesita un gateway WAN predeterminado 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 paquetes de respuesta y el tráfico generado por el sistema tienen sus propias opciones de activación y reglas de coincidencia. Estos casos se explican en Comprobar el enrutamiento SD-WAN de paquetes de respuesta y tráfico del sistema 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 destino Any, el enrutamiento SD-WAN para tráfico generado por el sistema está activado y también lo está para los paquetes de respuesta. 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 origen, destino 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 IP de origen traducida con el gateway realmente utilizado.
  • Comprobar si se eliminó un primary gateway o perfil SD-WAN 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 IP de origen 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.

API XML: aclarar los límites de los objetos antes de automatizar

La documentación de la API XML para SFOS 22.0 y 23.0 describe objetos con nombre independientes. La configuración mediante la UI explicada anteriormente sigue siendo el procedimiento práctico; sin embargo, no permite deducir un contrato XML inequívoco. Las siguientes observaciones señalan contradicciones documentadas, no una solicitud probada ni un esquema corregido. Para automatizar, se necesita que Sophos aclare los campos afectados para la versión correspondiente; aquí no se propone ninguna correspondencia numérica por conjetura ni se proporciona una solicitud XML ejecutable.

HealthCheckProfile con nombre: ciclo de vida y contadores de sondeo

HealthCheckProfile es un objeto de Health Check independiente, no el SDWANProfile ni la opción integrada de comprobación de estado del gateway. Al crearlo y actualizarlo, el campo obligatorio Name, de tipo string escalar, identifica el perfil de Health Check; ambas tablas de campos indican un máximo de 125 caracteres. La tabla de 22.0 también prohíbe las comas y permite expresamente caracteres UTF-8, mientras que estas dos indicaciones no aparecen en la tabla de 23.0. Esta ausencia no demuestra que haya cambiado la validación del nombre.

ProbeTargets se describe como un array de objetos monitorDetails, pero el ejemplo contiene elementos ProbeTarget. monitormethod indica TCP o PING; monitorip indica los tipos de datos IPADDRESS, IPADDRESS6 y DOMAINNAMELOOKUP. Para operator figuran los literales & y |, con | como valor predeterminado. De ello no se deduce ni una estructura XML diferente ni una equivalencia con el comportamiento de los dos Probe Targets en la UI descrito anteriormente. IPFamily también presenta una contradicción: ambas tablas indican IPv4 e IPv6, con IPv4 como valor predeterminado, pero al mismo tiempo establecen un máximo de 1 carácter.

Las dos filas de contadores parecen estar intercambiadas respecto a sus nombres: ProbesResponseFailure describe literalmente respuestas consecutivas para activar el objeto, con un valor predeterminado de 1; ProbeResponseSuccess describe sondeos consecutivos sin respuesta antes de desactivarlo, con un valor predeterminado de 3. Ambas tablas indican un intervalo de 1 a 10 para cada contador. Esta correspondencia documental no se corrige de forma implícita y no confirma el comportamiento en tiempo de ejecución. En particular, las explicaciones fiables de la UI sobre Deactivate gateway after y Activate gateway after no se trasladan automáticamente a estas etiquetas de la API.

La operación de eliminación independiente también identifica el perfil de Health Check mediante Name, no una ruta ni un perfil SD-WAN. Antes de una eliminación prevista, se comprueban los perfiles SD-WAN que lo referencian y se documenta su asociación de Health Check existente. Las fuentes no acreditan un procedimiento seguro de eliminación en cascada ni el comportamiento al eliminar un objeto de Health Check que todavía está referenciado. Esto no equivale a la eliminación de un perfil SD-WAN descrita anteriormente; esta eliminación tampoco constituye una prueba de fallo.

HealthCheckProfileStatus: estado administrativo del objeto de Health Check

HealthCheckProfileStatus activa o desactiva administrativamente el perfil de Health Check con nombre. El selector es el campo obligatorio Name, de tipo string escalar; el marcador de posición del ejemplo HealthCheckProfileStatusName no cambia la identidad de este campo. En ambas versiones, el ejemplo muestra ON/OFF para Status, mientras que la fila del campo obligatorio indica INTEGER sin correspondencia numérica. Por tanto, no queda acreditada ninguna representación numérica para activar o desactivar. Esta administración no equivale a la disponibilidad medida del gateway, al estado activo de un perfil SD-WAN ni a la activación o desactivación de una ruta. Un mensaje de éxito documentado, por sí solo, no demuestra que el estado haya cambiado realmente; habría que comprobar el estado administrativo de ese objeto con nombre concreto, por separado de los indicadores de disponibilidad.

SDWANPolicyRouteStatus: comprobar la ruta y el estado correctos

SDWANPolicyRouteStatus utiliza SDWANPolicyRouteName como selector obligatorio de tipo string escalar, no el Name de un perfil de Health Check. Los ejemplos de ambas versiones vuelven a mostrar ON/OFF para Status, mientras que la fila del campo obligatorio indica INTEGER y no proporciona ninguna correspondencia numérica. El código de resultado documentado 200 no es una confirmación independiente de que la ruta deseada haya cambiado su estado administrativo. Para ello habría que comprobar el estado On/Off real de esa ruta. La información emergente de Active, la accesibilidad del gateway y la decisión de descarte o fallback determinada por Route only through specified gateways responden a otras preguntas y no resuelven la contradicción del contrato XML de estado.

SDWANProfile: familia, estrategia y referencia independiente de Health Check

En SDWANProfile, Name identifica el propio perfil SD-WAN, con un máximo de 60 caracteres. En cambio, el campo obligatorio HealthCheckProfileName, de tipo string escalar, es la referencia al perfil de Health Check independiente, con un máximo de 85 caracteres. No se trata de la misma identidad ni de la misma longitud de nombre documentada que su campo Name, de 125 caracteres. Por ello, los límites de objetos y contadores de HealthCheckProfile también se aplican al preparar esta referencia; los ajustes integrados de Health Check no sustituyen la referencia con nombre obligatoria.

Los ejemplos y las descripciones de campos de ambos perfiles indican IPv4/IPv6 para IPFamily, pero la fila de validación solo permite IPv4 y, al mismo tiempo, establece un máximo de 1 carácter. Por tanto, las rutas IPv6 de la UI no demuestran que este contrato XML del perfil admita IPv6. Para SLAStrategy, el ejemplo y la descripción indican BestQuality, mientras que la lista de valores permitidos contiene BestQualityv; CustomSLA aparece en ambos. Para LBMethod, el ejemplo indica WRR/SrcSticky/DestSticky/SrcDestSticky/ConnectionSticky, mientras que la tabla indica INTEGER en el intervalo de 0 a 5, sin correspondencia con esos valores de texto. Para IsLatency, el valor predeterminado 1 contrasta con los literales permitidos OFF y ON. Ninguna de estas diferencias se resuelve mediante una supuesta corrección tipográfica, una representación numérica o una correspondencia booleana deducida. Las estrategias y los procedimientos de comprobación de la UI descritos anteriormente siguen siendo útiles, pero no demuestran que exista una solicitud ejecutable para el perfil.

Operación y documentación

Para cada ruta SD-WAN en producción se documentan finalidad, interfaz de entrada, origen y destino, servicios, gateway o perfil, mecanismo de respaldo, traducción NAT prevista, cliente de prueba, destino de prueba, responsable y fecha de revisión. Después de cambios de proveedor, VPN, interfaz o servicio en la nube se vuelven a comprobar la coincidencia, los registros y la conmutación por error.

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
  • la conmutación por error, el retorno al enlace preferido y la IP pública de origen reaccionan según lo documentado
  • se han registrado un responsable y una próxima fecha de revisión