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

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 firewall siguen un proceso independiente. En SFOS 22, normalmente no requieren una ruta IPsec manual. Utilice Enrutamiento SD-WAN para paquetes de respuesta y tráfico del sistema o el procedimiento específico para el relé DHCP, en lugar de aplicar este procedimiento de reenvío.

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.