Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

Tunnel Events

 

Tunnel events can include successful IPsec SA negotiations, IPsec and IKE SA rekeys, SA negotiation failures, and reasons for a tunnel going down. Tunnel events appear in the output for the show security ipsec inactive-tunnel, show security ipsec inactive-tunnel detail, and show security ipsec security-association detail commands. Table 1 lists the tunnel events in alphabetical order. Each event includes a description and the action you can take.

Table 1: IPsec VPN Tunnel Events

Tunnel Event

Description

Action

Bind-interface's address deleted. Existing IPSec SAs cleared

A configuration commit removed the IP address from the st0 interface, which resulted in the clearing of the IPsec SA for VPNs bound to the interface.

Review the VPN setup to determine the need for the IP address on the st0 tunnel interface. Review system logs for the commit change.

Bind-interface's address received. Information updated

A configuration commit changed or added an IP address to the st0 tunnel interface.

No action required.

Bind-interface's family deleted. Existing IPSec SAs cleared

A configuration commit removed the family inet or inet6 from the st0 interface, which resulted in the clearing of the IPsec SA for VPNs bound to the interface.

Verify in the configuration that st0.x has the family inet or inet6 associated with the interface. Review system logs for the commit changes.

Bind-interface's family received. Information updated

A configuration commit added the family inet or inet6 on the st0 interface.

No action required.

Bind-interface's zone received. Information updated

A configuration commit changed or added a security zone on the st0 tunnel interface.

No action required.

Bind-interface's zone status changed. Existing IPSec SAs cleared

The  st0.x interface status changed from Up, which cleared the IPsec SA for VPNs bound to the st0 interface where the status changed.

Review system logs for the the interface status change reason.

CA certificate for configured local certificate not found. Negotiation not initiated/successful

During VPN establishment using PKI certificates, the CA for the local certificate was not found on the device, which resulted  in VPN establishment failure.

Verify the ca-profile configuration. Verify that the CA certificate is loaded on the device. Reload the CA certificate if necessary.

Certificate has expired. Refer to syslog for more information

An attempt to establish a VPN using PKI certificates failed because the CA or local certificate was expired.

Verify certificate validity dates. Verify the system date and time.

Cleared unused redundant backup IPSec SA pairs.

The IPsec SA count for a tunnel crossed two pairs.

No action required.

Configured local certificate has been revoked. Negotiation not initiated/successful

During a local certificate revocation check using the CRL, the local certificate was revoked or the CRL could not be downloaded to allow the revocation check, which resulted in VPN establishment failure or a failure to initiate the VPN tunnel.

Review system logs or PKI trace options for information about the CRL validation failure. Verify the downloaded CRL. Manually load an updated CRL. Consult the CA administrator about why the  certificate is on the CRL. Disable the CRL revocation check.

CRL check failed as CA not reachable. Refer to syslog for more information

During a certificate revocation check using the CRL, the CA  server could not be reached or did not respond, which resulted in VPN establishment failure.

Verify that the CA server and the CRL distribution point are reachable.

CRL check failed for a certificate. Refer to syslog for more information

During a certificate revocation check using the CRL, the received peer certificate was revoked or the CRL could not be downloaded to allow the revocation check, which resulted in VPN establishment failure.

Review system logs or PKI trace options for information about the CRL validation failure. Verify the downloaded CRL. Manually load an updated CRL. Consult the CA administrator about why the certificate is on the CRL. Disable the CRL revocation check.

Deactivated tunnel as interface information is not ready on new primary node

During a failover in an SRX300, SRX320, SRX340, SRX345, or SRX550HM chassis cluster, interface information was not available on the new primary node. This event is specific to SRX300, SRX320, SRX340, SRX345, and SRX550HM chassis clusters.

No action required.

DPD detected peer as down. Existing IKE/IPSec SAs cleared.

DPD is enabled and the peer was not reachable for the configured interval and threshold. When this happens, the corresponding IKE and IPsec SAs are cleared, causing the tunnel to flap.

Check peer connectivity. Verify peer gateway connectivity, increase DPD intervals or thresholds, or enable probe-idle-tunnel.

Duplicate IKE/IPSec session detected. Old session cleared

An established peer connected again with different information, such as IP address, username, or IKE ID. This event occurs for AutoVPN, dynamic endpoint, and dialup tunnels only.

No action required.

External-interface's address deleted. Existing IPSec SAs cleared

A configuration commit removed or adjusted the IP address on the IKE external interface, which resulted in the clearing of the IPsec SA for IKE gateways bound to the interface.

Verify that an IP address is assigned to the IKE external interface. Review system logs for the commit change.

External interface's address received. Information updated

