如何排除 Cisco VPN 客户端身份验证错误 413?

如何排除 Cisco VPN 客户端身份验证错误 413?

我是一名软件开发承包商,我被授予了 Cisco VPN 访问权限,可以访问客户的网络。这是一个典型的设置,使用 RSA SecureID 软令牌,当我在开发工作站上的 VirtualBox 实例 (Win 7) 中运行 VPN Client (v 5.0.07.0440) 时,我能够成功通过它进行连接。

但是,当我直接在开发工作站的操作系统(也是 Win 7)上运行 VPN 客户端时,它失败了,并给了我身份验证错误 413。该错误通常归因于输入了错误的凭据,我发现的每个故障排除参考都指出用户错误是唯一可能的原因。

但我确信这不是问题所在,因为我可以在虚拟机上使用 VPN 客户端而不做任何其他更改时轻松证明这一点。我不知道这两个环境之间的相关区别是什么。任何指导都将不胜感激。

以下是来自 VPN 客户端的日志。(我已删除特定服务器和 IP 值并将其替换为 {text}。)

Cisco Systems VPN Client Version 5.0.07.0440
Copyright (C) 1998-2010 Cisco Systems, Inc. All Rights Reserved.
Client Type(s): Windows, WinNT
Running on: 6.1.7601 Service Pack 1

1      15:54:10.121  01/24/14  Sev=Info/4   CM/0x63100002
Begin connection process

2      15:54:10.132  01/24/14  Sev=Info/4   CM/0x63100004
Establish secure connection

3      15:54:10.132  01/24/14  Sev=Info/4   CM/0x63100024
Attempt connection with server "{server name}"

4      15:54:10.139  01/24/14  Sev=Info/6   IKE/0x6300003B
Attempting to establish a connection with {IP}.

5      15:54:10.144  01/24/14  Sev=Info/4   IKE/0x63000001
Starting IKE Phase 1 Negotiation

6      15:54:10.284  01/24/14  Sev=Info/6   GUI/0x63B00012
Authentication request attributes is 102h.

7      15:54:10.149  01/24/14  Sev=Info/4   IKE/0x63000013
SENDING >>> ISAKMP OAK AG (SA, KE, NON, ID, VID(Xauth), VID(dpd), VID(Frag), VID(Nat-T), VID(Unity)) to {IP}

8      15:54:10.155  01/24/14  Sev=Info/4   IPSEC/0x63700008
IPSec driver successfully started

9      15:54:10.155  01/24/14  Sev=Info/4   IPSEC/0x63700014
Deleted all keys

10     15:54:10.207  01/24/14  Sev=Info/5   IKE/0x6300002F
Received ISAKMP packet: peer = {IP}

11     15:54:10.207  01/24/14  Sev=Info/4   IKE/0x63000014
RECEIVING <<< ISAKMP OAK AG (SA, KE, NON, ID, HASH, VID(Unity), VID(Xauth), VID(dpd), VID(Nat-T), NAT-D, NAT-D, VID(Frag), VID(?)) from {IP}

12     15:54:10.207  01/24/14  Sev=Info/5   IKE/0x63000001
Peer is a Cisco-Unity compliant peer

13     15:54:10.207  01/24/14  Sev=Info/5   IKE/0x63000001
Peer supports XAUTH

14     15:54:10.207  01/24/14  Sev=Info/5   IKE/0x63000001
Peer supports DPD

15     15:54:10.207  01/24/14  Sev=Info/5   IKE/0x63000001
Peer supports NAT-T

16     15:54:10.207  01/24/14  Sev=Info/5   IKE/0x63000001
Peer supports IKE fragmentation payloads

17     15:54:10.212  01/24/14  Sev=Info/6   IKE/0x63000001
IOS Vendor ID Contruction successful

18     15:54:10.212  01/24/14  Sev=Info/4   IKE/0x63000013
SENDING >>> ISAKMP OAK AG *(HASH, NOTIFY:STATUS_INITIAL_CONTACT, NAT-D, NAT-D, VID(?), VID(Unity)) to {IP}

19     15:54:10.213  01/24/14  Sev=Info/6   IKE/0x63000055
Sent a keepalive on the IPSec SA

20     15:54:10.213  01/24/14  Sev=Info/4   IKE/0x63000083
IKE Port in use - Local Port =  {port}, Remote Port = {port}

21     15:54:10.213  01/24/14  Sev=Info/5   IKE/0x63000072
Automatic NAT Detection Status:
   Remote end is NOT behind a NAT device
   This   end IS behind a NAT device

22     15:54:10.213  01/24/14  Sev=Info/4   CM/0x6310000E
Established Phase 1 SA.  1 Crypto Active IKE SA, 0 User Authenticated IKE SA in the system

23     15:54:10.272  01/24/14  Sev=Info/5   IKE/0x6300002F
Received ISAKMP packet: peer = {IP}

24     15:54:10.273  01/24/14  Sev=Info/4   IKE/0x63000014
RECEIVING <<< ISAKMP OAK TRANS *(HASH, ATTR) from {IP}

25     15:54:10.273  01/24/14  Sev=Info/4   CM/0x63100015
Launch xAuth application

26     15:54:20.310  01/24/14  Sev=Info/6   IKE/0x63000055
Sent a keepalive on the IPSec SA

27     15:54:28.172  01/24/14  Sev=Info/4   CM/0x63100017
xAuth application returned

