Fallos en tráfico VPN después de balanceo de línea

Para temas sobre las VPN, incluyendo la configuración, resolución de problemas e interoperabilidad.
Responder
SSL
Mensajes: 8
Registrado: 30 Ago 2021, 10:20

Fallos en tráfico VPN después de balanceo de línea

Mensaje por SSL »

Hola,

Tengo varia dudas en cuanto a como resolver un problema.
Tenemos un FortiGate modelo 200E en la versión 6.0.5.
Conectado al puerto 13 del equipo penden 3 VPN IPSEC..hasta aquí todo bien, un proveedor de línea ha instalado un dispositivo que hace un balanceo de líneas.
El P13 del FW conecta con un dispositivo del proveedor que sale a internet a través de una fibra y tiene como backup un router 4G.
Cuando la línea de fibra cae levanta la conectividad a través del 4G y aquí es cuando viene el problema.
cuando levanta el 4G las VPN siguen levantadas, pero el tráfico que pasa a través de ellas deja de fluir.
Si volvemos a la fibra el tráfico inter-vpn no se encauza, solo se soluciona reiniciando el FW.

No se si la raiz del problema se encuentra en el FW o en el dispositivo del proveedor,pero sea lo que sea tengo que probar y solucionar lo que pasa.

Estoy intentando hacer un debug del trafico para ver si saco información pero por el momento no tengo nada.
Tengo entendido que refrescando las tablas MAC del FW podría recuperar la conectividad una vez levantado el 4G,lo intentaré,pero no me parece una solución sólida.

Adjunto una imagen por si pudiera aportar algo de luz

Gracias y Saludos!
I.
No tiene los permisos requeridos para ver los archivos adjuntos a este mensaje.
AndresW
Mensajes: 452
Registrado: 09 Jun 2014, 17:05

Re: Fallos en tráfico VPN después de balanceo de línea

Mensaje por AndresW »

Hola,

La verdad es que sin tener mayores antecedentes o un debug que sea preciso, atribuiría tu problema a que cuando se produce el failover entre la fibra y el 4G los endpoints de las 3 VPN dejan de reconocer la IP pública de este último, y obviamente los túneles no van a renegociar correctamente, y si bien los sigues viendo arriba por un tiempo, esto se debe a que los SA aún no caducan.

La razón de por qué al levantar la fibra no vuelven a su estado normal es justamente por que los lifetimes de negociación no se han completado, y al reiniciar el FG todo el proceso comienza de 0.

Esto lo puedes validar antes de reiniciarlo haciendo un reset a las VPN y luego pasando tráfico hacia los otros extremos:

diag vpn tunnel reset

Y para estar completamente seguro de que la causa raíz de tu problema es la hipótesis que planteo más arriba, corre un debug al IKE cuando estés haciendo uso del 4G:

diag debug app ike -1
diag debug enable

Con la información que esto te entregue sabrás específicamente por qué los túneles no se restablecen.

Ahora una solución podría ser que validaras con la gente de las 3 VPN si permiten establecerlas con IP dinámicas, así no importará si estás utilizando la fibra o el 4G. No obstante deberás realizar algunos ajustes localmente para que esto opere.

Sinceramente no veo que el problema pase por la tabla ARP del firewall puesto que el equipo del proveedor no cambia y la interfaz vinculada al puerto 13 de tu FortiGate sigue siendo la misma.

Mientras tanto revisa los puntos que te sugerí, y si tienes más dudas a través de Telegram podríamos ayudarte entre todos.
Saludos!

_____________________________________________________________

Grupo de Telegram referente a FortiGate --> https://t.me/FortiGate_es
SSL
Mensajes: 8
Registrado: 30 Ago 2021, 10:20

Re: Fallos en tráfico VPN después de balanceo de línea

Mensaje por SSL »

Hola AndresW,

Muchas gracias por tu tiempo, la verdad que lo que me comentas tiene buena pinta.
No me queda muy claro lo de pasar el tráfico hacia los otros extremos antes de reiniciar el túnel, a que te refieres?

La solución de configurar los túneles a través de IPs dinámicas es no es nada mala, lo probaré si tengo el OK de los otros extremos.

Gracias y Saludos,
I.
AndresW
Mensajes: 452
Registrado: 09 Jun 2014, 17:05

Re: Fallos en tráfico VPN después de balanceo de línea

