01-17-2007 06:37 AM
Having problems establishing Phase 2 with customer (see debug ouput), have double checked both ends of the configure and looks fine. Have tried aes-256, sha1 and 3des-md5. Below is my config and debug errors. What could be wrong?
router
crypto isakmp policy 20
encr 3des
hash md5
authentication pre-share
group 2
lifetime 3600
!
crypto isakmp key ******** address 205.x.x.x
!
crypto ipsec transform-set steve-3des-md5 esp-3des esp-md5-hmac
!
crypto map DrKW-IPSEC 140 ipsec-isakmp
description link to ******
set peer 205.x.x.x
set security-association lifetimem seconds 86400
set transform-set Steve-3des-md5
match address Hello
!
!
ip access-list extended hello
permit ip 63.x.x.x0 0.0.0.255 host 172.x.x.x
permit ip 63.x.x.x.0 0.0.0.255 host 172.x.x.x
!
!
!
debug
*Jan 17 13:14:24: ISAKMP (0:268437817): received packet from 205.x.x.x dport 500 sport 500 Global (R) QM_IDLE
*Jan 17 13:14:24: ISAKMP: set new node -1007386051 to QM_IDLE
*Jan 17 13:14:24: ISAKMP:(0:2361:HW:2): processing HASH payload. message ID = -1007386051
*Jan 17 13:14:24: ISAKMP:(0:2361:HW:2): processing SA payload. message ID = -1007386051
*Jan 17 13:14:24: ISAKMP:(0:2361:HW:2):Checking IPSec proposal 1
*Jan 17 13:14:24: ISAKMP: transform 1, ESP_3DES
*Jan 17 13:14:24: ISAKMP: attributes in transform:
*Jan 17 13:14:24: ISAKMP: SA life type in seconds
*Jan 17 13:14:24: ISAKMP: SA life duration (VPI) of 0x0 0x0 0xE 0x10
*Jan 17 13:14:24: ISAKMP: authenticator is HMAC-MD5
*Jan 17 13:14:24: ISAKMP: encaps is 1 (Tunnel)
*Jan 17 13:14:24: ISAKMP:(0:2361:HW:2):atts are acceptable.
*Jan 17 13:14:24: IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) INBOUND local= 63.x.x.x, remote= 205.x.x.x,
local_proxy= 63.x.0.0/255.255.0.0/0/0 (type=4),
remote_proxy= x.x.x.x/255.255.255.255/0/0 (type=1),
protocol= ESP, transform= esp-3des esp-md5-hmac (Tunnel),
lifedur= 0s and 0kb,
spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x2
*Jan 17 13:14:24: IPSEC(validate_transform_proposal): no IPSEC cryptomap exists for local address 63.x.x.x
*Jan 17 13:14:24: ISAKMP:(0:2361:HW:2): IPSec policy invalidated proposal
*Jan 17 13:14:24: ISAKMP:(0:2361:HW:2): phase 2 SA policy not acceptable! (local 63.x.x.x remote 205.x.x.x)
*Jan 17 13:14:24: ISAKMP: set new node 128920500 to QM_IDLE
*Jan 17 13:14:24: ISAKMP:(0:2361:HW:2):Sending NOTIFY PROPOSAL_NOT_CHOSEN protocol 3
spi 1720817752, message ID = 128920500
*Jan 17 13:14:24: ISAKMP:(0:2361:HW:2): sending packet to 205.x.x.x my_port 500 peer_port 500 (R) QM_IDLE
*Jan 17 13:14:24: ISAKMP:(0:2361:HW:2):purging node 128920500
*Jan 17 13:14:24: ISAKMP:(0:2361:HW:2):deleting node -1007386051 error TRUE reason "QM rejected"
*Jan 17 13:14:24: ISAKMP (0:268437817): Unknown Input IKE_MESG_FROM_PEER, IKE_QM_EXCH: for node -1007386051: state = IKE_QM_READY
*Jan 17 13:14:24: ISAKMP:(0:2361:HW:2):Node -1007386051, Input = IKE_MESG_FROM_PEER, IKE_QM_EXCH
*Jan 17 13:14:24: ISAKMP:(0:2361:HW:2):Old State = IKE_QM_READY New State = IKE_QM_READY
*Jan 17 13:14:24: %CRYPTO-6-IKMP_MODE_FAILURE: Processing of Quick mode failed with peer at 205.x.x.x
Solved! Go to Solution.
01-18-2007 05:57 AM
Stephen
My experience with L2L VPN's is that Phase 2 fails mainly for one of two reasons.
1) Incorrect parameters eg lifetimes, pfs settings, encryption etc.
2) Incorrect local and remote subnets. In the output you sent you have x out the remote address - does this address match what you have in your access-list ?
Jon
01-17-2007 09:53 AM
hello,
can you check if PFS 2 is enabled both sides? sometimes if PFS 2 is enabled on one side and not on other, the phase 2 may fail.
Raj
01-18-2007 04:15 AM
PFS is not set, both sides
01-18-2007 01:00 AM
Hi
In addition to checking PFS can you also check with customer that they have the same settings for the the remote and local subnet. ie.
Your local subnet 63.x.x.x /24, your remote subnet 172.x.x.x/32
Their local subnet 172.x.x.x/32, their remote subnet 63.x.x.x/24
HTH
01-18-2007 04:17 AM
According to customer these match, what else could be the reason for Phase 2 failing?
01-18-2007 05:57 AM
Stephen
My experience with L2L VPN's is that Phase 2 fails mainly for one of two reasons.
1) Incorrect parameters eg lifetimes, pfs settings, encryption etc.
2) Incorrect local and remote subnets. In the output you sent you have x out the remote address - does this address match what you have in your access-list ?
Jon
01-18-2007 06:34 AM
Jon,
Speaking to the customer again, they overload any outbound connections to their FW IP. For some reason they gave us their RFC1918 internal address, instead of the overload address.
Removed ACL, added new ACL.
Tunnel now working. Thanks.
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