Configurar VPN IPsec Site-to-Site Sophos Firewall

Una VPN IPsec Site-to-Site conecta dos sedes, o una Sophos Firewall con un firewall de terceros, mediante un túnel cifrado. En la práctica, estos túneles rara vez fallan por una única opción de la interfaz. Las causas más habituales son redes poco claras, perfiles IPsec diferentes, reglas de firewall ausentes, casos especiales de NAT o una ruta de retorno olvidada en uno de los lados.

Procedimiento resumido: Elegir el tipo de túnel, coordinar el perfil y los IDs, crear la conexión, enrutar la interfaz XFRM en route-based Any-to-Any, configurar las reglas de firewall y NAT y validar el túnel con tráfico real, logs y Packet Capture.

Este procedimiento sirve para conexiones Sophos con Sophos o con terceros entre una sede central, una sucursal o un cloud gateway. Microsoft Azure y AWS requieren detalles adicionales del proveedor: Conectar Sophos Firewall con Azure VPN Gateway y Conectar Sophos Firewall con AWS Site-to-Site VPN. Para el Remote Access de usuarios individuales, se aplica en cambio la comparativa entre Sophos Connect y SSL VPN. Si un túnel existente ya aparece en verde pero no pasa tráfico, consulte Sophos Firewall IPsec VPN Troubleshooting.

Si la conexión se establece exclusivamente entre dos Sophos Firewall y la sucursal debe crear el túnel como cliente hacia una sede central con acceso público estable, SSL Site-to-Site VPN es una alternativa más sencilla. Para peers de terceros, redundancia, routing dinámico o redes en crecimiento, IPsec route-based sigue siendo la opción más flexible.

Para varios firewalls administrados por Sophos Fusion (antes Sophos Central), un grupo de conexiones SD-WAN puede generar automáticamente los túneles basados en rutas, las interfaces XFRM, las rutas y las reglas opcionales. Esto no sustituye la planificación de la topología ni la validación local del tráfico.

Elegir entre policy-based y route-based

Antes de configurar hay que decidir si el túnel será policy-based o route-based. Fuera de la interfaz de Sophos, route-based también suele denominarse tunnel-based. Ambos términos describen un túnel con su propia interfaz XFRM. En cambio, el término “root-based”, que aparece ocasionalmente, no es un modo de VPN.

Sophos recomienda VPN route-based para diseños nuevos. Any-to-Any es especialmente flexible para redes en crecimiento porque los cambios de ruta no interrumpen el túnel. En cambio, modificar las subredes o los Traffic Selectors interrumpe las conexiones existentes. Ambos extremos del túnel deben usar el mismo tipo: no se admite policy-based en un extremo y route-based en el otro.

Para utilizar OSPF o BGP a través del túnel, el diseño más comprensible es route-based Any-to-Any con interfaces XFRM direccionadas. Antes de actualizar una configuración policy-based antigua, hay que comprobar si las redes VPN se anuncian mediante redistribute kernel; SFOS 22: rutas IPsec y redistribute kernel explica el cambio entre versiones y el marco para una migración segura.

Qué confirma realmente un túnel en verde

Un estado como Established confirma que los peers han negociado IKE y al menos una Child SA. No confirma que se seleccione una ruta, que coincida la regla de firewall, que NAT sea correcto, que el peer conozca la ruta de retorno ni que responda el host de destino. Por tanto, un túnel puede aparecer en verde sin transportar tráfico útil entre sedes.

Sophos Firewall utiliza ESP en modo túnel. ESP protege la integridad de los datos, autentica el origen de los datos transportados y ofrece protección antirrepetición frente a paquetes reinyectados.

La ruta de datos puede entenderse con el siguiente modelo:

Policy-based
Origen -> Regla de firewall -> Selector Local/Remote -> Child SA -> Peer -> Ruta de retorno y regla -> Destino

Route-based Any-to-Any
Origen -> Ruta o SD-WAN Route -> Regla de firewall -> XFRM -> Child SA -> Peer -> Ruta de retorno y regla -> Destino

Se trata de un modelo de diagnóstico, no de una representación completa del orden de procesamiento interno de SFOS. Aun así, la distinción es esencial para la validación: con policy-based, el par de redes de la conexión IPsec determina qué tráfico pertenece al túnel. Con route-based Any-to-Any, esa selección la toma el routing o SD-WAN.

Requisitos y datos de planificación

Antes de configurar deben documentarse al menos estos datos:

