Solución de problemas de VPN IPsec en Sophos Firewall

Las VPN IPsec de sitio a sitio suelen pasar desapercibidas mientras funcionan. Sin embargo, si un túnel no se establece, permanece inestable tras una reconexión o se muestra como conectado pero no transporta tráfico, se necesita un orden claro para el análisis. De lo contrario, se puede saltar rápidamente entre PSK, rutas, reglas de firewall y registros sin ver la causa real.

El artículo explica cómo verificar sistemáticamente las conexiones IPsec en Sophos Firewall: primero el establecimiento del túnel, luego las redes negociadas y finalmente el flujo real de paquetes. Si se está planificando o configurando un nuevo túnel de sitio, primero consulte Configurar VPN IPsec de sitio a sitio en Sophos Firewall. Para fundamentos generales de CLI, también es útil Solución de problemas de CLI en Sophos Firewall: comandos importantes.

Antes de la solución de problemas

Primero, se debe documentar brevemente la situación inicial. Esto puede parecer trivial, pero ahorra mucho tiempo, ya que muchos problemas de IPsec surgen de suposiciones asimétricas: una parte cree que está conectando la red A con la red B, pero la otra parte espera diferentes IDs, subredes o una versión de IKE diferente.

Puntos importantes:

• Nombre del túnel: azure-vpn
• Gateway local: Dirección WAN o FQDN de Sophos Firewall
• Gateway remoto: IP pública o FQDN del punto remoto
• Versión de IKE: IKEv1 o IKEv2
• Autenticación: Clave precompartida o certificado
• ID local / ID remota: Dirección IP, FQDN o identificador similar a un correo electrónico
• Redes locales: 172.16.10.0/24
• Redes remotas: 10.20.30.0/24
• Tipo de VPN: basada en políticas o basada en rutas
• Gateway type: Initiate the connection, Respond only o grupo de failover
• Tráfico esperado: Origen, Destino, Puerto y Dirección

En IPsec basado en políticas, las redes locales y remotas son parte de la negociación del túnel. En IPsec basado en rutas, también es importante qué rutas apuntan a la interfaz del túnel. Si el tráfico corre en la dirección incorrecta a pesar de un túnel activo, a menudo están involucradas Rutas IPsec, rutas estáticas, rutas de política SD-WAN o la Precedencia de rutas de Sophos Firewall.

Si el túnel está activo y las pruebas pequeñas funcionan, pero las transferencias más grandes se quedan colgadas, también se debe verificar MTU y MSS. El procedimiento para esto se encuentra en Verificar MTU y MSS en problemas de VPN en Sophos Firewall.

⚠️ Los registros de depuración y las capturas de paquetes pueden contener datos sensibles, como direcciones IP públicas, redes internas, nombres de host o datos de usuario. Estos datos deben recopilarse solo de manera específica y por un tiempo limitado, y deben revisarse antes de compartirlos.

Ruta de diagnóstico

Para la práctica, ayuda un orden simple:

1. ¿Se establece el túnel? Si no, primero verifique la versión de IKE, el perfil de IPsec, las IDs, PSK/certificado, NAT-T y la accesibilidad del punto remoto.
2. ¿Se establece la Fase 2? Si no, verifique los selectores de tráfico, las redes locales y remotas, PFS y las propuestas de Fase 2.
3. ¿Está instalada una Asociación de Seguridad? Si es así, verifique ipsec statusall y preste atención a los contadores de bytes.
4. ¿El tráfico pasa a través del túnel? Si no, verifique las reglas de firewall, NAT, enrutamiento, precedencia de rutas, rutas IPsec y el camino de retorno.
5. ¿Se ven paquetes? Si no está claro, combine Log Viewer y Packet Capture.

Un error común: un estado de túnel verde solo prueba que IPsec se ha negociado en principio. No prueba que las reglas de firewall sean correctas, que las rutas sean correctas o que el punto remoto conozca el camino de retorno.

Antes de pasar a Advanced Shell conviene revisar las listas de WebAdmin:

