FortiClient IPsec conectado sin acceso a la red: diagnóstico paso a paso en FortiGate

¿FortiClient muestra la conexión IPsec como establecida, pero no puedes acceder a los servidores de tu empresa? Aprende a diagnosticar IKEv2, Phase 2, rutas, DNS, políticas de firewall, split tunneling y NAT-T en FortiGate mediante una metodología técnica paso a paso y comandos CLI.

Una VPN conectada no significa necesariamente que el usuario tenga acceso a las aplicaciones corporativas. Este es uno de los problemas que puede aparecer después de implementar o migrar conexiones de acceso remoto hacia IPsec VPN en FortiGate.

FortiClient indica que la conexión se estableció correctamente. Sin embargo, el usuario no puede abrir una carpeta compartida, acceder al ERP, conectar mediante RDP, consultar una aplicación web interna o resolver nombres de servidores.

En esta guía de la Biblioteca Virtual SISTRO 2.0 explicamos cómo distinguir problemas de negociación IPsec, direccionamiento, rutas, DNS, políticas de seguridad, retorno de tráfico y NAT Traversal. Incluimos comandos CLI de FortiOS para investigar cada capa sin modificar configuraciones a ciegas.

Alcance: conexiones de acceso remoto FortiClient–FortiGate, principalmente IPsec IKEv2. Algunos comandos también aplican a VPN site-to-site. Las opciones concretas dependen de la versión de FortiOS, FortiClient y la arquitectura desplegada.

1. ¿Por qué una VPN IPsec puede conectarse sin permitir acceso a la LAN?

Una conexión remota utiliza diferentes componentes. Cada uno debe funcionar para que una aplicación corporativa sea accesible.

IKE / Phase 1: establece la asociación de seguridad y autentica la conexión.
IPsec / Phase 2: establece las asociaciones necesarias para transportar el tráfico cifrado.
Asignación de direcciones: proporciona los parámetros de red que necesita el cliente remoto.
Rutas: determinan qué tráfico debe viajar por el túnel.
Políticas de firewall: autorizan el tráfico desde la VPN hacia las redes internas.
Retorno: permite que el servidor responda correctamente al usuario remoto.
DNS: traduce nombres corporativos a direcciones internas.
Servicios: el servidor debe aceptar el protocolo y puerto solicitado.

Por tanto, ver el estado Connected en FortiClient no demuestra que las ocho condiciones estén satisfechas.

2. Primero identifica el síntoma correcto

Antes de modificar una política, identifica qué está fallando.

FortiClient nunca conecta: revisar conectividad con el gateway, negociación IKE, autenticación, propuestas y certificados.
La VPN conecta, pero no responde ningún recurso: revisar direcciones, rutas, Phase 2, políticas y tráfico de retorno.
La VPN permite entrar mediante IP, pero no por nombre: comenzar por DNS.
Funciona una subred, pero otra no: revisar split tunneling, rutas, objetos de red y reglas aplicables.
Funciona HTTPS, pero no RDP o SMB: investigar servicios, puertos, políticas y firewall del servidor.
Funciona desde casa, pero falla en determinadas redes móviles: revisar NAT-T, transporte IPsec y restricciones de la red de origen.

Esta clasificación permite evitar un error frecuente: diagnosticar autenticación cuando el problema real se encuentra en el enrutamiento.

3. Comprueba las asociaciones IPsec en FortiGate

El primer paso es consultar el estado del túnel desde la CLI de FortiOS.

get vpn ipsec tunnel summary
diagnose vpn ike gateway list
diagnose vpn tunnel list

Estos comandos permiten consultar el resumen de túneles, las asociaciones IKE y los detalles relacionados con las asociaciones IPsec.

Comprueba especialmente:

Nombre del gateway o túnel correspondiente al usuario.
Versión IKE negociada.
Estado de las asociaciones de seguridad.
Dirección asignada al cliente, cuando corresponda.
Contadores de tráfico enviado y recibido.
Selectores, redes y parámetros negociados.