• Extremo local: interfaz WAN de Sophos Firewall y dirección por la que el peer accede a esta interfaz.
• Remote Gateway: IP pública o DNS hostname del peer.
• Gateway type: normalmente Respond only en la central e Initiate the connection en la sucursal.
• IP version: IPv4, IPv6 o Dual. Dual solo está disponible para interfaces de túnel route-based con Any-to-Any como subred local y remota. Con Dual deben planificarse por separado las reglas de firewall IPv4 e IPv6.
• Redes locales: por ejemplo 172.16.10.0/24 y 172.16.20.0/24.
• Redes remotas: por ejemplo 10.20.30.0/24.
• Tipo de VPN: policy-based o route-based. También existe el Connection type Host-to-host, pero no es el objetivo de esta guía para sedes.
• Listening interface: interfaz WAN del firewall local. No puede utilizarse una bridge interface.
• Versión IKE: preferiblemente IKEv2 si el peer la admite.
• Authentication type: Preshared key, Digital certificate o RSA key.
• Local ID y Remote ID: especialmente importantes con FQDN, peers dinámicos, NAT-T o un wildcard gateway.
• Perfil IPsec: Encryption, Authentication, DH Group, PFS y Key life.
• Reglas de firewall: Sources, Destinations y Services permitidos.
• NAT: sin NAT o SNAT/DNAT por redes solapadas o requisitos del proveedor.
• Operación: responsable, ventana de mantenimiento, plan de pruebas, monitoring y ruta de fallback.

Ejemplo coherente para ambos firewalls

Los siguientes valores permiten seguir con claridad los pasos posteriores. Deben sustituirse por las direcciones WAN, redes y nombres propios:

Primero se crean ambas redes LAN como objetos en Hosts and services > IP host. En la sede central, 10.10.10.0/24 es el Local subnet y 10.20.20.0/24 el Remote subnet; en la sucursal se invierten. Lo mismo se aplica a los IDs: el Local ID de un lado debe ser el Remote ID esperado por el otro. La red de transferencia 10.255.0.0/30 solo se utiliza con route-based Any-to-Any y no debe solaparse con ninguna red de producción, VPN o management.

⚠️ Una VPN Site-to-Site no debe implementarse sin una ruta de retorno documentada. Si el firewall local envía tráfico al túnel pero el peer no conoce la ruta de vuelta o espera un NAT distinto, el túnel suele parecer sano aunque las aplicaciones no funcionen.

Redes, perfil, IDs y certificados

Las redes locales y remotas no deben solaparse involuntariamente. Son especialmente problemáticas las redes estándar habituales como 192.168.0.0/24, 192.168.1.0/24 o las redes de sucursales reutilizadas. Las redes solapadas requieren un diseño NAT deliberado. Usar el mismo rango de direcciones en ambos lados y traducirlo después “de alguna manera” crea túneles difíciles de mantener.

Por eso, para nuevas sedes merece la pena un plan de direccionamiento IP limpio. Si las VLANs o zonas todavía no están modeladas con claridad, consulte Configurar zonas e interfaces de Sophos Firewall.

Ambos lados deben usar parámetros compatibles en Phase 1 y Phase 2. Esto incluye cifrado, autenticación, DH group, PFS y lifetime. En conexiones con firewalls de terceros, lo más sencillo suele ser documentar primero un perfil común y configurar después ambos lados.

Con IKEv2, Sophos puede usar Preshared Keys únicos para cada combinación de Local ID y Remote ID. IKEv1 es más limitado porque solo se aplica un PSK por combinación de gateways. En entornos con varios túneles al mismo peer, conviene usar IKEv2 con IDs claramente definidos.

⚠️ Con IKEv1, el firewall utiliza el PSK de la conexión configurada más recientemente para la misma combinación de gateway local y remoto. Esto se aplica a las configuraciones IPsec site-to-site y de acceso remoto. Configurar posteriormente una conexión para esa combinación de gateways con un PSK diferente puede provocar un fallo de autenticación de las conexiones existentes durante una negociación posterior. Antes de añadir una conexión de este tipo o cambiar un PSK, revisar todas las configuraciones IKEv1 afectadas y coordinar el PSK con sus respectivos peers antes de la siguiente negociación.

NAT Traversal está siempre activo en Sophos Firewall. Si un lado está detrás de un router o NAT del proveedor, los IDs cobran más importancia porque la dirección pública del gateway no identifica al peer de forma inequívoca. El Local ID de un lado debe coincidir con el Remote ID que espera el otro. Los IDs de tipo DNS, IP o correo electrónico no tienen que resolverse públicamente, pero el formato y el valor deben coincidir de forma cruzada.

Sophos Firewall no ofrece un interruptor NAT-T independiente: Los dispositivos detectan NAT automáticamente. Sin NAT, las negociaciones IKE utilizan UDP 500 y el tráfico de datos usa ESP mediante IP protocol 50. Cuando el firewall detecta un dispositivo NAT, encapsula en UDP 4500 las negociaciones IKE y de fase 2 posteriores, así como los paquetes ESP.

Si hay un dispositivo NAT en la ruta IPsec y el peer es un firewall de otro fabricante, NAT-T también debe estar activado en ese firewall. La configuración se comprueba con la documentación de ese peer; Sophos Firewall no necesita un interruptor adicional.

Los peers detectan un dispositivo NAT durante el intercambio IKE de fase 1 y acuerdan entonces utilizar NAT-T. ESP es un protocolo de capa 3 sin información de puertos de capa 4, mientras que PAT también puede traducir puertos. Por ello, la encapsulación UDP a través del puerto 4500 proporciona una envoltura UDP identificable en la ruta NAT; el peer elimina esta envoltura y procesa el paquete IPsec original.

Si Sophos Firewall está detrás de un router, este necesita una regla DNAT o un reenvío de puertos desde la dirección pública al Listening interface privado del firewall. La ruta NAT-T debe permitir UDP 500 y UDP 4500; ESP nativo mediante IP protocol 50 solo es necesario en una ruta sin NAT. Esto es distinto del diseño posterior de SNAT o DNAT para redes solapadas o tráfico de datos traducido.

Con Digital certificate, los formatos y roles de los certificados de ambos lados deben coincidir exactamente. Sophos no admite certificados ECDSA para conexiones IPsec; se requieren certificados RSA. Una CA pública no debe utilizarse de forma general como Remote CA Certificate, ya que se confiaría demasiado en certificados ajenos. RSA key es un Authentication type independiente: ambos firewalls intercambian sus claves públicas y deben usar el mismo formato PKCS1 o DNS.

Cambiar la CA local Default de Sophos Firewall es un cambio del trust anchor, no una modificación estética del certificado. Los peers con un Default.pem importado y los certificados firmados localmente deben migrarse de forma controlada. Renovar de forma controlada la Default CA de Sophos Firewall explica el inventario, la ventana de mantenimiento, las pruebas y la recuperación.

Si se selecciona Digital certificate, no basta con elegirlo en el formulario. Antes deben prepararse la confianza de la CA, los certificados locales y del peer y los Certificate IDs. El procedimiento completo se describe en Configurar IPsec Site-to-Site con certificados. Si la CA revoca certificados antes de que expiren, la lista de revocación actual también debe formar parte del plan operativo. Un procedimiento independiente explica la importación de la CRL, la comprobación de nextUpdate y la prueba negativa controlada en Sophos Firewall.

Si un túnel no se establece, NO_PROPOSAL_CHOSEN, los errores de ID o los errores de autenticación son indicios habituales. La sección Probar el túnel y solucionar errores empieza con la delimitación adecuada.

Configurar IPsec policy-based

IPsec policy-based es la variante clásica para conexiones Site-to-Site sencillas. Las redes locales y remotas se definen directamente en la conexión IPsec.

1. Comprobar o crear el perfil IPsec

Ruta de menú:

Profiles > IPsec profiles

Primero hay que comprobar si un perfil existente coincide con el peer. Si se necesita un perfil propio, debe tener un nombre claro, por ejemplo Branch-Zurich-IKEv2. El nombre debe seguir siendo comprensible cuando existan varios túneles y peers.

Como mínimo hay que documentar:

• Versión IKE
• Phase 1 Encryption y Authentication
• DH Group
• Phase 2 Encryption y Authentication
• PFS
• Key life

En firewalls de terceros, el peer debe confirmar por escrito los mismos valores. Una captura de pantalla no suele ser suficiente porque algunos campos tienen nombres diferentes según el fabricante.

La interacción entre Phase 1, Phase 2, PFS, Lifetimes, Rekeying y DPD se explica en Entender y configurar de forma segura los perfiles IPsec de Sophos Firewall. Antes de activar, hay que comprobar Dead peer detection: Sophos especifica Hold o Disconnect para el peer que responde y Re-initiate para el iniciador. Un IPsec failover group modifica este comportamiento y no se rige por la misma lógica DPD.

2. Añadir la conexión IPsec

Ruta de menú:

Site-to-site VPN > IPsec

Crear una nueva conexión IPsec y elegir Policy-based como Connection type. A continuación, configurar los datos básicos:

• Nombre del túnel, por ejemplo branch-zurich
• IP version, normalmente IPv4
• Gateway type, por ejemplo Respond only en la central o Initiate the connection en la sucursal
• Listening interface como interfaz WAN local
• Gateway address del peer como dirección IP o DNS hostname
• Authentication type: Preshared key, Digital certificate o RSA key
• Local ID y Remote ID si son necesarios
• IPsec profile
• Local subnet
• Remote subnet

