Netscreen 25 to Cisco 2801 failing on phase2 negotiations



  • Trying to setup a tunnel between my Netscreen 25 and a branch office Cisco 2801.

    I keep getting the following error during Phase 2 negotiations. I’ve tried every different setting but regardless of what i choose on the netscreen I keep getitng the message, which would lead me to believe that the problem is on the Cisco side but the Cisco admin insists it’s set right.

    2006-03-13 13:56:34 info IKE: Removed Phase 2 SAs after receiving a notification message.
    2006-03-13 13:56:34 info IKE<209.58.252.170>: Received a notification message for DOI <1> <14> <no_proposal_chosen>.
    2006-03-13 13:56:34 info IKE<209.58.252.170> Phase 2: Initiated negotiations.

    Here’s the debug logs as well

    13:44:51 : IKE<209.58.252.170 > ****** Recv kernel msg IDX-14, TYPE-5 ******

    13:44:51 : IKE<209.58.252.170 > sa orig index<14>, peer_id<16>.

    13:44:51 : IKE<209.58.252.170 > isadb get entry by peer/local ip and port

    13:44:51 : IKE<209.58.252.170 > SA: (Root, local 63.133.150.18, state 3/182

    f +, i):

    13:44:51 : IKE<209.58.252.170 > start transit to qm state (3/182f)

    13:44:51 : IKE<209.58.252.170 > Phase 2: Initiated negotiation.

    –- more —

    13:44:51 : IKE<209.58.252.170 > Phase-2: start quick mode negotiation

    13:44:51 : IKE<209.58.252.170 > Create conn entry…

    13:44:51 : IKE<209.58.252.170 > …done(new 8b548db5)

    13:44:51 : IKE<209.58.252.170 > Initiator not set commit bit on 1st QM.

    13:44:51 : IKE<0.0.0.0 > dh group 2

    13:44:51 : IKE<209.58.252.170 > DH_BG_consume OK. p2 init

    13:44:51 : IKE<0.0.0.0 > add sa list for msg id <8b548db5>

    13:44:51 : IKE<209.58.252.170 > 0,0/0(0)/spi(b51e90bc)/keylen(0)

    13:44:51 : IKE<209.58.252.170 > Construct ISAKMP header.

    13:44:51 : IKE<209.58.252.170 > Msg header built (next payload #8)

    13:44:51 : IKE<209.58.252.170 > Construct [HASH]

    13:44:51 : IKE<209.58.252.170 > Construct [SA] for IPSEC

    13:44:51 : IKE<209.58.252.170 > Set IPSEC SA attrs: lifetime(3600/0)

    13:44:51 : IKE<209.58.252.170 > atts<00000003 00000000 00000003 00000002 00000001 00000002>

    13:44:51 : IKE<209.58.252.170 > proto(3)<esp>, esp(3)<esp_3des>, auth(2)<sha>, encap(1)<tunnel>, group(2)

    13:44:51 : IKE<209.58.252.170 > Before NAT-T attr unmap: private tunnel = 1

    .

    13:44:51 : IKE<209.58.252.170 > After NAT-T attr unmap: private tunnel = 1.

    13:44:51 : IKE<209.58.252.170 > Set IPSEC SA attrs: lifetime(3600/0)

    13:44:51 : IKE<209.58.252.170 > atts<00000003 00000000 00000002 00000002 00000001 00000002>

    13:44:51 : IKE<209.58.252.170 > proto(3)<esp>, esp(2)<esp_des>, auth(2)<sha>, encap(1)<tunnel>, group(2)

    13:44:51 : IKE<209.58.252.170 > Before NAT-T attr unmap: private tunnel = 1

    .

    13:44:51 : IKE<209.58.252.170 > After NAT-T attr unmap: private tunnel = 1.

    –- more —

    13:44:51 : IKE<209.58.252.170 > IKE P2 ID saved in nsp_tunnel (sa id 14) is …

    13:44:51 : IKE<209.58.252.170 > local 10.11.1.0/22 prot<0> port<0> type<4> remote 192.168.0.1/22 prot<0> port<0> type<4>

    13:44:51 : IKE<209.58.252.170 > Policy have separate SA. Use P2 ID from policy sa (22).

    13:44:51 : IKE<209.58.252.170 > Initiator P2 ID built: 10.11.1.0/22 prot<0> port<0> type<4>

    13:44:51 : IKE<209.58.252.170 > Responder P2 ID built: 192.168.0.1/24 prot<

    0> port<0> type<4>

    13:44:51 : IKE<209.58.252.170 > Construct [NONCE] for IPSec

    13:44:51 : IKE<209.58.252.170 > Construct [KE] for PFS

    13:44:51 : IKE<209.58.252.170 > Construct [ID] for Phase 2

    13:44:51 : IKE<209.58.252.170 > id payload constructed. type(4),ip(0a0b0100

    ),mask(fffffc00)

    13:44:51 : IKE<209.58.252.170 > Construct [ID] for Phase 2

    13:44:51 : IKE<209.58.252.170 > id payload constructed. type(4),ip(c0a80001

    ),mask(ffffff00)

    13:44:51 : IKE<209.58.252.170 > construct QM HASH

    13:44:51 : IKE<209.58.252.170 > Xmit*: [HASH] [SA] [NONCE] [KE] [ID] [ID]

    13:44:51 : IKE<209.58.252.170 > Encrypt P2 payload (len 340)

    13:44:51 : IKE<209.58.252.170 > send_request to peer

    13:44:51 : IKE<209.58.252.170 > Send Phase 2 packet (len=348)

    13:44:51 : IKE<209.58.252.170 > negotiating p2 -260252 seconds before SA <spi 00000000="">expires

    13:44:51 : IKE<209.58.252.170 > ike packet, len 200, action 0

    13:44:51 : IKE<0.0.0.0 > coach. sock 256

    13:44:51 : IKE<209.58.252.170 > ****** Recv packet if <ethernet3>of vsys <root>******

    –- more —

    13:44:51 : IKE<209.58.252.170 > Catcher: get 172 bytes. src port 500

    13:44:51 : IKE<209.58.252.170 > SA: (Root, local 63.133.150.18, state 3/182f +, i):

    13:44:51 : IKE<209.58.252.170 > ISAKMP msg: len 172, nxp 8[HASH], exch 5[INFO], flag 01 E

    13:44:51 : IKE<209.58.252.170 > Create conn entry…

    13:44:51 : IKE<209.58.252.170 > …done(new fb937220)

    13:44:51 : IKE<209.58.252.170 > Decrypting payload (length 144)

    13:44:51 : IKE<209.58.252.170 > Recv*: [HASH] [NOTIF]

    13:44:51 : IKE<209.58.252.170 > Process [NOTIF]:

    13:44:51 : IKE<209.58.252.170 > Received notify message for DOI <1> <14> <no_proposal_chosen>.

    13:44:51 : IKE<209.58.252.170 > ah-esp: notify has no matching QM record, mess_id in <fb937220>centry<8b548db5>

    13:44:51 : IKE<209.58.252.170 > process notify exit with <0>.

    13:44:51 : IKE<209.58.252.170 > Delete conn entry…

    13:44:51 : IKE<209.58.252.170 > …found(fb937220)

    13:44:51 : IKE<0.0.0.0 > proc_other_session_notify->

    13:44:51 : IKE<0.0.0.0 > process Notify Payload: doi(1), msg(14),txt <no_proposal_chosen>## 13:44:51 : IKE<0.0.0.0 > IKE: Removed Phase 2 SAs after receiving anotification message.

    13:44:51 : IKE<209.58.252.170 > Delete conn entry…

    13:44:51 : IKE<209.58.252.170 > …found(8b548db5)

    13:44:51 : IKE<209.58.252.170 > IKE msg done: PKI state<0> IKE state<3/182f</no_proposal_chosen></fb937220></no_proposal_chosen></root></ethernet3></spi></tunnel></sha></esp_des></esp></tunnel></sha></esp_3des></esp></no_proposal_chosen>



  • @mwdmeyer:

    @MaxPipeline:

    BTW, NAT-traversal has nothing to do with the problem. Nat-t is negotiated in p1 and will either be used or it won’t based on both sides configuration. It will not affect the outcome of p2 negotiations.

    Although I would normally agree with you. I had this problem last week and it took a bit of debugging as it looked like a P2 error. Once I turned off NAT-T everything seemed to work fine, odd.

    Perhaps you had an issue with one side using nattv1 and the other was using nattv2. The difference is v1 encaps ESP in udp 500 packets whereas v2 uses UDP 4500. Just a thought.



  • @MaxPipeline:

    BTW, NAT-traversal has nothing to do with the problem. Nat-t is negotiated in p1 and will either be used or it won’t based on both sides configuration. It will not affect the outcome of p2 negotiations.

    Although I would normally agree with you. I had this problem last week and it took a bit of debugging as it looked like a P2 error. Once I turned off NAT-T everything seemed to work fine, odd.



  • Thanks MaxPipeline.

    Once I had the admin on the other side kick the tunnel off from his end I immediatly saw the issues and modified my end to have the proposals he was sending me.



  • 13:44:51 : IKE<209.58.252.170 > Received notify message for DOI <1> <14> <no_proposal_chosen>.

    So it seems the Netscreen is the initiator and the Cisco is the responder. This would be easier to troubleshoot if the Cisco was the initiator. Can this be arranged? Otherwise according to the message above it seems the Cisco failed negotiations because the Cisco could not agree to any of the Netscreen’s p2 proposals or there was a proxy-id mismatch. Make sure the Cisco can accept p2-esp-des-sha or p2-esp-3des-sha. Also make sure the Cisco has correct proxy-id to match. If the Netscreen is sending proxy-id local 10.11.1.0/22 remote 192.168.0.1/22 then the Cisco would need to be the opposite (local 192.168.0.1/22 remote 10.11.1.0/22).

    BTW, NAT-traversal has nothing to do with the problem. Nat-t is negotiated in p1 and will either be used or it won’t based on both sides configuration. It will not affect the outcome of p2 negotiations.</no_proposal_chosen>



  • According to the web config it IS turned off.



  • Can you try turning off NAT translation in P1/gateway on the netscreen?


 

33
Online

38.4k
Users

12.7k
Topics

44.5k
Posts