Knowledge Center Search


 

[ScreenOS] How to Analyze IKE Phase 2 Messages in the Event Logs

  [KB9231] Show KB Properties

  [KB9231] Hide KB Properties

Categories:
Knowledge Base ID: KB9231
Last Updated: 16 Apr 2013
Version: 6.0

Summary:
If the Event log is reporting Internet Key Exchange (IKE) Phase 2 messages, this procedure can help determine the reason the VPN is not establishing Phase 2.

Problem or Goal:
An IKE VPN Tunnel is not coming up; identify and analyze Phase 2 messages in the Event Logs that could help determine why.

Cause:

Solution:

Use these steps to determine the IKE Phase 2 error messages and what to do to correct them.  For assistance in finding the IKE errors in the event logs, see KB4426 - How do I Find the VPN Entry in the Event Log?

Step 1.  Is there a message reporting Phase 2 Complete for the VPN in question? 

Example:
Message:  IKE <1.1.1.1> Phase 2 msg ID <8046e14d>: Completed negotiations with SPI <e37791d8>, tunnel ID <1>, and lifetime <3600> sec/<0> KB. 
     Where 1.1.1.1 is the IP address of the remote firewall in question.

Step 2. The most common Phase 2 errors are:
  • Message: IKE <ip_addr> Received notify message for DOI <1> <14> < NO_PROPOSAL_CHOSEN >
         or
    Message: IKE <ip_addr> Phase 2: Rejected proposals from peer, Negotiations failed.
         or
    Message: Rejected an IKE packet on <interface> from .....because there were no acceptable  Phase 2  proposals
    Meaning: The NetScreen device did not accept any of the IKE Phase 2 proposals that were sent by the specified IKE peer.

    Action: Check the local VPN configuration. Either change the local configuration to accept at least one of the remote peer’s Phase 2 proposals, or contact the remote peer’s administrator and arrange for the IKE configurations at both ends of the tunnel to use at least one mutually acceptable Phase 2 proposal.
    For assistance, see KB6168 - Received Notify Message for DOI <No_PROPOSAL_CHOSEN>

    You can also use "debug ike detail" to check the errors during VPN negotiation.

    debug ike detail:  is used to view the IKE Phase 1 and Phase 2 negotiations. Most IKE issues can be observed when viewing the event log.
    However, when troubleshooting a VPN with another vendor, or if the the remote peer device is not accessible, debug IKE detail could provide
    information on how the other VPN has been configured.
    This is the procedure to run “debug ike detail":

    undebug all                           (to turn off any debugs currently enabled)
    set db size 4096                      (to increase debug buffer)
    clear db                              (to clear debug buffer)
    set sa-filter <ip-address>            (where ip-address = rempte peer gateway ip address)
    debug ike detail                      (Initiate traffic for the remote side peer)
    undebug all                           (to turn off debugs enabled, after the traffic failed)
    get db st                             (to get the output)


    You can check the proposals sent by remote peer and accordingly modify the proposals on the local side.

  • Message: IKE <ip_addr> Phase 2: No policy exists for the proxy ID received: local ID (<ip_addr>/<mask>, <protocol>, <port_num>) remote ID (<ip_addr>/<mask>, <protocol>, <port_num>). 
    Meaning:  No policy found matching the specified attributes.

    Action:  The proxy-id must be an exact "reverse" match.  For example, the address book entries must have the same number of netmask bits, the list of services must match as well as the port numbers. If any of these fields don't match, the Phase 2 will fail. Check the address and/or service book entries. 

    To help troubleshoot a Proxy ID error, see one of the following articles:

  • Message: IKE <ip_addr>: Phase 2 negotiation request is already in the task list   
    Meaning: The IKE module in the local NetScreen device, when attempting to add a Phase 2 negotiation task to its task list, discovered that the list already contained an identical task for the specified peer.
    When beginning Phase 1 negotiations, the NetScreen device adds the tasks that the Phase 1 security association (SA) must do to its Phase 1 task list. One such task is to perform Phase 2 negotiations. If Phase 1 negotiations progress too slowly, local traffic might initiate another Phase 2 SA request to the IKE module. If it does initiate another Phase 2 request to the IKE module, before the NetScreen device adds the Phase 2 task to its task list, it will discover that an identical task is already in the list and refrain from adding the duplicate.

    Action: Check if the IKE Phase 1 negotiations with that peer have successfully completed.

    If you are receiving this message, see Step 6 of KB9221 - How to Troubleshoot a Site-to-Site VPN Tunnel that won't come up.

Step 3. If you have IKE Phase 2 errors other than those listed in Step 2, consult the Message Log Reference Guide for your ScreenOS version.


You can also check the event messages or VPN-related messages using the commands "get event" and "get log event type 536".


Step 4 For additional assistance, collect the Site-to-Site logs for both sides of the tunnel and open a case with your technical support representative.  See KB9229 - How to collect logs and open a case for a problem with a Site-to-Site VPN.


Related Links:

 

 

ASK THE KB

Question or KB ID:


 


 

 
Copyright© 1999-2012 Juniper Networks, Inc. All rights reserved.