07-09-2014 05:06 PM
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
BAD LOG
07-10-2014 02:03 AM
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).
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.
07-10-2014 09:18 AM
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".
07-10-2014 09:23 AM
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
07-10-2014 10:28 AM
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.
07-10-2014 10:38 AM
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
07-10-2014 10:57 AM
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.
07-10-2014 11:23 AM
Can you confirm if this is working with wired or it fails on both wireless and wired connection.
Regards,
Dinesh Moudgil
07-10-2014 11:29 AM
Fails both ways. Both ways work with other non-Home Premium clients.
07-10-2014 02:58 PM
We will need those debugs output from the ASA that will show us the reason of failed negotiation.
Regards,
Dinesh Moudgil
07-10-2014 03:36 PM
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".
07-10-2014 10:34 AM
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.
07-10-2014 10:43 AM
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#
09-27-2014 07:47 PM
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...
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide