Hola a todos, he tenido un problema frustrante en una VPN S2S IKEv2 desde nuestro ASA hasta el Checkpoint del cliente y me preguntaba si alguien ha encounterado algo similar.
Básicamente, ambos lados pueden establecer el túnel con tráfico interesante donde ambas fases negocian con éxito; sin embargo, cuando se establece desde el lado del ASA, el túnel es inestable; sólo parece haber tráfico unidireccional (ver bytes transmitidos pero no recibidos) - los pings TCP desde el ASA se agotan, y luego el túnel se deshace después de un par de minutos con mensajes de registro que simplemente dicen ‘razón: peer lost’. Cuando el túnel se inicia desde el lado del Checkpoint, sin embargo, el túnel se establece y no hay problemas - podemos hacer pings TCP exitosos desde el ASA y el túnel no se deshace.
Durante la resolución de problemas, el ingeniero del lado del Checkpoint confirmó que el túnel se establece con ambas fases negociadas correctamente cuando se inicia desde el ASA, y luego dijo que veía que el túnel se deshacía debido a DPD en el ASA (aparentemente han deshabilitado DPD en el Checkpoint).
Por ello, he deshabilitado DPD para este túnel (estableciendo el Timeout de Inactividad en la política de grupo del túnel a Ilimitado -Creo que esto deshabilita DPD, ¿correcto?) pero todavía veo los mismos problemas al iniciar el túnel desde el ASA.
Q1: Después del cambio, veo en los registros - “Local: x.x.x.x:4500 Remoto: x.x.x.x:4500 Usuario: x.x.x.x Necesito enviar un mensaje DPD al peer” → ¿esto significa que el ASA ha recibido un mensaje R-U-There y necesita responder o que el ASA está enviando mensajes R-U-There al Checkpoint y necesita una respuesta?
Q2: Una diferencia que he notado es que cuando el túnel se inicia desde el Checkpoint, el SA del túnel aparece como “IKEv2 IPsecOverNatT”, mientras que cuando se inicia desde el ASA, el SA aparece simplemente como “IKEv2 IPsec”. Creo que esto es el mayor indicador del problema, pero no puedo entender por qué causaría un problema cuando NAT-T está habilitado en el ASA y presumiblemente también en el Checkpoint si los túneles iniciados desde allí negocian con un SA ipsecovernatt. ¿Alguien tiene experiencia previa con una situación similar a esta?
EDIT:
Creo que finalmente lo he resuelto, deshabilitar DPD evitó que el túnel se destruyera tan rápidamente después de iniciarse, pero el túnel parecía estar atascado y sin poder alcanzar las subredes en el dominio de cifrado remoto (muchos paquetes UDP:4500 descartados en los registros), simplemente deshabilité NAT-Traversal para este túnel en el ASA y ¡boom!, puedo establecer el túnel con pings TCP exitosos.
Para estar seguro de que el problema está resuelto, necesitaré que el cliente intente iniciar el túnel desde su lado, ya que puede ser que sólo puedan hacerlo desde su lado usando NAT-T (potencialmente algún PAT/NAT extraño en su lado que no me dijeron).
Gracias por las sugerencias y aportes.
Edit2: El cliente probó y ahora se puede establecer el túnel en estado de funcionamiento desde ambos lados, trabajo hecho 