• En Site-to-site VPN > IPsec, con Show additional properties se pueden mostrar columnas adicionales como Local subnet, Remote subnet, Gateway type o Profile.
• En Profiles > IPsec profiles también se pueden mostrar propiedades adicionales para comparar más rápido los valores de Phase 1 y Phase 2.

Esto no es tan profundo como un log, pero evita errores básicos: perfil incorrecto, Gateway type incorrecto, mismas subredes en varios túneles o un túnel que ni siquiera pertenece al grupo de failover esperado.

¿Qué nivel está afectado?

Antes de los registros de depuración, se debe clasificar el problema de manera general. Esto aclara más rápidamente si se debe buscar en IKE, Fase 2, enrutamiento o flujo de paquetes.

• El túnel permanece inactivo: IKE, Gateway, IDs, PSK, certificado o propuesta Verificar strongswan.log en vivo y comparar Fase 1
• El túnel cambia constantemente entre activo e inactivo: Rekey, DPD, estabilidad de WAN o propuesta Comparar marcas de tiempo, DPD, tiempo de vida y eventos de WAN
• Fase 1 está activa, pero no hay SA secundaria: Selectores de tráfico, propuesta de Fase 2 o PFS Verificar redes locales y remotas de manera especular
• El túnel está verde, pero los contadores de bytes permanecen vacíos: El tráfico no llega al túnel Verificar regla de firewall, NAT, ruta y gateway del cliente
• Solo aumentan los bytes salientes: Falta el camino de retorno o el punto remoto Verificar firewall remoto, ruta remota y sistema de destino
• Packet Capture muestra paquetes sin regla correspondiente: El orden de las reglas, la zona o el servicio no son correctos Comparar Log Viewer, Policy Test y Rule ID

Esta clasificación no reemplaza un análisis detallado. Sin embargo, evita buscar un error de Fase 2 en las reglas de firewall o restablecer innecesariamente la clave precompartida en un problema de camino de retorno.

Recopilar registros

Sophos Firewall utiliza StrongSwan para IPsec. Los registros más importantes se encuentran en /log:

• strongswan.log: archivo de registro IPsec más importante para IKE, autenticación y SAs secundarias
• charon.log: registro del demonio IKE, útil según la versión y la situación
• strongswan-monitor.log: monitoreo del servicio IPsec
• dgd.log: detección de gateway muerto y failover de VPN

Se accede a la Advanced Shell por SSH y se cambia al directorio de registros si es necesario:

cd /log

El registro en vivo se puede seguir directamente:

tail -f /log/strongswan.log

Si hay varios túneles activos, se debe filtrar. Esto se puede hacer por el nombre del túnel, una IP de par o un texto de error típico:

tail -f /log/strongswan.log | grep -i azure-vpn

Para archivos de registro existentes, less suele ser más cómodo:

less /log/strongswan.log

En less, se puede buscar dentro del archivo con /término de búsqueda. Alternativamente, grep filtra directamente:

grep -i "no proposal" /log/strongswan.log

Activar depuración de StrongSwan

Si el registro normal no es suficiente, se puede poner el servicio StrongSwan en modo de depuración:

service strongswan:debug -ds nosync

Luego, verifique si el servicio está en modo de depuración:

service -S | grep strongswan

La salida debería mostrar el estado RUNNING,DEBUG para strongswan. Luego, vuelva a conectar el túnel o reproduzca el error de manera específica y observe el registro:

tail -f /log/strongswan.log

El mismo comando de depuración desactiva el modo de depuración nuevamente:

service strongswan:debug -ds nosync

⚠️ Mantenga la depuración activa solo mientras sea realmente necesaria. La depuración de IPsec puede generar rápidamente archivos de registro grandes y ocupar espacio innecesario en el firewall.

Fase 1: IKE, IDs y autenticación

Si el túnel no se establece en absoluto, la causa suele estar antes o durante la Fase 1. En este punto, los gateways aún no negocian redes de datos, sino primero IKE, autenticación y las identidades de ambas partes.

