Knowledge Search


[J/SRX] How to analyze IKE Phase 1 VPN status messages

  [KB10101] Show Article Properties


This article shows you how to review VPN status messages related to IKE Phase 1 not establishing and verify settings if no IKE Phase 1 messages are seen.



  • IKE Phase 1 is not UP. 
  • The output of the show security ike security-associations command reports that the state is DOWN for the remote address of the VPN.
  • The remote address of the VPN is not listed in the output of the show security ike security-associations command.


Troubleshooting IKE Phase 1 problems is best handled by reviewing VPN status messages on the responder firewall. The responder is the "receiver" side of the VPN that is receiving the tunnel setup requests. The initiator is the side of the VPN that sends the initial tunnel setup requests.

Step 1.  Configure a new syslog file, kmd-logs, to capture relevant VPN status logs on the responder firewall.

See: KB10097 - How to configure syslog to display VPN status messages

Don't forget to attempt to bring the VPN tunnel up again, so that the messages are captured in kmd-logs.

Step 2. Run the command show log kmd-logs, and look for Phase 1 errors, such as these:

Note: The messages below are for prior to Junos OS Release 12.1X44. For Junos OS Release 12.1X44 and later, see KB30548:IKE Phase 1 VPN status messages in 12.1X44 and later releases.

  • Message: 
    Jul 9 21:54:06 210-2 kmd[46022]: IKE negotiation failed with error: No proposal chosen. IKE Version: 1, VPN: ike-vpn-srx1 Gateway: gw-srx1, Local:, Remote:, Local IKE-ID: Not-Available, Remote IKE-ID: Not-Available, VR-ID:
    Meaning 1:
    The Phase 1 proposals do not match.

    Action 1:
    Make sure the parameters for the IKE gateway Phase 1 proposals on both the responder and the initiator match:
    • Authentication Method (Pre-shared, RSA-signature, or DSA-signature)
    • Diffie-Hellman Group Number (Group 1, 2, 5, 14, 19, 20, 24)
    • Encryption Algorithm (DES, 3DES, or AES)
    • Hash Algorithm (MD5, SHA-1, SHA-256, SHA-384)

    Meaning 2:
    Remote peer not recognized.  The responder did not recognize the incoming request as originating from a valid gateway peer.

    Action 2:
    On the responder, confirm the following IKE gateway configuration settings are correct:
    • The IP address specified for the (remote) gateway is correct.
      The dynamic entry specified for the (remote) gateway is correct.
    • The external-interface is correct.  
  • Message:
    Jul 9 21:32:34 210-2 kmd[45843]: IKE negotiation failed with error: Invalid syntax. IKE Version: 1, VPN: ike-vpn-srx1 Gateway: gw-srx1, Local:, Remote:, Local IKE-ID: Not-Available, Remote IKE-ID: Not-Available, VR-ID: 0
    Most likely the Phase 1 pre-shared keys do not match.

    On both the initiator and responder, re-enter the pre-shared-key in the IKE gateway configuration.

  • If you are unable to locate any Phase 1 messages, continue to Step 3.

Step 3 If the VPN is a route-based VPN, verify that a st0.x interface is bound to the VPN with the command:

root@CORPORATE# show security ipsec
policy ipsec_pol {
    proposal-set compatible;
vpn vpn1 {
    bind-interface st0.0;
    ike {
        gateway ike-vpn-srx1;
        ipsec-policy ipsec_pol;
Is there a st0 interface bound to the VPN?
  • Yes - Continue with Step 4.
  • No, I am using a policy-based VPN - Continue with Step 4.
  • No - Bind the st0 interface to the VPN: 

      set security ipsec vpn "vpn_name" bind-interface st0.0

    To do this using J-Web:
    • Go to Configuration > IPSec VPN > Auto Tunnel> Phase II.
    • Select the VPN tunnel in question and click Edit.
    • Click on the pull-down list for Bind to tunnel interface.
    • Select the st0 interface.
    • Click OK.  

Step 4. Is the VPN Gateway configured to use the correct outgoing interface?  For further assistance, see KB10121 - How to determine if the IPsec IKE Gateway is configured for the correct outgoing interface?.

  • Yes - Continue with Step 5.
  • No  - The IKE Gateway's outgoing interface cannot be changed.  Create a new IKE Gateway that points to the correct outgoing interface and then change the AutoKey IKE so that it is using the new gateway.

Step 5.  Is the SRX configured to allow IKE for host-inbound-traffic if SRX is to be responder?

  1. Locate the VPN external interface: 
    root@CORPORATE# show security ike
    policy ike_pol {
        mode main;
        proposal-set compatible;
        pre-shared-key ascii-text "$9$y0DlWL7-VY4aN-.PTz6/WLXxwYDik"; ## SECRET-DATA
    gateway gw_srx1 {
        ike-policy ike_pol;
        external-interface ge-0/0/8;
  2. Locate the security zone associated with the external-interface:
          root@CORPORATE# show security zones | display set | match ge-0/0/8
    set security zones security-zone untrust interfaces ge-0/0/8.0

  3. Verify that interface or zone allows host-bound IKE traffic:  
    root@CORPORATE# show security zones security-zone untrust
    interfaces {
    ge-0/0/8.0 {
    host-inbound-traffic {
    system-services {
  • Yes - Continue with Step 6.
  • No   - Enable IKE for the external interface:
    root@CORPORATE# set security zones security-zone interface host-inbound-traffic system-services ike
    root@CORPORATE# commit

Step 6.  Enable 'per tunnel debug' detailed logging (traceoptions), and analyze the output.

See: KB19943 - How to enable VPN (IKE/IPsec) traceoptions for only specific SAs (Security Associations)

Step 7.  If still not resolved, collect logs and open a case with your technical support representative. 

Logs: KB21781 - [SRX] Data Collection Checklist - Logs/data to collect for troubleshooting

See the Related Links section for more configuration and troubleshooting resources.

Related Links: