Sophos Firewall - Troubleshooting de IPsec VPN

Las VPN IPsec site-to-site suelen pasar desapercibidas mientras funcionan. Pero si un túnel no se establece, queda inestable después de una reconexión o aparece como conectado sin transportar tráfico, se necesita un orden claro de troubleshooting. Si no, es fácil saltar entre PSK, rutas, reglas firewall y logs sin ver la causa real.

Esta guía muestra cómo revisar conexiones IPsec en Sophos Firewall de forma sistemática: primero el establecimiento del túnel, después las redes negociadas y al final el flujo real de paquetes. Para bases generales de CLI, ayuda Sophos Firewall Troubleshooting: consejos y trucos de CLI.

Antes del troubleshooting

Primero conviene documentar la situación inicial. Parece básico, pero ahorra mucho tiempo porque muchos problemas de IPsec vienen de supuestos asimétricos: un lado cree que conecta la red A con la red B, mientras el otro espera otros IDs, otras subredes u otra versión de IKE.

Puntos importantes:

En IPsec policy-based, las redes locales y remotas forman parte de la negociación del túnel. En IPsec route-based también importa qué rutas apuntan a la interfaz del túnel. Si el tráfico toma una dirección incorrecta a pesar de un túnel activo, a menudo intervienen rutas IPsec, rutas estáticas, SD-WAN Policy Routes o la Route Precedence de Sophos Firewall.

⚠️ Los debug logs y Packet Captures pueden contener datos sensibles, como direcciones IP públicas, redes internas, hostnames o payload. Estos datos solo deberían recopilarse de forma específica, durante un tiempo limitado y revisarse antes de compartirlos.

Ruta de diagnóstico

En la práctica ayuda un orden simple:

1. ¿Se establece el túnel? Si no, revisar primero versión IKE, perfil IPsec, IDs, PSK/certificado, NAT-T y alcanzabilidad del peer.
2. ¿Se establece la fase 2? Si no, revisar traffic selectors, redes locales/remotas, PFS y proposals de fase 2.
3. ¿Hay una Security Association instalada? Si sí, revisar ipsec statusall y los contadores de bytes.
4. ¿Pasa tráfico por el túnel? Si no, revisar reglas firewall, NAT, routing, Route Precedence, rutas IPsec y camino de retorno.
5. ¿Se ven paquetes? Si no está claro, combinar Log Viewer y Packet Capture.

Un error frecuente: un túnel en verde solo demuestra que IPsec se negoció. No demuestra que las reglas firewall sean correctas, que las rutas coincidan o que el peer conozca el camino de retorno.

Recopilar logs

Sophos Firewall usa StrongSwan para IPsec. Los logs más importantes están en /log:

Abrir la Advanced Shell por SSH y cambiar si hace falta al directorio de logs:

cd /log

Seguir el log en directo:

tail -f /log/strongswan.log

Si hay varios túneles activos, conviene filtrar. Se puede filtrar por nombre del túnel, IP del peer o texto de error típico:

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

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

less /log/strongswan.log

Dentro de less se busca con /termino. Alternativamente se filtra directamente con grep:

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

Activar debug de StrongSwan

Si el log normal no basta, se puede poner el servicio StrongSwan en modo debug:

service strongswan:debug -ds nosync

Después revisar si el servicio está en modo debug:

service -S | grep strongswan

La salida debería mostrar RUNNING,DEBUG para strongswan. Luego reconectar el túnel o reproducir el error de forma dirigida y observar el log:

tail -f /log/strongswan.log

El mismo comando desactiva de nuevo el modo debug:

service strongswan:debug -ds nosync

⚠️ Debug solo debe ejecutarse durante el tiempo necesario. IPsec debug puede generar logs grandes rápidamente y ocupar espacio innecesario en la 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 ese punto los gateways todavía no negocian redes de datos, sino IKE, autenticación e identidades de ambos lados.

Causas típicas:

• la versión IKE no coincide
• el perfil IPsec o proposal no coincide
• Local ID o Remote ID es distinto de lo esperado
• Preshared Key incorrecto
• el peer llega a una IP pública equivocada
• NAT-T o port forwarding para UDP 500 y 4500 no está limpio
• certificados, CA o validez no coinciden en autenticación basada en certificados

No IKE config found