Causas típicas:

• La versión de IKE no coincide
• El perfil de IPsec o la propuesta no coinciden
• La ID local o remota es diferente a la esperada
• La clave precompartida es incorrecta
• El punto remoto alcanza la IP pública incorrecta
• NAT-T o la redirección de puertos en UDP 500 y 4500 no son correctos
• Los certificados, CA o la validez no coinciden en la autenticación basada en certificados

No se encontró configuración de IKE

Una entrada de registro como no IKE config found o NO_PROPOSAL_CHOSEN a menudo significa que Sophos Firewall no encuentra una configuración de IKE adecuada para el paquete entrante. Esto puede deberse a la versión de IKE, al gateway, a las IDs o al perfil de IPsec.

Verificar:

• ¿IKEv1 o IKEv2 coinciden en ambos lados?
• ¿El punto remoto coincide con la dirección del gateway remoto configurada o con el FQDN?
• ¿Las IDs locales y remotas coinciden?
• ¿Son compatibles la encriptación, autenticación, grupo DH y tiempo de vida?
• ¿El punto remoto utiliza una IP pública diferente a la documentada?

Fallo en la autenticación del par

peer authentication failed, AUTH_FAILED o no matching peer config found a menudo indican que las IDs o los datos de autenticación no coinciden. En el caso de la clave precompartida, a menudo se sospecha primero de la clave. Esto suele ser correcto, pero no siempre. Si la ID no coincide, el firewall puede no verificar contra la configuración de par esperada.

Verificar:

• La ID local de un lado coincide con la ID remota del otro lado.
• La ID remota de un lado coincide con la ID local del otro lado.
• La escritura, mayúsculas y minúsculas, FQDN y direcciones IP coinciden exactamente.
• La clave precompartida se ingresó sin espacios al principio o al final.
• Si hay varios túneles hacia el mismo punto remoto, es claro qué conexión debe coincidir.

Longitud de carga útil HASH_V1 inválida o fallo en la descifrado

En IKEv1, mensajes como invalid HASH_V1 payload length o decryption failed a menudo indican una clave precompartida incorrecta. En IKEv2, es más probable ver AUTHENTICATION_FAILED o AUTH_FAILED.

En la práctica, se debe restablecer la clave precompartida en ambos lados, en lugar de solo compararla visualmente. El copiar y pegar desde gestores de contraseñas, espacios invisibles o caracteres especiales diferentes son clásicos que consumen tiempo.

Fase 2: Selectores de tráfico y Asociaciones de Seguridad

Si la Fase 1 es exitosa, pero la Fase 2 no se establece, generalmente se trata de las redes y la SA secundaria. Sophos Firewall debe negociar con el punto remoto qué subredes locales y remotas están permitidas a través del túnel.

Indicaciones típicas en el registro:

• traffic selectors ... inacceptable
• failed to establish CHILD_SA
• received traffic selectors didn't match
• TSi y TSr muestran redes diferentes a las esperadas

Verificar:

• Las redes locales y remotas están configuradas de manera especular en ambos lados.
• La máscara de red y los objetos de host individuales coinciden exactamente.
• No hay superposiciones no deseadas con otros túneles.
• Múltiples redes de Fase 2 están representadas de manera idéntica en ambos lados.
• PFS, encriptación ESP, autenticación y tiempo de vida coinciden.

Ejemplo: Si Sophos Firewall espera localmente 172.16.10.0/24 y remotamente 10.20.30.0/24, el punto remoto debe ofrecer exactamente de manera especular 10.20.30.0/24 a 172.16.10.0/24. Un /24 en un lado y un solo host o una red más grande en el otro lado puede ser suficiente para que la SA secundaria no se instale.

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

Si el túnel se muestra como conectado, pero no pasa tráfico, IPsec en sí no es automáticamente la causa. Generalmente se trata de enrutamiento, reglas de firewall, NAT o el camino de retorno.

Primero, verifique el estado de IPsec en la Advanced Shell:

ipsec statusall

Lo más interesante es:

• ¿Está la IKE SA ESTABLISHED?
• ¿Está la SA secundaria INSTALLED?
• ¿Qué redes locales y remotas se muestran?
• ¿Los contadores de bytes aumentan en ambas direcciones?
• ¿Solo se ven bytes salientes, pero no entrantes?
• ¿Se reconecta o se rekeyea regularmente?

En IPsec route-based también se puede comprobar si XFRM state y policy están instalados:

ip xfrm state
ip xfrm policy

Si ipsec statusall muestra una SA establecida, pero ip xfrm state o ip xfrm policy no encajan con el túnel esperado, el problema normalmente ya no está en PSK o proposal, sino en Traffic Selectors, configuración XFRM, rutas o túneles competidores.

Si la SA secundaria está instalada, pero los contadores de bytes permanecen vacíos, es probable que el tráfico esperado no llegue al túnel. Luego, verifique el camino antes y después de IPsec.

Reglas de firewall

Para que el tráfico pase a través del túnel, se necesitan reglas de firewall adecuadas. Dependiendo del modelo de zonas, esto puede ser LAN a VPN, VPN a LAN o una zona propia. La regla debe cubrir correctamente el origen, destino, servicio y dirección.

Importante:

• Activar Log firewall traffic en las reglas relevantes.
• Verificar la posición de la regla para que no se aplique una regla más general antes.
• Elegir correctamente las zonas de origen y destino.
• No usar objetos demasiado amplios en varios VPNs si podrían coincidir con el túnel incorrecto.
• Verificar conscientemente características de seguridad como IPS, filtro web o control de aplicaciones si están activas en el tráfico.

Un procedimiento general de verificación se describe en Probar regla de firewall con Log Viewer, Policy Test y Packet Capture.

Enrutamiento y Rutas IPsec

Si el firewall no envía el tráfico al túnel, verifique las rutas. En IPsec basado en políticas, la tabla de enrutamiento de IPsec también puede ser relevante:

ip route show table 220

Si se necesita una asignación manual, una Ruta IPsec en Sophos Firewall puede ayudar. Si varios tipos de enrutamiento compiten, también se debe verificar la Prioridad de enrutamiento de Sophos Firewall.

Verificar:

• ¿Existe una ruta estática más específica que intercepte el tráfico?
• ¿Una ruta de política SD-WAN se aplica antes que la ruta VPN?
• ¿El gateway del cliente realmente apunta a Sophos Firewall?
• ¿El punto remoto tiene una ruta de retorno a la red local?
• ¿Existen redes locales y remotas superpuestas?

En VPN route-based también se deben controlar las interfaces XFRM. Dos interfaces XFRM no deben configurarse con redes de interfaz solapadas o idénticas. Si xfrm1 y xfrm2 están en la misma red de transferencia, el túnel puede estar established y aun así enrutar mal. En ese caso, revisar la asignación XFRM en Network > Interfaces y usar redes inequívocas.

Si varias conexiones IPsec usan las mismas subredes locales y remotas, no deberían coexistir sin diseño explícito. Esas conexiones pertenecen a un diseño de failover consciente o necesitan lógica de selectores/routing claramente distinta.

NAT

NAT no es intrínsecamente incorrecto en IPsec, pero debe configurarse conscientemente. Un MASQ no intencionado o una regla SNAT demasiado amplia puede hacer que el punto remoto no asigne el tráfico a la red esperada.

Verificar:

• ¿Una regla MASQ genérica se aplica antes que una regla VPN-NAT específica?
• ¿El punto remoto espera direcciones IP originales o traducidas?
• ¿Está documentado NAT en ambos lados?
• ¿La regla NAT coincide con la dirección del tráfico?

Si NAT está involucrado, el artículo Entender NAT en Sophos Firewall: SNAT, DNAT, MASQ, PAT es útil.

SFOS 22: Verificar conscientemente IPsec basado en políticas y NAT

