Screen OS

last person joined: 8 months ago 

This is a legacy community with limited Juniper monitoring.
  • 1.  Policy Based VPN debug clarification

    Posted 04-25-2014 01:32

    hey everyone.

     

    Ive been debugging a recent policy based VPN and got to the following point:

     

             IKE<x.x.x.x> Phase 2 received:
    ##  : IKE<x.x.x.x> atts<00000003 00000000 00000003 00000001 00000001 00000002>
    ##  : IKE<x.x.x.x> proto(3)<ESP>, esp(3)<ESP_3DES>, auth(1)<MD5>, encap(1)<TUNNEL>, group(2)
    ##  : IKE<x.x.x.x> expect [0]:
    ##  : IKE<x.x.x.x> atts<00000003 00000000 00000003 00000001 00000001 00000000>
    ##  : IKE<x.x.x.x> proto(3)<ESP>, esp(3)<ESP_3DES>, auth(1)<MD5>, encap(1)<TUNNEL>, group(0)
    ##  : IKE<x.x.x.x> proposal not acceptable, but no more proposal in payload.
    ##  : IKE<x.x.x.x> Phase 2: Rejected proposals from peer. Negotiations failed.
    ##  : IKE<x.x.x.x> (3,r): ERROR: 
    Error: processing quick-mode payloads
    ##  : IKE<x.x.x.x> oakley_process_quick_mode():exit
    ##  : IKE<x.x.x.x> Phase 2 msg-id <5be9ea02>: Negotiations have failed.

     

    At line

     

    ## : IKE<x.x.x.x> expect [0]:

     Does that mean it was expecting the remote host to have PFS Group (0) or none and it had Group 2?  I on my side have Group 0 (none) and communicated that with remote host but probably they used Group 2?

     

    Is this right?

     

    Thanks in advance for any poitners whatsoever!

     

    Spyros

     



  • 2.  RE: Policy Based VPN debug clarification
    Best Answer

    Posted 04-25-2014 09:15

    Hi,

     

    That is correct.  I would try changing your side to group 2 and re-check.  Good luck.



  • 3.  RE: Policy Based VPN debug clarification

    Posted 04-25-2014 12:19

    Thanks for the clarification, changed PFS to G2 and tunnel is now up.