Cloud VPN hacia Cisco ASA: reconstruir tras una discrepancia de propuesta

NEGOTIATION_FAILURE en un túnel de Cloud VPN con un Cisco ASA al otro lado es casi siempre una discrepancia de propuesta o de selectores, y el primer dato útil es que ninguna edición lo va a arreglar. Cloud VPN fija la propuesta IKE cuando se crea el objeto de túnel. No hay campo para cambiar un algoritmo en el sitio, así que la reparación consiste en borrar y volver a crear con un punto de partida anotado. Trátalo como una reconstrucción y el trabajo se convierte en una lista de comprobación en lugar de una tarde de conjeturas.

Lee el fallo antes de borrar nada

Un fallo de negociación es un problema de fase, y el registro del par suele nombrar la fase. Que falle la fase 1 significa que los extremos no se pusieron de acuerdo en una propuesta o no pudieron autenticarse entre sí. Que falle la fase 2 significa que el túnel subió y los selectores protegidos no coincidían. Son reparaciones distintas, y merece la pena extraer la línea del registro antes de que alguien toque una configuración.

El fallo también descarta cosas. No es una ruta de VPC, ni una regla de cortafuegos en la interfaz del túnel, ni un fallo de resolución de nombres dentro de la red. Perseguir esas pistas produce cambios seguros de sí mismos que no pueden alterar el resultado, y hacen más difícil atribuir el arreglo final.

Captura ambas configuraciones mientras aún existan

Borrar un túnel lleva medio minuto y destruye la única prueba que tenías. Antes, anota los selectores local y remoto, la dirección del par, quién tiene el secreto compartido y el crypto map o el perfil IKEv2 del ASA. El ASA responde a dos preguntas separadas: qué está configurado y qué está levantado ahora:

show running-config crypto ikev2
show crypto ikev2 sa
show crypto ipsec sa | include local ident|remote ident|status

En el lado de Google, lee el objeto de túnel en lugar del resumen de la consola, porque la dirección del par y los campos de selector son los valores que debes reproducir exactamente:

gcloud compute vpn-tunnels describe tunnel-to-asa --region europe-west1 \
  --format="yaml(peerIp,localTrafficSelector,remoteTrafficSelector,ikeVersion,sharedSecret)"

Pon esos valores en el ticket antes del primer borrado. La reconstrucción de abajo solo funciona porque puedes volver a crear el mismo objeto con una diferencia deliberada.

Los algoritmos que un lado se niega a negociar

Cloud VPN no elige de un abanico de algoritmos IKEv1 como hace un par tradicional. Los ajustes de par que espera son fijos: aes-cbc-128 para el cifrado, sha1-96 tanto para la integridad como para el PRF, grupo Diffie-Hellman 2, 36,600 segundos para la fase 1 y 10,800 segundos para la fase 2. La política del ASA tiene que ofrecer exactamente ese conjunto. Una segunda propuesta en el ASA no hace daño siempre que la coincidente esté también en la lista.

IKEv2 da más margen a ambos lados, pero las reglas mantienen la misma forma: activa PFS, elige un grupo DH que el túnel admita y mantén la lista de propuestas lo bastante corta como para que una discrepancia sea evidente. Un par ASA en Cloud VPN también implica enrutamiento estático, así que los prefijos protegidos hay que planificarlos y listarlos en lugar de dejarlos a BGP.

Una vida útil copiada de la plantilla de otro proveedor es el desvío habitual aquí. Google publica estos valores como ajustes obligatorios del par, así que ponlos; un valor más corto no se negocia hacia arriba hasta lo que quiere el ASA.

Borra, vuelve a crear y limpia el estado antiguo

Borra el túnel, no la puerta de enlace, y apunta el nombre que Cloud VPN da al reemplazo, porque los nombres se asignan y no se reutilizan. Vuelve a crearlo con los valores anotados y la misma dirección de par, y luego añade la propuesta coincidente a la lista de políticas del ASA.

Limpia las asociaciones de seguridad después del cambio en el ASA y antes de leer el resultado. Un ASA puede seguir ofreciendo una política obsoleta hasta que caduque la SA actual, así que una configuración correcta parece rota durante toda la vida útil antigua y el observador concluye que la reconstrucción falló cuando aún no había empezado:

clear crypto ikev2 sa
clear crypto ipsec sa

Confirma que la fase 1 sube antes de mirar la fase 2. Mientras la fase 1 está caída, la propuesta o la clave precompartida están mal, y el trabajo de selectores no lo cambiará.

Los selectores se reflejan, luego deciden los contadores

La fase 2 solo funciona cuando ambos extremos coinciden en las direcciones protegidas, y la coincidencia es especular, no compartida. El selector local de Google tiene que coincidir con el selector que el ASA llama remoto, y el selector remoto de Google con lo que el ASA llama local. Un túnel con 0.0.0.0/0 en un lado y una sola subred en el otro supera la fase 1 y luego falla la fase 2 con el mismo error de titular. Ningún lado puede ensanchar la lista del otro.

Para selectores basados en políticas, enumera cada par de prefijos y guarda la lista en el ticket. Una subred añadida más tarde en la sede necesita una edición en ambos extremos, porque una ruta nueva en el ASA no ensancha un selector, y el resultado es un túnel que está levantado y solo pasa tráfico para los prefijos que existían el primer día.

Termina con un solo flujo de host a host y lee los contadores de bytes en ambos lados. Contadores que suben en el ASA mientras se quedan planos en Google suelen significar que la respuesta sale por otra interfaz, o que el selector no cubre el prefijo de vuelta. Anota los algoritmos, las vidas útiles, los selectores y el nombre nuevo del túnel, porque el siguiente cambio de propuesta repite esta reconstrucción y esos valores la convierten en una tarea corta.