Crear una ruta IPsec en Sophos Firewall

Una ipsec_route manual corresponde al IPsec basado en políticas. Asocia un host o una red de destino a un túnel basado en políticas existente. Sin embargo, no amplía los selectores de tráfico ni sustituye las reglas de firewall y NAT ni la ruta de retorno en el par remoto.

Este comando no es adecuado para IPsec basado en rutas. En un túnel Any-to-any, la interfaz XFRM recibe una dirección IP; después, las rutas estáticas, SD-WAN o dinámicas determinan el trayecto. En un túnel basado en rutas con selectores de tráfico, SFOS crea la ruta automáticamente. No se pueden asignar direcciones IP ni rutas personalizadas a la interfaz XFRM asociada.

⚠️ Una ruta demasiado amplia o asignada al túnel incorrecto puede redirigir el tráfico de producción. Registre el estado inicial antes de realizar el cambio y tenga preparado el comando de eliminación exacto.

Cuándo es apropiada una ruta IPsec manual

El caso habitual es el tráfico reenviado cuya dirección cambia mediante DNAT o SNAT. NAT modifica la dirección, pero no la decisión de enrutamiento. Por tanto, puede ser necesaria una ruta adicional a la red remota.

Compruebe lo siguiente antes de ejecutar el comando:

• La conexión en Site-to-site VPN > IPsec > IPsec connections está basada en políticas.
• Los selectores de tráfico locales y remotos incluyen las direcciones que se presentan realmente al procesamiento IPsec después de aplicar NAT.
• Las reglas de firewall y NAT coinciden con el tráfico de prueba definido. Para SNAT con IPsec basado en políticas, Outbound interface está configurada como Any.
• El par remoto espera la dirección de origen visible y dispone de una ruta de retorno a través del mismo túnel.
• Ni las rutas estáticas o SD-WAN existentes ni la precedencia global de rutas dirigen el destino por otro trayecto.

Una ruta manual no corrige una máscara de red incorrecta, un selector incompatible ni una regla que bloquee el tráfico. En Configurar una VPN IPsec de sitio a sitio en Sophos Firewall se explican los tipos de túnel.

Registrar el estado inicial en la Device Console

En WebAdmin, abra admin > Console y seleccione 4. Device console. Para acceder mediante SSH, Conectarse a Sophos Firewall mediante SSH conduce al mismo menú.

En primer lugar, muestre las rutas IPsec manuales existentes y el orden global:

system ipsec_route show
system route_precedence show

Guarde la salida junto con el nombre del túnel, los selectores de tráfico, el ID de la regla de firewall, el ID de la regla NAT y el flujo de prueba previsto. En SFOS 22, tanto las rutas VPN basadas en políticas generadas automáticamente como las entradas ipsec_route manuales pertenecen a la categoría vpn. Estas rutas no aparecen en la tabla de enrutamiento de WebAdmin, por lo que ip route show table 220 no constituye una prueba fiable de lo contrario.

No modifique la precedencia de rutas como tarea secundaria. Es una configuración global que afecta a otras conexiones. Si realmente debe cambiarla, Modificar de forma segura la precedencia de rutas de Sophos Firewall describe el procedimiento independiente, incluida la reversión basada en valores.

Crear la ruta con un ejemplo de NAT controlado

Sophos documenta este caso de uso bien delimitado:

• Un túnel basado en políticas HO_to_Branch conecta la red local 192.168.2.0/24 con la red remota 192.168.3.0/24.
• El servidor local real 172.16.16.10 está fuera del selector local.
• El par remoto accede a él mediante 192.168.2.1. Esta dirección sustitutiva pertenece al selector local y, en el ejemplo, es la dirección de la interfaz LAN del firewall.

Remote 192.168.3.0/24 → 192.168.2.1 → DNAT → Server 172.16.16.10
Server 172.16.16.10 → reflexive SNAT → 192.168.2.1 → IPsec → Remote

Sustituya la red, las direcciones y el nombre del túnel por sus propios valores. La dirección sustitutiva debe coincidir con la selección local de la fase 2; la red de destino remota debe estar cubierta por el túnel existente.

