Sophos Firewall: diagnosticar sistemáticamente una VPN IPsec

En el troubleshooting de IPsec, el orden es decisivo: primero se comprueban IKE y la Child SA; después, las reglas de firewall, NAT, routing y el camino de retorno. Un túnel verde solo confirma la negociación, no que funcione el tráfico de usuarios.

Para un túnel nuevo, se debe empezar por Configurar una VPN IPsec site-to-site en Sophos Firewall. Los pasos siguientes se aplican a una conexión ya configurada.

Los ajustes avanzados globales, como la limpieza de sesiones durante failover, la ventana anti-replay, el umbral de cookies IKEv2 o el uso de direcciones del peer ya resueltas, no deben modificarse como primer intento de diagnóstico. Usar con seguridad los ajustes VPN globales explica su efecto, la comprobación inicial y el rollback.

Proceso de diagnóstico

1. El túnel permanece down: Comprobar en strongswan.log la versión de IKE, el perfil IPsec, el gateway, la Local/Remote ID, el PSK o el certificado.
2. Phase 1 está activa, pero no hay Child SA: Comparar los Traffic Selectors, la propuesta de Phase 2, PFS y las subredes.
3. El túnel está verde: Usar ipsec statusall para comprobar que la SA está ESTABLISHED, la Child SA está INSTALLED y los contadores de bytes aumentan.
4. Solo una dirección cuenta bytes: Comprobar las reglas de firewall, NAT, routing y, especialmente, el camino de retorno en el extremo remoto.
5. La causa sigue sin estar clara: Seguir un único flujo de prueba con Log Viewer y Packet Capture.

Al principio bastan unos pocos valores documentados: nombre del túnel, IP o FQDN del peer, versión de IKE, Local/Remote ID, redes locales y remotas, policy-based o route-based, perfil IPsec y una prueba con source, destination y service. Ejemplo: túnel azure-vpn, local 172.16.10.0/24, remoto 10.20.30.0/24.

En IPsec policy-based, las redes forman parte de la negociación. IPsec route-based utiliza una interfaz XFRM y rutas estáticas, SD-WAN o dinámicas. Si el camino es incorrecto, resultan útiles las guías específicas sobre rutas IPsec y Route Precedence.

⚠️ Los logs y Packet Captures pueden contener direcciones IP públicas, redes internas, nombres de host o datos de usuario. Deben recopilarse de forma específica y durante un tiempo limitado, y revisarse antes de compartirlos.

Antes del diagnóstico por CLI, Current activities > IPsec connections solo muestra las conexiones IPsec establecidas en ese momento. La lista se puede filtrar por Connection name, Local server name, Local subnet, Username, Remote server/host o Remote subnet y volver a cargar con Refresh. Disconnect finaliza activamente la conexión seleccionada y no es una actualización inofensiva: primero se documentan la hora y el estado, y solo se desconecta durante una ventana de prueba planificada. Esta instantánea no sustituye la comprobación de Child SA, logs y tráfico.

Comprobar los logs y la CLI

En Site-to-site VPN > IPsec, Show additional properties muestra, entre otros datos, Local subnet, Remote subnet, Gateway type y Profile. En Profiles > IPsec profiles también se pueden comparar directamente los valores de Phase 1 y Phase 2.

Los archivos más importantes de /log son:

• strongswan.log: IKE, autenticación y Child SAs
• charon.log: demonio IKE
• ipsec_monitor.log: supervisión del servicio IPsec
• /log/ipsec_conn/ipsec_<connectionname>.log: acciones Connect, Activate y Deactivate en WebAdmin
• xfrmi.log: interfaces XFRM
• dgd.log: Dead Gateway Detection y failover de VPN

La lista central actual de logs de SFOS 22 menciona ipsec_monitor.log. Una página anterior de troubleshooting de Sophos todavía incluye strongswan-monitor.log; para los sistemas SFOS 22 actuales, la lista de logs más reciente es la referencia válida.

En la Advanced Shell, el log principal se puede seguir en directo o filtrar. Si el acceso SSH y el shell aún no resultan familiares, puede consultarse Troubleshooting de la CLI de Sophos Firewall: comandos importantes.

cd /log
tail -f /log/strongswan.log
tail -f /log/strongswan.log | grep -i azure-vpn
less /log/strongswan.log
grep -i "no proposal" /log/strongswan.log

Estas líneas son alternativas, no un procedimiento consecutivo. En less, se utiliza /termino-busqueda para buscar dentro del archivo.

Depuración de StrongSwan

Si el registro normal no basta, anote primero el estado actual en la Advanced Shell:

service -S | grep strongswan

Si la salida ya indica un estado de depuración activo, no vuelva a ejecutar el comando de conmutación. Averigüe primero quién lo activó y con qué propósito; la secuencia siguiente solo se aplica si la depuración estaba inicialmente inactiva. El texto exacto puede variar según la compilación.

⚠️ Mantenga la depuración activa solo durante un periodo breve. Puede generar rápidamente archivos de registro grandes y ocupar almacenamiento.

Si la depuración no está activa, ejecute el comando una vez y compruebe el nuevo estado:

service strongswan:debug -ds nosync
service -S | grep strongswan

A continuación, siga strongswan.log en un segundo terminal, reproduzca el problema una sola vez y detenga tail con Ctrl+C:

tail -f /log/strongswan.log

Para terminar, ejecute una vez el mismo comando de conmutación. La segunda línea debe confirmar que se ha restaurado el estado normal sin depuración anotado anteriormente:

service strongswan:debug -ds nosync
service -S | grep strongswan

Comprobar el establecimiento del túnel

Phase 1: IKE, IDs y autenticación

Si el túnel no se establece, normalmente no coinciden la versión de IKE, el gateway, los IDs, la propuesta, el PSK o el certificado.

• no IKE config found o Remote peer is refusing our Phase 1 proposals: El firewall no encuentra una conexión adecuada o el perfil no coincide. Comprobar la versión de IKE, la Listening Interface, la dirección del peer, la Local/Remote ID y el perfil.
• peer authentication failed, AUTH_FAILED, AUTHENTICATION_FAILED, no matching peer config found o Remote peer reports we failed to authenticate: Los IDs y la autenticación no coinciden con la configuración esperada del peer.
• invalid HASH_V1 payload length o decryption failed: En IKEv1 suele indicar un PSK incorrecto; en IKEv2 aparece con más frecuencia AUTH_FAILED.
• El extremo remoto llega a otra dirección pública o UDP 500/4500 no se reenvía correctamente mediante NAT, un router o el proveedor.
• En los certificados, no coinciden la cadena de certificados, la CA emisora, la validez o el ID esperado.

Si un certificado se ha revocado antes de expirar o el efecto de la revocación sigue sin estar claro, se comprueban conjuntamente el issuer, el número de serie, thisUpdate, nextUpdate y el rechazo específico del servicio. El procedimiento seguro se explica en Importar y probar Certificate Revocation Lists en Sophos Firewall.

El Local ID de un lado debe coincidir con el Remote ID del otro y viceversa. Compare primero los ID y el PSK almacenado en ambos lados. Si debe cambiar el PSK, coordine la modificación en los dos peers durante una ventana de mantenimiento; los espacios invisibles y el copiado desde gestores de contraseñas son causas frecuentes. Un ID incorrecto puede impedir la asociación del peer antes de comprobar el PSK esperado.

Ante Remote peer is refusing our Phase 1 proposals, compare los valores de Phase 1, además de Gateway address y Listening interface, en ambos extremos. Si coinciden, el administrador del peer debe revisar la configuración y los logs del mismo momento en el extremo remoto que rechaza la conexión. Ante Remote peer reports we failed to authenticate, pídale también que confirme si el tipo de ID esperado es diferente, por ejemplo una dirección IP en lugar de un nombre DNS. Local ID y Remote ID deben coincidir de forma cruzada en tipo y valor; corrija únicamente la discrepancia confirmada y vuelva a comprobar el establecimiento del túnel. Antes de modificar nada, registre los valores anteriores y coordine el cambio con el administrador del peer durante una ventana de mantenimiento; si no hay mejora, restaure el estado documentado. No comparta PSK en logs ni en paquetes de soporte.