Un log como no IKE config found o NO_PROPOSAL_CHOSEN suele significar que Sophos Firewall no encuentra una configuración IKE adecuada para el paquete entrante. Puede deberse a la versión IKE, gateway, IDs o perfil IPsec.

Revisar:

• ¿IKEv1 o IKEv2 coincide en ambos lados?
• ¿El peer coincide con la Remote Gateway o FQDN configurado?
• ¿Coinciden Local ID y Remote ID?
• ¿Encryption, Authentication, DH Group y Lifetime son compatibles?
• ¿El peer usa otra IP pública que la documentada?

Peer authentication failed

peer authentication failed, AUTH_FAILED o no matching peer config found suele apuntar a IDs o datos de autenticación que no coinciden. Con Preshared Key se sospecha primero de la clave. A menudo es correcto, pero no siempre. Si el ID no coincide, la firewall quizá ni siquiera comprueba la configuración del peer esperado.

Revisar:

• Local ID de un lado corresponde al Remote ID del otro.
• Remote ID de un lado corresponde al Local ID del otro.
• Escritura, mayúsculas/minúsculas, FQDN y direcciones IP coinciden exactamente.
• Preshared Key se introdujo sin espacios al principio o al final.
• Con varios túneles al mismo peer, está claro qué conexión debe hacer match.

Invalid HASH_V1 payload o decryption failed

En IKEv1, mensajes como invalid HASH_V1 payload length o decryption failed suelen indicar un Preshared Key incorrecto. En IKEv2 se ven más bien AUTHENTICATION_FAILED o AUTH_FAILED.

En la práctica, conviene definir de nuevo el Preshared Key en ambos lados en lugar de compararlo solo visualmente. Copy-paste desde gestores de contraseñas, espacios invisibles o caracteres especiales distintos son pérdidas de tiempo clásicas.

Fase 2: Traffic selectors y Security Associations

Si la fase 1 funciona pero la fase 2 no se establece, el problema suele estar en las redes y la Child SA. Sophos Firewall debe negociar con el peer qué subredes locales y remotas pueden pasar por el túnel.

Indicaciones típicas en logs:

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

Revisar:

• Las redes locales y remotas están configuradas como espejo en ambos lados.
• Máscara de red y objetos host individuales coinciden exactamente.
• No hay solapamientos no deseados con otros túneles.
• Varias redes de fase 2 están representadas igual en ambos lados.
• PFS, ESP Encryption, Authentication y Lifetime coinciden.

Ejemplo: si Sophos Firewall espera local 172.16.10.0/24 y remoto 10.20.30.0/24, el peer debe ofrecer exactamente el espejo 10.20.30.0/24 hacia 172.16.10.0/24. Un /24 en un lado y un host individual o una red más grande en el otro pueden bastar para que la Child SA no se instale.

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

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

Primero revisar el estado IPsec en Advanced Shell:

ipsec statusall

Lo más interesante:

• ¿La IKE SA está ESTABLISHED?
• ¿La Child SA está INSTALLED?
• ¿Qué redes locales y remotas se muestran?
• ¿Suben los contadores de bytes en ambas direcciones?
• ¿Se ven solo bytes salientes, pero no entrantes?
• ¿El túnel reconecta o hace rekey con frecuencia?

Si la Child SA está instalada pero los contadores quedan vacíos, probablemente el tráfico esperado no llega al túnel. Entonces hay que revisar el camino antes y después de IPsec.

Reglas firewall

El tráfico a través del túnel necesita reglas firewall adecuadas. Según el modelo de zonas, puede ser LAN a VPN, VPN a LAN o una zona propia. La regla debe cubrir correctamente source, destination, service y dirección.

Importante:

• Activar Log firewall traffic en las reglas relevantes.
• Revisar la posición de la regla para que no haga match antes una regla más general.
• Elegir correctamente source zone y destination zone.
• Con varias VPNs, evitar objetos demasiado amplios si podrían hacer match con el túnel incorrecto.
• Revisar conscientemente Security Features como IPS, Web Filter o Application Control si están activos sobre ese tráfico.

Probar reglas firewall con Log Viewer, Policy Test y Packet Capture describe un flujo general.

Routing y rutas IPsec

Si la firewall no envía el tráfico al túnel, se revisan las rutas. En IPsec policy-based también puede ser relevante la tabla de routing IPsec:

ip route show table 220

Si hace falta una asignación manual, una ruta IPsec en Sophos Firewall puede ayudar. Si compiten varios tipos de routing, también hay que revisar la Route Precedence de Sophos Firewall.

Revisar:

• ¿Existe una ruta estática más específica que captura el tráfico?
• ¿Una SD-WAN Policy Route tiene prioridad sobre la ruta VPN?
• ¿El gateway del cliente apunta realmente a Sophos Firewall?
• ¿El peer tiene una ruta de retorno hacia la red local?
• ¿Hay redes locales y remotas solapadas?

NAT

NAT no es fundamentalmente incorrecto con IPsec, pero debe estar configurado conscientemente. Un MASQ no deseado o una regla SNAT demasiado amplia puede hacer que el peer ya no asocie el tráfico con la red esperada.

Revisar:

• ¿Una regla MASQ genérica hace match antes que una regla NAT VPN específica?
• ¿El peer espera direcciones IP originales o traducidas?
• ¿NAT está documentado en ambos lados?
• ¿La regla NAT coincide con la dirección del tráfico?

Si NAT está implicado, ayuda Entender NAT en Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Combinar Log Viewer y Packet Capture

Log Viewer muestra qué regla o módulo evaluó una conexión. Packet Capture en WebAdmin muestra en cambio si los paquetes llegan realmente, se reenvían, se descartan o los procesa la propia firewall.

Para troubleshooting de IPsec conviene definir una prueba lo más precisa posible:

Después:

1. Activar logging en la regla firewall.
2. Filtrar Log Viewer por Source IP, Destination IP 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. Revisar si los paquetes llegan, se reenvían y si vuelven respuestas.

Interpretación:

Para capturas más largas o casos de soporte, puede tener sentido recopilar logs de forma dirigida. Guardar logs de Sophos Firewall para soporte y análisis describe la exportación limpia.

Patrones de error típicos

Checklist práctica

Revisar de inmediato:

• Anotar estado del túnel y último error en WebAdmin.
• Iniciar tail -f /log/strongswan.log y reconectar el túnel.
• Revisar versión IKE, Local ID, Remote ID y Preshared Key.
• Comparar traffic selectors o redes locales/remotas como espejo.
• Revisar ipsec statusall para ESTABLISHED, INSTALLED y contadores de bytes.

Si el túnel está activo:

• Revisar reglas firewall en ambas direcciones.
• Activar logging en las reglas afectadas.
• Filtrar Log Viewer por source, destination y Rule ID.
• Ejecutar Packet Capture con filtro estrecho.
• Revisar reglas NAT y Route Precedence.
• Confirmar ruta de retorno en el peer.

Para soporte o análisis más largo:

• Activar debug solo brevemente y desactivarlo después.
• Guardar logs relevantes.
• Documentar hora, nombre del túnel, peer IP, source, destination y pasos de prueba.
• Revisar datos sensibles antes de compartirlos.

FAQ

¿Por qué el túnel IPsec está en verde, pero no pasa tráfico?

Un túnel en verde solo significa que IPsec se negoció. Las reglas firewall, NAT, routing, Route Precedence, rutas IPsec y el camino de retorno del peer pueden seguir estando mal.

¿Qué log es el más importante para IPsec en Sophos Firewall?

En la práctica, strongswan.log es el archivo más importante. Según el caso, también pueden ayudar charon.log, strongswan-monitor.log y dgd.log.

¿Cuándo se debe activar StrongSwan debug?

Debug es útil cuando el log normal no aporta suficiente información. Solo debería activarse de forma específica y breve, porque genera muchos más datos de log.

¿Qué significa traffic selectors inacceptable?

Las redes que ambos lados quieren negociar para fase 2 no coinciden. Hay que comparar exactamente subredes locales/remotas, objetos host y varias entradas de fase 2.

¿Qué significa AUTH_FAILED?

AUTH_FAILED indica un problema de autenticación. Causas frecuentes son Preshared Key, Local ID, Remote ID o certificados que no coinciden con lo esperado por el peer.

Fuentes

• Sophos Community: Troubleshooting site-to-site IPsec VPN issues
• Sophos Support: KBA-000006520
• Sophos Docs: Packet capture