Comprobar el routing SD-WAN para Reply Packets y System Traffic

Las SD-WAN Routes de Sophos Firewall no solo son relevantes para el tráfico clásico de los clientes hacia Internet. Según el entorno, también pueden afectar a los Reply Packets y al tráfico generado por el sistema. Es precisamente ahí donde suelen aparecer problemas de routing difíciles de detectar: la regla parece correcta y el gateway está activo, pero las respuestas toman una ruta incorrecta o el propio firewall no alcanza un servicio a través de la conexión prevista.

Esta guía explica las dos opciones de CLI reply-packet y system-generate-traffic, cuándo conviene comprobarlas y cómo probar los cambios de forma segura. Para configurar una SD-WAN Route convencional, consulte primero Configurar y probar una SD-WAN Route en Sophos Firewall. Para conocer el orden general entre rutas estáticas, SD-WAN Policy Routes y rutas VPN, consulte también Cambiar de forma segura la Route Precedence en Sophos Firewall.

⚠️ Estos ajustes pueden afectar inmediatamente al routing de producción. Antes de realizar un cambio, documente el estado actual, elija una ventana de mantenimiento y defina claramente cómo volver atrás. Son especialmente críticas las SD-WAN Routes amplias con Any, una Route Precedence que sitúe SD-WAN por delante de Static Routes y el routing SD-WAN habilitado para System Traffic o Reply Packets.

Fundamentos y limitaciones

Qué función tienen las dos opciones

En las SD-WAN Routes hay que distinguir entre el tráfico reenviado normal, los paquetes de respuesta y el tráfico que genera el propio firewall. Las dos opciones no determinan si una SD-WAN Route concreta está configurada correctamente. En su lugar, amplían los tipos de tráfico que puede tener en cuenta el SD-WAN Policy Routing.

Las dos opciones cumplen funciones diferentes:

• reply-packet: Afecta a los paquetes de respuesta del tráfico existente. Permite influir mediante SD-WAN en la ruta de retorno en determinados escenarios que no utilizan WAN.
• system-generate-traffic: Afecta al tráfico que genera el propio firewall. Permite conducir las conexiones originadas por el firewall a través de SD-WAN Routes definidas.

No se deben activar ambas opciones a ciegas simplemente porque «SD-WAN no funciona». Primero hay que determinar si el problema afecta realmente a Reply Packets o al tráfico generado por el sistema. En las conexiones normales, la causa suele ser la Firewall Rule, NAT, Route Precedence, el estado del gateway o una SD-WAN Route demasiado amplia.

Reply Packets

Los Reply Packets son paquetes de respuesta del tráfico existente. En las interfaces WAN, Sophos Firewall aplica por defecto routing simétrico a estas respuestas: los paquetes deben regresar por la misma interfaz WAN por la que entró la conexión original.

La opción reply-packet es especialmente relevante cuando se deben incluir los paquetes de respuesta en SD-WAN Policy Routing para determinados escenarios. Un ejemplo típico es el routing asimétrico en interfaces que no son WAN, como entre LAN y DMZ.

Hay una limitación importante: si el tráfico original utiliza la Default Route o WAN Link Load Balancing, las SD-WAN Routes no se aplican a esos Reply Packets. El firewall sigue utilizando la ruta de retorno adecuada a través de la interfaz de la conexión original.

Preguntas útiles para la comprobación:

• ¿Se trata realmente de tráfico de respuesta y no de una conexión nueva?
• ¿El tráfico pasa por WAN, LAN, DMZ, XFRM u otra zona?
• ¿Existe una SD-WAN Route que deba influir deliberadamente en la ruta de retorno?
• ¿La ruta es demasiado amplia, por ejemplo con Destination Any?
• ¿La Route Precedence hace que se evalúe antes que una ruta estática o VPN?

Tráfico generado por el sistema

El tráfico generado por el sistema es el que origina el propio Sophos Firewall. Algunos ejemplos son las consultas DNS, las descargas de firmas y las solicitudes de autenticación. En servicios como DHCP, SNMP o Syslog, la clasificación depende de la función y de la dirección del tráfico: no todo el tráfico destinado a un servicio del firewall es una conexión saliente generada por el sistema. De forma predeterminada, el firewall envía su propio tráfico a través de los gateways WAN de Network > WAN link manager.

Para este tráfico no se conocen Incoming interface ni Source networks, por lo que no son selectores adecuados. En una SD-WAN Route destinada a incluir tráfico del firewall, solo se deben limitar de forma específica Destination networks y Services; los demás criterios permanecen amplios. De lo contrario, una ruta con Destination Any puede desviar inesperadamente el tráfico del sistema y de administración por una ruta incorrecta.