Los mensajes Error on decryption of the exchange o Information field of the IKE request is malformed or not readable apuntan inicialmente a claves precompartidas diferentes. Solo si se confirma que el PSK es idéntico en ambos extremos y el error persiste se debe investigar la causa menos frecuente que indica Sophos: paquetes dañados por el ISP o por un router o firewall situado en el trayecto previo. Revise con el proveedor o el administrador responsable el trayecto afectado mediante capturas simultáneas y con filtros precisos, y compare los valores WAN de MTU/MSS con las especificaciones del proveedor. Una única captura no demuestra que los paquetes estén dañados. La guía de MTU y MSS explica la comprobación inicial, las pruebas seguras y la reversión; no reduzca los valores globalmente por suposición. TCP MSS no es una solución para los fallos de negociación IKE. Revise las capturas en busca de datos sensibles antes de compartirlas.

Phase 2: Traffic Selectors y Child SA

Si Phase 1 está activa, pero no existe una Child SA, normalmente difieren las subredes o los valores de Phase 2.

• traffic selectors ... inacceptable
• failed to establish CHILD_SA
• received traffic selectors didn't match
• Remote peer reports INVALID_ID_INFORMATION
• valores diferentes en TSi y TSr
• NO_PROPOSAL_CHOSEN después de Phase 1 is up y Initiating establishment of Phase 2 SA

NO_PROPOSAL_CHOSEN por sí solo no basta para clasificar el problema: antes de Phase 1, indica valores de IKE/Phase 1; después de una Phase 1 correcta, indica ESP, PFS u otros valores de Phase 2.

Para comparar todos los campos de General settings, Phase 1, Phase 2 y DPD, consulte Entender y configurar de forma segura los perfiles IPsec de Sophos Firewall.

Las redes deben estar invertidas entre ambos extremos. Si Sophos espera como red local 172.16.10.0/24 y como remota 10.20.30.0/24, el extremo remoto debe ofrecer 10.20.30.0/24 hacia 172.16.10.0/24. Un /24 frente a un único host o unos objetos de host mantenidos de forma diferente también pueden impedir la Child SA.

Si NO_PROPOSAL_CHOSEN o Remote peer reports INVALID_ID_INFORMATION persiste después de una Phase 1 correcta, aunque ya se hayan comparado Encryption, Authentication, el grupo PFS/DH de Phase 2 y las subredes invertidas entre ambos extremos, pida al administrador del peer que revise los logs de negociación remotos del mismo momento. Facilite el nombre del túnel, la hora, los valores de selector ofrecidos y el estado INSTALLED de la Child SA o del selector afectado según ipsec statusall; indique expresamente si falta esa SA, sin deducir del error que faltan todas las SA. ip xfrm policy complementa la comprobación de políticas, pero no demuestra que las SA estén instaladas. Antes de modificar nada, documente los valores anteriores y el procedimiento de reversión, y acuerde una ventana de mantenimiento. Después, corrija de forma coordinada solo la discrepancia demostrada y vuelva a comprobar el establecimiento y el mismo flujo de prueba; si no hay mejora, restaure el estado anterior.

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

En la Advanced Shell, este comando muestra las SA, las redes negociadas y los contadores de bytes:

ipsec statusall

Los valores importantes son ESTABLISHED, INSTALLED y los contadores en ambas direcciones. Si ambos permanecen a cero o no aumentan, probablemente el tráfico de prueba no llega al túnel. Si solo aumenta el lado saliente, normalmente falta el camino de retorno o una regla en el extremo remoto; si solo aumentan los bytes entrantes, se debe sospechar de la ruta local, la regla local o el sistema de destino.

Seguir un flujo de prueba