Interpretación: si la asociación IKE está establecida, pero no existe una asociación IPsec adecuada, aún podría existir un problema de negociación o configuración de tráfico. Si ambas aparecen establecidas, continúa investigando rutas y políticas.

Ten presente que ciertos túneles bajo demanda pueden mostrar estados diferentes hasta que se genera tráfico. Interpreta el resultado de acuerdo con la configuración real.

4. Revisa las rutas y el split tunneling

El split tunneling permite enviar a la VPN únicamente determinados destinos corporativos y mantener el resto del tráfico fuera del túnel.

Por ejemplo, una empresa podría tener las siguientes redes:

10.20.0.0/24 — servidores de aplicaciones.
10.30.0.0/24 — sistemas administrativos.
10.40.0.0/24 — recursos de infraestructura.

Si el cliente recibe una ruta hacia 10.20.0.0/24, pero no hacia 10.30.0.0/24, podría acceder a las aplicaciones de la primera red y fallar al intentar abrir el ERP ubicado en la segunda.

En Windows revisa las rutas instaladas:

route print
ipconfig /all

En Linux:

ip route
resolvectl status

En FortiGate revisa la tabla de rutas:

get router info routing-table all

Valida que los destinos corporativos estén incluidos en la configuración de acceso remoto, que las rutas lleguen al túnel adecuado y que no existan conflictos entre la subred local del usuario y la red corporativa.

Ejemplo: si el usuario trabaja desde una red doméstica 192.168.1.0/24 y la empresa utiliza exactamente la misma subred, puede producirse un conflicto de rutas. Este escenario requiere revisar el direccionamiento, no agregar permisos indiscriminados al firewall.

5. Verifica las políticas de seguridad entre IPsec y LAN

Una vez establecido el túnel, FortiGate continúa aplicando sus políticas de firewall.

Revisa la política que autoriza el tráfico desde la interfaz IPsec hacia la red donde se encuentra el servidor.

Los elementos principales son:

Interfaz de entrada: interfaz VPN correspondiente.
Interfaz de salida: LAN, VLAN o interfaz interna del servidor.
Dirección de origen: pool o grupos aplicables de usuarios VPN.
Dirección de destino: subred o servidor autorizado.
Servicio: HTTPS, RDP, SMB u otro servicio requerido.
Horario y estado de la política.
Registros de tráfico que permitan identificar aceptaciones o bloqueos.

En políticas tradicionales basadas en interfaces, revisa también la política de retorno si el diseño utiliza un flujo que la requiere. El tráfico de respuesta de una sesión permitida normalmente se gestiona mediante el seguimiento de estado del firewall.

Importante: no soluciones el problema creando una regla permanente de acceso irrestricto desde la VPN hacia toda la LAN. Aplica el principio de mínimo privilegio y utiliza registros para validar el diagnóstico.

6. Comprueba conectividad por IP antes de diagnosticar DNS

Una forma práctica de separar problemas de red de problemas de nombres consiste en probar una dirección IP interna conocida.

Supongamos que una aplicación HTTPS empresarial se encuentra en 10.20.0.10, puerto TCP 443.

Desde PowerShell en Windows:

Test-NetConnection 10.20.0.10 -Port 443

Si el puerto responde, existe conectividad TCP hacia ese servicio. Si no responde, todavía debemos investigar rutas, políticas, firewalls del servidor o disponibilidad de la aplicación.

También puedes utilizar:

ping 10.20.0.10

Sin embargo, que un servidor no responda ICMP no significa necesariamente que esté inaccesible. Muchas redes corporativas bloquean este protocolo.

7. La VPN funciona por dirección IP, pero no por nombre: revisa DNS

Este síntoma suele aparecer cuando los clientes VPN no reciben los servidores DNS corporativos adecuados, existe una configuración incorrecta de resolución de nombres o los equipos utilizan servidores públicos incapaces de resolver zonas internas.

Ejemplo:

nslookup intranet.corp.example

Comprueba:

Qué DNS recibe realmente FortiClient.
Si el DNS corporativo es alcanzable desde el túnel.
Si el sufijo de búsqueda está correctamente configurado.
Si la zona interna contiene el registro esperado.
Si la política VPN permite consultas DNS hacia los servidores correspondientes.
Si el sistema operativo está utilizando otra interfaz o resolvedor.

Un error DNS puede hacer que el usuario describa la VPN como caída, aunque el transporte IPsec y la conectividad IP funcionen correctamente.

8. Diagnostica el flujo real de tráfico con FortiOS

Cuando las rutas parecen correctas, pero el acceso sigue fallando, debemos observar qué hace el FortiGate con los paquetes.

Fortinet dispone de la herramienta Debug Flow, disponible desde CLI y también mediante la interfaz gráfica en versiones compatibles.

Ejemplo controlado para investigar el tráfico relacionado con un servidor 10.20.0.10:

diagnose debug disable
diagnose debug reset
diagnose debug flow filter addr 10.20.0.10
diagnose debug flow show function-name enable
diagnose debug flow trace start 100
diagnose debug enable

Genera una prueba desde el cliente remoto y revisa el resultado.

Al finalizar, detén y limpia el diagnóstico:

diagnose debug flow trace stop
diagnose debug disable
diagnose debug reset

Busca mensajes que indiquen si el paquete llega al firewall, qué ruta se seleccionó, qué política se aplicó y si el tráfico fue permitido o rechazado.

Si encuentras Denied by forward policy check, por ejemplo, revisa la coincidencia entre interfaces, objetos, servicio y políticas.

Los mensajes deben interpretarse junto con el resto de la traza; una línea aislada no siempre permite establecer una causa definitiva.

Precaución: ejecuta debug flow únicamente con autorización y durante un intervalo limitado. Puede generar gran cantidad de registros. El tráfico acelerado por hardware puede no aparecer íntegramente sin ajustes adicionales, que deben evaluarse cuidadosamente antes de aplicarse en producción.

9. Utiliza un sniffer para comprobar entrada y salida

Si necesitas determinar dónde desaparece el tráfico, utiliza la captura de paquetes del FortiGate.

diagnose sniffer packet any 'host 10.20.0.10' 4 20 a

Este ejemplo limita la captura a 20 paquetes relacionados con la dirección indicada.

Investiga si:

El paquete llega desde la interfaz IPsec.
El firewall lo envía hacia la LAN.
El servidor responde.
La respuesta vuelve al firewall.
El retorno sale por el túnel esperado.

Si observas solicitudes hacia el servidor, pero no respuestas, revisa el firewall local del servidor, la puerta de enlace, el enrutamiento interno y cualquier dispositivo intermedio.

Si las respuestas llegan a FortiGate pero no regresan correctamente al cliente, investiga las rutas, el túnel, las asociaciones IPsec y el tratamiento del tráfico de retorno.

10. NAT Traversal: cuando el túnel conecta pero el tráfico es unidireccional

Existe un escenario especialmente interesante en las conexiones IKEv2 desde redes domésticas, operadores móviles y otras ubicaciones donde el usuario está detrás de NAT.

NAT Traversal (NAT-T) permite transportar tráfico IPsec en condiciones donde existen dispositivos de traducción de direcciones.

Fortinet documentó en octubre de 2026 un caso específico donde FortiClient establece correctamente un túnel IKEv2, pero no consigue intercambiar tráfico de forma adecuada cuando NAT-T está deshabilitado en el FortiGate y el cliente está detrás de NAT.

En una investigación de este tipo revisa:

Si el cliente está detrás de un router o dispositivo que realiza NAT.
La configuración NAT-T en la Phase 1 correspondiente.
El tipo de transporte negociado.
Los registros y contadores de tráfico del túnel.
La versión de FortiClient y su compatibilidad.

