02-01-2009 01:27 PM
<p>Hi Guys,</p>
<p>I'm trying to setup an 1841 as a VPN server for dynamic clients using the Cisco VPN Client (v5)</p>
<p>I'm hitting a snag pretty much straight up. IKE P1, I get a policy mismatch yet looking at the offer versus the policy they match. The mismatch occurs on the authentication pre-share</p>
<p>Obviously, I've miscofigured somewhere. Can anyone point me to some reliable sample config (I've found some on the net, but it typically glosses over a step). Specifically, I'd like to know how the VPN Client handles authentication. It will send a group name with password, but how do I tell the ISAKMP policy what this group name and password will be?</p>
<p>I've used the client configuration option to spell this out, but it isn't doing the trick.</p>
<p>I'm utterly puzzled.</p>
<p>Your help would be much appreciatd.</p>
<p>Cheers</p>
<p>Scott</p>
02-01-2009 06:15 PM
Scott,
Go to this link, there are several config scenarions for configuring your router as VPN server for your clients.
http://www.cisco.com/en/US/products/ps5853/prod_configuration_examples_list.html
Specifically, I'd like to know how the VPN Client handles authentication. It will send a group name with password, but how do I tell the ISAKMP policy what this group name and password will be?
The clients will need to first authenticate the tunnel name for the particular RA tunnel group, this is configured in your router along with pre-share keys.
for example in this link taken from the same link above
crypto isakmp client configuration group vpn vpn will be the tunnel group name the vpn clients will be configuring in the Cisco RA VPN client software, as well as defining a pre-share key as key secret_key, this key provided to your clients when they create the vpn profile.
Then the second type of autentication comes in place after the tunnel group above the user has already gone through successfully.
The user authentication is next, it would all depend on what type of user authentication you will be implementing. Typical a RADIUS server such as Windows AD and IAS could be one method use for authenticating users, or you may also create local users in the router just as the above example shows as another method when no RADIUS or ACS is available,
when using local authenticaion by creating users will add another layer of more admin tasks to you by creating users in the router as suppose to using a RADIUS server like that of MS windows IAS that would already have users in Active Directory.
There are more examples in link provided showing several scenarios using local user database or RADIUS authentication.
Regards
PLS rate any helful post if it helps
02-02-2009 01:15 AM
Hi Jorge,
Thanks, some great links for this topic.
I've been able to progress slightly. It appears I had a typo in my group password.
I have hit another problem however, and before I digest let me say I've followed the config in the link you provided (http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a00801dddbb.shtml) word for word as well as my own initial config (which was the same without profiles)
Anyway, I'm now getting a "%CRYPTO-6-IKMP_NOT_ENCRYPTED: IKE packet from 1.1.1.1 was not encrypted and it should've been"
Ok, so I dont have an ACL for encrypting traffic but this is ISAKMP negotiations - one isnt needed - is it?
And, even if it were, how do I specify it? My clients are dynamic!
I'm all ears for suggestions.
Regards
Scott
02-02-2009 05:55 PM
Scott, is this error comming from when VPN client tries connecting? can you confirm the VPN client is using correct tunnel group password.
Regards
02-02-2009 06:11 PM
Hi Jorge,
Thanks for following this up.
The error comes when the client tries to connect. I've checked, and double checked the group name and password - they are correct (policy negotiation would fail if they weren't).
The client is the Cisco VPN Client 5.0.028 (its the latest one off the Cisco Software Download site).
The error is displayed on the Server from the debug crypto isakmp command.
The client dispalys an error to the effect of: repsonse not received from server.
I think I need to understand the IKE process better since this is where the error is occuring.
During the policy negotiation is the traffic encrypted?
After policy negotiation I understand key exchange is hashed via Diffie Hellman. I'm assuming this is what the router is referring to when it says "Unencrypted packet received" or is it referring to something else?
I'll try this again tonight and post some of the debug from both client and server.
If you have any suggestions in the meantime, i'm all ears.
Cheers
Scott
02-03-2009 06:55 PM
There are couple of good reference links
ISAKMP Phase-1 brake down
understanding Ipsec debugs
http://www.cisco.com/en/US/tech/tk583/tk372/technologies_tech_note09186a00800949c5.shtml
Ipsec
http://www.cisco.com/en/US/tech/tk583/tk372/technologies_tech_note09186a0080094203.shtml
Could you post the isakmp debugs to have a look .
Regards
02-05-2009 01:07 PM
Hi Jorge,
Thanks for the links, very good overview of the process.
Unfortunately, the dont shed any light on my problem. I'll post some debugs this weekend.
Rgds
Scott
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