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.

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. Los fundamentos se explican en 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.

Configurar la ruta SD-WAN

Definir los criterios de coincidencia

  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.

Elegir gateway o SD-WAN profile

Los primary/backup gateways son suficientes para una ruta preferida y un fallback. Para usar un SD-WAN profile se crean al menos dos gateways, después el profile en Routing > SD-WAN profiles y finalmente se selecciona en la ruta. Un profile resulta útil para varios caminos, load balancing o criterios SLA:

  • First available gateway utiliza el primer gateway disponible en el orden definido.
  • Load balancing distribuye conexiones; Session Persistence y Gateway Weights controlan la afinidad y el reparto.
  • Best quality compara un único criterio: latencia, jitter o pérdida de paquetes.
  • Custom SLA exige límites para los tres criterios y utiliza la estrategia de routing seleccionada si no se cumplen.

Los Health Checks prueban mediante ping o TCP hasta dos Probe Targets. Estos destinos deben representar el camino relevante, pero no demuestran que una aplicación completa funcione. Con Best Quality, el failback solo se produce cuando el gateway original es mejor por 10 ms de latencia o 5 ms de jitter; para la pérdida de paquetes no existe ese margen.

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.

Coordinar route precedence y NAT

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.

Probar y aceptar la ruta

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.

Probar failover y failback de forma segura

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

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.

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.

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ó después de una actualización de firmware, conviene consultar las notas de la versión actual de SFOS 22.0 antes de realizar cambios extensos en las reglas. SFOS 22.0 MR1 corrige, entre otros problemas, interrupciones aleatorias de SD-WAN y audio unidireccional mediante VPN route-based con SD-WAN routing.

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