Sécurité et VPN : Négociation IPSec/protocoles IKE

Foire aux questions d'IPsec : Pourquoi les téléphones d'Avaya ne peuvent-ils plus se connecter par l'intermédiaire d'IPsec VPN après mise à niveau du code sur l'ASA ?

17 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires

Introduction

Ce document décrit un problème rencontré quand Avaya est déployé sur un système dans lequel les téléphones utilisent le client intégré d'IPSec (IPsec).

Contribué par Atri Basu et Gustavo la Médina, ingénieurs TAC Cisco.

Pourquoi les téléphones d'Avaya ne peuvent-ils plus se connecter par l'intermédiaire d'IPSEC VPN après mise à niveau du code sur l'appliance de sécurité adaptable Cisco (ASA) ?

Afin de comprendre ce problème, vous devez comprendre comment la traversée de traduction d'adresses réseau (NAT-T) et les travaux NAT de la détection (NAT-D). Le processus NAT-D est composé de ces étapes :

  1. Détecte un ou plusieurs périphériques NAT entre les hôtes d'IPsec.
  2. L'identifie si le pair prend en charge NAT-T.
  3. Négocie l'utilisation de l'encapsulation de Protocole UDP (User Datagram Protocol) des paquets d'IPsec par les périphériques NAT dans l'Échange de clés Internet (IKE).

NAT-D envoie hache des adresses IP et des ports des deux pairs d'IKE de chaque extrémité à l'autre. Si les deux extrémités calculent ceux hache et produisez les mêmes résultats, ils savent qu'il n'y a pas NAT entre. Hache sont envoyés comme gamme de charges utiles NAT-D. Chaque charge utile contient une informations parasites. Dans le cas du multiple hache, de plusieurs charges utiles NAT-D sont envoyés. Normalement, il y a seulement deux charges utiles NAT-D. Les charges utiles NAT-D sont incluses dans les troisième et quatrièmes paquets du mode principal, et dans les deuxièmes et troisième paquets du mode agressif. Puisque cet exemple utilise un tunnel d'Accès à distance, c'est le mode agressif.

Un des détails inclus dans les charges utiles NAT-D est l'ID de constructeur (VID). L'échange de VIDs entre les aides de pairs déterminent la capacité NAT-T du serveur distant, comme décrit dans le Request For Comments (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.

Le courant a reçu le type de charge utile de la charge utile NAT-D est 20. Si vous regardez met au point sur l'ASA, vous voyez :

[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

Voici les instantanés des captures de paquet :

ASA à téléphoner :

Téléphone à l'ASA :

Avaya n'identifie pas la charge utile 20, et l'ASA ne comprend pas le type 15 de charge utile. L'explication pour ce comportement est parce que, en 2004, le même RFC a défini le type de charge utile en tant que 15. Par conséquent, depuis 2004, les téléphones d'Avaya qui utilisent ce type de charge utile ne sont plus RFC conforme. Ainsi, pourquoi a-t-cela fonctionné avec plus vieux celacode-t- ? Puisque, comme Avaya, une partie du code plus ancien (version 8.0.x) prend en charge toujours le vieil ID. Cependant, le code plus nouveau (versions 8.2.1+) est censé être conforme avec la nouvelle valeur RFC et ne devrait pas prendre en charge la charge utile type15. Néanmoins, vous pouvez trouver de diverses versions autour de cette charge utile immobile type15 de support, qui est ce qui pose le problème.

Avaya doit réparer le micrologiciel au téléphone de sorte que le client vpn intégré utilise le bon ID de paylod. Malheureusement, quelques autres téléphones d'Avaya, comme la gamme 46xx, ne sont plus dans la production et n'obtiendront pas une difficulté. Dans ce cas, vous devez obtenir le nouveau matériel ou devoir déclassifier l'ASA à une version sur laquelle elle fonctionnait. Évidemment cette dernière option n'est pas disponible si vous mettiez à jour afin d'obtenir un correctif de bogue en premier lieu. Quelles des versions de logiciel de Cisco qui fonctionnent avec la nécessité plus ancienne d'ID de charge utile d'être signalé et de la question réparée sur ces versions.


Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Document ID: 116294