Una prueba precisa ofrece más información que varios pings simultáneos:

• Source IP: 172.16.10.25
• Destination IP: 10.20.30.15
• Service: ICMP o TCP 443
• dirección esperada: LAN a VPN
• regla esperada: LAN_to_VPN_Branch

A continuación, se comprueba en este orden:

1. Activar Log firewall traffic en la regla afectada.
2. Filtrar Log Viewer por source, destination y Rule ID.
3. Iniciar Packet Capture con host 172.16.10.25 and host 10.20.30.15.
4. Ejecutar la prueba una sola vez.
5. Comparar la regla, el campo NAT Rule ID, el reenvío, la respuesta y los contadores de bytes.
6. Comprobar la ruta de retorno, la regla remota y el sistema de destino en el extremo remoto.

Packet Capture utiliza un búfer limitado y se detiene cuando se llena. La vista muestra, entre otros campos, Rule ID, NAT ID, Status y Reason. Durante una captura estándar, el tráfico FastPath acelerado suele desviarse temporalmente por SlowPath. Compruebe el estado del búfer, el filtro y el momento de la prueba antes de interpretar una captura vacía o detenida como prueba de que no existe tráfico.

Si no llega ningún paquete a Sophos Firewall, la causa se encuentra antes, por ejemplo, en el gateway del cliente, la VLAN o el routing local. Si llega, pero no se reenvía, no coinciden la regla, NAT, la ruta o una función de seguridad. La prueba completa de reglas se describe en Comprobar una regla de firewall con Log Viewer, Policy Test y Packet Capture.

Routing y XFRM

Con IPsec policy-based, SFOS crea las rutas VPN en el backend. No aparecen en la vista normal de routing. Consulte las IPsec Route manuales y la Route Precedence en la Device Console:

system ipsec_route show
system route_precedence show

El orden predeterminado es static, sdwan_policyroute, vpn. Por tanto, una entrada ausente en la vista normal no demuestra un fallo de routing. Para el flujo de prueba, correlacione Diagnostics > Tools > Route lookup, el registro del firewall y Packet Capture.

Con IPsec route-based, la ruta depende del tipo de interfaz XFRM:

• Any/Any o Dual: la interfaz XFRM tiene direcciones IP. Una ruta estática, SD-WAN o dinámica debe dirigir hacia ella el tráfico remoto.
• Traffic Selectors específicos: SFOS crea automáticamente la ruta estática. No se puede asignar una dirección IP ni otra ruta a la interfaz XFRM.

Compruebe la interfaz en Network > Interfaces y el camino en Diagnostics > Tools > Route lookup. La Device Console muestra las rutas estáticas configuradas:

show static-route

Compruebe los estados XFRM en la Advanced Shell:

ip xfrm state
ip xfrm policy

Si hay varias interfaces XFRM con dirección IP, compare también sus redes de tránsito: cada interfaz necesita una red propia que no se solape. No basta con que las direcciones IP individuales sean distintas. xfrm1 con 192.168.0.1/24 y xfrm2 con 192.168.0.6/24 pertenecen a 192.168.0.0/24; 192.168.0.1/16 en xfrm1 también se solapa con 192.168.0.6/24 en xfrm2, porque el /16 contiene el /24. Estos ejemplos ilustran un error, no direcciones recomendadas. Se trata de las redes de tránsito de las interfaces, no de las redes LAN protegidas en los Traffic Selectors.

⚠️ Cambiar el direccionamiento XFRM puede interrumpir el camino del túnel y el acceso de administración. Documente primero las direcciones IP, los prefijos y las rutas dependientes en ambos extremos, y prepare un acceso de administración independiente y una ventana de mantenimiento. En Network > Interfaces, cambie únicamente las interfaces afectadas con dirección IP a redes de tránsito disponibles y no solapadas, y coordine los cambios de direccionamiento del peer y de las rutas dependientes. Después, compruebe Route lookup, el mismo flujo de prueba y los contadores de bytes en ambas direcciones. Si no mejora, restaure las direcciones, los prefijos y las rutas documentados en ambos extremos. Con Traffic Selectors específicos sigue siendo válido: no asignar una IP XFRM ni una ruta adicional.