1. Asignar la red remota al túnel

Ejecute este comando en la Device Console:

system ipsec_route add net 192.168.3.0/255.255.255.0 tunnelname HO_to_Branch

Para net, SFOS requiere la máscara completa en notación decimal con puntos. Utilice el intervalo de destino más restringido que necesite la aplicación. El comando de reversión correspondiente es:

system ipsec_route del net 192.168.3.0/255.255.255.0

El comando de eliminación no incluye el nombre del túnel. Antes de eliminar la ruta, use system ipsec_route show para confirmar que el destino no es ambiguo. No elimine entradas ambiguas basándose únicamente en una suposición.

Para un único host de destino, la consola admite la siguiente forma:

system ipsec_route add host 10.33.46.69 tunnelname Azure_CH
system ipsec_route del host 10.33.46.69

Una ruta de host es más específica, pero solo es correcta cuando ese host concreto es el destino y los selectores de tráfico coinciden.

2. Configurar DNAT y SNAT reflexivo

1. En Rules and policies > NAT rules > Add NAT rule > New NAT rule, cree una regla DNAT. Original source es 192.168.3.0/24, Translated source permanece como Original, Original destination es 192.168.2.1 y Translated destination es 172.16.16.10.
2. Active Create reflexive rule.
3. Abra la regla generada Reflexive_NAT#_<DNAT_rule_name>. En Translated source, seleccione un objeto de host IP con 192.168.2.1. Cree el objeto en Hosts and services > IP host > Add. Sophos no permite traducir directamente a una interfaz en esta regla reflexiva.
4. Compruebe el orden, el estado y el registro de ambas reglas NAT, así como la regla de firewall asociada.

No añada una regla MASQ amplia ni permita además que el servidor real atraviese el túnel con su dirección sin traducir. Comprender NAT en Sophos Firewall explica la coincidencia y el orden de las reglas.

Validar la ruta de datos

Un túnel en verde y un ping no demuestran ni la traducción NAT ni la ruta de retorno. Para validar, defina un flujo de aplicación real, por ejemplo una conexión TCP desde el cliente remoto al servicio publicado del servidor.

1. Vuelva a ejecutar system ipsec_route show. La red de destino debe estar asignada exactamente una vez al túnel previsto.
2. Genere una única conexión controlada desde 192.168.3.0/24 hasta 192.168.2.1 en el servicio permitido.
3. Filtre Log viewer por Source, Destination y Firewall Rule ID. En la vista detallada, src_trans_ip muestra la dirección de origen realmente traducida con mayor fiabilidad que la vista de resumen.
4. Abra Monitor & analyze > Diagnostics > Packet capture y filtre por el cliente, la dirección sustitutiva y el servidor real. El ID de regla y el ID NAT deben coincidir con las reglas documentadas; las interfaces de entrada y salida deben mostrar el trayecto previsto.
5. En el par remoto, compruebe que las respuestas procedentes de 192.168.2.1 sean las esperadas y regresen a través del mismo túnel.
6. Pruebe un host o servicio próximo que no esté permitido. Esta prueba negativa debe seguir fallando y confirma que la ruta y las reglas no son demasiado amplias.

Una SA activa o el mero aumento de los contadores de bytes no bastan. Para realizar un análisis completo, consulte Solucionar problemas de VPN IPsec en Sophos Firewall; para analizar reglas y capturas, consulte Probar una regla de firewall con Log Viewer, Policy Test y Packet Capture.

Revertir por completo el cambio

Finalice primero las nuevas sesiones de prueba. Restaure por separado DNAT y SNAT reflexivo a su estado anterior documentado; modificar posteriormente la regla DNAT no elimina automáticamente la regla reflexiva.

Elimine después únicamente la ruta recién creada:

system ipsec_route del net 192.168.3.0/255.255.255.0
system ipsec_route show

Elimine el nuevo objeto de host IP únicamente cuando Object usage ya no muestre ninguna referencia. A continuación, repita el flujo de control original y la prueba negativa. La precedencia de rutas registrada anteriormente debe permanecer sin cambios.

Si únicamente se eliminó la ruta por error, el comando de adición guardado restaura la entrada exacta:

system ipsec_route add net 192.168.3.0/255.255.255.0 tunnelname HO_to_Branch

Variante: los clientes remotos acceden a una dirección virtual

Una dirección de destino virtual puede ocultar las direcciones de los servidores internos al par remoto. Este escenario no debe confundirse con el ejemplo anterior de NAT basado en políticas: la variante documentada utiliza IPsec basado en rutas con subredes Any-to-any, interfaces XFRM con direcciones asignadas y rutas normales. Para ello no se crea ninguna ipsec_route manual.

En el ejemplo, la red 192.168.2.0/24 se encuentra detrás del firewall 1; los clientes remotos situados detrás del firewall 2 pertenecen a 192.168.3.0/24. Acceden a los servidores 172.16.16.2 y 172.16.16.3 a través de la dirección virtual 10.10.10.1. Esta dirección es una dirección de destino DNAT, no la dirección del gateway XFRM. Todos los valores deben sustituirse por objetos adecuados para el entorno propio.

1. En las conexiones IPsec de ambos firewalls, establezca Connection type en Route-based (Tunnel interface), y Local subnet y Remote subnets en Any. En el ejemplo, el firewall 1 utiliza Respond only y el firewall 2, Initiate the connection. En Network > Interfaces, abra la barra azul de la correspondiente Listening interface, seleccione la interfaz XFRM, introduzca la dirección IP prevista para ella y guarde los cambios. El procedimiento de IPsec de sitio a sitio explica la configuración básica del túnel.
2. Limite las reglas de firewall al servicio real de la aplicación: en el firewall 2, de LAN a VPN, con origen 192.168.3.0/24 y los destinos necesarios 192.168.2.0/24 o 10.10.10.1, según corresponda; en el firewall 1, de VPN a la zona real de los servidores, con el mismo origen remoto y los objetos de destino necesarios 192.168.2.0/24 o 10.10.10.1, según corresponda. El valor Any del ejemplo de zona de destino no es una recomendación para permitir el acceso de forma permanente.
3. En Routing > SD-WAN routes > IPv4 > Add, en el firewall 2, enrute el origen 192.168.3.0/24 y los destinos necesarios 192.168.2.0/24 o 10.10.10.1, según corresponda, a través de un gateway de la interfaz XFRM local. En Link selection settings > Primary and backup gateways, seleccione o cree el Primary gateway adecuado. En el firewall 1, añada la ruta de retorno con los orígenes 192.168.2.0/24 o 10.10.10.1, según corresponda, y el destino 192.168.3.0/24 a través de su gateway XFRM. También pueden utilizarse rutas estáticas o dinámicas.
4. Route only through specified gateways impide utilizar un trayecto alternativo al descartar el tráfico cuando el túnel no está disponible. El ejemplo activa esta opción en el firewall 2 y la ofrece como opcional en el firewall 1; el comportamiento deseado en caso de fallo debe definirse de forma deliberada en ambos extremos. Administration > Device access > Ping/Ping6 > VPN afecta al ping dirigido a los servicios locales del firewall, no a la autorización de un servicio de servidor cuyo tráfico se reenvía.
5. En el firewall 1, en Rules and policies > NAT rules > Add NAT rule > New NAT rule, cree la regla DNAT: Original source 192.168.3.0/24, Translated source Original, Original destination 10.10.10.1, Translated destination un objeto de lista de servidores con 172.16.16.2 y 172.16.16.3, Load balancing method Round-robin. Permita únicamente el servicio necesario; la lista está pensada para varios servidores backend adecuados, no para hosts arbitrarios.

Para la validación, genere varias conexiones nuevas de la aplicación a la dirección virtual y compruebe en Packet Capture, así como mediante Rule ID y NAT ID, los backends seleccionados, el trayecto XFRM y las respuestas. Un ping por sí solo no confirma DNAT, ni el funcionamiento de la aplicación, ni la distribución. Antes de realizar cambios, haga una copia de seguridad de las rutas, las reglas y los objetos; al revertir la configuración, elimine únicamente los elementos creados para esta variante, tras comprobar sus dependencias, o restaure los valores anteriores, según corresponda. Aquí no hay ninguna ipsec_route que eliminar. Por ello, las siguientes comprobaciones de errores siguen distinguiendo entre ambos tipos de túnel.

