Sophos Firewall SD-WAN Verifique el enrutamiento para Reply Packets y System Traffic

SD-WAN Las rutas en Sophos Firewall no solo son relevantes para el tráfico clásico de cliente a Internet. Dependiendo del entorno, Reply Packets y el tráfico generado por el sistema también pueden verse afectados. Precisamente aquí es donde a menudo surgen problemas de enrutamiento difíciles de detectar: ​​la regla parece correcta, el Gateway está activo, pero las respuestas van por la ruta equivocada o el propio firewall no llega a un servicio a través de la línea esperada.

Esta guía explica las dos opciones de CLI reply-packet y system-generate-traffic, cuándo verificarlas y cómo probar los cambios de manera segura. Para la configuración normal de la ruta SD-WAN, Configurar y probar la ruta y prueba Sophos Firewall SD-WAN es lo primero. Para el orden general entre rutas estáticas, rutas de política SD-WAN y rutas VPN, también encaja Sophos Firewall cambiar de forma segura Route Precedence.

⚠️ Estas configuraciones pueden afectar inmediatamente el enrutamiento productivo. Antes de realizar un cambio, debe documentar el estado actual, elegir una ventana de mantenimiento y conocer un camino claro de regreso. Particularmente críticas son las rutas amplias SD-WAN con Any, Route Precedence delante de rutas estáticas y el enrutamiento SD-WAN activado para System Traffic o Reply Packets.

De qué se tratan las dos opciones

Con Rutas SD-WAN hay que diferenciar 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 única ruta SD-WAN se construye correctamente. En su lugar, amplían qué tipo de tráfico puede tenerse en cuenta mediante la política de enrutamiento SD-WAN.

Las dos opciones tienen diferentes tareas:

• reply-packet: Afecta los paquetes de respuesta al tráfico existente. Esto permite que la ruta de retorno se vea influenciada a través de SD-WAN en ciertos escenarios que no son WAN.
• system-generate-traffic: Afecta al tráfico generado por el propio firewall. Esto permite enrutar conexiones específicas del firewall a través de rutas SD-WAN definidas.

No se deben activar ambas opciones a ciegas sólo porque “SD-WAN no funciona”. Primero debe quedar claro si Reply Packets o el tráfico generado por el sistema se ve realmente afectado. Para conexiones normales, la causa real suele ser la regla del firewall, el estado NAT, Route Precedence, Gateway o una ruta SD-WAN que es demasiado ancha.

Reply Packets

Reply Packets son paquetes de respuesta al tráfico existente. Sophos Firewall generalmente aplica un enrutamiento simétrico para este tipo de respuestas en las interfaces WAN: los paquetes de respuesta deben regresar a través de la misma interfaz WAN a través de la cual entró la conexión original. La opción reply-packet es particularmente relevante si se deben tener en cuenta los paquetes de respuesta en ciertos escenarios de enrutamiento de políticas SD-WAN. Un ejemplo típico es el enrutamiento asimétrico en interfaces que no son WAN, como entre LAN y DMZ.

La restricción importante es: si el tráfico original se ejecuta a través de la ruta predeterminada o del equilibrio de carga del enlace WAN, las rutas SD-WAN no se aplican a este Reply Packets. Luego, el firewall continúa utilizando la ruta de retorno adecuada a través de la interfaz de la conexión original.

Preguntas típicas de los exámenes:

• ¿Se trata realmente de tráfico de respuesta y no de una nueva conexión?
• ¿El tráfico pasa por WAN, LAN, DMZ, XFRM u otra zona?
• ¿Existe una ruta SD-WAN que pretende influir intencionalmente en la ruta de regreso?
• ¿La ruta es demasiado ancha, por ejemplo el destino Any?
• ¿Route Precedence tiene efecto antes que una ruta estática o una ruta VPN?

Tráfico generado por el sistema

El tráfico generado por el sistema es el tráfico que genera el propio Sophos Firewall. Dependiendo del entorno, esto puede incluir DNS, NTP, Sophos Central, Syslog, actualizaciones, monitoreo, servicios de autenticación o conexiones de diagnóstico.

Con este tráfico, el firewall no reconoce una interfaz entrante normal ni una red de origen normal como ocurre con el tráfico de cliente reenviado. Por eso es necesario planificar las rutas SD-WAN con especial atención para el tráfico generado por el sistema: las redes de destino y Services deben elegirse con sensatez. De lo contrario, una ruta muy amplia puede llevar inesperadamente el tráfico de administración o del sistema por un camino equivocado.

Además, se aplican dos límites prácticos:

• Si todas las puertas de enlace configuradas en Network > WAN link manager están marcadas como Copia de seguridad únicamente, el firewall no reenviará el tráfico generado por el sistema a través de ellas. Al menos un Gateway debe estar Activo.
• El tráfico RED generado por el sistema en UDP 3410 es tráfico de Capa 2. SD-WAN Las rutas no aplican a esto.

Cuándo comprobar estas configuraciones

Las dos opciones son particularmente relevantes para diseños de enrutamiento más complejos. En entornos simples y únicos, rara vez son la primera palanca.

Desencadenantes útiles:

• El tráfico nativo del firewall no utiliza la ruta esperada WAN o VPN.
• Syslog, Central, DNS, NTP o monitoreo deben ejecutarse en una línea específica.
• IPsec VPN basado en rutas con interfaces XFRM se utiliza junto con rutas SD-WAN.
• 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 diferente a la esperada.
• Después de una actualización, SD-WAN, IPsec o NAT se comportan de manera diferente que antes.
• Una ruta amplia SD-WAN afecta repentinamente las redes internas o el acceso de administración. Para escenarios IPsec, también debe incluir Sophos Firewall IPsec VPN Solución de problemas. Para conexiones individuales, la prueba de regla Sophos Firewall con Log Viewer y Packet Capture suele ser un mejor punto de partida.

Ver estado actual

Los comandos se ejecutan en Device Console, no en Advanced Shell. Si el acceso a la consola aún no está claro, Connect Sophos Firewall via SSH le ayudará.

Verifique el estado de Reply Packets:

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

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

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

Además, WebAdmin en Routing > SD-WAN routes muestra en la información sobre herramientas de información de enrutamiento si el enrutamiento SD-WAN está activo para el tráfico generado por el sistema y Reply Packets.

Antes de realizar cualquier cambio, se debe documentar la edición actual. Esto es importante porque una reversión posterior sólo es posible de forma limpia si se conoce el estado anterior.

Habilitar opciones

SD-WAN Activar enrutamiento para Reply Packets:

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

SD-WAN Habilite el enrutamiento para el tráfico generado por el sistema:

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

Luego ejecute los comandos de estado nuevamente y documente el resultado.

⚠️ No realices múltiples cambios de ruta al mismo tiempo. Si Route Precedence, ruta SD-WAN, regla NAT y estas opciones CLI se cambian al mismo tiempo, es difícil atribuir claramente un error posteriormente.

Flujo seguro para cambios

Un proceso pragmático reduce el riesgo:

1. Defina el tráfico afectado específicamente: Origen, Destino, Servicio, Zona, esperado Gateway.
2. Documente las rutas, puertas de enlace y puertas de enlace SD-WAN existentes y Route Precedence.
3. Compruebe si el destino Any es realmente necesario.
4. Documente el estado actual de reply-packet y system-generate-traffic.
5. Cambie solo una opción.
6. Ejecute la prueba con un ejemplo de tráfico claro.
7. Verifique los contadores Log Viewer, Packet Capture y Gateway.
8. Documente el resultado y solo entonces realice más ajustes. Si el acceso de administración puede verse afectado, debe estar disponible un medio de acceso secundario: consola local, otra ruta de acceso interna o acceso desde una red de administración no afectada.

Validación después del cambio

Después de la activación, un estado verde Gateway no es suficiente. Hay que comprobar si el tráfico deseado realmente sigue el camino esperado.

Registros Log Viewer y SD-WAN

Los eventos relacionados con el firewall y SD-WAN se deben verificar en el Visor de registros. Para reglas de firewall relevantes, Log firewall traffic debe estar activo. Sin iniciar sesión, a menudo sólo verá una parte de la decisión.

Para comprobar:

• ¿Qué Firewall Rule ID es afectado?
• ¿Qué NAT Rule ID se utiliza?
• ¿Qué Gateway o qué interfaz aparece en el registro?
• ¿Hay caídas, infracciones de políticas o decisiones inesperadas sobre funciones de seguridad?

Packet Capture

El flujo de paquetes real se puede verificar con Diagnostics > Captura de paquetes. Para preguntas de enrutamiento, el filtro debe ser limitado: Origen IP, Destino IP, Puerto y Protocolo.

La comparación es importante:

• ¿Llega el paquete a la interfaz esperada?
• ¿Sale del firewall en la interfaz esperada?
• ¿Volverá la respuesta?
• ¿Se utiliza NAT?
• ¿Es plausible el camino de regreso para Reply Packets?

Usar Sophos Firewall Packet Capture en WebAdmin es adecuado para operación e interpretación.

Verificar servicios del sistema

En el caso del tráfico generado por el sistema, deberás probar específicamente el servicio afectado:

• DNS: Ejecute la búsqueda de DNS en el firewall y verifique la ruta de destino.
• NTP: Verifique el estado horario y la disponibilidad del servidor NTP.
• Syslog: Verifique el mensaje de prueba o el registro actual en el recopilador.
• Sophos Central: Verifique la conexión central y los informes.
• Monitoreo: Verificación SNMP, sFlow o verificaciones externas en el colector.

Si el tráfico generado por el sistema no es visible, también debe verificar si la ruta SD-WAN solo debe coincidir con las redes de origen o las interfaces entrantes. Estos criterios no están disponibles para el tráfico propiedad del firewall como lo están para el tráfico de clientes.

Errores típicos

• Ruta SD-WAN con destino Any para rutas internas: El tráfico interno o el acceso de administración se pueden enrutar a través de WAN. Son mejores los grupos objetivo de Internet o las redes objetivo específicas.
• Route Precedence establece SD-WAN antes de Estático: Las redes estáticas o conectadas directamente pueden coincidir inesperadamente con SD-WAN. Marque Route Precedence y configure Estático delante de SD-WAN si es necesario.
• system-generate-traffic activo sin limitación de destino: Los servicios específicos del firewall pueden utilizar la ruta incorrecta. Por lo tanto, defina cuidadosamente las redes de destino y Services.
• Reply Packets se confunde con conexiones nuevas normales: Entonces se procesa la causa incorrecta. Packet Capture y verifique la dirección del flujo.
• Varios cambios de ruta al mismo tiempo: La causa del error aún no está clara. Cambie gradualmente y documente cada prueba.
• No hay acceso de administración alternativo: WebAdmin o SSH pueden perderse de la red afectada. Prepare la ventana de mantenimiento y la ruta de acceso.

Un riesgo particularmente crítico surge cuando se juntan varias condiciones: Route Precedence está en SD-WAN antes de estático, una ruta amplia SD-WAN usa Any y el enrutamiento SD-WAN para tráfico generado por el sistema o Reply Packets está activo. En este caso, es posible que se pierda el acceso a WebAdmin o SSH desde ciertas subredes internas.

Interacción con NAT, IPsec y VoIP

SD-WAN rara vez aparece solo. NAT, IPsec o el tráfico específico de la aplicación desempeñan un papel en muchas interrupciones. Lo importante para SNAT es si la misma fuente IP se mantiene en diferentes puertas de enlace. Si se utilizan MASQ o diferentes direcciones de origen traducidas, la conmutación por error o el redireccionamiento pueden causar problemas de comunicación. Para lo básico, Comprenda que NAT se ajusta a Sophos Firewall.

Para las VPN IPsec basadas en rutas, las interfaces XFRM se pueden utilizar en rutas SD-WAN o perfiles SD-WAN. Luego, se deben verificar juntos el estado IPsec, la ruta SD-WAN, Route Precedence y las reglas del firewall. Los conceptos básicos del VPN basado en rutas se clasifican en Ruta IPsec en Sophos Firewall. Si tiene problemas con VoIP, también vale la pena mirar SIP, RTP, NAT y SD-WAN. Las notas de la versión SFOS-22.0-MR1 documentan un problema solucionado por el cual el audio VoIP solo funcionaba en un sentido a través de VPN basado en rutas con enrutamiento SD-WAN después de actualizar a SFOS 22.0 GA. El proceso práctico se puede encontrar en Sophos Firewall Solucionar problemas de VoIP con SIP y RTP.

Revertir

Antes de realizar cambios, se debe documentar el estado anterior. Si el acceso a la gestión, los servicios del sistema o el tráfico productivo se ven afectados, ya no es necesaria la improvisación. Primero restaure el estado anterior.

Prácticamente esto significa:

1. Restablezca los valores documentados antes para reply-packet y system-generate-traffic.
2. Devuelva Route Precedence al pedido anterior si se modifica.
3. Desactivar temporalmente las rutas SD-WAN que sean demasiado amplias o limitarlas a destinos específicos.
4. Pruebe el acceso a la gestión desde una red no afectada.
5. Luego, limite aún más la causa real.

Si se pierde el acceso a WebAdmin y SSH desde una subred interna pero aún es posible desde otra subred, primero se deben verificar desde allí la ruta amplia SD-WAN, Route Precedence y las dos opciones CLI.

Lista de verificación

• Estado actual de las dos opciones CLI documentadas.
• Tráfico afectado específicamente definido.
• Ruta SD-WAN no construida innecesariamente ancha con Any.
• Route Precedence marcado.
• Al menos un WAN-Gateway para System Traffic disponible como Activo.
• Conexión de gestión alternativa preparada.
• Sólo se realizó un cambio por prueba.
• Log Viewer y Packet Capture utilizados para la validación.
• NAT, IPsec y reglas de firewall verificadas.
• Resultado y rollback documentados en el diario de operaciones.

Preguntas frecuentes