Cliente MikroTik IPsec Fortigate 'Paquete ESP recibido con SPI desconocido'.

Question

Tenemos un cliente con 6 sitios que usan IPsec. De vez en cuando, posiblemente una vez a la semana, a veces una vez al mes, los datos simplemente dejan de fluir desde el servidor VPN remoto de Fortigate al cliente VPN IPsec local de MikroTik.

Para demostrar los síntomas del problema, adjunto un diagrama. En la pestaña SA instaladas del diagrama, verá una dirección IP de origen xx186.50 intentando comunicarse con xx7.3 pero con 0 bytes actuales. xx186.50 es el servidor Fortigate IPsec remoto del cliente y xx7.73 es un punto final IPsec basado en MikroTik. Parece que los datos que nos llegan desde el lado remoto no siempre fluyen.

Las fases 1 y 2 siempre están establecidas pero el tráfico siempre se niega a fluir desde el lado remoto hacia nosotros.

Intentamos varias cosas a lo largo del tiempo, como reiniciar, configurar relojes, incursionar en la configuración, volver a verificar y verificar la configuración, pero parece que el problema es completamente aleatorio. Y a veces cosas al azar lo solucionan. En un momento tuve la teoría de que si el túnel se inicia desde su lado funciona, pero jugar con "Enviar contacto inicial" no ha hecho ninguna diferencia.

Hemos tenido muchas conversaciones con el cliente sobre esto, pero tienen muchas más VPN IPsec internacionales y solo nuestra configuración de MikroTik está fallando.

Fortigar registro:

http://kb.fortinet.com/kb/microsites/microsite.do?cmd=displayKC&externalId=11654

Al observar la base de conocimientos de Fortigate, parece que los SPI no están de acuerdo y DPD marcaría la diferencia. Pero he probado todas y cada una de las combinaciones de DPD de este lado sin éxito. Me gustaría habilitar DPD en el otro lado, pero no puedo debido al control de cambios y también porque el cliente dice que está funcionando en todos los demás sitios con la misma configuración.EDITAR DPD estaba habilitado

Diagrama del cliente VPN local que no muestra flujo de tráfico:

He incluido un archivo de registro que muestra bucles continuos del archivo de registro de MikroTik "recibí un RU-THERE válido, ACK enviado":

eco: ipsec, depuración, paquete de 84 bytes de xx7.183[500] a xx186.50[500]

eco: ipsec, depuración, nombre de calcetín del paquete xx7.183 [500]

echo: ipsec, depuración, envío de paquetes desde xx7.183[500]

eco: ipsec, depuración, paquete envía paquete a xx186.50 [500]

eco: ipsec, depuración, paquete src4 xx7.183 [500]

eco: ipsec, depuración, paquete dst4 xx186.50[500]

echo: ipsec,debug,paquete 1 vez, el mensaje de 84 bytes se enviará a xx186.50[500]

eco: ipsec, depuración, paquete 62dcfc38 78ca950b 119e7a34 83711b25 08100501 bc29fe11 00000054 fa115faf

eco: ipsec, depuración, paquete cd5023fe f8e261f5 ef8c0231 038144a1 b859c80b 456c8e1a 075f6be3 53ec3979

eco: ipsec, depuración, paquete 6526e5a0 7bdb1c58 e5714988 471da760 2e644cf8

echo: ipsec, depuración, envío de paquetes a notificación de información.

echo: ipsec, depuración, el paquete recibió un RU-THERE válido, ACK enviado

He recibido varias sugerencias de expertos en IPsec y del propio MikroTik, insinuando que el problema está en el lado remoto. Sin embargo, la situación se complica enormemente porque otros cinco sitios están funcionando y el firewall del cliente está bajo control de cambios. La configuración también funcionó siempre durante muchos años, por lo que afirman que no puede ser un error de configuración de su parte. Esta sugerencia parece plausible pero no puedo implementarla debido al control de cambios. Sólo puedo cambiar el lado del cliente:

Asegúrese de que el respondedor IPSec tenga configurado pasiva=yes y send-initial-contact=no.

Esto no funcionó.

EDITAR 9 de diciembre de 2013

Estoy pegando capturas de pantalla adicionales con la configuración de Fortigate y lo que creemos que son los selectores de modo rápido en el lado de Mikrotik.

Permítanme reiterar que no creo que sea un problema de configuración. Supongo que es un problema de sincronización por el cual el lado A o el lado B intentan enviar información de manera demasiado agresiva, lo que hace que la negociación de la información (por ejemplo, el SPI) no esté sincronizada.

EDITAR 11 de diciembre de 2013

Lamentablemente tengo que renunciar a este tema. Felizmente todo está funcionando. Por qué funciona sigue siendo un misterio, pero para ilustrar mejor lo que hicimos, publiqué otra imagen en línea.

Lo arreglamos por:

1. Desactivando PPPoE en el cliente.
2. Instalando un enrutador completamente nuevo (Router B) y probado en Border. Funcionó en Border.
3. Apagar el nuevo enrutador B en la frontera. Y LUEGO, SIN HACER UN ÚNICO CAMBIO, el enrutador A del punto final del cliente comenzó a funcionar. Entonces, simplemente agregar un enrutador duplicado en el borde y desconectarlo nuevamente hizo que el enrutador original funcionara.

Así que agregue esta solución a la lista de cosas que hemos hecho:

1. Reiniciar. Eso funcionó una vez.
2. Crea un nuevo túnel con una nueva IP. Eso funcionó una vez pero sólo una vez. Después de cambiar la IP, el punto final del cliente volvió a estar activo.
3. Cambiar servidores de tiempo.
4. Juega con todos los entornos posibles.
5. Esperar. Una vez, después de un día, todo salió bien. Esta vez, incluso después de días, nada salió bien.

Así que postulo que hay una incompatibilidad tanto en Fortigate como en MikroTik que sólo ocurre en situaciones muy aleatorias. Lo único que no hemos podido probar es actualizar el firmware en Fortigate. Tal vez haya un valor de configuración corrupto oculto o un problema de sincronización invisible para el configurador.

Además, especulo que el problema se debe a problemas de sincronización que provocan una discrepancia en el SPI. Y supongo que Fortigate no quiere "olvidarse" del antiguo SPI, como si el DPD no estuviera funcionando. Simplemente sucede de forma aleatoria y, por lo que puedo decir, solo cuando el punto final A es Fortigate y el punto final B es MikroTik. Los constantes intentos agresivos de restablecer la conexión "se aferran" a los antiguos valores del SPI.

Lo agregaré a esta publicación cuando vuelva a suceder.

EDITAR 12 de diciembre de 2013

Como era de esperar, volvió a suceder. Como recordará, tenemos configurados 6 enrutadores de punto final IPsec del cliente MikroTikexactamente lo mismoconectándose a un servidor Fortigate. El último incidente se produjo nuevamente en un enrutador aleatorio, no en el que publiqué aquí originalmente. Teniendo en cuenta la última solución en la que instalamos este enrutador duplicado, tomé este atajo:

1. Deshabilite el enrutador A, el enrutador que ya no desea recibir paquetes de Fortigate.
2. Copie la configuración IPsec del enrutador A a un enrutador temporal más cercano al borde de nuestra red.
3. Deshabilite inmediatamente la configuración recién creada.
4. Vuelva a habilitar el enrutador A.
5. Automáticamente simplemente comienza a funcionar.

Al mirar el comentario de @mbrownnyc, creo que estamos teniendo un problema con Fortigate al no olvidar los SPI obsoletos a pesar de que DPD está activado. Investigaré el firmware de nuestro cliente y lo publicaré.

Aquí hay un diagrama nuevo, muy parecido al anterior, pero que solo muestra mi "solución":

Answer 1

Puede que no sea la causa de su problema, pero puede ser información útil para otros usuarios. Tuvimos un problema ligeramente similar con una VPN entre Mikrotik y Sonicwall. El tráfico se detendría aleatoriamente, lo que requeriría que se purgaran las SA.

Al final, nos dimos cuenta de que Sonicwall estaba creando una SA separada para cada política de red (según el aspecto de su captura de pantalla, parece que tiene 2 políticas/subredes a través de la VPN). No sé si esta configuración de 'SA por política' está codificada o es configurable, ya que no tenía acceso a Sonicwall.

Nuestro Mikrotik estaba usando el nivel 'requerido' para las políticas (el valor predeterminado y que se ve en su captura de pantalla). Esto hace que el enrutador cree una única SA con el par remoto. Al enviar tráfico para cualquiera de las políticas para ese par, utilizará esta misma SA, independientemente de la subred src/dest.

Básicamente, esto significaba que funcionaba siempre que solo usáramos una subred. Tan pronto como nuestro Mikrotik intentara enviar tráfico para la segunda subred, lo enviaría a través de la SA existente (que en lo que respecta a Sonicwall es para un par de subred específico), Sonicwall se quejaría, los números de secuencia de SA saldrían de Golpe y todo se detuvo. (En nuestro caso, el cliente recibió errores de "repetición" por su parte)

Al final, fue tan simple como cambiar el Nivel de política a "único", de modo que ambos extremos utilizaron una SA única para cada par de subred único. Los túneles quedaron perfectamente felices después de eso.

Answer 2

Sé que has verificado esto (tal como lo hice yo cuando tuve un problema intermitente similar, pero completamente diferente), pero asegúrate de no tener una dirección IP duplicada que comparta el enrutador A. Esto le daría un problema intermitente cuando su enrutador del lado alto realiza una búsqueda arp para el enrutador A y se confunde. Se podría pensar que dup Ips en los enrutadores daría un error constante, pero no es así.