Mensaje por AndresW »

Me refería a que hicieras la siguiente prueba:

1.- Simular la caída de la fibra para que el tráfico conmute a través del 4G.

2.- Como ya sabemos que las VPN no se restablecen automáticamente, y pierdes la conectividad, levanta nuevamente la fibra. (El equipo del proveedor debiera ser lo suficientemente inteligente como para volver a enrutar todo por ese enlace).

3.- Aún las VPN, incluso con la fibra operativa no levantan, SIN reiniciar el FortiGate ejecuta el siguiente comando para forzar la bajada y subida de todos los túneles.

diag vpn tunnel reset

4.- Espera unos 10 segundos y prueba con algún ping o bien otro servicio que esté del otro lado de alguna de las VPN.
SSL escribió: 08 Oct 2021, 15:06 Hola AndresW,

Muchas gracias por tu tiempo, la verdad que lo que me comentas tiene buena pinta.
No me queda muy claro lo de pasar el tráfico hacia los otros extremos antes de reiniciar el túnel, a que te
Saludos!

_____________________________________________________________

Grupo de Telegram referente a FortiGate --> https://t.me/FortiGate_es
AndresW
Mensajes: 452
Registrado: 09 Jun 2014, 17:05

Re: Fallos en tráfico VPN después de balanceo de línea

Mensaje por AndresW »

Olvidé comentarte respecto a cómo lograr que los túneles levanten con IP dinámica. Básicamente necesitas habilitar el servicio de DDNS en tu FG, que si tienes una suscripción a FortiGuard activa, puedes utilizar esa o bien de algún tercero como DynDNS o similar, pero te recomiendo la primera.

La idea es que a tus 3 peers como tu extremo para establecer la VPN le entregues el FQDN que te asigne el DDNS en vez de la IP pública, de esta manera da igual si estás utilizando la fibra o la conexión de respaldo móvil.

Te dejo un documento donde se explica como configurar lo antes mencionado:

[Debes identificarte para poder ver enlaces.]

En tu versión de FoS no debiera ser distinto el procedimiento.
Saludos!

_____________________________________________________________

Grupo de Telegram referente a FortiGate --> https://t.me/FortiGate_es
SSL
Mensajes: 8
Registrado: 30 Ago 2021, 10:20

Re: Fallos en tráfico VPN después de balanceo de línea

Mensaje por SSL »

Hola AndresW,

Probaré a activar el DDNS en la interfaz del extremo contrario (al que apuntamos en nuestra VPN)
De esta interfaz penden unas cuantas VPN, entiendo que seguirán funcionando por IP y podré atacar a la VPN que me interesa a través de FQDN?
Esta acción requiere un reinicio de interfaz o reinicio de las VPNs dependientes de esta?

Gracias y Saludos!
I.
AndresW
Mensajes: 452
Registrado: 09 Jun 2014, 17:05

Re: Fallos en tráfico VPN después de balanceo de línea

Mensaje por AndresW »

El DDNS debes activarlo en el FortiGate, no en los endpoints.
Saludos!

_____________________________________________________________

Grupo de Telegram referente a FortiGate --> https://t.me/FortiGate_es
SSL
Mensajes: 8
Registrado: 30 Ago 2021, 10:20

Re: Fallos en tráfico VPN después de balanceo de línea

Mensaje por SSL »

Hola!

Estuve haciendo las pruebas de conmutación y el resultado de estas me hace pensar que la raíz del problema se encuentra en la LAN en vez de la VPN o la conmutación de líneas del dispositivo de salida a internet conectado "delante" del FW.

Desconecté el puerto de fibra de salida principal y el equipo conmutó a la salida 4G.

Comprobé como el tráfico desde una IP de la LAN (10.240.4.1) llegaba por ping al servidor ubicado detrás de la VPN.


