Crear una ruta IPsec en Sophos Firewall

Una ruta IPsec manual no es necesaria para todos los túneles. Se utiliza principalmente con IPsec basado en políticas cuando es preciso asignar tráfico reenviado y traducido a un túnel concreto.

IPsec basado en rutas: No cree una ipsec_route. El tráfico circula a través de interfaces XFRM y rutas estáticas, SD-WAN o dinámicas. IPsec basado en políticas sin un caso especial de NAT: Compruebe primero el túnel, las reglas de firewall, NAT y la ruta de retorno. IPsec basado en políticas con tráfico DNAT o SNAT reenviado: Los siguientes pasos ayudan a comprobar y configurar la ruta.

⚠️ Una ruta IPsec incorrecta puede dirigir tráfico de producción al túnel equivocado. Guarde el estado inicial antes de cada cambio y prepare un procedimiento de rollback exacto.

Comprobar, crear y eliminar una ruta IPsec

Los comandos para mostrar, crear y eliminar rutas se ejecutan en la Device Console. Si aún no dispone de acceso, Conectar Sophos Firewall por SSH muestra cómo llegar a la Device Console.

Guardar el estado inicial

Antes de ejecutar un comando Add, debe conocer la ruta concreta del tráfico:

• Se trata de un túnel basado en políticas activo, no de IPsec basado en rutas.
• El host o la red de destino coinciden con los selectores del túnel y con la traducción prevista.
• Las reglas de firewall y NAT coinciden con el tráfico de prueba definido; para SNAT, Outbound interface está configurada como Any.
• Se han comprobado Route Precedence y las rutas que compiten entre sí.
• El extremo remoto espera la dirección de origen visible y dispone de una ruta de retorno.

Documente primero todas las rutas IPsec manuales:

system ipsec_route show

Si existen problemas de routing o NAT, guarde también Route Precedence y la configuración de NAT para el tráfico del sistema:

system route_precedence show
show advanced-firewall

En la Advanced Shell, esta vista antigua de troubleshooting también puede resultar útil:

ip route show table 220

Según Sophos, en SFOS 22 las rutas IPsec basadas en políticas y las entradas de ipsec_route no aparecen en esta tabla. Por tanto, la ausencia de una entrada no demuestra que no exista una ruta IPsec. Los elementos decisivos siguen siendo system ipsec_route show, la configuración y una prueba de tráfico.

Crear una ruta para un host

Sintaxis:

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

Ejemplo para el host 10.33.46.69 a través del túnel Azure_CH:

system ipsec_route add host 10.33.46.69 tunnelname Azure_CH

Crear una ruta para una red

Sintaxis:

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

Ejemplo para la red 10.33.46.0/24:

system ipsec_route add net 10.33.46.0/255.255.255.0 tunnelname Azure_CH

La máscara debe coincidir exactamente con el destino deseado. Una ruta demasiado amplia puede dirigir al túnel tráfico adicional de forma involuntaria.

Eliminar una ruta de forma segura

⚠️ Los comandos de eliminación no contienen el nombre del túnel. Antes de eliminar una ruta, use system ipsec_route show para comprobar que el host o la red son inequívocos y tenga preparado el comando Add completo para el rollback. No elimine entradas ambiguas por simple suposición.

Eliminar una ruta de host:

system ipsec_route del host <host-ip>

Eliminar una ruta de red:

system ipsec_route del net <network>/<netmask>

Vuelva a comprobar la lista:

system ipsec_route show

Si el resultado de la prueba empeora, restaure la ruta con el comando Add guardado anteriormente.

Cuándo es adecuado usar ipsec_route

IPsec basado en políticas e IPsec basado en rutas

Con IPsec basado en políticas, las redes locales y remotas definen los selectores del túnel. Una ipsec_route manual puede asignar hosts o redes adicionales a un túnel existente, pero no sustituye a unos selectores adecuados, a las reglas de firewall ni a la ruta de retorno.

