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 tráfico que origina el propio Sophos Firewall. Según el entorno, puede incluir consultas DNS, descargas de firmas, solicitudes de autenticación, DHCP, NTP, Syslog o conexiones con Sophos Central. De forma predeterminada, este tráfico utiliza los gateways WAN activos 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. 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.

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.

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

Para el tráfico reenviado, compruebe en Log viewer los eventos relacionados con el firewall y SD-WAN. En las Firewall Rules relevantes debe estar activado Log firewall traffic. En cambio, 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.

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?

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

Comprobar los servicios del sistema

Para el tráfico generado por el sistema, pruebe específicamente el servicio afectado:

• DNS: Ejecute una consulta DNS en el firewall y compruebe la ruta de destino.
• NTP: Compruebe el estado de la hora y la disponibilidad del servidor NTP.
• Syslog: Compruebe un mensaje de prueba o un registro reciente en el colector.
• Sophos Central: Compruebe la conexión con Central y los informes.
• Monitorización: Compruebe SNMP, sFlow o los controles externos en el colector.

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. Si se utiliza MASQ o distintas Source IP traducidas, un failover o rerouting puede causar problemas de comunicación. 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. Desactive temporalmente las SD-WAN Routes demasiado amplias o limítelas a destinos concretos.
4. Pruebe el acceso de administración desde una red no afectada.
5. 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