Crear una ruta IPsec en Sophos Firewall

Normalmente, Sophos Firewall detecta por sí misma a través de qué túnel IPsec es accesible una red de destino. En un túnel IPsec basado en políticas clásico, las redes locales y remotas son parte de la configuración del túnel. En IPsec basado en rutas, el tráfico se dirige al túnel a través de interfaces XFRM, rutas estáticas, rutas SD-WAN o enrutamiento dinámico.

Por lo tanto, una ruta IPsec manual no es estándar para cada túnel. Es una herramienta para ciertos escenarios basados en políticas, especialmente cuando el tráfico reenviado debe trabajar con NAT o una asignación especial al túnel. Si se establece incorrectamente una ruta de este tipo, el tráfico puede dirigirse al túnel equivocado o una conexión existente puede volverse más difícil de rastrear.

Para nuevos túneles de sitio a sitio, primero configure Configurar VPN IPsec de sitio a sitio en Sophos Firewall. Para la resolución de problemas generales de IPsec, consulte Resolución de problemas de VPN IPsec en Sophos Firewall. Si se trata de VPNs basadas en rutas, XFRM y planificación de interfaces, consulte Configurar zonas e interfaces en Sophos Firewall.

Cuándo es útil una ruta IPsec

Una ruta IPsec es especialmente relevante cuando existe un túnel IPsec basado en políticas, pero el tráfico esperado no se asigna correctamente al túnel.

Casos típicos:

• Un host o red debe dirigirse específicamente a través de un túnel basado en políticas.
• Existen múltiples túneles, redes de destino superpuestas o configuraciones VPN históricas.
• El tráfico se traduce mediante DNAT o SNAT y luego debe asignarse a un túnel IPsec existente.
• Después de una actualización a SFOS 22, se debe verificar si los casos especiales basados en políticas antiguos aún funcionan como se espera.
• La búsqueda de rutas, el visor de registros o la captura de paquetes muestran que el tráfico se dirige hacia WAN o un camino incorrecto.

No todos estos casos se resuelven con ipsec_route. Primero se deben verificar las reglas de firewall, las reglas NAT, la precedencia de rutas, las puertas de enlace locales y las rutas de retorno.

Basado en políticas, basado en rutas y SFOS 22

La diferencia más importante:

• IPsec basado en políticas: Sophos Firewall realiza búsquedas IPsec en segundo plano redes locales/remotas en la conexión IPsec, reglas de firewall, ipsec_route si es necesario.
• IPsec basado en rutas: El tráfico se enruta a la interfaz del túnel Interfaz XFRM, ruta estática, ruta SD-WAN o enrutamiento dinámico.

Para nuevas conexiones de sitio a sitio o más grandes, IPsec basado en rutas suele ser más claro, ya que los cambios de enrutamiento no alteran los selectores de túnel cada vez. Sin embargo, para conexiones simples de sitio a sitio o entornos existentes, IPsec basado en políticas sigue siendo relevante.

SFOS 22 ha trabajado en varios aspectos del comportamiento de IPsec. En las notas de la versión SFOS-22.0-MR1 se documentan varios problemas resueltos relacionados con IPsec basado en políticas, ipsec_route, SD-WAN, SNAT y búsqueda de rutas. Para los administradores, esto significa que después de una actualización, se deben probar específicamente los casos especiales basados en políticas, especialmente si están involucrados NAT, MPLS, SD-WAN o rutas IPsec manuales.

Requisitos previos

Antes de realizar un cambio, estos puntos deben estar claros:

• Acceso a la Consola del dispositivo, por ejemplo, a través de SSH.
• Nombre del túnel IPsec.
• Host de destino o red de destino que debe alcanzarse a través del túnel.
• Conexión IPsec activa o correctamente configurada.
• Reglas de firewall adecuadas para la dirección esperada.
• Claridad sobre si está involucrado NAT.
• El estado actual de las rutas IPsec existentes está documentado.

Si el acceso a la consola aún no está configurado, Conectar Sophos Firewall por SSH explica cómo establecer una conexión SSH con el firewall y abrir la Consola del dispositivo.

⚠️ Una ruta IPsec incorrecta puede interrumpir el tráfico productivo. Antes de realizar cambios, se deben documentar el nombre del túnel, la red de destino, NAT, la ruta de retorno y las rutas existentes.

Verificar antes del cambio

No se debe establecer una ruta IPsec como primer paso. Este orden es sensato:

1. Verificar el estado del túnel: La conexión IPsec está activa y las redes esperadas están negociadas.
2. Verificar las reglas de firewall: Zona de origen, zona de destino, origen, destino, servicio y registro son correctos.
3. Verificar NAT: Está claro si las direcciones IP originales o traducidas deben pasar por el túnel.
4. Verificar la precedencia de rutas: Las rutas estáticas, SD-WAN y VPN se evalúan en el orden esperado. Si compiten varios tipos de enrutamiento, Cambiar de forma segura la precedencia de rutas en Sophos Firewall puede ayudar.
5. Verificar el punto final: El punto final conoce la ruta de retorno y la dirección de origen esperada.
6. Usar captura de paquetes: Comprobar si el tráfico llega, a dónde se redirige y si las respuestas regresan.

Para la verificación general de reglas, consulte Probar reglas de firewall con Log Viewer, Policy Test y Packet Capture. Para los fundamentos de NAT, consulte Entender NAT en Sophos Firewall.

Mostrar rutas IPsec existentes

Los comandos se ejecutan en la Consola del dispositivo, no en el Advanced Shell.

system ipsec_route show

La salida debe documentarse antes de cualquier cambio. Así se puede ver más tarde si se ha añadido una nueva ruta y si debe eliminarse.

Además, la tabla de enrutamiento IPsec puede ser relevante para el análisis:

ip route show table 220

Esta verificación se realiza en el Advanced Shell y está más orientada a la resolución de problemas. Para cambios normales en ipsec_route, la Consola del dispositivo es el lugar adecuado.

Crear una ruta IPsec para un host

Si solo un host individual debe ser accesible a través de un túnel específico, se utiliza host.

Sintaxis:

system ipsec_route add host <host-ip> tunnelname <tunnelname>

Ejemplo:

system ipsec_route add host 10.33.46.69 tunnelname Azure_CH

Después, no solo se debe probar el ping, sino también el tráfico real de la aplicación. Una prueba ICMP puede funcionar, mientras que TCP, NAT o la ruta de retorno siguen siendo incorrectos.

Crear una ruta IPsec para una red

Si una red completa debe ser accesible a través del túnel, se utiliza net.

Sintaxis:

system ipsec_route add net <network>/<netmask> tunnelname <tunnelname>

Ejemplo:

system ipsec_route add net 10.33.46.0/255.255.255.0 tunnelname Azure_CH

Con las rutas de red se debe tener especial cuidado. Una red demasiado grande puede atraer más tráfico al túnel de lo planeado. En redes superpuestas, debe estar claro de antemano qué lado ve qué direcciones y si se utiliza NAT.

Eliminar una ruta IPsec

Si la ruta ya no es necesaria o se estableció incorrectamente, se puede eliminar.

Eliminar ruta de host:

system ipsec_route del host <host-ip>

Eliminar ruta de red:

system ipsec_route del net <network>/<netmask>

Luego, verifique la lista nuevamente:

system ipsec_route show

Si la ruta ha afectado el tráfico productivo, se debe probar nuevamente la conexión afectada después de eliminarla y comparar las entradas del Log Viewer.

NAT e IPsec basado en políticas

NAT no es intrínsecamente incorrecto en IPsec. Sin embargo, debe estar bien planificado, ya que NAT cambia la dirección que ve el punto final.

Sophos distingue entre otros los siguientes casos en IPsec:

• NAT directamente en la configuración de IPsec, por ejemplo, en redes superpuestas.
• Reglas NAT independientes bajo Rules and policies > NAT rules.
• ipsec_route para tráfico reenviado, cuando el tráfico traducido debe asignarse a un túnel basado en políticas.
• sys-traffic-nat para el tráfico generado por el sistema del propio firewall.

Una regla NAT no cambia automáticamente la decisión de enrutamiento del firewall. Si se usa un túnel existente basado en políticas con DNAT/SNAT para hosts adicionales, sigue siendo necesaria una IPsec Route adecuada hacia la red remota. En reglas SNAT reflexivas, la dirección de origen traducida debe existir como objeto IP host; no se puede traducir simplemente directamente a una interfaz.

Lo importante es la dirección: Si el tráfico IPsec basado en políticas debe traducirse mediante SNAT, la regla SNAT adecuada debe trabajar con Outbound interface en Any. Si la regla está restringida a interfaces WAN específicas, no se aplicará al tráfico IPsec basado en políticas. Detalles como estos llevan en la práctica a túneles que están verdes pero no transportan el tráfico esperado.

