Also, I'll have to run the

jimgurley · ‎07-09-2014

Our ASA5505 works fine for a handful of VPN users, but ONE client won't work, which happens to be the only Home Premium unit.

I'm sitting at my desk, and I have a W7 Pro x64 machine working right next to a W7 Home Premium x64 machine not working. Both were installed from the same media, which includes the same pre-configured profile. They are both running 5.0.07.0440. I use the same username/password. I tried another Home Premium x64 machine and it doesn't work either. I've tried them wired and wireless.

The logs (at level=2) are similar except the failing machines record some "retransmissions". Ignoring that, they are in lock step until they diverge as shown below. Maybe the "retransmission" is the actual problem, but that doesn't tell me how to fix it. We contracted to have our ASA5505 setup, and the vendor is no longer available, so there isn't a lot of expertise around (e.g. just me, an old hardware guy). Any suggestions would be appreciated!

GOOD LOG

43 16:31:19.375 07/09/14 Sev=Info/4 IKE/0x63000056

Received a key request from Driver: Local IP = 192.168.63.1, GW IP = 74.40.167.114, Remote IP = 0.0.0.0

44 16:31:19.383 07/09/14 Sev=Info/4 IKE/0x63000013

SENDING >>> ISAKMP OAK QM *(HASH, SA, NON, KE, ID, ID) to 74.40.167.114

logs diverge here

45 16:31:19.524 07/09/14 Sev=Info/4 IKE/0x63000014

RECEIVING <<< ISAKMP OAK INFO *(HASH, NOTIFY:STATUS_RESP_LIFETIME) from 74.40.167.114

46 16:31:19.524 07/09/14 Sev=Info/4 IKE/0x63000014

RECEIVING <<< ISAKMP OAK QM *(HASH, SA, NON, KE, ID, ID, NOTIFY:STATUS_RESP_LIFETIME) from 74.40.167.114

47 16:31:19.537 07/09/14 Sev=Info/4 IKE/0x63000013

SENDING >>> ISAKMP OAK QM *(HASH) to 74.40.167.114

48 16:31:22.920 07/09/14 Sev=Info/4 CM/0x63100034

The Virtual Adapter was enabled:

IP=192.168.63.1/255.255.255.0

DNS=192.168.123.2,0.0.0.0

WINS=0.0.0.0,0.0.0.0

Domain=clearcreek.domain

Split DNS Names=

BAD LOG

34 16:39:27.685 07/09/14 Sev=Info/4 IKE/0x63000056

Received a key request from Driver: Local IP = 192.168.63.2, GW IP = 74.40.167.114, Remote IP = 0.0.0.0

35 16:39:27.685 07/09/14 Sev=Info/4 IKE/0x63000013

SENDING >>> ISAKMP OAK QM *(HASH, SA, NON, KE, ID, ID) to 74.40.167.114

logs diverge here

36 16:39:27.685 07/09/14 Sev=Info/4 IKE/0x63000014

RECEIVING <<< ISAKMP OAK TRANS *(Retransmission) from 74.40.167.114

37 16:39:27.685 07/09/14 Sev=Info/4 IKE/0x63000014

RECEIVING <<< ISAKMP OAK TRANS *(Retransmission) from 74.40.167.114

38 16:39:27.685 07/09/14 Sev=Info/4 IKE/0x63000014

RECEIVING <<< ISAKMP OAK TRANS *(Retransmission) from 74.40.167.114

39 16:39:27.685 07/09/14 Sev=Info/4 IKE/0x63000014

RECEIVING <<< ISAKMP OAK INFO *(HASH, DEL) from 74.40.167.114

40 16:39:27.685 07/09/14 Sev=Info/4 IKE/0x63000013

SENDING >>> ISAKMP OAK INFO *(HASH, DEL) to 74.40.167.114

41 16:39:27.701 07/09/14 Sev=Info/4 IKE/0x63000049

Discarding IPsec SA negotiation, MsgID=CCE47AE2

42 16:39:27.701 07/09/14 Sev=Info/4 IKE/0x63000017

Marking IKE SA for deletion (I_Cookie=FC188982F322AEF2 R_Cookie=0171208F0B95DD70) reason = PEER_DELETE-IKE_DELETE_UNSPECIFIED

43 16:39:27.701 07/09/14 Sev=Info/4 IPSEC/0x63700014

Deleted all keys

44 16:39:28.418 07/09/14 Sev=Info/4 IKE/0x6300004B

Discarding IKE SA negotiation (I_Cookie=FC188982F322AEF2 R_Cookie=0171208F0B95DD70) reason = PEER_DELETE-IKE_DELETE_UNSPECIFIED

45 16:39:28.418 07/09/14 Sev=Info/4 CM/0x63100012

Phase 1 SA deleted before first Phase 2 SA is up cause by "PEER_DELETE-IKE_DELETE_UNSPECIFIED". 0 Crypto Active IKE SA, 0 User Authenticated IKE SA in the system

46 16:39:28.543 07/09/14 Sev=Info/4 IKE/0x63000001

IKE received signal to terminate VPN connection

47 16:39:28.590 07/09/14 Sev=Info/4 IPSEC/0x63700014

Deleted all keys

48 16:39:28.590 07/09/14 Sev=Info/4 IPSEC/0x63700014

Deleted all keys

49 16:39:28.590 07/09/14 Sev=Info/4 IPSEC/0x63700014

Deleted all keys