Si varias conexiones usan las mismas redes locales y remotas como caminos alternativos, su selección y failover deben quedar definidos. Incluya las conexiones policy-based y las route-based con Traffic Selectors específicos en el mismo grupo de failover IPsec. Los túneles XFRM Any/Any pueden conmutar mediante rutas SD-WAN; el procedimiento enlazado explica el orden, el Health Check y la prueba controlada.

Comprobar NAT según el tipo de túnel

NAT está permitido, pero no sustituye una ruta. Compruebe primero que el camino del destino original o traducido selecciona el túnel correcto y después que el peer espera las direcciones realmente utilizadas.

Si las redes local y remota son idénticas, una sola indicación sobre SNAT no basta. Usar NAT con redes IPsec solapadas describe el proceso simétrico completo de direccionamiento, túnel, reglas y routing.

• Policy-based con SNAT: la regla SNAT prevista necesita Outbound interface Any. La regla SNAT predeterminada con puertos WAN específicos no coincide con el tráfico IPsec policy-based.
• Route-based con Any/Any o Dual: la interfaz XFRM tiene una dirección IP y necesita una ruta explícita. Determine si existe traducción y cómo se realiza a partir de la regla NAT coincidente y Packet Capture; no la deduzca solo del tipo de túnel.
• Route-based con Traffic Selectors específicos: SFOS crea la ruta automáticamente y no asigna una dirección IP a la interfaz XFRM. Suponer MASQ hacia una presunta IP XFRM no es una vía de diagnóstico fiable; compruebe la Source original, la traducida y la NAT Rule ID coincidente.

Documente la Source original y la traducida, permítalas en el peer según corresponda y asegure la ruta de retorno. NAT en Sophos Firewall explica los fundamentos y el orden de las reglas.

Inestabilidad y casos especiales de SFOS 22

Si el tráfico se detiene más tarde, se deben comparar las marcas de tiempo del estado del túnel, strongswan.log, dgd.log, los eventos WAN y la prueba de la aplicación. Las causas frecuentes son:

• El equipo de otro fabricante utiliza rekeying basado en tráfico; Sophos Firewall admite rekeying basado en tiempo.
• Con IPsec policy-based, un timeout de inactividad en el firewall remoto termina la conexión tras un periodo sin tráfico. Compare con el administrador del peer el timeout de la conexión VPN afectada y la hora de desconexión. Antes de cambiarlo, anote su valor anterior y su ámbito; si se confirma esta causa, desactive el timeout de inactividad de esa conexión en el extremo remoto durante una ventana de prueba acordada. La conexión puede así permanecer establecida mientras está inactiva. Después, espere el periodo de inactividad que causaba el problema y compruebe el mismo flujo de prueba, el estado del túnel y los contadores de bytes. Si no mejora, restaure el ajuste anterior del peer. Esto no modifica los timeouts globales de SFOS, las Key Lifetimes ni DPD.
• Ambos extremos realizan el rekey al mismo tiempo. Se deben escalonar intencionadamente las Key Lifetimes de Phase 1 y Phase 2 del Initiator y del Responder.
• La interfaz asignada se ha desactivado. Los túneles Initiator se desconectan de inmediato y los túneles Responder, como máximo, después de un periodo de inactividad o del DPD timeout.
• Las transferencias grandes fallan aunque una prueba pequeña funcione; en ese caso, se deben comprobar MTU y MSS.

Bloqueos repetidos del firewall con multicast a través de VPN

Si los bloqueos coinciden en el tiempo con tráfico multicast que atraviesa un túnel VPN, primero se deben guardar la versión y el build del firmware, el túnel afectado, las marcas de tiempo y los datos de diagnóstico o crash disponibles. Sophos confirma este problema como NC-180433 y lo corrigió en SFOS 22.0 MR2 Build 546.

