目录

简介

在思科自适应安全设备(ASA)上进行代码升级后，Avaya电话为什么无法再通过IPSEC VPN连接？

简介

本文档介绍在电话使用内置互联网协议安全(IPsec)客户端的系统上部署Avaya时遇到的问题。

在思科自适应安全设备(ASA)上进行代码升级后，Avaya电话为什么无法再通过IPSEC VPN连接？

要了解此问题，您需要了解网络地址转换穿越(NAT-T)和NAT发现(NAT-D)的工作原理。NAT-D过程包括以下步骤：

1. 检测IPsec主机之间的一个或多个NAT设备。

2. 确定对等体是否支持NAT-T。

3. 通过互联网密钥交换(IKE)中的NAT设备协商使用用户数据报协议(UDP)封装IPsec数据包。

NAT-D将两个IKE对等体的IP地址和端口的散列从两端发送到另一端。如果两端计算这些散列并产生相同的结果，则它们知道两者之间没有NAT。散列作为一系列NAT-D负载发送。每个负载包含一个散列。如果存在多个散列，则发送多个NAT-D负载。通常，只有两个NAT-D负载。NAT-D负载包含在主模式的第三和第四数据包以及主动模式的第二和第三数据包中。由于本示例使用远程访问隧道，因此它是主动模式。

NAT-D负载中包含的一个详细信息是供应商ID(VID)。 对等体之间的VID交换有助于确定远程主机的NAT-T功能，如请求注解(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.

当前接受的NAT-D负载负载类型为20。如果查看ASA上的调试，您将看到：

[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

以下是数据包捕获的快照：

ASA到电话：

电话到ASA:

Avaya无法识别负载20，而ASA不了解负载类型15。此行为的解释是，在2004年，相同的RFC将负载类型定义为15。因此，自2004年以来，使用此负载类型的Avaya电话不再符合RFC。那么，为什么它能用较旧的代码？因为与Avaya一样，某些旧代码（版本8.0.x）仍支持旧ID。但是，较新的代码（版本8.2.1+）应符合新的RFC值，并且不应支持负载类型15。尽管如此，您仍可以找到围绕该代码的各种版本，这些版本仍支持负载类型15，这是导致问题的原因。

Avaya需要修复电话上的固件，以便内置VPN客户端使用正确的付费ID。遗憾的是，其他一些Avaya手机（如46xx系列）已停产，无法修复。在这种情况下，您需要获取新设备，或者需要将ASA降级到其工作的版本。显然，如果您升级以首先获得漏洞修复，则后一个选项不可用。需要报告任何与旧负载ID配合使用的思科软件版本，并解决这些版本上的问题。