A configuration commit changed or added a security zone on the IKE external interface.

No action required.

External-interface's device status changed. Existing IPSec SAs cleared

The IKE gateway external interface status changed from Up, which resulted in clearing of the IPsec SA  for all IKE gateways associated with the external interface where the status changed.

Review system logs for the interface status change reason.

External-interface's primary address change triggered clearing of IPSec SA

A configuration commit adjusted the IP address on the IKE external interface, which resulted in clearing of the IPsec SA for IKE gateways bound to the adjusted interface.

Verify the IP address assigned to the external interface. Verify use of the primary setting on the external interface. Review system logs for the commit change.

External-interface's sub-unit status changed. Existing IPSec SAs cleared

The IKE gateway external interface status changed from Up, which resulted in clearing of the IPsec SA  for all IKE gateways associated with the external interface where the status changed.

Review system logs for the interface status change reason.

External interface's zone received. Information updated

A configuration commit changed or added a security zone on the IKE external interface.

No action required.

External interface's zone status changed. Existing IPSec SAs cleared

A configuration commit changed the security zone for the IKE external interface, which resulted in the clearing of the IPsec SA  for all IKE gateways associated with the changed external interface.

Review system logs for commit changes.

Gateway configuration deletion triggered clearing of IPSec SA

A configuration commit deleted or deactivated the IKE gateway, which resulted in clearing of the IPsec SA.

Review system logs for commit changes.

Group VPN configuration change triggered clearing of IPSec SA

A configuration commit changed the group VPN configuration, which resulted in clearing of the IPsec SA.

Review system logs for commit changes.

Hard lifetime of IPSec SA expired.

This event is tracked for a tunnel only if there are no more IPsec SAs. Otherwise, this event is tracked in statistics only to avoid multiple events being recorded during rekeys.

If the rekey fails or does not complete before the lifetime expires, this event is recorded and the statistics counter is incremented. If the hard lifetime expires before a rekey occurs, a higher lifetime value is recommended. If a rekey was triggered and failed, there might be some other issue noted in another tunnel event.

Idle timer triggered. Existing IPSec SAs cleared.

idle-time is configured at the [edit security ipsec vpn vpn-name ike] hierarchy level, and the tunnel was idle for the configured time. 

Increase the idle tunnel interval.

IKE SA cleared as lifetime exipred

The IKE configured lifetime seconds expired. The default setting is 28,800 seconds. This event does not impact current IPsec SAs. 

No action required. You can use DPD to maintain IKE establishment.

IKE SA cleared on backup HA node as requested from primary HA node

The primary chassis cluster node requested that the IKE SA be cleared on the backup node.

Review system logs on the primary node for the IKE SA clear reason.

IKE SA negotiation successfully completed

IKE Phase 1 negotiations were successfully completed.

No action required.

IKE SA rekey successfully completed

When using IKEv2, the IKE SA expired with an established IPsec SA. IKEv2 requires an established IKE SA while an IPsec SA is active. 

No action required.

IKE SA UDP port change detected with peer. Existing IPSec SAs cleared.

There was a NAT-T port change, possibly caused by changed ports on the NAT device after the tunnel was established. An IPsec layer UDP packet was received from the peer with a different port for the established tunnel. This event resulted in the clearing of the IPsec SA.

Verify the NAT device behavior that led to the port change.

IKE version mismatch detected

The SRX Series device and the VPN peer attempted to use different IKE versions, which resulted in tunnel establishment failure.   The SRX Series device is configured for IKEv1 usage by default.

Adjust the VPN peer to use the same IKE version as the SRX Series; or configure the SRX Series to use the same IKE version in as the peer with set security ike gateway gateway-name version v1-only or set security ike gateway gateway-name version v2-only.

Initial-Contact received from peer. Stale IKE/IPSec SAs cleared.

Initial contact was received from the peer.

No action required.

IPSec SA delete payload received from peer, corresponding IPSec SAs cleared.

A peer or remote device sent a delete notification for a given IPsec SA, resulting in the deletion of that particular SA pair.  If that SA is the last IPsec SA for that tunnel, the tunnel goes down. This event can occur for various reasons: for example, after a rekey the peer might send a delete for an old SA, or a configuration change triggered on a peer resulted in the clearing of the IPsec SA.

Review peer logs to locate the event that caused the SA deletion request to be sent.

IPSec SA negotiation successfully completed

IPsec Phase 2 negotiations were successfully completed.

No action required.

IPSec SA rekey successfully completed

The IPsec rekey was successfully completed.

No action required.

IPSec SA UDP port change detected with peer. Existing IPSec SAs cleared.