JMA200E_FW1 # diag sniffer packet any "host 10.240.4.1 and icmp" 4 0 a
interfaces=[any]
filters=[host 10.240.4.1 and icmp]
2021-10-13 10:14:28.966158 port5 in 10.240.4.1 -> *IP no mostrada por seguridad*: icmp: echo request
2021-10-13 10:14:28.966170 LKS-DC-1 out 10.240.4.1 -> *IP no mostrada por seguridad*: icmp: echo request
2021-10-13 10:14:29.037910 LKS-DC-1 in *IP no mostrada por seguridad* -> 10.240.4.1: icmp: echo reply
2021-10-13 10:14:29.037922 port5 out *IP no mostrada por seguridad* -> 10.240.4.1: icmp: echo reply
2021-10-13 10:14:29.465810 LKS-DC-1 in *IP no mostrada por seguridad* -> 10.240.4.1: icmp: echo request
2021-10-13 10:14:29.465823 port5 out *IP no mostrada por seguridad* -> 10.240.4.1: icmp: echo request
2021-10-13 10:14:29.466039 port5 in 10.240.4.1 -> *IP no mostrada por seguridad*: icmp: echo reply
2021-10-13 10:14:29.466051 LKS-DC-1 out 10.240.4.1 -> *IP no mostrada por seguridad*: icmp: echo reply


Mediante la salida 4G tratamos de acceder via web al *IP no mostrada por seguridad* desde la IP 172.20.15.3 ubicada en la red LAN (detrás del puerto1 del FW)
Vemos como el tráfico llega pero la pantalla no muestra contenido,mientras que a través de la fibra si lo hacía
Hacemos un seguimiento del tráfico de los paquetes y observamos como este es enrutado a través de la VPN del FW al destino y este vuelve para ser dirigido a través del puerto 1 de vuelta a la 172.20.15.3

⇒ Debug flow for traffic from PC 172.20.15.3 destined to *IP no mostrada por seguridad* on port 80:

JMA200E_FW1 # id=20085 trace_id=1786 func=print_pkt_detail line=5494 msg="vd-root:0 received a packet(proto=6, 172.20.15.3:1033->*IP no mostrada por seguridad*:80) from port1. flag [S], seq 3748937589, ack 0, win 64240"
id=20085 trace_id=1786 func=init_ip_session_common line=5654 msg="allocate a new session-5940a32c"
id=20085 trace_id=1786 func=vf_ip_route_input_common line=2591 msg="find a route: flag=04000000 gw-*IP no mostrada por seguridad* via LKS-DC-1"
id=20085 trace_id=1786 func=fw_forward_handler line=751 msg="Allowed by Policy-80: SNAT"
id=20085 trace_id=1786 func=__ip_session_run_tuple line=3322 msg="SNAT 172.20.15.3->10.240.0.200:61449"
id=20085 trace_id=1786 func=ipsecdev_hard_start_xmit line=692 msg="enter IPsec interface-LKS-DC-1"
id=20085 trace_id=1786 func=esp_output4 line=897 msg="IPsec encrypt/auth"
id=20085 trace_id=1786 func=ipsec_output_finish line=532 msg="send to 91.200.117.209 via intf-port13"
id=20085 trace_id=1787 func=print_pkt_detail line=5494 msg="vd-root:0 received a packet(proto=6, *IP no mostrada por seguridad*:80->10.240.0.200:61449) from LKS-DC-1. flag [S.], seq 2632781985, ack 3748937590, win 8192"
id=20085 trace_id=1787 func=resolve_ip_tuple_fast line=5569 msg="Find an existing session, id-5940a32c, reply direction"
id=20085 trace_id=1787 func=__ip_session_run_tuple line=3336 msg="DNAT 10.240.0.200:61449->172.20.15.3:1033"
id=20085 trace_id=1787 func=vf_ip_route_input_common line=2591 msg="find a route: flag=04000000 gw-172.20.15.3 via port1"

Desde un PC de fuera de la LAN se pudieron llevar a cabo los servicios que no podían hacerse desde la LAN (no entiendo bien entonces porque usan una VPN contra la IP pública)
Cuando se volvió a conectar la fibra principal estos servicios ya fueron de nuevo accesibles desde dentro de la LAN.

Según las pruebas llevadas a cabo el miércoles todo indica que el problema con los paquetes de retorno debe estar detrás del puerto 1 del FW, ahora debemos verificar la configuración de todos los dispositivos entre la 172.20.15.3 y el puerto1 de este ...

P.D; Esta LAN no tiene segmentación por medio de VLANes y todas las IPs de los equipos son fijas configuradas manualmente....puede que el problema sea este, que el tráfico se pierda aquí.

Creo que con esto puedo descartar que el problema esté en el balanceo o en el FW....ahora no sé que es peor :|


Saludos,
I.
Responder