3

I'm a software developer contractor, and I've been given Cisco VPN access to a customer's network. It's a typical set up, using an RSA SecureID soft token, and I'm successfully able to connect through VPN Client (v 5.0.07.0440) when I run it within a VirtualBox instance (Win 7) on my development workstation.

However, when I run VPN Client directly on the development workstation's OS itself (also Win 7), it has been failing, and gives me Authentication Error 413. That error is normally attributed to bad credentials having been entered, and every troubleshooting reference I've found points to user error being the only possible cause.

Yet I'm certain that's not the issue here, as I can easily prove to myself when using the VPN Client on the VM and changing nothing else. I'm at a loss as to what that relevant difference is between the two environments. Any guidance would be appreciated.

Log from VPN Client follows. (I've redacted specific server & IP values and replaced them with {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
David Korn
  • 31
  • 1
  • 1
  • 6
  • Did you try reinstall the client? – Danila Ladner Jan 24 '14 at 23:31
  • Yes, thanks for reminding me to mention that. I uninstalled, rebooted, re-installed....no joy. I eventually did it a second time and then I also followed instructions for how to remove all remnants when uninstalling (lingering files and registry keys). – David Korn Jan 25 '14 at 00:21
  • Are you behind a firewall? Is there any sort of antivirus checking involved that maybe is turned off inside the VM? Also: are other users from your network connected to this VPN? Maybe the max number of concurrent connections is reached? – duenni Jan 27 '14 at 20:18
  • Thanks for the ideas. I've disabled antivirus, and verified that the VM VPN Client can connect right after the host OS VPN Client cannot. So not a concurrency issue. – David Korn Jan 28 '14 at 07:52

3 Answers3

0

This may be a shot in the dark, but have you tried the DNE (Deterministic Network Enhancer) update from Citrix? I've had it magically fix issues with the legacy Cisco VPN client in the past. It's obviously not necessary on a fresh Win7 install. But if it's an older, cruftier install, that has possibly had multiple VPN clients installed in its lifetime mucking about with the network stack, it seems to tweak things and make them happy again. It's also one of the keys to making that legacy client work in Windows 8 and beyond. From the site:

Citrix supplies software to a number of software and hardware companies. When they install their products on your systems, they will often contain DNE.

DNE extends operating systems and network protocol devices and stacks to introduce measurement and controls. Our customers use these extensions to build products that do things like intrusion detection, VPNs, Network Address Translation (NAT), traffic measurement, response time measurement, bandwidth control, compression, content filtering, content protection, policy management, proxies, billing, packet marking, routing, protocol translation, wireless communication, secure tunnels and much more.

If you want to try it, do the following:

  • Uninstall the Cisco VPN client
  • Install the DNE update
  • Reinstall the Cisco VPN client
Community
  • 1
Ryan Bolger
  • 16,755
  • 4
  • 42
  • 64
  • Thanks much, Ryan, this sounded like just the sort of thing I was looking for. But alas I had no change after carefully following all the suggestions on that page. I'll keep fiddling. – David Korn Jan 28 '14 at 07:58
  • Because your answer seemed to offer the best (and nearly only) hope at fixing my problem, I'm awarding you the expiring bounty. Unfortunately I'm still at a loss as to how to fix this issue, so I'm leaving the question as unanswered. – David Korn Feb 03 '14 at 18:15
  • Thanks. Sorry you still don't have your answer though. That legacy Cisco client has always been a PITA. If it's an option, you might save time by just re-installing Windows on that dev machine. – Ryan Bolger Feb 03 '14 at 19:44
0

It is difficult for me to understand the problem without any Cisco 'router#debug crypto ipsec on' output. However if authentication is via SSL certificates (RSA mode), you may eventually refer to http://vouters.dyndns.org/tima/Linux-Windows-Cisco-VPN-Cisco_may_abort_when_attempting_to_establish_a_VPN.html This document describes two problem between some VPN clients and Cisco IOS. The first one is a missing sent issuer issue (the information is inside an SSL certificate). The last one describes a NAT-T payload exchange issue.

Otherwise for working Cisco IOS configurations, you may query the search engine at http://vouters.dyndns.org/ with the keyword "Cisco"

In the hope this can help you. Regards, Philippe

user1910461
  • 26
  • 1
  • Thanks, Philippe. I appreciate you posting, and I read over your linked white paper. It sounds to me like the issues described there would affect the Cisco server side, and yet my issue seems to be local to my client machine configuration. (as even a Win7 virtual machine within my host Win7 OS is connecting to the Cisco VPN fine) It could be that I'm just not understanding something about your answer. – David Korn Feb 03 '14 at 18:12
0

I finally solved my own issue, and it did turn out to be my own user error! I'm posting this to save future users embarrassment:

After I had installed the RSA SecureID software on my host OS and rebooted, the VPN Client had begun expecting my RSA PIN, rather than the ever changing RSA passcodes I was used to using. This behavior was new to me, and I kept entering in the passcodes instead of the PIN. (I didn't notice the change in VPN Client authentication prompt from "Passcode" to "PIN".) Once I finally wised up and started entering in the PIN, it worked just fine.

(The VM didn't have the RSA app installed, and that's why it had worked fine with passcodes.)

David Korn
  • 31
  • 1
  • 1
  • 6