Un MAC que no coincide en IKE significa que falló la comprobación de la clave compartida

Tu registro de Cloud VPN muestra un intento con clave compartida seguido de MAC mismatched, y el primer instinto suele ser buscar un problema de dirección. En esta rama MAC es un código de autenticación de mensaje: un valor calculado sobre el intercambio con la clave negociada. El par comparó su propio cálculo con el valor recibido, y diferían. No hay ninguna tarjeta de red implicada, y ningún ajuste de interfaz cambia esa comparación.

En la práctica lo producen dos condiciones: los secretos de los dos extremos no son el mismo valor, o las identidades usadas para seleccionar el secreto no se corresponden. Decide cuál leyendo el par, no el túnel individual.

Qué demuestra la etapa

La comprobación se ejecuta después de que ambos lados hayan intercambiado los parámetros iniciales y se hayan identificado. Selecciona claves compartidas candidatas para las identidades local y remota e intenta validar los datos de autenticación recibidos; cuando ninguna valida, se emite el diagnóstico. Es una afirmación fuerte sobre la autenticación y débil sobre la causa, porque no dice qué lado está equivocado.

El éxito anterior no se traslada a esta comprobación. Un IKE_SA_INIT completado, o una carga de detección de NAT que devolvió los valores esperados, demuestra que los pares pueden hablar. No demuestra nada sobre si comparten un secreto.

Dos errores de configuración, un mensaje

El primero es un desajuste real del secreto, y normalmente es un accidente de aprovisionamiento: un valor generado instalado en una consola y reescrito en la otra, un carácter final que sobrevivió en un lado, o una comilla que llegó con un pegado. El segundo es un desajuste de identidad, donde el secreto es correcto pero la identidad que presenta el par selecciona otra entrada, así que el secreto correcto nunca se prueba. Ambos producen la misma línea, por eso adivinar cuesta una tarde.

Compara el par antes de tocar cualquier secreto. Haz coincidir el túnel, el punto final del par, la ventana temporal y la configuración remota, porque dos túneles redundantes pueden tener secretos distintos y la pantalla que tienes delante puede no ser la que falló.

La detección de NAT es otra etapa

La detección de NAT pregunta cómo se reescriben los paquetes, no quién es el par. Una puerta de enlace de cliente detrás de NAT sigue autenticándose correctamente cuando su identidad configurada es la que el par espera, y un problema de NAT se muestra como una discrepancia de propuesta o de puerto en lugar de una comparación de autenticación fallida.

No traslades una afirmación antigua sobre una versión de proveedor a un despliegue actual. Lo que el tránsito NAT requiere en tu versión pertenece a su propia documentación, y la frase MAC mismatch no es evidencia a favor ni en contra.

Decide desde el par, no desde la pantalla

Lee ambas configuraciones una junto a otra con el secreto oculto, y luego haz tres preguntas. ¿La identidad de cada lado es exactamente lo que espera el otro, carácter por carácter? ¿Usan ambos extremos la misma versión de IKE y el mismo método de autenticación? ¿El túnel que falla corresponde a la configuración que estás leyendo? Un no a cualquiera de ellas decide la reparación sin tocar el secreto.

Si las tres están limpias, sustituye el secreto mediante el flujo de trabajo aprobado en lugar de editar a su alrededor.

Después de que el par se autentique

Una vez que la autenticación tiene éxito, la siguiente superficie de fallo es la asociación de seguridad hija: propuestas y selectores de tráfico. Rotar un secreto que ya se aceptó no puede arreglar un fallo hijo, y alarga la interrupción. Lee el estado de la hija, luego los selectores y rangos protegidos en ambos lados, y haz coincidir la guía de solución de problemas de Cloud VPN con la etapa que realmente falló.

Correlaciona registros nuevos de ambos extremos para el mismo par y la misma ventana. Un lado solo da un veredicto sin la entrada del otro, y esa es la ambigüedad que produjo el mensaje desde el principio.

Qué no concluir

No leas el mensaje como una exigencia de cambiar direcciones MAC, y no publiques el secreto compartido mientras pides ayuda; un extracto que contiene la clave necesita la clave eliminada, no el registro conservado. Tampoco asumas un fallo de enrutamiento, porque los pares que no pueden alcanzarse no producen ninguna comparación de autenticación. Y no generalices una limitación documentada de una familia de productos a toda implementación de IPsec.

Registra el par que falla, el estado del túnel antes y después, y cuál de las dos condiciones cambiaste. Ese registro convierte la próxima aparición en una comprobación de cinco minutos.