Cómo resolver el error de tráfico IPsec VPN site to site denegado por la política de verificación en Fortinet

En entornos de redes, es fundamental garantizar el tráfico bidireccional a través de túneles VPN IPsec entre dispositivos FortiGate. Este artículo abordará un problema común: la falta de tráfico de retorno de un fortiGate después de establecer un túnel VPN. A través de este artículo, se proporcionarán pasos para diagnosticar y resolver este problema, asegurando una comunicación fluida entre los dispositivos FortiGate.

Descripción del problema

Este artículo describe que en una VPN Site-to-Site o Dial-Up VPN de IPsec, se presenta tráfico unidireccional, donde no se recibe tráfico de retorno desde FortiGate a otros firewalls FortiGate.

Alcance

Este artículo aplica a dispositivos FortiGate.

Diagnóstico paso a paso

Topología:

Servidor Local ——–FortiGate-1——-Túnel IPSEC—–FortiGate-2—-Servidor Remoto.

La configuración se detalla en el siguiente artículo: Cómo configurar VPN Site to Site entre FortiGates (Usando el asistente de configuración de VPN).

Una vez hecha la configuración, si los túneles están operativos pero el tráfico no se envía de FortiGate-1 a FortiGate-2, siga estos pasos:

Realice un seguimiento del tráfico con los siguientes comandos:

diagnose sniffer packet any » host x.x.x.x and host y.y.y.y» 6 0 l

x.x.x.x —> Dirección IP de origen.

y.y.y.y —> Dirección IP de destino.

Si se recibe tráfico desde el extremo del servidor pero no se envía a través de la ‘Interfaz de túnel’, obtenga los registros de depuración con el siguiente comando:

diagnose reset

diagnose debug flow filter saddr x.x.x.x ——-> Dirección IP de origen.

diagnose debug flow filter daddr y.y.y.y ——-> Dirección IP de destino.

diagnose debug flow show function-name enable

diagnose debug flow show iprope enable

diagnose debug console timestamp enable

Artículos relacionados  Cómo configurar los ajustes de correo electrónico de alerta

diagnose debug flow trace start 999 ——-> Número de paquetes capturados.

diagnose debug enable

Después de 5 o 6 segundos, desactive la depuración con el siguiente comando:

diagnose debug disable

Los errores de depuración suelen aparecer como ‘denegado por la política de verificación de reenvío o Política ID 0’.

Solución recomendada

Verifique la política del firewall y configure las siguientes reglas:

Póliza del túnel IPsec hacia la LAN -> Establecer Origen y Destino en ‘Todos’.

Póliza de la LAN hacia el túnel IPsec -> Establecer Origen y Destino en ‘Todos’.

Asegúrese de que los horarios y servicios bajo las políticas de firewall en ambos firewalls estén correctamente configurados según los requisitos.

Verifique nuevamente, el tráfico bidireccional debería fluir desde FortiGate-1 hacia FortiGate-2.

Comandos CLI utilizados
  • diagnose sniffer packet any » host x.x.x.x and host y.y.y.y» 6 0 l
  • diagnose reset
  • diagnose debug flow filter saddr x.x.x.x
  • diagnose debug flow filter daddr y.y.y.y
  • diagnose debug flow show function-name enable
  • diagnose debug flow show iprope enable
  • diagnose debug console timestamp enable
  • diagnose debug flow trace start 999
  • diagnose debug enable
  • diagnose debug disable
Buenas prácticas y recomendaciones
  • Es útil verificar otro FortiGate-2 siguiendo los mismos pasos de solución de problemas.
  • Si la dirección IP sigue sin ser accesible, intente habilitar NAT de origen desde la ‘Política de túnel hacia LAN’. Esto puede permitir que la dirección IP sea accesible.
  • El habilitar SNAT es solo una solución temporal en caso de que no exista una ruta inversa desde el destino; esto debería ser solucionado por el dispositivo intermedio entre FortiGate y el PC de la LAN.
Artículos relacionados  Cómo resolver problemas de configuración de la política de Traffic Shaping con categoría de aplicación, filtro de URL y ISDB en Fortinet

Asegúrese de que no haya ACL configuradas en el switch que impidan recibir tráfico de una fuente o servicio particular.

Si no se trata de un problema de FortiGate, solicite al usuario que verifique en la subred local si el tráfico de redirección no está permitido.

Si las direcciones IP de origen de los paquetes provenientes del túnel IPsec no forman parte de una red que los dispositivos LAN puedan encaminar correctamente, es posible que no respondan adecuadamente. Al habilitar SNAT, la dirección de origen se traduce a una dirección dentro de la LAN, asegurando que los dispositivos LAN vean el tráfico como proveniente de su propia subred.

Una vez que el usuario permita el tráfico de la subred local, debería funcionar sin problemas.

¿Te ha resultado útil??

0 / 0

Deja una respuesta 0

Your email address will not be published. Required fields are marked *