El tráfico generado por el sistema es un caso especial

ipsec_route no resuelve por sí solo todos los problemas de tráfico. Para tráfico reenviado de clientes o servidores, el comando puede ser directamente relevante. El tráfico generado por el propio firewall, como solicitudes de autenticación o casos relacionados con DHCP, también necesita una lógica correcta de source NAT y enrutamiento.

Sin una configuración específica, el tráfico generado por el sistema suele usar un gateway de Network > WAN link manager. Por eso, un túnel IPsec verde no basta para enviar automáticamente las solicitudes propias del firewall al túnel. DHCP Relay también debe evaluarse por separado: en IPsec basado en políticas, el DHCP Relay debe activar específicamente la opción Relay through IPsec. En las VPN route-based esta opción no es necesaria; ahí el tráfico DHCP se enruta como tráfico normal mediante rutas estáticas, SD-WAN o dinámicas hacia el otro extremo, siempre que las subredes locales y remotas estén en Any y existan rutas adecuadas en ambos lados.

En la práctica, esto significa:

• El tráfico de cliente o servidor a través del firewall puede ser un tema de ipsec_route.
• Con IPsec basado en políticas, las solicitudes propias del firewall pueden requerir una combinación de ipsec_route, sys-traffic-nat y subredes locales o remotas adecuadas.
• Con IPsec basado en rutas, estos casos suelen usar rutas SD-WAN hacia la interfaz XFRM y sys-traffic-nat.
• No se debe intentar resolver cada problema de tráfico del sistema de manera general con ipsec_route.

Para el tráfico generado por el sistema y el contexto SD-WAN, consulte Enrutamiento SD-WAN para paquetes de respuesta y tráfico del sistema.

Probar el cambio

Después de crear o eliminar una ruta IPsec, se debe probar específicamente el tráfico afectado.

Procedimiento práctico:

1. Definir caso de prueba: Origen, destino, servicio, dirección y túnel esperado.
2. Activar el registro de reglas de firewall para la regla afectada.
3. Documentar system ipsec_route show.
4. Generar tráfico de prueba exactamente una vez.
5. Filtrar Log Viewer por origen, destino y regla de firewall.
6. Ejecutar Packet Capture con un filtro estrecho.
7. Verificar si los bytes en ipsec statusall aumentan en ambas direcciones.
8. Verificar el punto final en la ruta de retorno, NAT y firewall local.

Si las transferencias grandes se quedan colgadas, aunque el enrutamiento y NAT parezcan correctos, también se debe verificar MTU y MSS en problemas de VPN.

Errores típicos

• Túnel verde, sin tráfico: A menudo falta una regla, NAT, ruta de retorno o asignación IPsec. Revisar Log Viewer, Packet Capture e ipsec statusall.
• El tráfico va hacia WAN: La precedencia de rutas o la asignación IPsec no encaja. Revisar Route Lookup, rutas SD-WAN e ipsec_route show.
• SNAT no se aplica en IPsec basado en políticas: La regla SNAT probablemente tiene una interfaz de salida incorrecta. Verificar la regla SNAT con Any.
• Un host funciona, una red no: La máscara de red, el objeto o el selector de tráfico no encaja. Comparar redes locales y remotas.
• Comportamiento diferente después de la actualización a SFOS 22: Puede estar implicado un caso especial antiguo con IPsec basado en políticas, NAT o SD-WAN. Revisar release notes, caso de prueba y peer.
• El tráfico propio del firewall no pasa por el túnel: El tráfico del sistema se enruta de manera diferente. Verificar SD-WAN, precedencia de rutas y sys-traffic-nat.

Lista de verificación

Antes del cambio:

• Documentado el nombre del túnel y el punto final.
• Host de destino o red de destino claramente definidos.
• Reglas de firewall y reglas NAT verificadas.
• Precedencia de rutas y contexto SD-WAN verificados.
• Rutas IPsec existentes aseguradas.
• Planificado un período de mantenimiento o un momento de prueba controlado.

Después del cambio:

• system ipsec_route show verificado nuevamente.
• Log Viewer muestra la regla esperada.
• Packet Capture muestra la ruta esperada.
• El punto final ve la dirección de origen esperada.
• La ruta de retorno funciona.
• Cambio y justificación documentados.

Preguntas frecuentes