No todos los problemas de una VPN conectada sin tráfico se deben a NAT-T. Esta hipótesis cobra relevancia cuando las evidencias indican tráfico asimétrico y se cumplen las condiciones descritas.

Consulta el caso técnico oficial de Fortinet sobre IKEv2 y NAT-T.

11. ¿Y si la VPN no consigue establecerse?

Si el problema no es el acceso a recursos, sino que el túnel ni siquiera se establece, debemos cambiar el enfoque.

Para investigar la negociación IKE, Fortinet documenta el siguiente diagnóstico:

diagnose debug application ike -1
diagnose debug enable

Para detenerlo:

diagnose debug disable
diagnose debug reset

En equipos con múltiples túneles, aplica filtros de IKE adecuados a tu versión de FortiOS antes de activar el diagnóstico para limitar el volumen de salida.

Comprueba compatibilidad entre propuestas criptográficas, autenticación, certificados, identidades, métodos EAP y versión de IKE.

Hay otra consideración importante: FortiClient 7.4.4 y posteriores ya no admiten IPsec IKEv1, por lo que debes validar el uso de IKEv2 al planificar los clientes compatibles.

12. Caso práctico ilustrativo: conectado a la VPN, pero sin acceso al ERP

Imaginemos una empresa con las siguientes características:

Firewall FortiGate con acceso remoto IPsec IKEv2.
Usuarios conectados desde Windows mediante FortiClient.
Aplicación empresarial en 10.30.0.25.
Red de usuarios remotos asignada por el gateway VPN.
Split tunneling habilitado.

Síntoma: el túnel aparece conectado, pero el ERP no abre.

Secuencia de investigación:

Confirmar las asociaciones IKE e IPsec con los comandos de diagnóstico.
Verificar en Windows si existe una ruta hacia 10.30.0.0/24.
Realizar una prueba TCP hacia la IP y el puerto real del ERP.
Confirmar que exista una política VPN–LAN que permita dicho tráfico.
Ejecutar debug flow para observar la decisión del firewall.
Validar que el servidor tenga una ruta de retorno hacia la red VPN.
Comprobar la resolución DNS si el acceso por IP funciona.

Hipótesis ilustrativa: la configuración de split tunneling incluye la red 10.20.0.0/24, pero omite la 10.30.0.0/24. En este caso, la VPN puede funcionar correctamente y el problema estar en la distribución de rutas hacia los clientes.

Este es un ejemplo de laboratorio conceptual, no el resultado de una intervención real realizada por SISTRO. Debe validarse en cada entorno antes de modificar configuraciones.

13. Matriz rápida para identificar la causa

IKE no establece: gateway, conectividad, autenticación, certificados o parámetros IKE.
IKE establece, pero IPsec no: revisar Phase 2, propuestas y selectores aplicables.
IPsec establece, pero no hay tráfico: rutas, políticas, NAT-T, retorno y filtrado.
Funciona por IP, pero no por nombre: DNS, sufijos y acceso a resolvedores.
Una subred funciona y otra no: split tunneling, rutas y reglas específicas.
Un servicio funciona y otro falla: puerto, política, servicio o firewall del servidor.
Solo falla desde determinadas ubicaciones: NAT, transporte, rutas locales y restricciones de la red.

14. Checklist de diagnóstico para administradores

☐ Modelo exacto de FortiGate.
☐ Versión y compilación de FortiOS.
☐ Versión de FortiClient y sistema operativo.
☐ Método de autenticación y versión IKE.
☐ Estado de IKE y Phase 2.
☐ Dirección asignada al cliente remoto.
☐ Direcciones y rutas recibidas por el endpoint.
☐ Configuración split tunnel o full tunnel.
☐ Políticas VPN–LAN y servicios autorizados.
☐ Ruta de retorno hacia la red VPN.
☐ DNS corporativo y resolución de nombres.
☐ NAT-T y transporte negociado.
☐ Registros y contadores de tráfico.
☐ Pruebas TCP hacia aplicaciones críticas.
☐ Capturas y evidencias antes de modificar la configuración.

15. ¿Cómo evitar estos problemas durante una migración de SSL VPN a IPsec?

La prevención comienza antes de actualizar FortiOS. Desde FortiOS 7.6.3, Fortinet eliminó SSL VPN tunnel mode, por lo que las empresas que utilizaban este método deben revisar su transición a IPsec.

En nuestra guía anterior explicamos el cambio, las diferencias entre tecnologías y cómo planificar la migración.

Lee también: FortiGate SSL VPN desaparece en FortiOS 7.6.3 — cómo migrar a IPsec.

Una migración no debe validarse únicamente comprobando que el usuario puede conectarse. También es necesario probar aplicaciones internas, DNS, acceso a diferentes subredes, autenticación, conexiones desde redes externas y escenarios de recuperación.

16. Firewalls, licencias y asesoría Fortinet en México

Si tu empresa necesita renovar un firewall, revisar su versión de FortiOS, implementar acceso remoto IPsec o evaluar una nueva arquitectura de seguridad, SISTRO puede ayudarte con la selección de equipos y servicios.

La recomendación es evaluar el modelo, la versión instalada, las necesidades de acceso remoto, el número de usuarios, las aplicaciones críticas y los requisitos de disponibilidad antes de contratar equipo o servicios.

17. Preguntas frecuentes

¿Por qué FortiClient dice conectado, pero no tengo internet o acceso a servidores?

Porque el establecimiento del túnel no garantiza rutas, políticas, DNS o conectividad hacia las aplicaciones. Primero hay que determinar si el problema afecta toda la conectividad o únicamente destinos específicos.

¿Qué comando muestra los túneles IPsec activos en FortiGate?

Puedes utilizar get vpn ipsec tunnel summary, diagnose vpn ike gateway list y diagnose vpn tunnel list para consultar diferentes aspectos del estado IPsec.

¿Qué significa que Phase 1 esté establecida y Phase 2 no?

Significa que la asociación IKE y las asociaciones utilizadas para transportar tráfico no están en el mismo estado. Es necesario revisar negociación, parámetros, selectores y si existe tráfico que deba activar el túnel.

¿Cómo saber si el problema es DNS?

Compara una prueba hacia la dirección IP interna con otra hacia el nombre del servidor. Si el servicio responde por IP, pero el nombre no resuelve correctamente, investiga DNS.

¿Qué es NAT-T en IPsec?

Es el mecanismo de NAT Traversal para transportar tráfico IPsec cuando intervienen dispositivos que realizan traducción de direcciones. Su configuración debe revisarse según el diseño y el comportamiento observado.

¿Debo permitir todo el tráfico para corregir la VPN?

No. Lo correcto es identificar interfaces, redes y servicios necesarios, y autorizar únicamente el acceso requerido con políticas documentadas.

¿Este procedimiento aplica a FortiOS 7.4 y 7.6?

Gran parte de la metodología sí, pero las opciones concretas de CLI, características disponibles y compatibilidad de FortiClient dependen de la versión. Consulta siempre la documentación correspondiente a tu compilación.

18. Documentación técnica de referencia

Conclusión: diagnostica cada capa antes de cambiar la configuración

Una conexión IPsec puede aparecer activa mientras el acceso a aplicaciones corporativas continúa fallando. El método más efectivo consiste en separar negociación, direccionamiento, rutas, políticas, retorno de tráfico, DNS y disponibilidad del servicio.

La secuencia recomendada es: estado del túnel → rutas → conectividad IP → políticas → flujo de paquetes → DNS y aplicaciones.

En SISTRO creemos que la seguridad empresarial no termina con la compra del firewall. Una implementación correctamente diseñada, documentada y validada es tan importante como el equipo seleccionado.

Conoce las soluciones Fortinet disponibles en SISTRO.NET y continúa consultando nuestras guías en la Biblioteca Virtual SISTRO 2.0.