There was a NAT-T port change, possibly caused by changed ports on the NAT device after the tunnel was established. An IPsec layer UDP packet was received from the peer with a different port for the established tunnel. This event resulted in the clearing of the IPsec SA.

Verify the NAT device behavior that led to the port change.

IPSec SAs cleared as corresponding IKE SA deleted.

The IPsec SA was deleted.

No action required.

Key pair not found for configured local certificate. Negotiation failed

During VPN establishment using PKI certificates, a corrupt or missing key-pair file from the local device was detected, which resulted  in VPN establishment failure.

Verify configuration of local-certificate in the IKE policy. Verify that the key-pair is located in /var/db/certs/common/key-pair. Generate a new key-pair and certificate-request, and load the new certificate.

Lifetime in kilobytes expired for IPSec SA.

The lifetime-kilobytes value has expired. Before this event, the soft lifetime triggered a rekey for the IPsec SA. The event is not captured and only a statistics counter is incremented.

If the rekey fails or does not complete before the lifetime expires, this event is recorded and the statistics counter is incremented. If the hard lifetime expires before a rekey occurs, a higher lifetime value is recommended.  If a rekey was triggered and failed, there might be some other issue noted in another tunnel event.

Manual next-hop-tunnel configuration change triggered clearing of IPSec SA

A configuration commit changed the next-hop tunnel for the st0 interface, which resulted in the clearing of the IPsec SA for the VPN linked to the changed next-hop tunnel.

Review system logs for commit changes.

Negotiation failed with error code INVALID_IKE_VERSION received from peer

The peer device rejected an incoming VPN tunnel setup request from the SRX Series device because of mismatched IKE versions, resulting in tunnel establishment failure.  

Verify the VPN configuration and VPN peer configuration for IKE version usage. Configure the SRX Series device to use IKEv1 or IKEv2 based on the peer setup by entering set security ike gateway gateway-name version v1-only or set security ike gateway gateway-name version v2-only.

Negotiation failed with error code NO_PROPOSAL_CHOSEN received from peer

The VPN peer informed the SRX Series device of VPN failure based on a mismatch of proposals, IKE version, peer gateway match, proxy ID/traffic-selectors, DH groups, or PSK usage. 

Review peer logs for the failure reason. Review configurations on the SRX Series device and the peer to ensure that expected VPN attributes match.

Negotiation failed with error code TS_UNACCEPTABLE received from peer

The VPN peer rejected the proxy ID/traffic selector requested by the SRX Series device, which resulted in tunnel establishment failure.

Review peer logs for the rejection reason. For route-based VPNs, verify the configured proxy ID/traffic selector. For policy-based VPNs, verify the source, policy, or application defined in the security policy bound to the VPN.

OCSP revocation check failed as server not reachable. Refer to syslog for more information

During a certificate revocation check using OCSP, the OCSP server could not be contacted, which resulted in VPN establishment failure.

Verify that the OCSP server is reachable. Verify the configured IP address of the OCSP server.

OCSP revocation check failed for a certificate. Refer to syslog for more information

During a certificate revocation check using OCSP, a revoke response was received, which resulted in VPN establishment failure.

Review OCSP server logs for the revocation reason.

Peer proposed phase1 negotiation mode (main/aggressive) does not match with configuration

The IKE negotiation mode configured on the SRX Series device for IKEv1 does not match the peer’s proposed mode.

Revise the peer or SRX Series device configuration to match the other device.

Peer proposed phase1 proposal conflicts with local configuration. Negotiation failed

The Phase 1 proposal configured on the SRX Series device does not match the peer’s proposal.

Revise the peer or SRX Series device configuration to match the other device.

Peer proposed traffic-selectors are not in configured range

The traffic selector configured on the SRX Series device does not match the peer’s proposed traffic selectors.

Revise the peer or SRX Series device configuration to match the other device.

Peer proposed unsupported multiple traffic-selector attributes for a single IPSec SA. Negotiation failed.

During IKEv2 negotiations, the peer device sent a proposal containing multiple traffic selectors for a single VPN tunnel, which resulted  in the failure of the VPN tunnel setup. 

Review the peer configuration of ACLs or traffic selectors.

Peer proposed unsupported port range in traffic-selector attribute. Phase 2 negotiation failed

During IPsec negotiation, the peer device sent a traffic selector that contained an unsupported port range, which resulted in the failure of the VPN tunnel setup.

Adjust the peer configuration for the port range setup for the ACLs or traffic selectors.

Peer proposed unsupported protocol in traffic-selector attribute. Phase 2 negotiation failed

During IPsec negotiation, the peer device sent a traffic selector that contained an unsupported protocol, which resulted in the failure of the VPN tunnel setup.