No se necesita una Firewall Rule normal para este tráfico. Por eso, en Current activities > Live connections, el tráfico generado por el sistema muestra la Firewall Rule ID 0. La Local service ACL de Administration > Device access es independiente: controla el acceso a los servicios locales del firewall, no la selección de la ruta SD-WAN de salida. Si se necesita una Source IP concreta, tampoco basta con una regla SNAT normal: las reglas NAT traducen tráfico reenviado; para el tráfico del firewall puede ser necesario configurar sys-traffic-nat en la Device Console, según el escenario.

También se aplican dos limitaciones prácticas:

• Si todos los gateways configurados en Network > WAN link manager están marcados únicamente como Backup, el firewall no reenvía por ellos el tráfico generado por el sistema. Al menos un gateway debe estar Active.
• El tráfico RED generado por el sistema en UDP 3410 es tráfico de capa 2. Las SD-WAN Routes no se aplican a él.

Acceder a un servidor de autenticación mediante IPsec route-based

Un caso especial importante es un servidor AD o LDAP en la sede central al que el propio firewall de una sucursal debe acceder mediante un túnel IPsec route-based. Una regla normal de LAN a VPN no dirige esta solicitud porque el tráfico lo genera el firewall. Por tanto, en un túnel any-to-any con interfaces XFRM direccionadas deben planificarse expresamente las rutas de ida y vuelta.

El ejemplo siguiente utiliza 10.10.1.1 como dirección de origen visible del firewall de la sucursal, 10.10.2.15 como servidor AD y TCP 636 para LDAPS. Estos valores no son ajustes predeterminados del producto. Deben sustituirse por una dirección de la sucursal permitida en el túnel y con ruta de retorno en la sede central, el servidor real y el servicio de autenticación realmente configurado.

1. En el firewall de la sucursal, crear una SD-WAN Route específica con Source networks en Any, el host AD como Destination networks y el servicio de autenticación necesario. TCP 636 solo es adecuado si el servidor utiliza realmente LDAPS. Como Primary Gateway se utiliza la dirección XFRM remota a través de la interfaz XFRM local.
2. Activar Route only through specified gateways únicamente cuando la solicitud deba descartarse de forma deliberada si el túnel no está disponible. Comprobar el selector para el tráfico generado por el sistema como se ha descrito anteriormente y activarlo de forma controlada para este procedimiento.
3. En la Device Console, utilizar primero show advanced-firewall para registrar las entradas sys-traffic-nat existentes y su orden. A continuación, traducir la dirección de origen propia del firewall a la dirección prevista de la sucursal. Esta dirección debe coincidir con las reglas del túnel y de la ruta de retorno:

set advanced-firewall sys-traffic-nat add destination 10.10.2.15 snatip 10.10.1.1

4. En el firewall de la sede central, crear una SD-WAN Route de retorno desde el host AD hacia la dirección traducida de la sucursal mediante la dirección XFRM remota. Mantener el origen, el destino y el servicio tan restringidos como en la sucursal.
5. En la sede central, crear reglas con registro desde VPN hacia la red del servidor y desde la red del servidor de vuelta a VPN, con los hosts y servicios concretos. Los ejemplos amplios con Any de las instrucciones del producto no son adecuados como estado permanente.
6. Ping/Ping6 en Administration > Device access para la zona VPN solo es necesario si el probe target es una dirección local del firewall o una dirección XFRM. Para un host reenviado detrás del túnel se necesitan, en cambio, el túnel, la ruta y, si procede, la Firewall Rule correspondientes. Después de la prueba, restablecer cualquier permiso temporal de Device Access a su estado anterior.

Para la aceptación, se ejecutan una prueba real de conexión al servidor y un inicio de sesión de usuario. En el firewall de la sucursal, el tráfico generado por el sistema aparece en Current activities > Live connections con Firewall Rule ID 0; en la sede central deben coincidir las reglas registradas previstas. Packet Capture debe mostrar la solicitud y la respuesta en las interfaces XFRM planificadas. Un ping correcto no confirma por sí solo LDAPS, la autenticación ni la ruta de retorno.

Para el rollback, primero se comprueba si las dos SD-WAN Routes, las reglas, los objetos de gateway y cualquier permiso temporal de Ping/Ping6 tienen otras dependencias. Eliminar la entrada NAT con exactamente los mismos selectores; si al crearla también se utilizaron netmask o interface, deben incluirse en el comando de eliminación:

set advanced-firewall sys-traffic-nat delete destination 10.10.2.15 snatip 10.10.1.1

A continuación, comprobar con show advanced-firewall que solo haya desaparecido la entrada prevista. Eliminar exclusivamente las rutas, reglas y objetos creados para este procedimiento, restablecer las dos opciones globales de SD-WAN y Route Precedence a sus valores anteriores documentados y volver a probar la ruta de datos original.

Preparación

Cuándo conviene comprobar estos ajustes

Las dos opciones son especialmente relevantes en diseños de routing complejos. En entornos sencillos con una sola WAN, rara vez son el primer elemento que se debe modificar.

Casos en los que conviene comprobarlas:

• El tráfico del propio firewall no utiliza la ruta WAN o VPN prevista.
• Syslog, Central, DNS, NTP o la monitorización deben utilizar una conexión concreta.
• Se utiliza una route-based IPsec VPN con interfaces XFRM junto con SD-WAN Routes.
• VoIP u otro tráfico sensible solo funciona en una dirección a través de SD-WAN/VPN.
• Packet Capture muestra respuestas en una interfaz distinta de la esperada.
• Después de una actualización, SD-WAN, IPsec o NAT se comportan de forma diferente.
• Una SD-WAN Route amplia afecta repentinamente a redes internas o al acceso de administración.

En escenarios IPsec, consulte también Solucionar problemas de IPsec VPN en Sophos Firewall. Para conexiones concretas, Probar una regla de Sophos Firewall con Log Viewer y Packet Capture suele ser un mejor punto de partida.

Mostrar el estado actual

Los comandos se ejecutan en la Device Console, no en la Advanced Shell. Si todavía no tiene claro el acceso a la consola, consulte Conectarse a Sophos Firewall mediante SSH.

Comprobar el estado de Reply Packets:

show routing sd-wan-policy-route reply-packet

Comprobar el estado del tráfico generado por el sistema:

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

Además, en WebAdmin, el tooltip de información de routing de Routing > SD-WAN routes indica si el routing SD-WAN está activo para el tráfico generado por el sistema y los Reply Packets.

También se debe documentar la Route Precedence actual:

system route_precedence show

Antes de cualquier cambio, documente la salida actual. Es esencial para poder realizar un rollback limpio si se conoce el estado anterior.

En Routing > SD-WAN routes también debe quedar claro cómo reacciona cada ruta afectada ante un fallo del gateway. Con Route only through specified gateways, el firewall descarta el tráfico si los gateways indicados no están disponibles. Sin esta opción, comprueba las SD-WAN Routes siguientes y después WAN Link Load Balancing. Si se elimina el Primary Gateway seleccionado o el SD-WAN Profile, SFOS también elimina la ruta; si solo se elimina el Backup Gateway, la ruta permanece con None como backup.

Cambiar la configuración

Activar o desactivar las opciones

Activar el routing SD-WAN para Reply Packets:

set routing sd-wan-policy-route reply-packet enable

Activar el routing SD-WAN para el tráfico generado por el sistema:

set routing sd-wan-policy-route system-generate-traffic enable

A continuación, vuelva a ejecutar los comandos de estado y documente la salida.

Para desactivar las opciones de forma específica, utilice los comandos inversos:

set routing sd-wan-policy-route reply-packet disable
set routing sd-wan-policy-route system-generate-traffic disable

⚠️ No realice varios cambios de routing al mismo tiempo. Si se modifican simultáneamente Route Precedence, la SD-WAN Route, la regla NAT y estas opciones de CLI, después resultará muy difícil atribuir correctamente un error.

Procedimiento seguro para los cambios

Un procedimiento pragmático reduce el riesgo:

1. Defina con precisión el tráfico afectado: Source, Destination, Service, Zone y gateway previsto.
2. Documente las SD-WAN Routes, los gateways y la Route Precedence existentes.
3. Compruebe si Destination Any es realmente necesario.
4. Documente el estado actual de reply-packet y system-generate-traffic.
5. Cambie una sola opción.
6. Realice una prueba con un ejemplo de tráfico claramente definido.
7. Compruebe Log Viewer, Packet Capture y los contadores OUT/IN de la SD-WAN Route.
8. Documente el resultado y solo entonces realice otros ajustes.

Si el acceso de administración puede verse afectado, debe existir una segunda vía de acceso: consola local, otra ruta interna o acceso desde una red de administración no afectada.

