cancelar
Mostrando los resultados de 
Buscar en lugar de 
Quiere decir: 
cancel
701
Visitas
0
ÚTIL
2
Respuestas

Problemas VPN L2L

lvenegas022
Level 1
Level 1

Saludos

Tengo configurada una vpn site to site (L2L) ambos dispositivos son Cisco ASA 5520, la conexion funcionaba correctamente. pero de pronto esta tando este error:

ASA1               -----      internet                      -----  ASA2

IP 186.32.189.178                              IP 186.179.167.2 

es una vpn site to site

En el ASA 2 me da este error y la detecta como vpn remote accces.

26  IKE Peer: 186.32.189.178

    Type    : user            Role    : responder

    Rekey   : no              State   : MM_WAIT_MSG3

alguno sabe que puede ser este error.

pura vida

1 SOLUCIÓN ACEPTADA

Soluciones aceptadas

Gustavo Medina
Cisco Employee
Cisco Employee

Hola,

Cuando el tunel esta siendo negociado siempre va a aparecer como remote access, incluso tratandose de un L2L.

En este caso, el ASA 2 como lo llamas esta actuando como responder, recibió el primer paquete de Main Mode y envió el 2do pero no ha recibido respuesta a este paquete por eso el output muestra MM_WAIT_MSG3; si revisas el IKE sa en ASA 1 lo que vas a ver es MM_WAIT_MSG2. Estos paquetes van en UDP 500 asi que una posibilidad sería que este trafico esta siendo bloqueado en la direccion ASA2 >>> ASA 1 de manera que si el ASA2 actuara como initiator la salida sería MM_WAIT_MSG2 y en ASA1 ni siquiera verias la negociacion. Para confirmar esto puedes correr los debugs de isakmp en ambos lados o incluso capturar el trafico de IP publica a IP Publica en las interfaces outside de ambos lados simultaneamente.

Pura Vida...

Ver la solución en mensaje original publicado

2 RESPUESTAS 2

Gustavo Medina
Cisco Employee
Cisco Employee

Hola,

Cuando el tunel esta siendo negociado siempre va a aparecer como remote access, incluso tratandose de un L2L.

En este caso, el ASA 2 como lo llamas esta actuando como responder, recibió el primer paquete de Main Mode y envió el 2do pero no ha recibido respuesta a este paquete por eso el output muestra MM_WAIT_MSG3; si revisas el IKE sa en ASA 1 lo que vas a ver es MM_WAIT_MSG2. Estos paquetes van en UDP 500 asi que una posibilidad sería que este trafico esta siendo bloqueado en la direccion ASA2 >>> ASA 1 de manera que si el ASA2 actuara como initiator la salida sería MM_WAIT_MSG2 y en ASA1 ni siquiera verias la negociacion. Para confirmar esto puedes correr los debugs de isakmp en ambos lados o incluso capturar el trafico de IP publica a IP Publica en las interfaces outside de ambos lados simultaneamente.

Pura Vida...

perfecto muchas gracias ya le di que era el problema

Gracias por la ayuda