Ir al contenido
Avanet

Solución de problemas de VPN IPsec en Sophos Firewall

Sophos Firewall

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.

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.
  6. El firewall se bloquea repetidamente con multicast a través de VPN: No provocar el problema con más pruebas de carga. Guardar la versión del firmware, las marcas de tiempo y los datos de diagnóstico disponibles; NC-180433 está corregido en SFOS 22.0 MR2 Build 546.

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.

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.

Debug de StrongSwan

Si el log normal no es suficiente, primero se debe comprobar el estado actual en la Advanced Shell:

service -S | grep strongswan

Si ya aparece RUNNING,DEBUG, no se debe volver a ejecutar el toggle como si fuera una activación. Se utiliza el debug existente y después se desactiva tal como se describe a continuación.

⚠️ El debug solo debe permanecer activo durante poco tiempo. Puede generar rápidamente archivos de log grandes y ocupar espacio de almacenamiento.

Si el debug todavía no está activo, se ejecuta el toggle, se comprueba el nuevo estado y se reproduce el error una sola vez:

service strongswan:debug -ds nosync
service -S | grep strongswan
tail -f /log/strongswan.log

En strongswan debe aparecer RUNNING,DEBUG. A continuación, el mismo comando vuelve a desactivar el modo debug; el segundo comando confirma el retorno al estado normal:

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.

La Local ID de un extremo debe coincidir con la Remote ID del otro y viceversa. Se debe volver a establecer el PSK en ambos lados; los espacios invisibles o el copiar y pegar desde gestores de contraseñas son causas frecuentes. Un ID incorrecto puede impedir la asignación del peer antes incluso de comprobar el PSK esperado.

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.

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.

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 vacíos, 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.

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

En IPsec policy-based, SFOS 22 gestiona las rutas VPN en el backend. Las rutas IPsec manuales y Route Precedence se comprueban en la Device Console:

system ipsec_route show
system route_precedence show

El comando de la Advanced Shell conocido por procedimientos de troubleshooting anteriores no es una prueba fiable de un túnel policy-based en SFOS 22:

ip route show table 220

En SFOS 22, las rutas VPN policy-based y las entradas manuales ipsec_route no son visibles allí. Por tanto, la ausencia de una entrada no demuestra ni que falte una ruta ni que exista un error de routing.

En IPsec route-based, debe existir una ruta estática, SD-WAN o dinámica hacia la interfaz XFRM, junto con los estados XFRM adecuados. Se comprueba la interfaz XFRM en Network > Interfaces y el camino en Diagnostics > Tools > Route lookup; la Device Console muestra las rutas estáticas configuradas:

show static-route

Los estados XFRM se comprueban en la Advanced Shell:

ip xfrm state
ip xfrm policy

Las interfaces XFRM no deben utilizar redes de transferencia solapadas. Las conexiones con subredes locales y remotas idénticas deben pertenecer a un grupo de failover común o necesitan una lógica de selectores y routing claramente diferente.

Comprobar NAT según el tipo de túnel

NAT está permitido, pero debe coincidir con el tipo de túnel y las direcciones que espera el extremo remoto.

  • Policy-based con SNAT: La regla SNAT prevista necesita Outbound interface Any. La regla SNAT predeterminada con puertos WAN concretos no coincide con el tráfico IPsec policy-based.
  • Route-based con Any/Any o Dual: MASQ traduce la source a la IP XFRM; esta se ve en el encabezado IP interno de Packet Capture.
  • Route-based con Traffic Selectors concretos: Si coincide una regla MASQ, el firewall descarta el tráfico porque esas interfaces XFRM no tienen una dirección IP asignada.

La source original y la traducida deben estar documentadas, permitidas en el extremo remoto y disponer de una 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.
  • 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.
  • Varias conexiones con las mismas subredes no están en el mismo grupo de failover.
  • 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.

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 Build 411 o MR1 Build 490 en determinados appliances XGS físicos: 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, se restaura el estado inicial:

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

Después se desactiva el debug de StrongSwan. Se deben guardar 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.