[j-nsp] Re: IPSec Interoperability with Cisco Router

Mon Jan 17 21:33:58 EST 2005

Hi Harsit

   Thanks for your quick response. Do you know the timeout(X sec) value KMD is wating since 
whenever the next or periodic  "negotiation is already in progress" logged in the KMD message, 
I can not see any IKE session sending from J20 by using ethereal or monitor traffic. That's what
our customer always complain that we never trigger IKE session in such kind of case.

BR // Eric Shih

-----Original Message-----
From: Harshit Kumar [mailto:harshit at juniper.net]
Sent: Tuesday, January 18, 2005 10:23 AM
To: Eric Shih (TP/ERT)
Cc: juniper-nsp at puck.nether.net
Subject: RE: [j-nsp] IPSec Interoperability with Cisco Router

In case #1 it wont send an IKE message out since one negotiation is
 already in progress.

Here is how kmd works ....

KMD starts the IKE negotiation and waits for the peer to send a response
 for X seconds. While it is waiting in this state, the periodic trigger
 (in < X secs) kicks in again and tries to start the nego again. Since
KMD 
is waiting for peer response and hasn't given up yet, this time it wont
send 
an IKE packet out and  will log the message "negotiation is already in
progress".
 When it has done waiting for X seconds, it will try and send the ike
packet out
 again ....

Harshit

-----Original Message-----
From: Eric Shih (TP/ERT) [mailto:eric.shih at ericsson.com] 
Sent: Monday, January 17, 2005 6:02 PM
To: Harshit Kumar
Cc: juniper-nsp at puck.nether.net
Subject: RE: [j-nsp] IPSec Interoperability with Cisco Router

Hello Harshit

    In case 1, what do you mean by " negotiation is alredy in progress"
? Becasue when we use monitor traffic or ethereal to capture
packet from J20, it seems that no IKE packet transmit from J20.  However
in case 2, I do see the IKE retransmit in kmd log or
live tracing packets. I am wandering if we have case 1 log message, does
J20 will not re-transmit the IKE seesion ? What we
only see in kmd log is periodic case 1 message but no ike seesion ?
Thanks for your support !!

BR // Eric Shih

-----Original Message-----
From: Harshit Kumar [mailto:harshit at juniper.net]
Sent: Tuesday, January 18, 2005 4:33 AM
To: Eric Shih (TP/ERT); juniper-nsp at puck.nether.net
Subject: RE: [j-nsp] IPSec Interoperability with Cisco Router

Hi Eric,

#1  is a periodic trigger to start the ike negotiation, but it finds
 that the negotiation is already in progress. Not harmful.

#2 Indicates this end is trying to establish the IKE session but the
 other end doesn't seem to be responding. Either due to packet drop
 or due to config error on the other end.

The messages like the following indicate that the IKE negotiation is
initiated
 by the J20. You can only see them if you set [security traceoptions
flag ike]

Jan 17 12:27:05 jnp_ike_connect: Start, remote_name = 7.7.7.2:500, xchg
=
2, flags = 00010000
Jan 17 12:27:05 ike_sa_allocate: Start, SA = { 3d3c4eb8 987e5e6f -
00000000 00000000 }

Harshit

-----Original Message-----
From: Eric Shih (TP/ERT) [mailto:eric.shih at ericsson.com] 
Sent: Monday, January 17, 2005 6:59 AM
To: juniper-nsp at puck.nether.net
Cc: Harshit Kumar
Subject: RE: [j-nsp] IPSec Interoperability with Cisco Router

Hello Harshit

    I think we have found out the problem. It may a firewall in-between
that prohibits the ISAKMP packets initiated from M20.
    However, there seems no extra log to prove that M20 does initiate a
session. There's only below message 1. Do you have
   any idea of thease messages ? However, for other tunnel without FW
in-between that prohibits the ISAKMP service,the kmd 
   message will show as below message 2. It seems that M20 will
retransmit the ISAKMP packet and tunnel will not 
   established because of timout.That's what I confused.

   1.
    Negotiation already started for
p1_local=ipv4(udp:500,[0..3]=211.77.241.245)
                p1_remote=ipv4(udp:500,[0..3]=203.74.252.2)
                p2_local=ipv4_subnet(any:0,[0..7]=10.3.2.0/24)
                p2_remote=ipv4_subnet(any:0,[0..7]=10.0.0.0/8)

    2.
    Jan 17 22:01:00 ike_retransmit_callback: Start, retransmit SA = {
4b77d272 1600a1f5 - 00000000 00000000}, nego = -1
    Jan 17 22:01:00 ike_retransmit_callback: Isakmp query retry limit
reached, deleting
    Jan 17 22:01:00 Phase-1 [initiator] failed with error(Timeout) for
                local=ipv4(udp:500,[0..3]=211.77.241.241)
                remote=ipv4(udp:500,[0..3]=211.73.135.29)
    Jan 17 22:01:00 Phase-1 negotiation timeout for
p1_local=ipv4(udp:500,[0..3]=211.77.241.241)
                p1_remote=ipv4(udp:500,[0..3]=211.73.135.29)
    Jan 17 22:01:00 211.77.241.241:500 (Initiator) <-> 211.73.135.29:500
{ 4b77d272 1600a1f5 - 00000000 00000000 [-1] / 0x00000000 } IP; Error = 
                Timeout    (8197)

-----Original Message-----
From: Harshit Kumar [mailto:harshit at juniper.net]
Sent: Friday, January 14, 2005 10:16 AM
To: Eric Shih (TP/ERT); juniper-nsp at puck.nether.net
Subject: RE: [j-nsp] IPSec Interoperability with Cisco Router

Hi Eric,
              Sorry for the late reply. Please contact JTAC and open a
case 
 with them.

Thanks
Harshit

-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net
[mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Eric Shih
(TP/ERT)
Sent: Saturday, January 01, 2005 7:26 PM
To: juniper-nsp at puck.nether.net
Subject: [j-nsp] IPSec Interoperability with Cisco Router

Hello Harshit

   Because our J20(M20) is using ES-PIC for IPSec tunnel insted of
AS-PIC, there's no command you mention.
We have tried with Cisco 1760 and Cisco PIX firewall which have same
problem. 

BR
Eric

_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
http://puck.nether.net/mailman/listinfo/juniper-nsp