En IPsec policy-based, como máximo uno de los lados de los Traffic Selectors puede estar configurado como Any. Si hay varias redes locales y remotas específicas, Sophos crea una Phase 2 SA para cada combinación.

Con Respond only, la dirección wildcard * puede ser útil si varias sucursales o peers dinámicos se conectan a la central. En ese caso debe establecerse al menos un Local ID o Remote ID; normalmente conviene usar ambos para una asignación inequívoca. El Local ID de un lado corresponde al Remote ID que espera el otro. Initiate the connection no admite una dirección wildcard, por lo que el peer debe definirse como dirección IP o DNS hostname.

Debe utilizarse un Preshared Key robusto y único, y documentarlo de forma segura. Reutilizar una antigua clave predeterminada en varias sedes es un riesgo operativo innecesario.

A continuación, se crea la conexión de forma especular en el peer. En el ejemplo, la sede central espera a 203.0.113.20 con Respond only; sus redes Local/Remote son 10.10.10.0/24 y 10.20.20.0/24. La sucursal usa Initiate the connection, la Gateway address 198.51.100.10 e invierte redes e IDs Local/Remote. Perfil, autenticación y PSK deben ser compatibles. La conexión solo se activa después de guardar ambas entradas y comprobar las reglas.

Los ajustes avanzados de User authentication mode solo corresponden a perfiles IKEv1 con lógica XAuth, como diseños cliente-servidor muy antiguos. En conexiones Site-to-Site normales con IKEv2, no deben interpretarse como un paso de autenticación adicional. Tampoco deben planificarse ajustes obsoletos de idle connection como un diseño operativo moderno.

3. Activar el túnel

Al guardar puede seleccionarse Activate on save. En entornos productivos debe hacerse dentro de una ventana de mantenimiento definida, cuando el peer esté accesible y ambos lados puedan revisar los logs.

Después de guardar, la lista muestra dos estados relevantes:

• si la conexión está activa
• si el túnel está realmente established

Una entrada activa no equivale automáticamente a un túnel establecido. Con varias redes locales o remotas también puede haber varias Security Associations.

Configurar IPsec route-based

IPsec route-based separa la negociación VPN de la selección de ruta. Con Any-to-Any, SFOS proporciona una interfaz XFRM direccionable. Para Traffic Selectors específicos, la documentación actual de SFOS 22 se contradice sobre la creación de la interfaz, como se explica a continuación.

1. Crear la conexión como route-based

Ruta de menú:

Site-to-site VPN > IPsec

Elegir Route-based (Tunnel interface) en la conexión. Los parámetros de gateway, autenticación, IDs y perfil IPsec deben seguir coincidiendo con el peer. Además, hay que saber qué interfaz XFRM se crea después y cómo se enruta.

2. Implementar Any-to-Any o Traffic Selectors

Para Any-to-Any, Sophos muestra la interfaz XFRM generada bajo la interfaz física utilizada en:

Network > Interfaces

Una interfaz XFRM generada siempre permanece asignada a la zona VPN. Las dos variantes se configuran de manera distinta.

Any-to-Any con IPv4, IPv6 o Dual

Cuando Local subnet y Remote subnet están configuradas como Any, SFOS crea automáticamente la interfaz XFRM para la conexión IPsec route-based. No hay que añadir una interfaz XFRM por separado. En Network > Interfaces, se despliega la interfaz física seleccionada como Listening interface y se abre la interfaz XFRM generada. En el ejemplo, la sede central recibe 10.255.0.1/30 y la sucursal 10.255.0.2/30. Con Dual también se necesitan reglas IPv4 e IPv6 separadas.

El Name editable es el nombre mostrado. No debe confundirse con los valores que asigna SFOS: Hardware es el nombre del registro, IPsec connection es la conexión route-based asociada y Network zone siempre es VPN. Solo se configuran los campos de dirección de la versión IP seleccionada en la conexión IPsec:

• IPv4/netmask: introducir la dirección IPv4 de transferencia planificada y seleccionar su subred.
• IPv6/prefix: introducir la dirección IPv6 de transferencia planificada y el prefijo.
• Con Dual, configurar ambas familias. Si la conexión solo usa IPv4 o solo IPv6, SFOS no aplica los valores introducidos para la otra versión.

En Advanced settings > Interface settings, conservar el MTU predeterminado o introducir el valor probado expresamente. SFOS calcula el valor predeterminado restando la sobrecarga IPsec máxima al MTU de la interfaz física. Activar Override MSS e introducir un valor solo si la red requiere uno distinto del predeterminado del firewall; no presuponer un valor numérico no documentado.

