Support Support Downloads Knowledge Base Case Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[SRX] How to troubleshoot IKE Phase 1 VPN connection issues

0

0

Article ID: KB10101 KB Last Updated: 15 Mar 2021Version: 14.0
Summary:
 

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

Note: The Phase1 SA is used to create the Phase2 SA, which is used for the traffic flow between the gateways. It is possible to see Phase 2 SA up and Phase 1 down (mostly a display issue or rekey). Therefore, check the Phase 2 SA status and actual traffic status before continuing with troubleshooting the Phase 1 SA.

 

Symptoms:
 
  • IKE Phase 1 is not UP. For more information about determining the status of IKE Phase 1, refer to KB10090 - How do I tell if a VPN Tunnel SA (Security Association) is active.

  • 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.

 

Solution:
 

Perform the following steps to correct the IKE Phase 1 issue:

  1. Review the output of show security ipsec inactive-tunnels for helpful tips.

root@Corporate> show security ipsec inactive-tunnels   
  Total inactive tunnels: 1
  Total inactive tunnels with establish immediately: 1
  ID           Port   Gateway          Tunnel Down Reason
  131073       500    192.168.1.1    
   Peer proposed phase1 proposal conflicts with local configuration. Negotiation failed (1 times)  ==> This confirms there is a configuration mismatch

If you don't find anything conclusive, continue to Step 2.

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

Example

# set system syslog file kmd-logs daemon info
# set system syslog file kmd-logs match KMD
# commit

Note: The filename is kmd-logs; it is important that you do not name the file kmd, as the IKE debugs are written to the file kmd. The file kmd-logs is written to the /var/log directory. For more information, see KB10097 - [Includes video] How to configure syslog to display VPN status messages.

  1. Then attempt to bring the VPN tunnel up again, so that the VPN status messages are logged to the syslog file, kmd-logs.

  2. Look for Phase 1 errors in the syslog file, kmd-logs:

> show log kmd-logs

Refer to KB30548 - [SRX] IKE Phase 1 VPN status messages for a listing of common IKE connection errors, and follow the recommended solutions.

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

  1. If the VPN is a route-based VPN, verify that an st0.x interface is bound to the VPN and security zone:

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;
    }
}
root@CORPORATE# show security zones
security-zone VPN-Zone {
    host-inbound-traffic {
        system-services {
            all;
        }
        protocols {
            all;
        }
    }
    interfaces {
        st0.0;                          
    }
}

Is there an st0 interface bound to the VPN and security zone?

  • Yes - Continue with Step 6.
  • No - If you are using a policy-based VPN, continue with Step 6. Otherwise, bind the st0 interface to the VPN and security zone.
  1. Is the VPN Gateway configured to use the correct outgoing interface? For further assistance, see KB10121 - [SRX] How to determine if the IPsec IKE Gateway is configured for the correct outgoing interface?

  • Yes - Continue with Step 7.
  • No  - Adjust the IKE Gateway's outgoing interface to the correct outgoing interface.
  1. If the SRX device is to be the responder device, verify that the SRX device is configured to allow IKE for host-inbound-traffic:

    1. Locate the VPN external interface: 

root@CORPORATE# show security ike
policy ike_pol {
    mode main;
    proposal-set compatible;
    pre-shared-key ascii-text "$ABC123"; ## SECRET-DATA
}
gateway gw_srx1 {
    ike-policy ike_pol;
    address 2.2.2.2;
    external-interface ge-0/0/8;
}
  1. 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
  1. Verify that the 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 {
                ike;
            }
        }
    }
} 

Note: If the VPN is to be used for Dynamic Endpoint connections from NCP clients using NCP Pathfinder, include the option of system-services "tcp-encap".

  1. Verify that the peer gateway is reachable:

    1. In the show route output, check if there is an active route towards the peer. If no active routes are there, add the proper routes.

    2. If there is an active route, check if any IKE packets have been received from the peer by using show security ike security-associations:

root@Corporate> show security ike security-associations    
Index   State  Initiator cookie  Responder cookie  Mode           Remote Address   
247373  DOWN   dbb4ebf61a954c2f  0000000000000000  Main           2.2.2.2

The above output shows that the "Responder cookie" is all zeros (000000), which means that the device has not received any packets from the peer. Check the peer side to see if IKE packets are being received from the SRX device, and if they are responding or not.

  1. Confirm that there are no firewall filters on the SRX device, which can block UDP 500 packets towards the SRX device from the specific peer.

If there any routers or firewalls in the path that are blocking IPsec, which uses IP protocol 50, UDP port 500, and 4500 (if using NAT-Traversal), work with the admin of that firewall or router to allow IPsec through for the IP address of your firewall and the remote IP gateway. See KB17953 - NAT Traversal (NAT-T) supported scenarios.
  1. Enable "per tunnel debug" detailed logging (traceoptions), and analyze the output. See KB19943 - [SRX] How to enable VPN (IKE/IPsec) traceoptions for specific SAs (Security Associations).

  2. If the problem is still not resolved, collect logs and open a case with your technical support representative. See KB21781 - [SRX] Data Collection Checklist - Logs/data to collect for troubleshooting.

 

Modification History:
 

2021-03-15: Refreshed article for clarity and made it up-to-date

2020-03-26:

  • Removed message log examples related to old version of Junos.

  • Included reference to use of tcp-encap system service.

2020-02-25: Minor, non-technical edits.

 

Related Links

Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search