En actualizaciones a SFOS 22, IPsec basado en políticas debe verificarse con especial cuidado. Sophos señala en las notas de la versión de SFOS-22 un comportamiento cambiado en VPN IPsec basado en políticas. Además, en los problemas resueltos se documenta NC-170917: El tráfico IPsec basado en políticas podría fallar si la regla SNAT predeterminada estaba configurada con una dirección IP estática en lugar de MASQ.

Para la práctica, esto significa: Si un túnel basado en políticas está verde después de la actualización, pero no hay tráfico o solo tráfico unidireccional, NAT no debe tratarse como un tema secundario. Una regla SNAT predeterminada antigua, amplia o inusualmente ajustada puede cambiar exactamente el tráfico que el punto remoto espera con las redes originales.

Puntos de verificación típicos después de una actualización a SFOS-22:

• ¿El túnel es realmente basado en políticas?: En IPsec basado en políticas, las redes locales y remotas son parte de la negociación. NAT puede romper esta expectativa.
• ¿Se ajustó la regla SNAT predeterminada?: Una IP SNAT estática en lugar de MASQ puede tener efectos diferentes a los esperados después de una actualización.
• ¿Existen reglas VPN-NAT específicas?: Estas deben estar por encima de las reglas SNAT o MASQ generales y coincidir con la dirección del tráfico.
• ¿Coinciden los selectores de tráfico y los objetos NAT?: El punto remoto debe esperar ya sea las redes originales o las redes traducidas, no ambas al azar.
• ¿Packet Capture muestra la IP de origen esperada?: Así se reconoce si el firewall usa una dirección de origen diferente antes del túnel.

Un caso de prueba limpio consiste en una fuente, un destino y un servicio. Luego, se verifica secuencialmente la regla de firewall, la regla NAT, ipsec statusall, ip route show table 220, Packet Capture y el punto remoto. Si la prueba solo funciona con la regla NAT desactivada o movida, el problema no está en el establecimiento del túnel, sino en el camino hacia el túnel.

Para la planificación de la actualización, también es útil Verificar Sophos Firewall antes de la actualización a SFOS 22. Para los fundamentos de NAT y el orden de las reglas, Entender NAT en Sophos Firewall es una mejor introducción.

Rekey, failover y estado de interfaz

Si un túnel funciona primero y falla más tarde, la configuración inicial no siempre es la causa. Entonces hay que revisar la evolución temporal:

• Traffic-based Rekeying en terceros: Sophos Firewall espera lógica de rekey basada en tiempo. Si el peer fuerza traffic-based Rekeying, el túnel puede quedarse bloqueado o renegociar.
• Key exchange collisions: Si ambos lados hacen rekey al mismo tiempo, pueden aparecer fases inestables. En estos casos, las lifetimes de Phase 1 y Phase 2 deben coordinarse conscientemente entre Initiator y Responder.
• Interfaz desactivada: Si se desactiva la interfaz correspondiente, un túnel Site-to-Site iniciador se corta de inmediato. Conexiones responder y Remote Access caen a más tardar por inactividad o DPD timeout.
• DGD y grupo de failover: En escenarios de failover, revisar además dgd.log, estado de gateway, conexión primaria/secundaria y pares de subredes idénticos.

Estos errores se reconocen mejor por marcas de tiempo que por un único snapshot. Para problemas intermitentes, conviene correlacionar estado del túnel, strongswan.log, dgd.log, eventos WAN y prueba de aplicación.

SFOS 22: PPPoE-WAN con interfaz alias y aceleración IPsec

Si después de una actualización a SFOS 22.0 GA o SFOS 22.0 MR1 un túnel IPsec está conectado pero no se reenvía tráfico, puede haber un caso especial adicional en ciertas configuraciones. Sophos enumera en la lista de problemas conocidos NC-181526: En hardware XGS, los túneles IPsec en interfaces alias de un puerto PPPoE-WAN pueden establecerse, pero no reenviar tráfico útil si IPsec acceleration está activa.