Antes de modificar los campos, registrar el nombre, las direcciones, el MTU, el estado y valor de Override MSS, y las rutas o gateways dependientes. Tras guardar, volver a abrir la interfaz y verificar que Hardware, IPsec connection y la zona VPN siguen asignados sin cambios. Ejecutar después Route lookup en ambos peers y probar tráfico real en ambos sentidos, incluida una transferencia grande si cambió MTU o MSS. Para volver atrás, restaurar los valores registrados y las rutas o gateways anteriores. Si es una conexión nueva, desactivarla y eliminar solo sus rutas y reglas dependientes; no intentar borrar ni recrear por separado la interfaz XFRM generada.

Después se crea en ambos lados la ruta hacia la LAN remota mediante Routing > Static routes > IPv4 unicast route > Add:

• Sede central: Destination 10.20.20.0/24, Interface la interfaz XFRM local.
• Sucursal: Destination 10.10.10.0/24, Interface la interfaz XFRM local.

Como alternativa puede utilizarse una SD-WAN Route o routing dinámico mediante BGP u OSPF. Con una SD-WAN Route hay que decidir expresamente si se permite otra ruta de fallback. Si el tráfico no debe desviarse cuando falle el túnel, se activa Route only through specified gateways y se prueba este fallo por separado.

Las rutas y las reglas de firewall deciden qué tráfico entra en el túnel. Una ruta estática sencilla puede apuntar directamente a la interfaz XFRM. Para varias líneas, comprobaciones SLA o determinados diseños de Failover, se crea además un Custom Gateway con la dirección IP XFRM de la contraparte y se utiliza en una SD-WAN Route.

Los túneles Any-to-Any pueden controlar varios XFRM Gateways directamente mediante SD-WAN y comprobaciones SLA; no necesitan un VPN Failover Group adicional. En cambio, los túneles Policy-based y los túneles Route-based con Traffic Selectors utilizan un IPsec Failover Group para conexiones redundantes. El procedimiento enlazado explica el orden, el Health Check, Automatic failback y la prueba de fallo controlada. El grupo desactiva DPD en las conexiones asignadas y establece Key negotiation tries en 3.

Después de guardar, deben comprobarse cuatro puntos:

1. La interfaz XFRM aparece en Network > Interfaces y tiene la IP de transferencia prevista.
2. La ruta remota apunta a la interfaz XFRM o al gateway XFRM correspondiente.
3. Diagnostics > Tools > Route lookup devuelve la interfaz o el gateway XFRM esperado para un host real de la LAN remota. La misma prueba se realiza en el peer.
4. Las reglas solo permiten las direcciones y los servicios previstos.

Traffic Selectors

Con subredes específicas, el comportamiento de SFOS 22 en este caso especial no es inequívoco: puede no existir una interfaz XFRM, pero el firewall también puede crear una por cada configuración de Traffic Selectors. Despliegue la Listening interface en Network > Interfaces y compruebe el estado real del build instalado; también puede seleccionar una interfaz XFRM existente en Diagnostics > Packet capture. Si aparece una interfaz XFRM, no le asigne una dirección IP ni rutas. La ruta estática se crea automáticamente cuando el túnel está established. No se admite Any solo en un lado y un selector específico en el otro.

Esta variante es adecuada para redes pequeñas y claramente definidas. Si la interfaz es visible, usarla como se documenta para confirmar el tráfico saliente en Diagnostics > Packet capture; comprobar además la ruta automática, las Child SAs, los logs y el tráfico en ambos sentidos. WAF sobre IPsec route-based con Traffic Selectors no es compatible.

Un túnel Any-to-Any no puede cambiarse directamente a Traffic Selectors específicos. Hay que clonar o volver a crear la conexión y realizar después una migración controlada.

3. Tener en cuenta XFRM y MTU

Las VPN route-based son más propensas a malentendidos relacionados con routing, MTU y MSS. Si las pruebas pequeñas funcionan pero las transferencias grandes se bloquean, no debe modificarse inmediatamente el perfil IPsec. Primero hay que comprobar MTU, MSS, fragmentación y la ruta real. El procedimiento adecuado se describe en Comprobar MTU y MSS en Sophos Firewall para problemas VPN.

Reglas de firewall, NAT y Device Access

Reglas de firewall y reglas automáticas

Después de configurar IPsec hacen falta reglas para el tráfico productivo. Sin reglas adecuadas, el túnel puede aparecer en verde pero las aplicaciones no funcionarán.

Ruta de menú:

Rules and policies > Firewall rules

Reglas habituales:

• Red local hacia red remota: por ejemplo LAN a VPN.
• Red remota hacia red local de servidores: por ejemplo VPN a Server.
• Management o monitoring: permitir solo sistemas de administración o monitoring definidos.
• DNS, AD, RDP, HTTPS: permitir solo los servicios necesarios, no Any de forma general.

