SW Client quit connecting

[jimgurley]

My server had a hiccup yesterday, and since then, my ASA5505 quit letting external users in via the SW Client 5.0.07.0440.  The hiccup was some sort of disk error that as far as I've discovered, caused my domain server to switch it's network adapters IPv4 Properties to "default", meaning nothing worked (DHCP, DNS, SQL) until I found the problem and corrected it.  Didn't take long as the symptoms were pretty obvious.

Everything else seems to work, including an ASA point-to-point VPN to a foreign network.  When I try to access my office network via the client, I get a "Error 433".  We hired a consultant to install the ASA many years ago, and he's no longer in the field, so I'm trying to get a hint of what might be wrong on the server to stop the authentication, or whatever. Here's the Client log for the attempt:

I have a bare metal backup from before the hiccup, so I have a painful alternative if it's hopeless.

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.2.9200

25 13:22:07.456 01/03/18 Sev=Info/4 CM/0x63100002
Begin connection process

26 13:22:07.456 01/03/18 Sev=Info/4 CM/0x63100004
Establish secure connection

27 13:22:07.456 01/03/18 Sev=Info/4 CM/0x63100024
Attempt connection with server "74.40.167.114"

28 13:22:07.456 01/03/18 Sev=Info/4 IKE/0x63000001
Starting IKE Phase 1 Negotiation

29 13:22:07.456 01/03/18 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 74.40.167.114

30 13:22:07.471 01/03/18 Sev=Info/4 IPSEC/0x63700008
IPSec driver successfully started

31 13:22:07.471 01/03/18 Sev=Info/4 IPSEC/0x63700014
Deleted all keys

32 13:22:08.002 01/03/18 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 74.40.167.114

33 13:22:08.018 01/03/18 Sev=Info/4 IKE/0x63000013
SENDING >>> ISAKMP OAK AG *(HASH, NOTIFY:STATUS_INITIAL_CONTACT, NAT-D, NAT-D, VID(?), VID(Unity)) to 74.40.167.114

34 13:22:08.018 01/03/18 Sev=Info/4 IKE/0x63000083
IKE Port in use - Local Port = 0xF501, Remote Port = 0x1194

35 13:22:08.018 01/03/18 Sev=Info/4 CM/0x6310000E
Established Phase 1 SA. 1 Crypto Active IKE SA, 0 User Authenticated IKE SA in the system

36 13:22:08.159 01/03/18 Sev=Info/4 IKE/0x63000014
RECEIVING <<< ISAKMP OAK TRANS *(HASH, ATTR) from 74.40.167.114

37 13:22:08.159 01/03/18 Sev=Info/4 CM/0x63100015
Launch xAuth application

Asks for credentials here

38 13:22:22.594 01/03/18 Sev=Info/4 CM/0x63100017
xAuth application returned

39 13:22:22.594 01/03/18 Sev=Info/4 IKE/0x63000013
SENDING >>> ISAKMP OAK TRANS *(HASH, ATTR) to 74.40.167.114

40 13:22:38.142 01/03/18 Sev=Info/4 IKE/0x63000014
RECEIVING <<< ISAKMP OAK TRANS *(Retransmission) from 74.40.167.114

41 13:22:38.142 01/03/18 Sev=Info/4 IKE/0x63000021
Retransmitting last packet!

42 13:22:38.142 01/03/18 Sev=Info/4 IKE/0x63000013
SENDING >>> ISAKMP OAK TRANS *(Retransmission) to 74.40.167.114

43 13:22:38.282 01/03/18 Sev=Info/4 IKE/0x63000014
RECEIVING <<< ISAKMP OAK INFO *(HASH, DEL) from 74.40.167.114

44 13:22:38.282 01/03/18 Sev=Info/4 IKE/0x63000017
Marking IKE SA for deletion (I_Cookie=4AE4723DAAA67F38 R_Cookie=C5DCCA9D16B9CFC4) reason = PEER_DELETE-IKE_DELETE_UNSPECIFIED

45 13:22:39.017 01/03/18 Sev=Info/4 IKE/0x6300004B
Discarding IKE SA negotiation (I_Cookie=4AE4723DAAA67F38 R_Cookie=C5DCCA9D16B9CFC4) reason = PEER_DELETE-IKE_DELETE_UNSPECIFIED

46 13:22:39.017 01/03/18 Sev=Info/4 CM/0x63100014
Unable to establish Phase 1 SA with server "74.40.167.114" because of "PEER_DELETE-IKE_DELETE_UNSPECIFIED"

47 13:22:39.032 01/03/18 Sev=Info/4 IKE/0x63000001
IKE received signal to terminate VPN connection

48 13:22:39.048 01/03/18 Sev=Info/4 IPSEC/0x63700014
Deleted all keys

49 13:22:39.048 01/03/18 Sev=Info/4 IPSEC/0x63700014
Deleted all keys

50 13:22:39.048 01/03/18 Sev=Info/4 IPSEC/0x63700014
Deleted all keys

51 13:22:39.048 01/03/18 Sev=Info/4 IPSEC/0x6370000A
IPSec driver successfully stopped

[Francesco Molino]

Hi

How are users authenticated? Local db or Radius ? Can you validate if ASA can still access this remote user database?
Can you run debug crypto isakmp and ipsec on ASA while a user tries to connect and share a text file with this output?

[jimgurley]

I didn't install this equipment and I'm not an IT guy (old retired chip designer).

It's not a radius server, so I'm guessing it's the local db.

I don't know how to test if the ASA can access the db, and I have no idea what the second paragraph is asking me to do.  I'm not at the office right now, so it would have to wait anyway, unless I can login remotely (which I think can be done, but I've never done it).

[Francesco Molino]

OK, there's no IT guys that manage this asa? If not we can try to setup a webex session to take a look on it but you'll need to have access to asa with admin credentials

[jimgurley]

Correct - no IT.  This is a small rural medical practice with an SQL based records system.  I'm just the doctor's husband and volunteer IT department. A consultant installed the equipment ten years ago, billed another hour of time to fix it when I had to install a new server four years ago, and now is out of the business, as far as I can tell.  I've learned enough about the CLI to open one new port, so I do have access to the device.  The consultant said to stay away from the GUI.

I'm going to reboot the server this morning (in a few hours) and pour over the event log and see if there's any hints there.  I'll post again if it's still unresolved.

[jimgurley · Accepted solution]

My bad.

I hadn't rebooted my server since I had repaired the network properties.  There's obviously something ASA related that happens during boot based on the server IP that doesn't fix itself with a reboot of the ASA device.  Working fine now, although I wish I had a block diagram of how things work and were the files are...