Con IPsec basado en rutas, el tráfico se dirige a la interfaz XFRM. Según el diseño, se utiliza una ruta estática, una ruta SD-WAN o routing dinámico. ipsec_route es la herramienta equivocada en este caso. Los fundamentos de ambas variantes se explican en Configurar una VPN IPsec de sitio a sitio en Sophos Firewall y Configurar zonas e interfaces en Sophos Firewall.

Diferencia entre SFOS 21.5 y 22

La clasificación dentro de Route Precedence ha cambiado:

• En SFOS 21.5, las rutas IPsec basadas en políticas que se generan automáticamente pertenecen a la categoría vpn, mientras que las entradas manuales de ipsec_route pertenecen a static.
• En SFOS 22, tanto las rutas IPsec basadas en políticas automáticas como las manuales pertenecen a la categoría vpn. No aparecen como rutas normales del kernel y se procesan internamente mediante marcas, zonas y flags.

Después de actualizar desde SFOS 21.5, conviene volver a probar Route Precedence y los casos especiales existentes. La comprobación de actualización a SFOS 22 contiene las verificaciones generales. Cambiar Route Precedence de forma segura en Sophos Firewall explica el orden global.

Si las redes VPN policy-based se redistribuían hasta ahora a OSPF o BGP mediante redistribute kernel, esta comprobación no es suficiente: a partir de SFOS 22, las rutas VPN dejan de ser rutas normales del kernel. Por qué redistribute kernel ya no anuncia rutas IPsec después de actualizar a SFOS 22 explica el comportamiento y el diseño de destino XFRM route-based.

Una ruta manual solo resulta útil cuando el túnel, los selectores de tráfico, la regla de firewall, la regla NAT y la ruta de retorno son correctos. No corrige una máscara errónea, una ruta de retorno ausente en el extremo remoto ni una regla que bloquea el tráfico.

NAT para tráfico reenviado

NAT modifica las direcciones, pero no cambia automáticamente la decisión de routing. Si un túnel basado en políticas transporta tráfico adicional traducido mediante DNAT o SNAT, puede ser necesaria una ruta IPsec adecuada hacia el host o la red remotos.

Para aplicar SNAT a IPsec basado en políticas, la regla NAT correspondiente debe tener Outbound interface configurada como Any. Si se limita a una interfaz WAN concreta, no coincidirá con el tráfico IPsec. Entender NAT en Sophos Firewall explica con más detalle el orden, el matching y la ruta de retorno.

El cambio debe realizarse durante una ventana de mantenimiento o con un caso de prueba controlado. Antes deben estar definidos estos valores:

• direcciones de origen y destino originales y traducidas,
• redes local y remota de la conexión IPsec,
• nombre del túnel y regla de firewall esperada,
• ruta de retorno y direcciones permitidas en el extremo remoto.

Tratar por separado el tráfico generado por el sistema

Las consultas DNS, de autenticación u otras solicitudes generadas por el propio firewall no siguen necesariamente la misma lógica que el tráfico de clientes reenviado. En SFOS 22, normalmente no necesitan una ipsec_route. Solo la guía específica de Sophos para consultas de autenticación la menciona como solución alternativa condicional cuando, debido a la configuración concreta de Route Precedence, se ha demostrado que la solicitud no entra en el túnel basado en políticas.

Si es necesario, la dirección de origen de este tráfico puede definirse con sys-traffic-nat. Ejemplo: el firewall debe acceder al servidor 10.10.2.15 utilizando la dirección SNAT/de interfaz definida 10.10.1.1. Esta dirección debe coincidir con las subredes IPsec y disponer de una ruta de retorno en el extremo remoto.

Los siguientes comandos se ejecutan en la Device Console:

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

Rollback:

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

Si al añadir la entrada también se utilizaron interface o netmask, deben indicarse los mismos selectores al eliminarla. Routing SD-WAN para Reply Packets y System Traffic contiene más ejemplos.

DHCP requiere un análisis específico:

• Con IPsec basado en políticas, el relay necesita la opción Relay through IPsec, las subredes IPsec locales y remotas adecuadas, sys-traffic-nat, así como las reglas y rutas de retorno necesarias en el extremo remoto. Si las solicitudes siguen sin entrar en el túnel debido a la configuración concreta de routing, puede ser necesaria una ipsec_route como fallback comprobado.
• Con IPsec basado en rutas, no se activa Relay through IPsec. Se admite un relay hacia el lado del servidor DHCP mediante una interfaz XFRM con subredes Any-to-any, rutas estáticas, SD-WAN o dinámicas y reglas adecuadas en ambos firewalls. ipsec_route no forma parte de este camino.
• Si, en una configuración de IPsec basado en políticas, el firewall de la sede principal actúa como servidor DHCP para redes remotas, debe activarse Lease over IPsec. Según Sophos, las interfaces de firewall configuradas como servidor DHCP no son compatibles con este diseño basado en rutas.

Este comando también se ejecuta en la Device Console:

system dhcp lease-over-IPSec enable

Los procedimientos antiguos de SFOS 21.5 mencionaban expresamente ipsec_route con mayor frecuencia para autenticación y DHCP. Estas configuraciones deben revisarse durante una actualización y no reproducirse sin comprobarlas.

Probar y validar el cambio

Un túnel en verde o un ping correcto no bastan como prueba. ICMP puede funcionar aunque TCP, NAT o la ruta de retorno sigan siendo incorrectos.

1. Defina origen, destino, servicio, dirección y túnel esperado.
2. Active el logging de la regla de firewall afectada.
3. Guarde system ipsec_route show antes de la prueba.
4. Genere una vez el tráfico real de la aplicación.
5. Filtre Log Viewer por origen, destino y regla.
6. Ejecute Packet Capture con un filtro preciso en ambos lados del camino.
7. Compruebe en el extremo remoto la dirección de origen, la ruta de retorno y el firewall local.
8. Documente el resultado, el cambio y el comando de rollback.

En la Advanced Shell, estos comandos muestran las SA negociadas, los contadores de bytes y las políticas XFRM:

ipsec statusall
ip xfrm policy

Sin embargo, por sí solos no demuestran que NAT, la regla de firewall y la ruta de retorno sean correctos. Para un análisis sistemático, consulte Probar reglas de firewall con Log Viewer, Policy Test y Packet Capture. Si solo se bloquean transferencias grandes, compruebe además MTU y MSS en problemas de VPN.

Acotar errores y realizar el rollback

El túnel está activo, pero no circula tráfico

Compruebe la regla de firewall, NAT, los selectores de tráfico y la ruta de retorno. A continuación, compare Log Viewer, Packet Capture y los contadores de ipsec statusall. El procedimiento completo se encuentra en Troubleshooting de VPN IPsec en Sophos Firewall.

El tráfico se dirige hacia WAN

Compruebe Route Precedence, las rutas SD-WAN y system ipsec_route show. En SFOS 22, la ausencia de una entrada en la tabla 220 no debe utilizarse como prueba de que no existe una ruta IPsec.

SNAT no se aplica

Con IPsec basado en políticas, compruebe que Outbound interface está configurada como Any y que tanto las direcciones originales como las traducidas coinciden con el túnel y el extremo remoto.

Un host funciona, pero una red no

Compare la máscara, el objeto de host/red y los selectores de tráfico en ambos extremos. No cree una ruta más amplia antes de comprender la diferencia.

El camino cambia después de actualizar a SFOS 22

Vuelva a comprobar Route Precedence y todos los casos especiales basados en políticas que utilicen NAT, SD-WAN o MPLS. No elimine ni vuelva a crear rutas antiguas de forma automática.

El tráfico generado por el firewall no llega al destino

Distinga primero si se trata de autenticación, DNS, DHCP u otro servicio. Después, compruebe Route Precedence, SD-WAN, sys-traffic-nat y el procedimiento correspondiente para SFOS 22.

Si el problema comienza inmediatamente después del cambio, elimine la ruta nueva, compruébelo con system ipsec_route show y repita la prueba anterior. Si el problema continúa, restaure por completo el estado inicial documentado.

Preguntas frecuentes