Link to home
Start Free TrialLog in
Avatar of mcstechguru1978
mcstechguru1978Flag for United States of America

asked on

Cisco VPN Crypto Map

I am having trouble adding a new IPSec VPN to a Cisco 1712 router.  There is currently a site-to-site VPN with an existing crypto map assigned to the external interface f0.  Below is the configuration information needed for this.  The problem I am having is I can not get past Phase 1 negotiation.  Here is a small snip of the output from a debug on isakmp:  
--
Jul 25 01:48:53.071: ISAKMP : Scanning profiles for xauth ...
*Jul 25 01:48:53.071: ISAKMP:(0:0:N/A:0):Checking ISAKMP transform 1 against priority 10 policy
*Jul 25 01:48:53.071: ISAKMP:      life type in seconds
*Jul 25 01:48:53.071: ISAKMP:      life duration (basic) of 3600
*Jul 25 01:48:53.075: ISAKMP:      encryption AES-CBC
*Jul 25 01:48:53.075: ISAKMP:      keylength of 256
*Jul 25 01:48:53.075: ISAKMP:      auth XAUTHInitPreShared
*Jul 25 01:48:53.075: ISAKMP:      hash SHA
*Jul 25 01:48:53.075: ISAKMP:      default group 2
*Jul 25 01:48:53.075: ISAKMP:(0:0:N/A:0):Encryption algorithm offered does not match policy!
*Jul 25 01:48:53.075: ISAKMP:(0:0:N/A:0):atts are not acceptable. Next payload is 3
----------




aaa authentication login 2Phase local-case
aaa authentication login userauthen local
aaa authorization network groupauthor local
aaa session-id common
ip subnet-zero
!
!
!
!
no ip domain lookup
ip domain name yourdomain.com
ip cef
ip inspect name FIREWALL tcp
ip inspect name FIREWALL udp
ip inspect name FIREWALL ftp
ip ids po max-events 100
no ftp-server write-enable
!
!
!
!
!
!
crypto isakmp policy 10
 encr 3des
 authentication pre-share
 group 2
!
crypto isakmp policy 20
 encr 3des
 hash md5
 authentication pre-share
 group 2
!
crypto isakmp policy 100
 encr 3des
 authentication pre-share
 group 2
crypto isakmp key A$Cs2sK3y address 65.x.x.x
crypto isakmp key A$Cs2sK3y address 12.x.x.x no-xauth
crypto isakmp keepalive 30 10
!
crypto isakmp client configuration group clientvpn
 key p@ssw0rd
 dns 192.168.40.10 192.168.40.1
 domain xxxx.local
 pool clientvpnpool
 acl 140
!
!
crypto ipsec transform-set s2stunnel esp-3des esp-sha-hmac
crypto ipsec transform-set clientvpn esp-3des esp-sha-hmac
!
crypto dynamic-map dynmap 10
 set transform-set clientvpn
!
!
crypto map ascs2s 10 ipsec-isakmp
 set peer 65.x.x.x
 set transform-set s2stunnel
 match address 120
crypto map ascs2s 140 ipsec-isakmp
 set peer 12.x.x.x
 set security-association lifetime seconds 86400
 set transform-set s2stunnel
 match address Nueterra-KC1
crypto map ascs2s 210 ipsec-isakmp dynamic dynmap
!
crypto map clientmap client authentication list userauthen
crypto map clientmap isakmp authorization list groupauthor
crypto map clientmap client configuration address respond
crypto map clientmap 10 ipsec-isakmp dynamic dynmap
!
!
!
interface Tunnel140
 ip address 10.248.40.2 255.255.255.0
 ip tcp adjust-mss 1400
 keepalive 10 3
 tunnel source 10.250.40.1
 tunnel destination 10.250.248.1
!
interface Loopback140
 ip address 10.250.40.1 255.255.255.255
!
interface BRI0
 no ip address
 shutdown
 no cdp enable
!
interface FastEthernet0
 description ***xxxxxxxxx***
 ip address 216.x.x.x  255.255.255.248
 ip access-group out-in in
 ip nat outside
 ip inspect FIREWALL out
 ip virtual-reassembly
 speed auto
 full-duplex
 no cdp enable
 crypto map ascs2s
!
!
!
!
!
ip local pool clientvpnpool 10.16.20.1 10.16.20.200
!
!
!
ip nat inside source route-map nonatvpn interface FastEthernet0 overload
!
!
!
!access-list 140 permit ip 192.168.40.0 0.0.0.255 10.16.20.0 0.0.0.255
Avatar of rfc1180
rfc1180
Flag of United States of America image

