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.
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 [juniper.net] .
The output of the show security ike security-associations command reports that the state is DOWN for the remote address of the VPN.
show security ike security-associations
The remote address of the VPN is not listed in the output of the show security ike security-associations command.
Perform the following steps to correct the IKE Phase 1 issue:
Review the output of show security ipsec inactive-tunnels for helpful tips.
show security ipsec inactive-tunnels
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 .
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
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 [juniper.net] .
/var/log
Then attempt to bring the VPN tunnel up again, so that the VPN status messages are logged to the syslog file, kmd-logs .
kmd-logs
Look for Phase 1 errors in the syslog file, kmd-logs :
> show log kmd-logs
show log kmd-logs
Refer to KB30548 - [SRX] IKE Phase 1 VPN status messages [juniper.net] 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.
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.
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? [juniper.net]
Yes - Continue with Step 7. No - Adjust the IKE Gateway's outgoing interface to the correct outgoing interface .
If the SRX device is to be the responder device, verify that the SRX device is configured to allow IKE for host-inbound-traffic:
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; }
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
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" .
tcp-encap"
Verify that the peer gateway is reachable:
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.
show route
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
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.
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 [juniper.net] .
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) [juniper.net] .
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 [juniper.net] .
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.