Las interfaces XFRM siempre pertenecen a la zona VPN. Si se usan ambas direcciones, hacen falta reglas inbound y outbound adecuadas. Las reglas separadas con logging muestran con mayor claridad durante la aceptación qué servicios puede alcanzar cada lado. La estructura general se describe en Crear y comprobar de forma segura reglas de Sophos Firewall.

Los paquetes IPsec entrantes primero se desencapsulan y se descifran. Después, la regla de firewall correspondiente aplica sus políticas de seguridad al tráfico de datos antes de reenviarlo al destino. Para el tráfico saliente, la regla de firewall correspondiente se aplica antes de la encapsulación y el cifrado.

La opción Create firewall rule crea reglas separadas con los prefijos Incoming y Outgoing en la parte superior de la lista. Después:

• Comprobar la posición de las reglas.
• Restringir Source y Destination.
• Reducir Any a los Services necesarios.
• Activar Log firewall traffic para la puesta en marcha y el análisis de errores.
• Seleccionar conscientemente IPS, Web, Application Control y otras Security Features.
• Asignar un nombre claro a la regla, por ejemplo LAN_to_Branch_Zurich.

⚠️ Las reglas de firewall creadas automáticamente son un punto de partida, no un diseño de seguridad terminado. Especialmente en túneles entre sedes hacia redes de servidores, hay que reducir los servicios, Sources y Destinations después de la primera prueba.

Sophos no puede crear reglas automáticamente para route-based Any-to-Any. Con Dual, las reglas IPv4 e IPv6 se crean por separado. Si el tráfico de Internet de una sucursal debe pasar por la central, también se necesita un diseño NAT y de seguridad independiente.

Planificar NAT según el tipo de túnel

NAT no está prohibido con IPsec, pero debe tener un motivo claro. Los casos habituales son redes solapadas, requisitos cloud o direcciones de origen exigidas por terceros. NAT no sustituye una ruta ni modifica la decisión de routing: independientemente de la traducción, SFOS debe poder seleccionar una ruta VPN, estática, SD-WAN o dinámica adecuada.

Ruta de menú:

Rules and policies > NAT rules

Antes de crear una regla NAT deben responderse estas preguntas:

• ¿El peer espera direcciones IP originales o direcciones traducidas?
• ¿Hay redes solapadas?
• ¿NAT se configura en la conexión IPsec o mediante reglas NAT separadas?
• ¿Está documentada la dirección de retorno?
• ¿Log Viewer muestra la Source y Destination esperadas después de NAT?

La lógica NAT varía según el tipo de VPN:

• En IPsec policy-based y VPN route-based con Traffic Selectors, NAT para redes solapadas puede configurarse directamente en la conexión IPsec.
• En route-based Any-to-Any, se utilizan reglas SNAT y DNAT en Rules and policies > NAT rules.
• Con redes solapadas, ambos lados deben entender el mismo plan de traducción. Un NAT unilateral sin planificación de la ruta de retorno suele producir túneles verdes sin tráfico utilizable.

⚠️ En IPsec route-based con Traffic Selectors, usar el NAT de la conexión IPsec y no asignar una dirección IP ni una ruta manual a una interfaz XFRM si el build instalado la muestra. IPsec con NAT para redes solapadas muestra la configuración especular completa de direcciones, DNS y NAT.

Si el tráfico de una VPN route-based con Traffic Selectors coincide con una regla SNAT con Translated source = MASQ, el firewall descarta los paquetes porque estas interfaces XFRM no tienen direcciones IP asignadas. Esto puede explicar un túnel en verde sin tráfico utilizable. Para el flujo de prueba afectado, comprobar la regla NAT que coincide y su posición, y corregir únicamente la regla en conflicto; no desactivar MASQ de forma general para otras conexiones. Después, volver a comprobar el mismo flujo en ambos sentidos con Log Viewer y Packet Capture.

Si el tráfico útil de IPsec policy-based se traduce mediante una regla SNAT separada, su Outbound interface debe ser Any. Una regla limitada a puertos WAN concretos —normalmente la regla SNAT predeterminada— no se aplica a este tráfico VPN. Con Any, el firewall utiliza el valor de Translated source configurado en la regla SNAT correspondiente. Este comportamiento también se aplica cuando Override source translation (SNAT) está activado para interfaces de salida específicas.

Desde SFOS 22, IPsec policy-based crea la ruta VPN en el backend. Una ipsec_route manual solo es relevante para determinados escenarios de tráfico reenviado y no es un paso estándar; el tráfico generado por el sistema no la necesita. Consulte también Comprender las reglas NAT de Sophos Firewall.

Device Access para IPsec entrante

