Hola amigos,
Me gustaría compartirles un caso que involucre autenticación por radius L2TP. El escenario que nuestro cliente desea lograr es establecer un túnel L2TP desde una sucursal a HQ, autenticando el lado remoto por medio de un servidor radius. Claro está que no fue fácil desde un principio J, algunos problemas pueden surgir. Haciendo una captura de paquetes, el cliente fue capaz de ver que el punto de falla de este problema es el proceso PPP CHAP, después de recibir el mensaje “ACCEPT” del servidor radius, el LNS AR2240 envía una falla de CHAP instantáneamente (no involucra la sesión “3-way handshake”). Para hacer esta información más clara adjunto la topología:
Ciertamente es necesario empezar una sesión de debugging mientras se intenta autenticar el lado remoto de radius. En el LNS: debugging ppp all debugging l2tp all debugging cm all debugging radius all debugging aaa all
No publicare todos los registros de debugging aquí, pero puedo decirles que mensajes pude identificar. 1. Solicitud de Autenticación 2. Aceptación de Autenticación 3. Attr decode err. (type=11) 4. Fallo de Autenticación con usuario o password ilegal 5. LCP abierto a cerrar.
Claramente el mensaje más importante es el código de error. Esto nos indica que uno de los atributos enviados por el servidor radius no pudo ser decodificado por el AR. Revisando la captura de paquetes observamos algunos atributos privados de Microsoft involucrados en el proceso. Además el atributo "Tunnel-Assignment-Id" tiene una longitud mayor (15) que el máximo admitido (6). Como se ve a continuación.
Al remover los atributos privados de Microsoft y ajusta la longitud del atributo Tunnel-Assignment-Id podemos corregir el problema de decodificación y continuar con el troubleshooting. Es importante remover atributos innecesarios de los mensajes de radius especialmente cuando se trabaja en un ambiente de múltiples vendedores. Espero que haya disfrutado leyendo este caso. |
