Knowledge Search


×
 

[Archive] Failing Phase 2 VPN negotiation with Cisco VPN concentrator

  [KB3284] Show Article Properties


Summary:
Failing Phase 2 VPN negotiation with Cisco VPN concentrator
Symptoms:
Cisco debug:

38093 06/23/2005 18:28:35.300 SEV=4 IKE/120 RPT=14250 10.10.10.52
Group [10.10.10.52]
PHASE 2 COMPLETED (msgid=8b105e59)
38094 06/23/2005 18:28:39.300 SEV=4 IKEDBG/97 RPT=11125 10.10.10.52
Group [10.10.10.52]
QM FSM error (P2 struct &0x5dedd40, mess id 0x8b105e59)!
<<<<<<<<<<< HERE
38098 06/23/2005 18:28:40.990 SEV=4 IKE/119 RPT=11144 10.10.10.52
Group [10.10.10.52]
PHASE 1 COMPLETED 38099 06/23/2005 18:28:40.990 SEV=4 AUTH/22 RPT=11136 10.10.10.52
User [10.10.10.52] Group [10.10.10.52] connected, Session Type: IPSec/LAN-to -LAN
38102 06/23/2005 18:28:41.030 SEV=5 IKE/231 RPT=12339 10.10.10.52
Group [10.10.10.52] Could not find centry for IPSec SA delete message
<<<<<<<<<<<< HERE
## 17:24:39 : IKE<192.168.10.71   >   Start by finding matching member SA (verify -1/2)
## 17:24:39 : IKE<192.168.10.71   >   Verify sa: index 2
## 17:24:39 : IKE<192.168.10.71   >   IKE<192.168.10.71> Matching policy: gw ip <192.168.10.71> peer entry id<11>
## 17:24:39 : IKE<192.168.10.71   >   Local  ID: 192.168.11.0/24 prot<0> port<0> type<4>
## 17:24:39 : IKE<192.168.10.71   >   Remote ID: 172.16.128.0/20 prot<0> port<0> type<4>
## 17:24:39 : IKE<0.0.0.0        >   protocol matched expected<0>.
## 17:24:39 : IKE<0.0.0.0        >   port matched expect<0>.
## 17:24:39 : IKE<0.0.0.0        >   local address matched.
## 17:24:39 : IKE<0.0.0.0        >   remote address matched.
## 17:24:39 : IKE<192.168.10.71   >   Proxy ID match: Located matching Phase 2 SA <188>.
## 17:24:39 : IKE<192.168.10.71   >   send_request to peer
## 17:24:39 : IKE<192.168.10.71   >   Send Phase 2 packet (len=52) 
<<<<<<<<<<<<<<<<<<<< NS sends phase 2
## 17:24:39 : ms 64232014 rt-timer callback
## 17:24:39 : ms 64232021 rt-timer callback
## 17:24:39 : IKE<192.168.10.71   >   hdr
## 17:24:39 : IKE<192.168.10.71   >   ike packet, len 320, action 0
## 17:24:39 : IKE<0.0.0.0        >   coach. sock 2048
## 17:24:39 : IKE<192.168.10.71   > ****** Recv packet if <ethernet2/1> of vsys <Root> ******
## 17:24:39 : IKE<192.168.10.71   >   Catcher: get 292 bytes. src port 500
## 17:24:39 : IKE<192.168.10.71   >   SA: (Root, local 10.10.10.52, state 3/182f +, i):
## 17:24:39 : IKE<192.168.10.71   >   ISAKMP msg: len 292, nxp 8[HASH], exch 32[QM], flag 01  E
## 17:24:39 : IKE<192.168.10.71   >   Receive re-transmit IKE phase 2 packet, SA(192.168.10.71) exchg(32) len(292)
## 17:24:39 : ms 64232132 rt-timer callback
## 17:24:40 : ms 64233009 rt-timer callback
## 17:24:40 : ms 64233011 rt-timer callback
## 17:24:41 : ms 64234011 rt-timer callback
## 17:24:41 : ms 64234015 rt-timer callback
## 17:24:42 : ms 64235015 rt-timer callback
## 17:24:42 : ms 64235018 rt-timer callback
## 17:24:43 : IKE<0.0.0.0        >   IKE: phase-2 packet re-trans timer expired
## 17:24:43 : IKE<192.168.10.71   >   phase-2 packet re-trans timer expired. 
                <<<< Re-transmitt timer expired.

When the Cisco initiates the connection the both SAs come up and traffic passes Netscreen initiates the connection we pass phase 1 and negotiate phase 2. Traces from NS Side and you can see the netscreen is sending an encrypted phase 2 message. NS actually resends the message a few times and times out. We then delete the SA in that direction, which is the reason why we only see one SA active.
Solution:

There is a setting on the Netscreen that is preventing the SA from coming up.

set ike responder-set-commit

This command allows the initiator to send a request to confirm the establishment of the new IPSEC SA. The responder does not use the new sa until it receives this confirmation.  This is part of the RFC 2408 under the commit bit. I'm not sure if the commit bit is configured on the VPN concentrator, but it seems to point to an interop issue between our devices.

The Commit Bit can be set (at anytime) by either party participating in the SA establishment, and can be used during both phases of an ISAKMP SA establishment. However, the value MUST be reset after the Phase 1 negotiation.

From what we observed, phase 1 established, but phase 2 did not. Somewhere during the negotiation, one side did not receive a confirmation.

mktg:NS500(M)-> get config | i respond
set ike responder-set-commit
set ike respond-bad-spi 1
mktg:NS500(M)-> unset ike responder-set-commit

mktg:NS500(M)-> get sa
total configured sa: 38
HEX ID Gateway Port Algorithm SPI Life:sec kb Sta PID vsys
000000a6< 192.168.10.71 500 esp: des/md5 73ff2c38 expir unlim I/I 208 0 <<< DOWN
000000a6> 192.168.10.71 500 esp: des/md5 2f58f200 expir unlim I/I 207 0

mktg:NS500(M)-> ping 172.16.128.24 from eth3/1
Type escape sequence to abort

Sending 5, 100-byte ICMP Echos to 172.16.128.24, timeout is 2 seconds from ethernet3/1
!!!!!
Success Rate is 100 percent (5/5), round-trip time min/avg/max=38/59/85 ms
mktg:NS500(M)-> get sa
total configured sa: 38
HEX ID Gateway Port Algorithm SPI Life:sec kb Sta PID vsys
000000a6< 192.168.10.71 500 esp: des/md5 73ff3485 3575 unlim A/U 208 0 << ACTIVE/UP
000000a6> 192.168.10.71 500 esp: des/md5 38307bd9 3575 unlim A/U 207

Related Links: