Preguntas frecuentes sobre IPSec: ¿Por qué los teléfonos Avaya ya no pueden conectarse a través de VPN IPsec después de actualizar el código en el ASA?
Contenido
Introducción
Este documento describe un problema encontrado cuando Avaya se implementa en un sistema en el que los teléfonos utilizan el cliente de seguridad de protocolo de Internet (IPsec) integrado.
¿Por qué los teléfonos Avaya ya no pueden conectarse a través de VPN IPSEC después de actualizar el código en el dispositivo de seguridad adaptable (ASA) de Cisco?
Para entender este problema, debe entender cómo funciona la traducción de direcciones de red transversal (NAT-T) y la detección de NAT (NAT-D). El proceso NAT-D consta de los siguientes pasos:
- Detecta uno o más dispositivos NAT entre hosts IPsec.
- Identifica si el par admite NAT-T.
- Negocia el uso de la encapsulación de protocolo de datagramas de usuario (UDP) de los paquetes IPsec a través de dispositivos NAT en el Intercambio de claves de Internet (IKE).
NAT-D envía los hashes de las direcciones IP y los puertos de ambos peers IKE de cada extremo al otro. Si ambos extremos calculan esos hashes y producen los mismos resultados, saben que no hay NAT entre ellos. Los hashes se envían como una serie de cargas útiles NAT-D. Cada carga útil contiene un hash. En el caso de varios hashes, se envían varias cargas útiles NAT-D. Normalmente, sólo hay dos cargas útiles NAT-D. Las cargas útiles NAT-D se incluyen en los paquetes tercero y cuarto del Modo principal y en los paquetes segundo y tercero del Modo agresivo. Dado que este ejemplo utiliza un túnel de acceso remoto, es el modo agresivo.
Uno de los detalles incluidos en las cargas útiles de NAT-D es la ID del proveedor (VID). El intercambio de VID entre pares ayuda a determinar la capacidad NAT-T del host remoto, como se describe en Solicitud de comentarios (RFC) 3947:
The format of the NAT-D packet is:
1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload length |
+---------------+---------------+---------------+---------------+
~ HASH of the address and port
+---------------+---------------+---------------+---------------+
The payload type for the NAT discovery payload is 20.
El tipo de carga útil aceptado actual de la carga útil NAT-D es 20. Si observa las depuraciones en el ASA, verá:
[IKEv1]IP = 192.168.96.120, IKE_DECODE RECEIVED Message (msgid=0) with payloads:
HDR + KE (4) + NONCE (10) + UNKNOWN (15), *** ERROR *** + UNKNOWN (15),
*** ERROR *** + NONE (0) total length : 232
Estas son las instantáneas de las capturas de paquetes:
ASA al teléfono:
Teléfono a ASA:
Avaya no reconoce la carga útil 20 y ASA no entiende el tipo de carga útil 15. La explicación de este comportamiento es que, en 2004, el mismo RFC definió el tipo de carga útil como 15. Por lo tanto, desde 2004, los teléfonos Avaya que utilizan este tipo de carga útil ya no son compatibles con RFC. Entonces, ¿por qué funcionó con código antiguo? Porque, al igual que Avaya, algunos de los códigos anteriores (versión 8.0.x) aún admiten el ID anterior. Sin embargo, se supone que el nuevo código (versiones 8.2.1+) cumple con el nuevo valor RFC y no debe soportar el tipo de carga útil 15. Sin embargo, puede encontrar varias versiones alrededor de las cuales aún soportan payload type15, que es lo que causa el problema.
Avaya necesita reparar el firmware en el teléfono para que el cliente VPN integrado utilice el ID de carga correcta. Desafortunadamente, algunos otros teléfonos Avaya, como la serie 46xx, ya no están en producción y no tendrán solución. En este caso, es necesario obtener un nuevo equipo o volver a actualizar el ASA a una versión en la que funcionaba. Obviamente esta última opción no está disponible si se actualiza para obtener una corrección de errores en primer lugar. Es necesario informar de cualquiera de las versiones de software de Cisco que funcionan con la ID de carga útil anterior y corregir el problema en esas versiones.
Comentarios