Este punto solo debe verificarse si las causas normales no coinciden. Un túnel verde sin tráfico sigue siendo generalmente un problema de reglas, enrutamiento, NAT o camino de retorno. El caso especial de SFOS-22 se vuelve más probable si se cumplen todos los siguientes puntos:

• Sophos Firewall está ejecutando SFOS 22.0 GA o SFOS 22.0 MR1.
• Se trata de hardware XGS.
• El túnel afectado utiliza una interfaz alias en un puerto PPPoE-WAN.
• El túnel se establece, pero el tráfico útil no pasa.
• Las reglas de firewall, NAT, rutas, camino de retorno y Packet Capture no explican el comportamiento.
• La aceleración IPsec está activa.

Como solución temporal, se documenta desactivar la aceleración IPsec:

system ipsec-acceleration off

Esto no debe usarse como un comando genérico de ajuste de IPsec. El cambio debe realizarse en una ventana de mantenimiento o un procedimiento de soporte documentado, con pruebas antes y después y una clara asignación al problema afectado. Sophos enumera SFOS 22.0.2 MR2 como la versión de corrección para este problema conocido. Si esta versión está aprobada para el entorno afectado, una actualización planificada es más limpia que una solución temporal olvidada.

Procedimiento de verificación práctica:

1. Documentar el estado del túnel y ipsec statusall.
2. Ejecutar Packet Capture con un filtro de origen/destino estrecho.
3. Verificar si el túnel realmente utiliza una interfaz alias en un puerto PPPoE-WAN.
4. Anotar la versión activa de SFOS y el modelo de hardware.
5. Probar el cambio en la aceleración IPsec solo de manera específica y documentada.
6. Después de la prueba, comparar contadores de bytes, Packet Capture, Log Viewer y prueba de aplicación.

Combinar Log Viewer y Packet Capture

El Log Viewer muestra qué regla o módulo ha evaluado una conexión. Packet Capture en WebAdmin muestra si los paquetes realmente llegan, se reenvían, se descartan o son procesados por el firewall.

Para la solución de problemas de IPsec, se debe definir una prueba lo más estrecha posible:

• IP de origen: 172.16.10.25
• IP de destino: 10.20.30.15
• Servicio: ICMP o TCP 443
• Dirección esperada: LAN a VPN
• Regla esperada: LAN_to_VPN_Branch

Luego:

1. Activar el registro en la regla de firewall.
2. Filtrar Log Viewer con IP de origen, IP de destino y módulo Firewall.
3. Iniciar Packet Capture con un filtro estrecho, por ejemplo, host 172.16.10.25 and host 10.20.30.15.
4. Reproducir la prueba exactamente una vez.
5. Verificar si los paquetes llegan, se reenvían y si las respuestas regresan.

Interpretación:

• No llega ningún paquete a Sophos Firewall: Verificar cliente, gateway, VLAN, switch o enrutamiento local
• El paquete llega, pero no se reenvía: Verificar regla de firewall, NAT, ruta o característica de seguridad
• El paquete se envía al túnel, falta la respuesta: Verificar ruta de retorno, punto remoto, firewall remoto o host remoto
• Solo bytes salientes en ipsec statusall: Verificar camino de retorno o política remota
• Solo bytes entrantes: Verificar ruta local, regla de firewall local o sistema de destino

Para capturas más largas o casos de soporte, puede ser útil recopilar registros de manera específica. El artículo Guardar registros de Sophos Firewall para soporte y análisis describe la exportación limpia.

Escenarios de error típicos

Los siguientes escenarios de error se refieren a las cadenas de registro sin procesar de StrongSwan/Charon en strongswan.log. En WebAdmin, las mismas causas suelen aparecer como un mensaje traducido, por ejemplo no IKE config found como “Remote peer is refusing our Phase 1 proposals”, peer authentication failed como “Remote peer reports we failed to authenticate” o traffic selectors ... inacceptable como “Remote peer reports INVALID_ID_INFORMATION”. Si primero consulta WebAdmin en lugar del registro sin procesar, esta correspondencia ayuda a encontrar el caso adecuado.