Para solicitudes IPsec entrantes, el firewall debe poder aceptar tráfico IPsec en la zona WAN correspondiente. Esto no se resuelve mediante una regla LAN-to-WAN normal, sino mediante los servicios locales del firewall.

Ruta de menú:

Administration > Device access

IPsec debe estar permitido para WAN si el firewall acepta solicitudes entrantes, por ejemplo con Respond only. Esto no sustituye las reglas para el tráfico útil a través del túnel. Al mismo tiempo, hay que comprobar si WebAdmin, SSH, User Portal o VPN Portal están accesibles de forma demasiado amplia. Para endurecer estos servicios locales, consulte Proteger el acceso a Sophos Firewall: configurar correctamente Device Access.

Probar el túnel y solucionar errores

Una buena prueba de aceptación no comprueba solo el estado verde. Comprueba el flujo real de datos.

Definir una matriz de aceptación

Antes de la primera prueba debe definirse una pequeña matriz de aceptación. Así queda claro qué conexión debe funcionar y cuál debe permanecer bloqueada de forma intencionada.

Casos de prueba útiles:

• Red de clientes local hacia red de servidores remota: prueba habitual de aplicación, por ejemplo HTTPS, RDP, SMB, SQL o ICMP solo como prueba básica.
• Red de clientes remota hacia red de servidores local: comprobar la dirección contraria si la conexión se usa de forma bidireccional.
• DNS o AD a través del túnel: probar solo si estos servicios deben pasar realmente por el túnel. Definir con precisión Source, servidor de destino y puerto.
• Monitoring o backup: comprobar si los sistemas previstos acceden desde la dirección correcta y no requieren por error reglas Any.
• Prueba bloqueada: un puerto o una red no autorizados expresamente deben bloquearse. De lo contrario, la base de reglas es demasiado amplia.
• Transferencia grande: en transferencias de archivos, RDP, VoIP o problemas de aplicación, observar también MTU/MSS y la fragmentación.

Para cada caso de prueba deben anotarse Source IP, Destination IP, Service, regla de firewall esperada, regla NAT esperada y dirección esperada. Después de cada prueba se comparan Log Viewer, Packet Capture y los contadores de bytes. Si solo se prueba ping, el túnel aún no está aceptado.

1. Comprobar el estado

En la interfaz WebAdmin:

Site-to-site VPN > IPsec

Comprobar:

• La conexión está activa.
• El estado del túnel es established.
• Si hay varias redes, todas las Child SAs esperadas están establecidas.

En Current activities > IPsec connections, las conexiones realmente establecidas se filtran por Connection name, Local subnet o Remote subnet, y la vista se actualiza con Refresh. Disconnect interrumpe una SA de forma controlada, por ejemplo cuando ambos lados están preparados para un cambio; no sustituye la desactivación ni el rollback.

El número esperado se define antes de la prueba: route-based Any-to-Any crea una conexión Phase 2 por interfaz XFRM; Dual crea una para IPv4 y otra para IPv6. Policy-based y route-based con Traffic Selectors crean una conexión por cada combinación de Local y Remote subnet.

Antes del primer tráfico útil Any-to-Any, se comprueba el host de destino real en Diagnostics > Tools > Route lookup. En cada firewall, el resultado debe apuntar a la interfaz o al gateway XFRM previsto.

2. Comprobar Log Viewer

Ruta de menú:

Log viewer

Generar tráfico de prueba con Source, Destination y Service claros. Después, comprobar en Log Viewer qué regla de firewall coincide y si NAT, Webfilter, IPS u otros módulos influyen en el tráfico. El procedimiento se describe en Probar una regla de firewall con Log Viewer, Policy Test y Packet Capture. Los rekeys, disconnects y errores de conexión recurrentes se comprueban en los logs de IPsec, no se deducen del estado actual de las SAs.

3. Packet Capture y Advanced Shell

Si Log Viewer no basta, debe utilizarse Packet Capture con un filtro restringido:

Diagnostics > Packet capture

Ejemplo de filtro:

host 172.16.10.25 and host 10.20.30.15

En el troubleshooting de VPN es importante comprobar ambas direcciones. Los paquetes salientes sin respuesta suelen indicar un problema de ruta de retorno, NAT o del peer.

Advanced Shell

Para un troubleshooting más profundo mediante SSH, abrir 5. Device Management > 3. Advanced Shell y comprobar el estado actual de las SAs:

ipsec statusall

Entre otros, son relevantes:

• IKE SA established
• Child SA installed
• Traffic Selectors locales y remotos
• contadores de bytes en ambas direcciones

Si SSH todavía no está preparado, consulte Conectarse a Sophos Firewall mediante SSH.

Logs IPsec actuales