Validación después del cambio

Tras la activación, no basta con que el gateway aparezca en verde. Hay que comprobar si el tráfico deseado utiliza realmente la ruta prevista.

Live Connections, Log Viewer y contadores SD-WAN

Antes de la prueba, comprobar en System services > Log settings si está activado el registro de SD-WAN. Las entradas aparecen en el módulo SD-WAN de Log viewer; para el tráfico reenviado también debe estar activado Log firewall traffic en la Firewall Rule correspondiente. Anotar el estado anterior del registro y restablecerlo después de la prueba si solo se activó temporalmente.

El tráfico generado por el sistema no se controla mediante una Firewall Rule. Se puede identificar en Current activities > Live connections por la Firewall Rule ID 0 y por las interfaces Inbound y Outbound. La Local service ACL sigue siendo el control independiente para el acceso a los servicios locales del firewall.

Compruebe lo siguiente:

• ¿Se trata de tráfico reenviado con una Firewall Rule ID o de System Traffic con ID 0?
• ¿Qué NAT Rule ID se utiliza para el tráfico reenviado?
• ¿Qué gateway o interfaz aparece en el registro?
• ¿Hay drops, infracciones de políticas o decisiones inesperadas de Security Features?
• ¿La SD-WAN Route solo muestra OUT para Requests o también IN para Replies? Los contadores solo aparecen si los criterios Source y Destination coinciden con la dirección correspondiente.

Packet Capture

El flujo real de paquetes se puede comprobar mediante Diagnostics > Packet capture. Para analizar el routing, el filtro debe ser específico: Source IP, Destination IP, puerto y protocolo.

Es importante comparar:

• ¿El paquete llega a la interfaz prevista?
• ¿Sale del firewall por la interfaz prevista?
• ¿Regresa la respuesta?
• ¿Se aplica NAT?
• ¿Es plausible la ruta de retorno de los Reply Packets?
• ¿Muestra Status el valor Generated para las solicitudes originadas por el firewall y, cuando corresponda, Consumed para las respuestas entregadas al firewall?
• ¿Coinciden Gateway ID, NAT ID y las interfaces Inbound y Outbound con la ruta prevista?

Para utilizar e interpretar esta función, consulte Utilizar Packet Capture en WebAdmin de Sophos Firewall.

Comprobar el servicio del sistema afectado

Que una ruta coincida no demuestra por sí solo que el servicio funcione. Antes de la prueba, anote Destination IP, puerto, Source IP prevista e interfaz Outbound prevista. Después, active exactamente la función afectada, por ejemplo una solicitud de autenticación o una consulta DNS desde el firewall, y compruebe tanto Packet Capture como la confirmación en el sistema remoto. Utilice como prueba negativa un destino que no coincida u otro servicio; no debe coincidir con la ruta restringida.

Si el tráfico generado por el sistema no aparece, compruebe si la ruta exige innecesariamente criterios de Source networks, Incoming interface, usuario o aplicación. Para el tráfico del propio firewall, deben decidir principalmente Destination networks y Services. Si el destino espera una dirección de origen concreta, compruebe además la Source IP y una posible configuración de sys-traffic-nat.

Errores y dependencias

Errores habituales

• SD-WAN Route con Destination Any para rutas internas: El tráfico interno o el acceso de administración pueden enrutarse a través de WAN. Es preferible utilizar grupos de destinos de Internet o redes de destino concretas.
• Route Precedence sitúa SD-WAN por delante de Static: Las redes conectadas directamente o estáticas pueden coincidir inesperadamente con SD-WAN. Compruebe Route Precedence y, si es necesario, sitúe Static por delante de SD-WAN.
• system-generate-traffic activo sin limitar el destino: Los servicios del propio firewall pueden utilizar una ruta incorrecta. Defina con precisión las redes de destino y Services.
• Confundir Reply Packets con conexiones nuevas normales: Se investigará una causa incorrecta. Compruebe Packet Capture y la dirección del flujo.
• Buscar una Firewall Rule para el tráfico generado por el sistema: Este tráfico tiene la Firewall Rule ID 0; las Firewall Rules normales no lo controlan. Compruebe la ruta, el servicio, Live Connection y, si procede, sys-traffic-nat.
• Tratar Direct Web Proxy como tráfico HTTP/HTTPS normal: Con el proxy directo, la SD-WAN Route debe incluir el puerto configurado en Web > General settings > Web proxy listening port. Como alternativa, Services puede configurarse como Any. Source Network e Incoming Interface no coinciden con los Reply Packets del tráfico del proxy; para la ruta de retorno se necesita al menos un gateway WAN o una ruta estática adecuada.
• Realizar varios cambios de routing al mismo tiempo: La causa del error queda sin identificar. Realice los cambios paso a paso y documente cada prueba.
• No disponer de un acceso de administración alternativo: Se puede perder el acceso a WebAdmin o SSH desde la red afectada. Prepare una ventana de mantenimiento y una vía de acceso.