Adjust the peer configuration for the protocol setup for the ACLs or traffic selectors.

Peer's IKE-ID validation failed during negotiation

The received IKE ID did not match the expected IKE ID, which resulted in tunnel establishment failure. The default expected IKE ID is the IP address, peer, or dynamic  setting configured for the IKE gateway.

Review the VPN peer configuration for the  IKE ID the peer is sending. Configure the SRX Series device using remote-identity to adjust to the expected IKE ID of the peer.

Proposed peer's IKE-ID does not match with peer's certificate. Negotiation failed

When using PKI certificates, the peer IKE ID value was not in the SAN field of the received certificate, which resulted in VPN establishment failure.

Review the VPN peer and reissue a certificate with an updated SAN based on the IKE ID value. Adjust the VPN peer’s IKE ID to match the SAN field of the certificate.

Received use IKEv1 message from peer

The  peer device rejected an  incoming VPN tunnel setup request from the SRX Series device to use IKEv2 when the peer is configured to use IKEv1, which resulted in tunnel establishment failure.  

Adjust the VPN peer setup to use IKEv2, or adjust the SRX Series device’s configuration to use IKEv1 by entering set security ike gateway gateway-name version v1-only.

Requested peer to use IKEv1 instead of IKEv2

The SRX Series device is configured to use IKEv1 by default, and the peer attempted to set up IKE using IKEv2, which resulted in tunnel establishment failure.

Adjust the VPN peer to use IKEv1, or configure the SRX Series device to use IKEv2 by entering set security ike gateway gateway-name version v2-only.

Security policy change triggered clearing of IPSec SA

A policy-based VPN configuration commit changed security policies bound to the IPsec VPN, which resulted in the clearing of the IPsec SA associated with the changed policies.

Review system logs for commit changes.

Shortcut Tunnel deleted because of inactivity

When using IKEv2 with ADVPN, the device received a shortcut suggestion. However, it did not receive a request from a partner to complete the setup of the shortcut tunnel. 

Verify that shortcut tunnel peers can reach each other. Verify that the shortcut partners can exchange UDP500 IKEv2 traffic between them.

Shortcut Tunnel deleted when idle-time is reached

When using IKEv2 with ADVPN, traffic flowing over the shortcut tunnel fell below the idle-threshold for longer than the idle-time (default is 5 packets per second for 900 seconds). Traffic continues to flow through the  IPsec tunnel to the hub.

If traffic is sporadic, decrease idle-threshold and increase idle-time. The shortcut tunnel should remain established during times of low traffic throughput.

Tunnel configuration changed. Corresponding IKE/IPSec SAs are deleted

A configuration commit adjusted the  IKE/IPsec configuration, which resulted  in clearing of the IPsec SA.

Review system logs for commit changes.

Tunnel configuration is deleted. Corresponding IKE/IPSec SAs are deleted

A configuration commit deleted or deactivated the IKE/IPsec configuration, which resulted in clearing of the IPsec SA.

Review system logs for commit changes.

Tunnel deleted on backup HA node as requested from primary HA node

This event is generated on the backup chassis cluster node when the tunnel on the primary node is deleted.

No action required.

Tunnel ID reused for other tunnel on primary node. Cleared stale tunnel

On SRX5400, SRX5600, and SRX5800 chassis clusters, if the tunnel ID becomes out of sync for a given tunnel, the old tunnel is removed on the backup chassis cluster node.

No action required.

Tunnel is ready. Waiting for trigger event or peer to trigger negotiation.

The required configuration is available for peer negotiation. The device is awaiting traffic for tunnel establishment or a tunnel setup request from the peer.

No action required.

Unsupported AH and ESP bundle negotiation request denied

The peer proposed AH and ESP protocols on the same IPsec tunnel, but the SRX Series device does not support this configuration.

Reconfigure the peer for either AH or ESP protocol on the tunnel.

User cleared IKE SA from CLI, corresponding IPSec SAs cleared

The IKE SA was manually cleared using the CLI, which cleared the IKE SA but which does not affect current established IPsec SAs.

No action required.

User cleared IPSec SA from CLI.

A user or an administrator has cleared the IPsec SA manually in the CLI.

No action required.

VPN monitoring detected tunnel as down. Existing IPSec SAs cleared.

VPN monitor is configured for the tunnel and the peer did not respond to VPN monitor keepalive messages, or the peer was not reachable. The corresponding IPsec SAs were cleared.

Check peer connectivity and the VPN monitor destination address.

Zone change for all interface detected. Existing IPSec SAs cleared

A configuration commit changed the security zone for all interfaces, which resulted in clearing of all device IPsec SAs.

Review system logs for commit changes.