La descripción pública del problema no indica un tipo de túnel o diseño multicast concreto ni ofrece un workaround por CLI. En un build anterior de SFOS 22, se debe comprobar el camino de actualización, actualizar a MR2 Build 546 o a una versión aprobada más reciente y repetir después el mismo tráfico de forma controlada. No se deben modificar por suposición los parámetros del túnel, IPsec Acceleration ni los servicios. Si el firewall sigue fallando con MR2 o una versión posterior, se deben entregar los datos recopilados a Sophos Support en lugar de seguir atribuyendo automáticamente el problema a NC-180433.

La configuración normal y la validación controlada se explican en Enrutamiento multicast en Sophos Firewall; el bloqueo descrito aquí sigue siendo un caso especial ligado al firmware.

Los paquetes IKEv2 se fragmentan

En el Known Issue NC-136352, el perfil IKEv2 predeterminado puede ofrecer tantos grupos DH que los paquetes IKE superen los 1'500 bytes. Si un componente intermedio descarta fragmentos o información PMTU, el Initiator realiza envíos repetidos mientras el Responder no recibe nada.

Ante este síntoma exacto, se comprueba el peer en la Advanced Shell:

tcpdump -ni any 'host 203.0.113.10 and (udp port 500 or udp port 4500)'

A continuación, en el perfil IPsec solo se debe ofrecer el grupo DH realmente necesario o un número considerablemente menor de grupos. Sophos Firewall tcpdump describe filtros generales de tcpdump y la exportación de PCAP.

Alias PPPoE e IPsec Acceleration

NC-181526 afecta a SFOS 22.0 GA Respin Build 411 o MR1 en determinadas XGS Appliances: el túnel utiliza una interfaz alias de un puerto PPPoE-WAN, está conectado, pero no transporta datos de usuario cuando IPsec Acceleration está activa. Se excluyen XGS 88/88w, 108/108w, 118/118w y 128/128w.

La Sophos Known Issues List actual indica SFOS 22.0.2 MR2 Build 546 como versión corregida; sin embargo, NC-181526 no aparece por separado en la lista publicada de correcciones de MR2. Por ello, después de la actualización se debe repetir el mismo flujo de prueba, en lugar de deducir la corrección únicamente a partir de la versión.

⚠️ La desactivación de IPsec Acceleration es global, reinicia todos los túneles IPsec y provoca una interrupción. Solo se debe probar en una ventana de mantenimiento si la combinación de build, hardware, alias PPPoE y síntomas coincide exactamente.

Los comandos siguientes se ejecutan en la Device Console:

system ipsec-acceleration show
system ipsec-acceleration disable
system ipsec-acceleration show

Si no hay ninguna mejora, restaure el estado anotado antes de la prueba. Si la aceleración estaba activa, use:

system ipsec-acceleration enable

Con NC-180520, SFOS 22.0 MR2 corrige un caso de IP alias similar, pero diferente: el gateway XFRM podía permanecer inaccesible con Acceleration activa si ESP llegaba a través de otro puerto WAN. Los dos Issue IDs no deben considerarse equivalentes. La comprobación de actualización a SFOS 22 reúne más verificaciones antes y después de la actualización.

Validación y escalado

Después de cada cambio, se debe repetir el mismo flujo de prueba individual y documentar al menos estos puntos:

1. Hora, nombre del túnel, IP del peer, source, destination y service
2. Estado de WebAdmin e ipsec statusall antes y después de la prueba
3. Reglas de firewall y NAT asignadas
4. Packet Capture y contadores en ambas direcciones
5. Ruta de retorno y regla remota en el extremo remoto
6. Cambio, resultado y rollback preparado

Desactive después solo la depuración de StrongSwan activada durante este procedimiento. No cambie un estado preexistente sin conocer a su responsable y su propósito. Guarde de forma específica los logs relevantes para Sophos Support; Guardar logs de Sophos Firewall describe la exportación. Antes de compartir paquetes de logs grandes y capturas, se deben revisar para detectar datos sensibles.