El riesgo es especialmente crítico cuando coinciden varias condiciones: Route Precedence sitúa SD-WAN por delante de Static, una SD-WAN Route amplia utiliza Any y está activo el routing SD-WAN para el tráfico generado por el sistema o los Reply Packets. En ese caso, se puede perder el acceso a WebAdmin o SSH desde determinadas subredes internas.

Interacción con NAT, IPsec y VoIP

SD-WAN rara vez actúa de forma aislada. En muchas incidencias también intervienen NAT, IPsec o el tráfico específico de una aplicación.

Con SNAT, es importante comprobar si se conserva la misma dirección de origen a través de gateways diferentes. Consulte el estado actual en la Device Console mediante show routing reroute-connection y show routing reroute-snat-connection. SFOS puede redirigir conexiones tras un fallo del gateway, pero las conexiones SNAT deben conservar la misma dirección de origen traducida en ambas rutas. MASQ o distintas direcciones traducidas pueden interrumpir una comunicación activa durante el rerouting. En este artículo, estos dos valores solo se consultan, no se modifican. Para conocer los fundamentos, consulte Comprender NAT en Sophos Firewall.

En las route-based IPsec VPN, las interfaces XFRM se pueden utilizar en SD-WAN Routes o SD-WAN Profiles. En ese caso, se deben comprobar conjuntamente el estado de IPsec, la SD-WAN Route, Route Precedence y las Firewall Rules. Los fundamentos de las route-based VPN se explican en IPsec Route en Sophos Firewall.

En caso de problemas de VoIP, también conviene revisar SIP, RTP, NAT y SD-WAN. Las notas de la versión SFOS-22.0-MR1 documentan la corrección de un problema por el que, tras actualizar a SFOS 22.0 GA, el audio VoIP solo funcionaba en una dirección a través de una route-based VPN con SD-WAN Routing. El procedimiento práctico se encuentra en Solucionar problemas de VoIP con SIP y RTP en Sophos Firewall.

Rollback y cierre

Rollback

Antes del cambio, documente el estado anterior. Si después se ven afectados el acceso de administración, los servicios del sistema o el tráfico de producción, no improvise más cambios. Primero restaure el estado anterior.

En la práctica, esto significa:

1. Restablezca los valores anteriores documentados de reply-packet y system-generate-traffic con los comandos enable o disable correspondientes.
2. Devuelva Route Precedence al orden anterior si se modificó.
3. Restablezca las SD-WAN Routes modificadas a sus valores anteriores documentados; elimine las rutas creadas solo para la prueba después de comprobar sus dependencias.
4. Elimine las entradas temporales de sys-traffic-nat con exactamente los mismos selectores y compruébelo con show advanced-firewall.
5. Restablezca las Firewall Rules, los objetos de gateway, los permisos de Device Access y los ajustes de registro modificados solo para la prueba.
6. Pruebe el acceso de administración y la ruta de datos original desde una red no afectada.
7. Solo entonces continúe delimitando la causa real.

Si se pierde el acceso a WebAdmin y SSH desde una subred interna, pero sigue siendo posible desde otra, utilice esta última para comprobar primero la SD-WAN Route amplia, Route Precedence y las dos opciones de CLI.

Lista de comprobación

• Se ha documentado el estado actual de las dos opciones de CLI.
• Se ha documentado Route Precedence con system route_precedence show.
• Se ha definido con precisión el tráfico afectado.
• Para System Traffic, solo se han utilizado Destination y Service como criterios de coincidencia decisivos.
• La SD-WAN Route no se ha configurado con un Any innecesariamente amplio.
• Se ha comprobado Route Precedence.
• Hay al menos un gateway WAN Active para System Traffic.
• Se ha preparado una conexión de administración alternativa.
• Solo se ha realizado un cambio por prueba.
• Se han utilizado Log Viewer y Packet Capture para la validación.
• También se han comprobado NAT, IPsec y las Firewall Rules.
• Se han documentado el resultado y el rollback en el registro de operaciones.

Preguntas frecuentes