your logging:

*Jul 25 01:48:53.075: ISAKMP:      encryption AES-CBC
*Jul 25 01:48:53.075: ISAKMP:      keylength of 256

indicates that the other side is sending AES 256, but none of your policies have AES 256

You need to ensure that all phase 1 and phase 2 information matches on both ends.

Billy
Avatar of asavener
Either you need to add a new isakmp policy using AES 256, or they need to add an isakmp policy that matches one that you have defined.

Try adding these lines:

crypto isakmp policy 5
 encr aes 256
 authentication pre-share
 group 2
Avatar of mcstechguru1978

ASKER

I don't think  it is the policy, I believe it is on having a dynamic crypto as another line on the existing crypto for site to site.  I did had the above policy, no go.  I have attached a complete debug on isakmp when attempting to connect.
 Isakmp-Debug.txt
I should add, I am using 2 clients to test this connection, Mac OS 10.6.6 using the built in Cisco IPSec client and Win 7 Ultimate using the Cisco IPSec client version 5.0.07.0410.
*Jul 25 15:07:37.168: ISAKMP:(0:0:N/A:0):Checking ISAKMP transform 5 against priority 10 policy
*Jul 25 15:07:37.168: ISAKMP:      life type in seconds
*Jul 25 15:07:37.168: ISAKMP:      life duration (basic) of 3600
*Jul 25 15:07:37.168: ISAKMP:      encryption 3DES-CBC
*Jul 25 15:07:37.168: ISAKMP:      auth XAUTHInitPreShared
*Jul 25 15:07:37.168: ISAKMP:      hash SHA
*Jul 25 15:07:37.168: ISAKMP:      default group 2
*Jul 25 15:07:37.168: ISAKMP:(0:0:N/A:0):Xauth authentication by pre-shared key offered but does not match policy!
It's actually finding a matching policy, but it's failing when it sends the pre-shared key.
Here's a nice runthrough:  http://www.ciscoblog.com/archives/2006/12/configuring_a_c.html

If you continue having difficulty, I'd suggest that you create a new crypto map with just the dynamic VPN, then you can avoid any interference from the site-to-site VPN configuration.
I have been over this several ways trying different transform sets, etc.  I will have to get this to work within the existing crypto map when just had the site to site originally.  As far as the pre-shared key, I have checked multiple times and created a new one, still the same outcome.  With the pre-shared key failing, that has me going back to the existing crypto map, the dynamic I need applied, I do not think is getting used.
Yes, that is why you need to eliminate confounding variables.  If it works without the rest of the crypto map, then that tells you something.  If it still doesn't work without the rest of the crypto map, then that tells you something different.
I will try that tonight.  Will need to wait until that facility is closed to take down that tunnel to test with a new map.
I applied the clientmap crypto directly to the outside interface and get the exact same policy match errors.
Well, no go on this way  configuring.  What about a crypto isakmp profile and a virtual template to get this going?  What would be a configuration guide for that?
Well I tried going down the profile router, but when I went to configure a virtual template, not all the commands where available to create a tunnel.  Any suggestions?
If you're getting an error with the pre-share key, then there's a problem with your pre-share key..

Make sure you don't have a trailing space; I've seen that mess up a lot of Cisco passwords.  A space is not a valid character for the leading character, but it's a valid character thereafter.
I have tried multiple different keys with the same results.
What IOS version are you running?
Sorry for the delay.  Version 12.2(7t)XM4

flash:c1700-k9o3sy7-mz.123-7.XR.bin
ASKER CERTIFIED SOLUTION
Avatar of asavener
asavener
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
LOL.  12.2(15) is from October of 2003....
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Will do.  That was the next step, waiting on smart net renewal.
Any update?
Yes. Sorry. IOS upgrade fixed the problem.  I have am ACL problem now.  When connected from the client, ICMP traffic to the allowed inside network returns a reply from the outside interface.  Thoughts?
What reply does it receive?

I've seen where the access list on the outside interface need an entry for the decrypted traffic.

Try inserting the line "permit ip 10.16.20.0 0.0.0.255 any" into your out-in access-list.
I will give that a go.
Rereading, i'm unclear on whether the issue is with the LAN-to-LAN tunnel, or the dynamic connections.

If it's the LAN-to-LAN, you may need "permit GRE any any"
This is for the remote-access VPN.  The GRE tunnel works fine.
Agreed and worked.  IOS fixed the issue. Along with a few ACL adjustments.