FAQ IPsec : Pourquoi les téléphones Avaya ne peuvent-ils plus se connecter via un VPN IPsec après la mise à niveau du code sur l'ASA ?

Introduction

Ce document décrit un problème rencontré lors du déploiement d'Avaya sur un système dans lequel les téléphones utilisent le client IPsec (Internet Protocol Security) intégré.

Pourquoi les téléphones Avaya ne peuvent-ils plus se connecter via un VPN IPSEC après la mise à niveau du code sur l'appareil de sécurité adaptatif Cisco (ASA) ?

Afin de comprendre ce problème, vous devez comprendre comment fonctionnent la traduction d'adresses de réseau (NAT-T) et la découverte NAT (NAT-D). Le processus NAT-D se compose des étapes suivantes :

1. Détecte un ou plusieurs périphériques NAT entre des hôtes IPsec.
2. Indique si l'homologue prend en charge NAT-T.
3. Négocie l'utilisation de l'encapsulation UDP (User Datagram Protocol) des paquets IPsec via des périphériques NAT dans l'échange de clés Internet (IKE).

NAT-D envoie les hachages des adresses IP et des ports des deux homologues IKE de chaque extrémité à l'autre. Si les deux extrémités calculent ces hachages et produisent les mêmes résultats, elles savent qu'il n'y a pas de NAT entre les deux. Les hachages sont envoyés sous la forme d'une série de charges utiles NAT-D. Chaque charge utile contient un hachage. Dans le cas de hachages multiples, plusieurs charges utiles NAT-D sont envoyées. Normalement, il n'y a que deux charges utiles NAT-D. Les charges utiles NAT-D sont incluses dans les troisième et quatrième paquets du mode principal et dans les deuxième et troisième paquets du mode agressif. Puisque cet exemple utilise un tunnel d'accès distant, il s'agit du mode agressif.

L'un des détails inclus dans les charges utiles NAT-D est l'ID de fournisseur (VID). L'échange de VID entre homologues permet de déterminer la capacité NAT-T de l'hôte distant, comme décrit dans RFC (Request for Comments) 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 type de charge utile accepté actuel de la charge utile NAT-D est 20. Si vous regardez les débogages 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 des captures instantanées des paquets :

ASA vers téléphone :

Téléphone vers ASA :

Avaya ne reconnaît pas la charge utile 20 et l'ASA ne comprend pas la charge utile de type 15. L'explication de ce comportement est que, en 2004, le même RFC a défini le type de charge utile comme 15. Par conséquent, depuis 2004, les téléphones Avaya qui utilisent ce type de données utiles ne sont plus compatibles RFC. Alors, pourquoi a-t-il fonctionné avec un code plus ancien ? Parce que, comme Avaya, une partie de l'ancien code (version 8.0.x) prend toujours en charge l'ancien ID. Cependant, le nouveau code (Versions 8.2.1+) est censé être conforme à la nouvelle valeur RFC et ne doit pas prendre en charge le type de charge utile15. Néanmoins, vous pouvez trouver différentes versions autour de qui prennent toujours en charge le type de charge utile15, ce qui est la cause du problème.

Avaya doit réparer le micrologiciel sur le téléphone de sorte que le client VPN intégré utilise l'ID de bloc d'alimentation approprié. Malheureusement, certains autres téléphones Avaya, comme la série 46xx, ne sont plus en production et ne recevront pas de correctif. Dans ce cas, vous devez soit obtenir un nouvel équipement, soit rétrograder l'ASA vers une version sur laquelle il fonctionnait. Évidemment cette dernière option n'est pas disponible si vous avez mis à niveau afin d'obtenir une correction de bogues en premier lieu. Toutes les versions logicielles de Cisco qui fonctionnent avec l'ancien ID de charge utile doivent être signalées et le problème résolu sur ces versions.