La vista actual de logs de SFOS 22 separa las funciones:

• strongswan.log: servicio IPsec y conexiones.
• charon.log: servicio IPsec y NAT en conexiones IPsec.
• ipsec_monitor.log: monitoring del servicio IPsec.
• /log/ipsec_conn/ipsec_<connectionname>.log: activación, desactivación y conexión mediante WebAdmin.
• xfrmi.log: interfaces XFRM en IPsec route-based.
• dgd.log: solo de forma adicional con failover VPN, SD-WAN, DGD o Link Load Balancing; no como log IPsec general.

Para un diagnóstico completo de logs y XFRM, consulte Sophos Firewall IPsec VPN Troubleshooting.

Errores habituales

• El túnel no se establece: probablemente no coinciden la versión IKE, el perfil, el PSK, el certificado, el Local ID o el Remote ID. Comprobar strongswan.log, el perfil IPsec y el peer.
• Phase 1 está activa, Phase 2 no: probablemente no coinciden las redes locales o remotas, o la Phase 2 proposal. Comprobar Traffic Selectors, subredes y PFS.
• El túnel está verde, pero no hay acceso: probablemente falta una regla de firewall, NAT, routing o la ruta de retorno. Comprobar Log Viewer, Packet Capture y routing.
• Solo funciona una dirección: el peer no conoce la ruta de retorno o NAT es incorrecto. Comprobar el peer, las reglas NAT y los contadores de bytes.
• Los pings pequeños funcionan, pero las aplicaciones se bloquean: probablemente intervienen MTU/MSS, fragmentación o una Security Feature. Comprobar MTU/MSS y Packet Capture.
• Route-based Any-to-Any no funciona: probablemente no coinciden la IP XFRM, el gateway, la ruta o la regla de firewall. Comprobar Network > Interfaces, routing y las reglas de zona VPN.
• Route-based con Traffic Selectors no funciona: comprobar si el build real muestra la interfaz XFRM bajo la Listening interface. Si aparece, usarla en Packet Capture, pero no asignarle IP ni ruta. Comprobar también la ruta automática, los Selectors, las reglas de zona VPN y una posible regla MASQ.
• Varios túneles se afectan entre sí: probablemente hay redes solapadas o configuraciones de Selectors similares. Comprobar los objetos de túnel, el failover group y las rutas.

Rollback tras una aceptación fallida

Un túnel nuevo se revierte de forma controlada, sin eliminar objetos por tanteo:

1. En Current activities > IPsec connections, desconectar la SA con Disconnect y desactivar la nueva conexión IPsec.
2. Desactivar solo las rutas estáticas o SD-WAN, reglas NAT y reglas de firewall creadas para este cambio, incluidas las reglas VPN automáticas. No eliminar por separado una interfaz XFRM generada si el build la muestra; la desactivación de la conexión gestiona esa interfaz.
3. En una migración, volver a asignar el perfil previo a la conexión anterior y, a continuación, reactivar la conexión y la ruta anterior.
4. Volver a probar el flujo original y el tráfico local de Internet o entre sedes con Log Viewer y Packet Capture.
5. Eliminar los objetos nuevos únicamente cuando Object Usage no muestre más dependencias y se haya demostrado que la ruta anterior vuelve a funcionar.

Checklist

Antes del cambio:

• Las redes locales y remotas son inequívocas.
• Se ha elegido conscientemente entre policy-based y route-based.
• El perfil IPsec está coordinado con el peer.
• El Preshared Key, los certificados o las claves RSA están documentados de forma segura.
• Las reglas de firewall están planificadas, incluida la dirección, posición, logging y servicios.
• Con Create firewall rule, está claro qué reglas creadas automáticamente deben revisarse.
• En route-based Any-to-Any están planificados la IP XFRM, el gateway, las reglas de firewall manuales y las rutas.
• En route-based con Traffic Selectors se ha registrado la visibilidad XFRM real; no se prevén IP XFRM ni rutas manuales, tanto si el build muestra la interfaz como si no.
• NAT está excluido o documentado de forma deliberada.
• Se ha comprobado Device Access para IPsec entrante.
• Se conocen la ventana de mantenimiento, el peer y la ruta de fallback.

Después del cambio:

• El estado del túnel es established.
• La matriz de aceptación, con al menos una prueba por cada dirección necesaria, se ha ejecutado y superado.
• Log Viewer muestra la regla de firewall esperada.
• Packet Capture muestra el tráfico de ida y vuelta.
• Se han probado los accesos internos a DNS y aplicaciones.
• Los contadores de bytes aumentan en ambas direcciones.
• NAT y la ruta de retorno están coordinados con el peer.
• El cambio está documentado en la documentación de red.

Preguntas frecuentes