Aislar sistemáticamente los errores habituales

La ruta existe, pero el tráfico se dirige a la WAN

Compruebe system ipsec_route show, la precedencia de rutas y las rutas SD-WAN competidoras. En SFOS 22, la ausencia de una entrada en la tabla de enrutamiento de WebAdmin o en la tabla 220 no demuestra que la ruta IPsec no exista. En la precedencia de rutas, vpn solo tiene prioridad sobre static para el tráfico destinado a la zona WAN; por tanto, también deben comprobarse las zonas y el trayecto real hacia el destino.

El túnel está activo, pero NAT no se aplica

Compare las direcciones originales y traducidas con los selectores de tráfico. Para SNAT basado en políticas, Outbound interface debe ser Any. A continuación, compruebe Firewall Rule ID, NAT ID y src_trans_ip, en lugar de basarse únicamente en el estado del túnel.

Con Any, el firewall utiliza la Translated source de la regla SNAT correspondiente, incluso cuando Override source translation (SNAT) está activado para interfaces de salida específicas. Una regla que solo incluye determinados puertos WAN en Outbound interface, como la regla SNAT predeterminada habitual, no coincide con este tráfico IPsec basado en políticas. La explicación de NAT del artículo sobre IPsec de sitio a sitio aclara esta interacción; no implica que deban cambiarse las opciones de anulación de forma generalizada. Tras corregir la regla de forma específica, genere un nuevo flujo de aplicación controlado y vuelva a comprobar NAT ID, src_trans_ip, los selectores y la ruta de retorno, siguiendo la validación de la ruta de datos descrita anteriormente.

El trayecto de ida funciona, pero falta la respuesta

El par remoto debe conocer la dirección traducida y devolver el tráfico a través del mismo túnel. Compruebe su selector, su regla de firewall y su ruta de retorno. Una ruta local ipsec_route más amplia no puede corregir una ruta de retorno distinta.

El tráfico generado por el sistema o DHCP se ve afectado

Las solicitudes de autenticación, DNS y DHCP generadas por el propio firewall siguen un proceso independiente. Sin embargo, sería incorrecto afirmar de forma general que el tráfico del sistema no requiere una ruta IPsec manual: para IPsec basado en políticas, la guía de autenticación para SFOS 22.0 y 23.0 contempla expresamente una ruta IPsec cuando la solicitud no llega al túnel debido a la precedencia de rutas seleccionada. Primero deben ser correctos la dirección de origen, sys-traffic-nat, los selectores de tráfico y la ruta de retorno; solo entonces se asocia únicamente el destino necesario al túnel existente basado en políticas. La validación se realiza con una solicitud de autenticación real y Packet Capture; la reversión se efectúa por separado con el comando system ipsec_route del host o del net correspondiente, tras comprobar la entrada.

El procedimiento completo para la autenticación con IPsec basado en políticas y basado en rutas se encuentra en Enrutamiento SD-WAN para paquetes de respuesta y tráfico del sistema. Allí también se ponen en contexto las contradicciones entre las funciones de las direcciones NAT descritas y los ejemplos de comandos. Si la dirección de origen no está aclarada, no realice cambios en producción y, en particular, no utilice la dirección del servidor AD como origen traducido. Para IPsec basado en rutas se utilizan rutas XFRM, no ipsec_route; el relé DHCP sigue siendo un procedimiento independiente. De ello no se desprende ni que deba modificarse de forma general la precedencia global de rutas ni una garantía de funcionamiento.

Falta un anuncio dinámico después de actualizar a SFOS 22

En SFOS 22, las rutas VPN basadas en políticas no son rutas normales del kernel. Si OSPF o BGP las anunciaban anteriormente mediante redistribute kernel, Por qué redistribute kernel deja de anunciar rutas IPsec después de actualizar a SFOS 22 explica este problema de migración independiente.