50 16:39:28.590 07/09/14 Sev=Info/4 IPSEC/0x6370000A

IPSec driver successfully stopped

Dinesh Moudgil · ‎07-10-2014

Hi Jim,

At this moment, it seems like the non working system shows the delete event recieved from the headend (39 16:39:27.685 07/09/14 Sev=Info/4 IKE/0x63000014 ,RECEIVING <<< ISAKMP OAK INFO *(HASH, DEL) from 74.40.167.114).

Please start by deleting the .pcf file on this system or trying to configure the connection-profile again on the client.
If this does not help,try to test with local authentication for testing if possible.
Run "debug crypto condition peer <public_ip_of_VPN_client>" and then "debug crypto isakmp 200" and "debug crypto ips 200" for working and non working device and post the results.

For your further knowledge , the error that you are getting , it has been discussed here as follows:-

Verify Idle/Session Timeout

If the idle timeout is set to 30 minutes (default), it means that it drops the tunnel after 30 minutes of no traffic passes through it. The VPN client gets disconnected after 30 minutes regardless of the setting of idle timeout and encounters the PEER_DELETE-IKE_DELETE_UNSPECIFIED error.

Configure idle timeout and session timeout as none in order to make the tunnel always up, and so that the tunnel is never dropped even when using third party devices.

Here is the link for your reference:-
http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/81824-common-ipsec-trouble.html#solution13

Regards,
Dinesh Moudgil

P.S. Please rate helpful posts.

Cisco Network Security Channel - https://www.youtube.com/c/CiscoNetSec/

jimgurley · ‎07-10-2014

Failed on all three suggestions:

I can only copy the PCF file from the working unit. The consultant that created the PCF did not reveal the credentials, so I have to rely on the canned file.

I can't find anything like "local authentication". The PROPERTIES of the connection doesn't include it.

By "run" I assume you mean in a CMD window, in which case "debug" is not a recognized command".

Dinesh Moudgil · ‎07-10-2014

Jim,

The debug commands are to be run on the VPN head end (ASA) while you are trying to connect with the VPN. This will show us why the negotiation is failing for the VPN client.
Regarding authentication, we would need the configuration snippet from ASA to confirm the parameters.
HTH.

Regards,
Dinesh Mooudgil

Cisco Network Security Channel - https://www.youtube.com/c/CiscoNetSec/

jimgurley · ‎07-10-2014

I'll try running debug when I attempt to connect. Does it need to be carefully timed or can it be run after the failure?

I have no idea what "config snippet from ASA" refers to. All VPN clients use the identical PCF file, so I'm not sure how that could be an issue.

Dinesh Moudgil · ‎07-10-2014

The debugs need to be run simultaneously (on ASA) when you try to connect with client.
Can you confirm the type of connection (wireless/wired) that is being used and platform details (Windows 7/XP etc).

Regards,
Dinesh Moudgil

Cisco Network Security Channel - https://www.youtube.com/c/CiscoNetSec/

jimgurley · ‎07-10-2014

The failing client is "Windows 7 Home Premium 64 bit" and is wireless (or wired) to our home network. I can connect successfully with Windows 7 Pro (32 or 64) and WinXP from the same home network. I tried a different client that also runs Home Premium, and it fails as well.

As far as the debug results, once I get past the error with the word "condition", having a successful and failed connection on the same public IP seems like it will muddy the test results.

Dinesh Moudgil · ‎07-10-2014

Can you confirm if this is working with wired or it fails on both wireless and wired connection.

Regards,
Dinesh Moudgil

Cisco Network Security Channel - https://www.youtube.com/c/CiscoNetSec/

jimgurley · ‎07-10-2014

Fails both ways. Both ways work with other non-Home Premium clients.

Dinesh Moudgil · ‎07-10-2014

We will need those debugs output from the ASA that will show us the reason of failed negotiation.

Regards,
Dinesh Moudgil

Cisco Network Security Channel - https://www.youtube.com/c/CiscoNetSec/

jimgurley · ‎07-10-2014

Several posts back I showed the debug command fails with a "^" under the "o" in Connection. I see the copy/paste moved the carat, but it was originally under the "o".

jimgurley · ‎07-10-2014

Also, I'll have to run the debug command via RDP over a working VPN from the same public IP as the failing client, so the results may be funny? I'm not sure how the failure can be IP related since many clients (except for the Home Premium) work from there.

jimgurley · ‎07-10-2014

I tried the debug, and the ASA doesn't recognize the command either.

User Access Verification

Password:
Type help or '?' for a list of available commands.
ClearCreak-ASA> debug crypto condition peer 216.115.15.37
^
ERROR: % Invalid input detected at '^' marker.
ClearCreak-ASA>

When I enabled advanced commands, I get:

ClearCreak-ASA> enable

Password: **********
ClearCreak-ASA# debug crypto condition peer 216.115.15.37
^
ERROR: % Invalid input detected at '^' marker.
ClearCreak-ASA#

bobwire77 · ‎09-27-2014

I am having this exact same problem. All other computers work fine (XP, 7 Pro). But the machine with Windows 7 Home Premium gets "secure vpn connection terminated by peer. reason 433: reason not specified be peer" It is almost instant. The other computers have no such problem. They connect all the time and stay connected for hours. these were installed in the same way using the correct 64 bit installer, 5.0.07.0440. Would LOVE for this to have an easy fix...

Win 7 Home Premium 64 bit error 433