28     15:54:28.172  01/24/14  Sev=Info/4   IKE/0x63000013
SENDING >>> ISAKMP OAK TRANS *(HASH, ATTR) to {IP}

29     15:54:30.396  01/24/14  Sev=Info/5   IKE/0x6300002F
Received ISAKMP packet: peer = {IP}

30     15:54:30.397  01/24/14  Sev=Info/4   IKE/0x63000014
RECEIVING <<< ISAKMP OAK TRANS *(HASH, ATTR) from {IP}

31     15:54:30.397  01/24/14  Sev=Info/4   IKE/0x63000013
SENDING >>> ISAKMP OAK TRANS *(HASH, ATTR) to {IP}

32     15:54:30.397  01/24/14  Sev=Info/4   IKE/0x63000017
Marking IKE SA for deletion  (I_Cookie={cookie} R_Cookie={cookie}) reason = DEL_REASON_WE_FAILED_AUTH

33     15:54:30.398  01/24/14  Sev=Info/4   IKE/0x63000013
SENDING >>> ISAKMP OAK INFO *(HASH, DEL) to {IP}

34     15:54:30.453  01/24/14  Sev=Info/5   IKE/0x6300002F
Received ISAKMP packet: peer = {IP}

35     15:54:30.454  01/24/14  Sev=Info/4   IKE/0x63000058
Received an ISAKMP message for a non-active SA, I_Cookie={Cookie} R_Cookie={Cookie}

36     15:54:30.454  01/24/14  Sev=Info/4   IKE/0x63000014
RECEIVING <<< ISAKMP OAK INFO *(Dropped) from {IP}

37     15:54:30.965  01/24/14  Sev=Info/4   IKE/0x6300004B
Discarding IKE SA negotiation (I_Cookie={Cookie} R_Cookie={Cookie}) reason = DEL_REASON_WE_FAILED_AUTH

38     15:54:30.965  01/24/14  Sev=Info/4   CM/0x63100014
Unable to establish Phase 1 SA with server "{server}" because of "DEL_REASON_WE_FAILED_AUTH"

39     15:54:30.965  01/24/14  Sev=Info/5   CM/0x63100025
Initializing CVPNDrv

40     15:54:30.979  01/24/14  Sev=Info/6   CM/0x63100046
Set tunnel established flag in registry to 0.

41     15:54:30.979  01/24/14  Sev=Info/4   IKE/0x63000001
IKE received signal to terminate VPN connection

42     15:54:30.987  01/24/14  Sev=Info/4   IPSEC/0x63700014
Deleted all keys

43     15:54:30.987  01/24/14  Sev=Info/4   IPSEC/0x63700014
Deleted all keys

44     15:54:30.987  01/24/14  Sev=Info/4   IPSEC/0x63700014
Deleted all keys

45     15:54:30.987  01/24/14  Sev=Info/4   IPSEC/0x6370000A
IPSec driver successfully stopped

答案1

这可能是一个盲目的尝试,但你试过DNE(确定性网络增强器)更新Citrix 的?过去,我曾神奇地用它修复了旧版 Cisco VPN 客户端的问题。在全新安装的 Win7 上,这显然不是必需的。但如果是较旧、较复杂的安装,在其生命周期内可能安装了多个 VPN 客户端,与网络堆栈混在一起,它似乎可以调整一些东西,让它们再次正常运行。这也是让旧版客户端在 Windows 8 及更高版本中运行的关键之一。来自网站:

Citrix 为许多软件和硬件公司提供软件。当他们在您的系统上安装其产品时,它们通常会包含 DNE。

DNE 扩展了操作系统和网络协议设备和堆栈,以引入测量和控制。我们的客户使用这些扩展来构建产品,这些产品可以执行入侵检测、VPN、网络地址转换 (NAT)、流量测量、响应时间测量、带宽控制、压缩、内容过滤、内容保护、策略管理、代理、计费、数据包标记、路由、协议转换、无线通信、安全隧道等功能。

如果您想尝试一下,请执行以下操作:

  • 卸载 Cisco VPN 客户端
  • 安装 DNE 更新
  • 重新安装 Cisco VPN 客户端

答案2

在没有 Cisco 'router#debug crypto ipsec on' 输出的情况下,我很难理解这个问题。但是,如果身份验证是通过 SSL 证书(RSA 模式)进行的,您最终可能会参考http://vouters.dyndns.org/tima/Linux-Windows-Cisco-VPN-Cisco_may_abort_when_attempting_to_establish_a_VPN.html 本文档描述了一些 VPN 客户端和 Cisco IOS 之间的两个问题。第一个是缺少发送颁发者的问题(信息位于 SSL 证书内)。最后一个描述了 NAT-T 有效负载交换问题。

否则,对于有效的 Cisco IOS 配置,您可以查询搜索引擎http://vouters.dyndns.org/关键字为“Cisco”

希望这能帮到你。问候,Philippe

答案3

我终于解决了自己的问题,结果发现确实是我自己的用户错误!我发布此信息是为了让未来的用户免于尴尬:

在主机操作系统上安装 RSA SecureID 软件并重新启动后,VPN 客户端开始需要我的 RSA PIN,而不是我习惯使用的不断变化的 RSA 密码。这种行为对我来说很新奇,我一直输入密码而不是 PIN。(我没有注意到 VPN 客户端身份验证提示从“密码”更改为“PIN”。)当我终于醒悟过来并开始输入 PIN 时,它工作得很好。

(虚拟机没有安装 RSA 应用程序,这就是它能使用密码正常工作的原因。)

相关内容