• no IKE config found: La versión de IKE, gateway, IDs o perfil no coinciden Comparar versión de IKE, ID local/remota y propuestas
• NO_PROPOSAL_CHOSEN: Desajuste de propuesta Verificar encriptación, autenticación, grupo DH, PFS y tiempo de vida
• peer authentication failed: ID o autenticación no coinciden Verificar ID local/remota y PSK/certificado
• AUTH_FAILED: Clave precompartida, certificado o ID no coinciden Restablecer PSK, verificar cadena de certificados e IDs
• traffic selectors ... inacceptable: Las redes locales y remotas no coinciden Comparar subredes y objetos de host de manera especular
• failed to establish CHILD_SA: Las redes de Fase 2 o las propuestas ESP no coinciden Verificar selectores de tráfico, PFS, perfil ESP y tiempos de vida
• Túnel verde, sin bytes: El tráfico no llega al túnel Verificar regla de firewall, ruta, NAT y gateway del cliente
• Bytes salientes, sin entrantes: Falta el punto remoto o el camino de retorno Verificar reglas remotas, ruta remota y sistema de destino
• ipsec statusall muestra SAs, pero el tráfico route-based se detiene más tarde: revisar XFRM state, XFRM policy, redes XFRM solapadas, grupo de failover y comportamiento de rekey.
• Varios túneles con las mismas subredes: los túneles pertenecen a un grupo de failover o necesitan una lógica de selectores/routing claramente diferenciada.
• Transferencias grandes se cuelgan a pesar del túnel activo: MTU/MSS, pérdida de paquetes o descubrimiento de MTU de ruta Verificar MTU y MSS en problemas de VPN
• SFOS 22, IPsec basado en políticas, túnel verde, falta tráfico: NAT, SNAT predeterminado o selectores de tráfico no coinciden correctamente después de la actualización Verificar SNAT predeterminado, reglas VPN-NAT, MASQ, Packet Capture y punto remoto
• SFOS 22, PPPoE-WAN-Alias, túnel verde, sin tráfico: posible problema conocido con aceleración IPsec Verificar tipo de interfaz, versión de SFOS y probar system ipsec-acceleration off solo de manera específica
• Reconexiones o rekeys frecuentes: Tiempo de vida, DPD, línea inestable o problema de propuesta Verificar tiempos de rekey, DPD, estabilidad de WAN y registros

Lista de verificación práctica

Verificar de inmediato:

• Anotar el estado del túnel y el último mensaje de error en WebAdmin.
• Iniciar tail -f /log/strongswan.log y volver a conectar el túnel.
• Verificar versión de IKE, ID local, ID remota y clave precompartida.
• Comparar selectores de tráfico o redes locales y remotas de manera especular.
• Verificar ipsec statusall en ESTABLISHED, INSTALLED y contadores de bytes.

Si el túnel está activo:

• Verificar reglas de firewall en ambas direcciones.
• Activar el registro en las reglas afectadas.
• Filtrar Log Viewer con origen, destino y Rule ID.
• Ejecutar Packet Capture con un filtro estrecho.
• Verificar reglas NAT y precedencia de rutas.
• En VPN route-based, comprobar ip xfrm state, ip xfrm policy y las redes de interfaces XFRM.
• En varios túneles parecidos, mostrar grupo de failover y columnas Local-/Remote-Subnet.
• En SFOS 22 con IPsec basado en políticas, verificar SNAT predeterminado, reglas VPN-NAT específicas y IP de origen esperada.
• En SFOS 22 con PPPoE-WAN-Alias, verificar si el problema conocido de aceleración IPsec se aplica.
• Confirmar ruta de retorno en el punto remoto.

Para soporte o análisis más prolongado:

• Activar depuración solo brevemente y luego desactivarla.
• Guardar registros relevantes.
• Documentar hora, nombre del túnel, IP de par, origen, destino y procedimiento de prueba.
• Verificar datos sensibles antes de compartir.

Preguntas frecuentes