Phase 2

[stephendrkw]

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

[sachinraja]

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

[stephendrkw]

PFS is not set, both sides

[Jon Marshall]

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

[stephendrkw]

According to customer these match, what else could be the reason for Phase 2 failing?

[Jon Marshall · Accepted solution]

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

[stephendrkw]

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.