Häufig gestellte Fragen zu IPsec: Warum können Avaya-Telefone nach einem Code-Upgrade auf der ASA nicht mehr über IPsec VPN verbunden werden?

Einführung

Dieses Dokument beschreibt ein Problem, das bei der Bereitstellung von Avaya auf einem System auftritt, in dem die Telefone den integrierten Internet Protocol Security (IPsec)-Client verwenden.

Warum können Avaya-Telefone nach einem Code-Upgrade auf der Cisco Adaptive Security Appliance (ASA) keine Verbindung mehr über IPSEC VPN herstellen?

Um dieses Problem zu verstehen, müssen Sie wissen, wie Network Address Translation Traversal (NAT-T) und NAT Discovery (NAT-D) funktionieren. Der NAT-D-Prozess besteht aus folgenden Schritten:

1. Erkennt ein oder mehrere NAT-Geräte zwischen IPsec-Hosts.
2. Identifiziert, ob der Peer NAT-T unterstützt.
3. Verhandelt die Verwendung von UDP-Kapselung (User Datagram Protocol) von IPsec-Paketen über NAT-Geräte in Internet Key Exchange (IKE).

NAT-D sendet die Hashes der IP-Adressen und Ports beider IKE-Peers von einem Ende zum anderen. Wenn beide Enden diese Hashes berechnen und die gleichen Ergebnisse liefern, wissen sie, dass es zwischen den beiden keine NAT gibt. Die Hashes werden als Folge von NAT-D-Payloads gesendet. Jede Nutzlast enthält einen Hash. Bei mehreren Hashes werden mehrere NAT-D-Payloads gesendet. Normalerweise gibt es nur zwei NAT-D-Payloads. Die NAT-D-Payloads sind im dritten und vierten Paket des Hauptmodus und im zweiten und dritten Paket im aggressiven Modus enthalten. Da in diesem Beispiel ein Remote-Zugriffstunnel verwendet wird, ist dies der aggressive Modus.

Eine der Angaben in den NAT-D-Payloads ist die Vendor ID (VID). Der Austausch von VIDs zwischen Peers hilft bei der Bestimmung der NAT-T-Funktion des Remote-Hosts, wie in Request for Comments (RFC) 3947 beschrieben:

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.

Der derzeit akzeptierte Nutzlasttyp der NAT-D-Nutzlast ist 20. Wenn Sie sich die Debugging-Informationen auf der ASA anschauen, sehen Sie:

[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

Hier sind Snapshots von den Paketerfassungen:

ASA an Telefon:

Telefon an ASA:

Avaya erkennt Payload 20 nicht, die ASA hingegen nicht Payload vom Typ 15. Die Erklärung für dieses Verhalten ist, dass 2004 der gleiche RFC den Payload-Typ als 15 definiert hat. Daher sind die Avaya Telefone, die diesen Payload-Typ verwenden, seit 2004 nicht mehr RFC-konform. Warum funktioniert es mit älterem Code? Denn wie Avaya unterstützt auch ein Teil des älteren Codes (Version 8.0.x) weiterhin die alte ID. Der neuere Code (Version 8.2.1+) sollte jedoch den neuen RFC-Wert erfüllen und den Payload-Typ 15 nicht unterstützen. Trotzdem finden Sie verschiedene Versionen, die den Payload-Typ 15 noch unterstützen, was das Problem verursacht.

Avaya muss die Firmware am Telefon reparieren, damit der integrierte VPN-Client die richtige Payload-ID verwendet. Leider sind einige andere Avaya Telefone, wie die 46xx Serie, nicht mehr in der Produktion und werden keine Lösung erhalten. In diesem Fall müssen Sie entweder neue Geräte erwerben oder die ASA auf eine Version herabstufen, auf der sie funktioniert hat. Offensichtlich ist diese zweite Option nicht verfügbar, wenn Sie ein Upgrade durchgeführt haben, um eine Fehlerbehebung überhaupt zu erhalten. Alle Softwareversionen von Cisco, die mit der älteren Payload-ID arbeiten, müssen gemeldet und das Problem in diesen Versionen behoben werden.