IPSec Troubleshooting - IPSec Fault Cause Reference

Description

Identity authentication failed.

Possible Causes

• The authentication modes of IKE peers on both ends are inconsistent.
• The pre-shared keys of the two IKE peers are inconsistent.
• An IKE peer failed to validate the remote certificate.

Solution

1. Run the display ike proposal command to check whether the authentication modes of the two IKE peers are consistent.

   <sysname> display ike proposal number 10 
   ------------------------------------------- 
    IKE Proposal: 10 
    Authentication Method      : PRE_SHARED 
    ...... 
   -------------------------------------------

   • If the authentication modes are inconsistent, run the authentication-method command to change the authentication modes to be consistent.
   • If the authentication modes are consistent and are PRE_SHARED, run the pre-shared-key command in the IKE peer view to change the pre-shared keys of the two IKE peers to be consistent.
   • If the authentication modes are consistent and are RSA-SIGNATURE or DIGITAL-ENVELOPE, go to step 2.
2. Run the display clock command to check whether the system time of the two IKE peers is consistent.
   • If not, run the clock datetime command in the user view to change the system time of the two IKE peers to be consistent.
   • If so, go to step 3.
3. Run the display pki certificate command to check whether the remote certificate has expired.
   • If so, apply for a new remote certificate.
   • If not, go to step 4.
4. Run the display pki certificate command to check the local certificate and CA certificate and check whether the two certificates can form a complete certificate chain based on the issuer of the local certificate and subject of the CA certificate.
   • If not, import the remote CA certificate.
   • If so, go to step 5.
5. When the remote certificate is validated based on CRL, run the display pki crl command to check whether the CRL has expired.
   • If so, update the CRL.
   • If not, go to step 6.
6. Collect required information and contact technical support personnel.

Description

The IKE peer of the specified ID was not found.

Possible Causes

The ID carried in the IKE negotiation packet sent by the remote device is inconsistent with the remote-id-type and remote-id configured on the local device.

Solution

1. Run the display ike peer command to view the IDs used on both ends.

   <sysname> display ike peer name peer1 
   ----------------------------------------------------------- 
    Peer name                               : peer1 
    IKE version                             : v1v2 
    VPN instance                            : - 
    Remote IP                               : 10.1.1.1 
    Authentic IP address                    : - 
    Proposal                                : - 
    Pre-shared-key                          : 
    Local ID type                           : IP 
    Local ID                                : - 
    Remote ID type                          : - 
    Remote ID                               : - 
   ......

   View the Local ID type, Local ID, Remote ID type, and Remote ID fields to check the mismatched parameters on both ends.

2. Run the local-id-type, local-id, remote-id-type, or remote-id command in the IKE peer view to change the local ID or remote ID.

Description

Failed to construct the local ID.

Possible Causes

The local end failed to obtain the local ID.

Solution

1. Run the display ike peer command to check whether the local ID of the device is configured correctly.

   <sysname> display ike peer name peer1 
   ----------------------------------------------------------- 
    Peer name                               : peer1 
    IKE version                             : v1v2 
    VPN instance                            : - 
    Remote IP                               : 10.1.1.1 
    Authentic IP address                    : - 
    Proposal                                : - 
    Pre-shared-key                          : 
    Local ID type                           : FQDN 
    Local ID                                : - 
    Remote ID type                          : - 
    Remote ID                               : - 
   ......

   View the Local ID type and Local ID fields. By default, the local ID type is IP, and the local ID is the primary address of an interface.

   • If not, run the local-id-type or local-id command to change the local ID configuration.
   • If so, go to step 2.
2. Collect required information and contact technical support personnel.

Description

The cookie value is mismatched.

Possible Causes

The responder does not receive the IKE_INIT_SA request that carries the expected cookie value.

Upon receipt of a large number of IKE_INIT_SA requests, the responder sends a response message containing the Notify payload of the cookie type in plaintext mode to the initiator. The response message contains the cookie value that the responder wants the initiator to return. The initiator constructs a Notify payload, which contains the cookie value received from the responder, places the Notify payload before the first payload of the original IKE_INIT_SA request, and sends an IKE_INIT_SA request to the responder again.

Solution

1. Check whether the device is attacked.
   • If so, find the attack source.
   • If not, go to step 2.
2. Collect required information and contact technical support personnel.

Description

The critical payload is dropped.

Possible Causes

The device received an unidentifiable critical payload.

Solution

• Collect required information and contact technical support personnel.

Description

The number of IKE peers reached the limit.

Possible Causes

The number of configured IKE peers reached the limit.

Solution

• Plan the network properly or expand the device capacity.

Description

EAP authentication failed.

Possible Causes

The server failed to verify EAP authentication parameters.

• The user name and password are incorrect.
• The EAP authentication configuration is incorrect.

Solution

1. Check whether the user name and password are consistent with those on the server.
   • If not, change the user name and password.
   • If so, go to step 2.
2. Check whether the EAP authentication configuration is consistent with that of the server.
   • If not, modify the configuration to ensure that it is correct.
   • If so, go to step 3.
3. Collect required information and contact technical support personnel.

Description

EAP authentication expired.

Possible Causes

The device did not receive packets from the client or server during EAP authentication.

• The link from the device to the client or server is unreachable.
• The client or server is not working properly.

Solution

1. Perform a ping operation to check whether the link from the device to the client or server is reachable.
   • If not, ensure that the network configurations, including interfaces and IP addresses, are correct.
   • If so, go to step 2.
2. Check whether the client or server is working properly. For example, check whether the client or server has been powered off or is not functioning properly.
   • If not, ensure that the client and server are working properly.
   • If so, go to step 3.
3. Collect required information and contact technical support personnel.

Description

The encapsulation modes on both ends are inconsistent.

Possible Causes

The encapsulation modes of IKE peers on both ends are inconsistent.

Solution

1. Run the display ipsec proposal command to view the encapsulation modes used on both ends.

   <sysname> display ipsec proposal name tran1 
   IPSec proposal name: tran1 
    Encapsulation mode: Tunnel 
   ......

2. Run the encapsulation-mode command in the IPSec proposal view to change the encapsulation modes used on both ends to be consistent.

Description

The first packet is rate-limited.

Possible Causes

When a large number of IPSec tunnels need to be established, the number of IKE SAs to be negotiated is larger than the configured maximum value.

Solution

1. Run the display ike global config command to check whether the number of IKE SAs to be negotiated reaches the configured maximum value.

   <sysname> display ike global config 
   IKE Global Config: 
   -------------------------------------------------------------- 
    ...... 
     IKE call admission               : 800 
   ......

   • If not, run the ike call admission limit in-negotiation-sa command in the system view to change the maximum number of IKE SAs to be negotiated.
   • If so, go to step 2.
2. Plan the network properly.

Description

Security ACL rules on both ends conflict with each other.

Possible Causes

Security ACL rules of IKE peers on both ends overlap.

Solution

1. Run the display ipsec policy command to view security ACLs on both ends and then run the display acl command to view security ACL rules on both ends.

   <sysname> display ipsec policy name map1 
   =========================================== 
   IPSec policy group: "map1"  
   Using interface: GigabitEthernet0/0/1  
   =========================================== 
        Sequence number: 10 
        Policy Alias: map1-10 
        Security data flow: 3000  
   ......  
    
   <sysname> display acl 3000  
   Advanced ACL 3000, 1 rule                                 
   Acl's step is 5                                                                   
    rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.2.2.0 0.0.0.255  

   Determine the overlapping ACL rules.

2. Run the rule command in the ACL view to change security ACL rules.

Description

Security ACLs or IKE peer addresses on both ends are mismatched.

Possible Causes

• Security ACLs of IKE peers on both ends are mismatched.
• IKE peer addresses on both ends are mismatched.
• When IPSec negotiation is performed using tunnel interfaces, the destination address configured on a tunnel interface of the local device is inconsistent with the remote address configured in the IKE peer view.

Solution

1. Run the display ipsec policy command to view security ACLs on both ends and then run the display acl command to check whether security ACL rules on both ends match.

   <sysname> display ipsec policy name map1 
   =========================================== 
   IPSec policy group: "map1"  
   Using interface: GigabitEthernet0/0/1  
   =========================================== 
        Sequence number: 10 
        Policy Alias: map1-10 
        Security data flow: 3000  
   ......  
    
   <sysname> display acl 3000  
   Advanced ACL 3000, 1 rule                                 
   Acl's step is 5                                                                   
    rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.2.2.0 0.0.0.255  

   • If not, run the rule command in the ACL view to change security ACL rules.
   • If so, go to step 2.
2. Run the display ike peer command to check whether IKE peer addresses on both ends match.

   <sysname> display ike peer name peer1 
   ----------------------------------------------------------- 
    Peer name                               : peer1 
    IKE version                             : v1v2 
    VPN instance                            : - 
    Remote IP                               : 10.1.1.1 
    Authentic IP address                    : - 
    Proposal                                : - 
    Pre-shared-key                          : 
    Local ID type                           : IP 
    Local ID                                : - 
    Remote ID type                          : - 
    Remote ID                               : - 
   ......

   View the Remote IP field and the remote device's local address. By default, the device uses the primary IP address of an interface as the local address.

   • If not, run the remote-address command in the IKE peer view to change the remote address.
   • If so, go to step 3.
3. If IPSec negotiation is performed based on tunnel interfaces, view the destination address configured on the local tunnel interface and the remote address configured in the IKE peer view.

   If no destination address is configured on the local tunnel interface, enable the local device to use the remote address configured in the IKE peer view to initiate negotiation. If no destination address is configured for the local tunnel interface and no remote address is configured in the IKE peer view, the local device can only accept the negotiation initiated by the remote device.

   If the destination address is configured on the local tunnel interface, ensure that the destination address is the same as the remote address configured in the IKE peer view.

Description

The number of fragmented packets exceeded the limit.

Possible Causes

The number of fragmented packets received by the device exceeded the limit.

Solution

1. Run the mtu command in the interface view to change the MTU value of the remote device.
2. If the fault persists, collect required information and contact technical support personnel.

Description

The reassembly of fragmented packets expired.

Possible Causes

• Some received fragmented packets were lost.
• The device is not working properly.

Solution

1. Perform a ping operation to check whether the link between both ends is reachable.
   • If not, ensure that the network configurations, including interfaces and IP addresses, are correct and that the network is not congested.
   • If so, go to step 2.
2. Check whether the device is working properly, for example, whether its CPU usage is high.
   • If not, ensure that the device is working properly.
   • If so, go to step 3.
3. Collect required information and contact technical support personnel.

Description

IKEv2 does not support the SM algorithm in IPSec proposals.

Possible Causes

IKEv2 uses the unsupported SM algorithm.

Solution

1. Run the display ipsec proposal command to view the IPSec proposal parameters used on both ends.

   <sysname> display ipsec proposal name tran1 
   IPSec proposal name: tran1 
    Encapsulation mode: Tunnel 
    Transform         : esp-new 
    ESP protocol      : Authentication SM3 
                        Encryption SM1

2. Run the required command in the IPSec proposal view to modify the SM algorithm to another algorithm.
   • Run the ah authentication-algorithm command to change the authentication algorithm used in AH.
   • Run the esp authentication-algorithm command to change the authentication algorithm used in ESP.
   • Run the esp encryption-algorithm command to change the encryption algorithm used in ESP.

Description

An IPSec tunnel was torn down in disconnect state.

Possible Causes

When IPSec is associated with NQA, VRRP, or BFD, the device is in disconnect state based on the detection result.

Solution

1. Check whether it is normal that the device is in disconnect state.
   • If not, for example, the device is in disconnect state not because of an active/standby switchover, ensure that its configuration is correct.
   • If so, go to step 2.
2. Check whether the link between both ends is reachable.
   • If not, ensure that the network configurations, including interfaces and IP addresses, are correct.
   • If so, go to step 3.
3. Collect required information and contact technical support personnel.

Description

The DH algorithm of the initiator is mismatched.

Possible Causes

The DH algorithms of IKE peers on both ends are mismatched.

Solution

1. Run the display ike proposal command to view the DH algorithms used on both ends.

   <sysname> display ike proposal number 10 
   ------------------------------------------- 
    IKE Proposal: 10 
    Authentication Method      : PRE_SHARED 
    Authentication Algorithm : SHA2-256 
    Encryption Algorithm       : AES-256 
    Diffie-Hellman Group       : MODP-2048 
   ......

   View the Diffie-Hellman Group field.

2. Run the dh command in the IKE proposal view to change the DH algorithms used on both ends to be consistent.

Description

There is no valid cookie value.

Possible Causes

IKE negotiation entries of the local device have been deleted. Due to network or other reasons, the local device receives the negotiation message carrying the previous cookie value from the remote device. As a result, this cookie value is mismatched on the local device.

Solution

1. Perform a ping operation to check whether the IPSec service is normal.
   • If so, no action is required.
   • If not, run the reset ike sa command to clear the SA established through IKE negotiation and enable the device to initiate IKE negotiation again.
2. If the fault persists, collect required information and contact technical support personnel.

Description

The packet length is invalid.

Possible Causes

The length of the packet received by the device is less than the required length.

Solution

1. Check whether the device is attacked.
   • If so, find the attack source.
   • If not, go to step 2.
2. Collect required information and contact technical support personnel.

Description

IP address allocation failed.

Possible Causes

• No IP address pool was configured.
• All IP addresses in the IP address pool had been allocated.

Solution

1. Check whether an IP address pool has been configured.
   • If not, configure an IP address pool.
   • If so, go to step 2.
2. Run the display ip pool command to check whether all IP addresses in the IP address pool have been allocated.
   • If so, plan the network segment of the IP address pool correctly.
   • If not, go to step 3.
3. Collect required information and contact technical support personnel.

Description

The number of IPSec tunnels reached the limit.

Possible Causes

The number of established IPSec tunnels reached the limit.

Solution

• Plan the network properly or expand the device capacity.

Description

The number of IPSec tunnels was license controlled or reached the limit.

Possible Causes

The number of IPSec tunnels reached the limit.

Solution

1. Run the display license command to check whether the number of IPSec tunnels is license controlled.
   • If so, go to step 2.
   • If not, go to step 3.
2. Run the display ipsec sa brief command to check whether the number of IPSec tunnels on the device exceeds the license limit.
   • If so, apply for a license or plan the network properly.
   • If not, go to step 3.
3. Check whether the number of IPSec tunnels on the device exceeds the device limit based on the device model.
   • If so, expand the device capacity or plan the network properly.
   • If not, go to step 4.
4. Collect required information and contact technical support personnel.

Description

The local address is mismatched.

Possible Causes

The destination address of the IKE negotiation packet received by the local device from the remote device is mismatched with the local address.

Solution

1. Run the display ike peer command to view the remote addresses used on both ends.

   <sysname> display ike peer name peer1 
   ----------------------------------------------------------- 
    Peer name                               : peer1 
    IKE version                             : v1v2 
    VPN instance                            : - 
    Remote IP                               : 10.1.1.1 
    Authentic IP address                    : - 
    Proposal                                : - 
    Pre-shared-key                          : 
    Local ID type                           : IP 
    Local ID                                : - 
    Remote ID type                          : - 
    Remote ID                               : - 
   ......

   View the Remote IP field and the remote device's local address. By default, the device uses the primary IP address of an interface as the local address.

2. If not, run the remote-address command in the IKE peer view of the remote device to change the remote address.

Description

A malformed message.

Possible Causes

The pre-shared keys of IKE peers on both ends are inconsistent.

Solution

1. Run the display ike peer command to view the pre-shared keys used on both ends.

   <sysname> display ike peer name peer1 
   ----------------------------------------------------------- 
    Peer name                               : peer1 
    IKE version                             : v1v2 
    VPN instance                            : - 
    Remote IP                               : 10.1.1.1 
    Authentic IP address                    : - 
    Proposal                                : - 
    Pre-shared-key                          : %^%#G7(t:%yFw/PVF>Jsva;"zx]oL!sw-8z\C;I}%%RY%^%# 
    Local ID type                           : IP 
    Local ID                                : - 
    Remote ID type                          : - 
    Remote ID                               : - 
   ......

   View the Pre-shared-key field, which is displayed in ciphertext. Change the pre-shared keys as required.

2. Run the pre-shared-key command in the IKE peer view to change the pre-shared keys on both ends to be consistent.

Description

A malformed payload.

Possible Causes

The pre-shared keys of IKE peers on both ends are inconsistent.

Solution

1. Run the display ike peer command to view the pre-shared keys used on both ends.

   <sysname> display ike peer name peer1 
   ----------------------------------------------------------- 
    Peer name                               : peer1 
    IKE version                             : v1v2 
    VPN instance                            : - 
    Remote IP                               : 10.1.1.1 
    Authentic IP address                    : - 
    Proposal                                : - 
    Pre-shared-key                          : %^%#G7(t:%yFw/PVF>Jsva;"zx]oL!sw-8z\C;I}%%RY%^%# 
    Local ID type                           : IP 
    Local ID                                : - 
    Remote ID type                          : - 
    Remote ID                               : - 
   ......

   View the Pre-shared-key field, which is displayed in ciphertext. Change the pre-shared keys as required.

2. Run the pre-shared-key command in the IKE peer view to change the pre-shared keys on both ends to be consistent.

Description

NAT detection failed.

Possible Causes

The device failed to process the NAT detection payload.

Solution

• Collect required information and contact technical support personnel.

Description

The mask is mismatched.

Possible Causes

After the IPSec mask filtering function is enabled, the local device checks the source and destination address masks of the data flow of the remote device. If the masks are smaller than the configured source and destination address masks, IKE negotiation fails.

Solution

1. Run the display ipsec global config command to check whether the source and destination address masks of data flows on both ends are correct.

   <sysname> display ipsec global config 
   IPSec Global Config: 
   -------------------------------------------------------------- 
   ...... 
     IPSec netmask source                                : 24 
     IPSec netmask destination                           : 24 
   ......

   • If so, no action is required.
   • If not, go to step 2.
2. Run the ipsec netmask command in the system view to change the source and destination address masks as required.

Description

No policy is applied to an interface.

Possible Causes

• The IPSec policy is incorrectly applied to an interface.
• The remote address configured in the IKE peer view is the local address. As a result, packets are not sent from the specified interface and sent to an internal loopback interface.

Solution

1. Run the display ipsec interface brief command to check whether the IPSec policy applied to the interface is correct.

   <sysname> display ipsec interface brief 
   ------------------------------------------------ 
     IPSec policy        : policy1 
     Using interface     : GigabitEthernet1/0/0 
     IPSec policy number : 10 
     IPSec policy Type : policy 
   ------------------------------------------------

   • If not, apply a correct IPSec policy in the interface view.
   • If so, go to step 2.
2. Run the display ike peer command to view the local and remote addresses used by the device.

   <sysname> display ike peer name peer1 
   ----------------------------------------------------------- 
    Peer name                               : peer1 
    IKE version                             : v1v2 
    VPN instance                            : - 
    Remote IP                               : 10.1.1.1 
    Authentic IP address                    : - 
    Proposal                                : - 
    Pre-shared-key                          : %^%#G7(t:%yFw/PVF>Jsva;"zx]oL!sw-8z\C;I}%%RY%^%# 
    Local ID type                           : IP 
    Local ID                                : - 
    Remote ID type                          : - 
    Remote ID                               : - 
   ......

   Remote IP must be different from the local address. By default, the device uses the primary IP address of an interface as the local address.

   Run the remote-address command in the IKE peer view to change the remote address.

Description

Failed to select the tunnel interface from the user table based on the remote ID.

Possible Causes

• The user ID type and ID configured for the IKE user are incorrect.
• The interface associated with the IKE user is incorrect.

Solution

1. Run the display ike user-table command to view the user ID type, user ID, and interface associated with the IKE user.

   <sysname> display ike user-table number 10 
   --------------------------------------------------------------------------- 
    IKE User-table: 10, Number of users: 1 
   --------------------------------------------------------------------------- 
    
     User Name              : user1 
     User ID-type           : IP 
     User ID                : 1.1.1.1 
     Pre-shared-key         : %^%#D,Ul0!:u2RM;giQtp4KDzkbm*)=Y[NYF[N6s)SMQ%^%# 
     VPN instance           : vrf1 
     Description            : USER1 
     Interface-assign       : Tunnel0/0/1

   View the User ID-type, User ID, and Interface-assign fields.

2. Run the id-type and interface-assign commands in the IKE user view to configure a correct user ID type, user ID, and interface associated with the IKE user.

Description

The IKE peer address is mismatched.

Possible Causes

• The source address of the IKE negotiation packet received by the local device from the remote device is mismatched with the remote address.
• When IPSec negotiation is performed based on tunnel interfaces, the destination address configured on the local tunnel interface is inconsistent with the remote address configured in the IKE peer view.

Solution

1. Run the display ike peer command to check whether IKE peer addresses on both ends match.

   <sysname> display ike peer name peer1 
   ----------------------------------------------------------- 
    Peer name                               : peer1 
    IKE version                             : v1v2 
    VPN instance                            : - 
    Remote IP                               : 10.1.1.1 
    Authentic IP address                    : - 
    Proposal                                : - 
    Pre-shared-key                          : 
    Local ID type                           : IP 
    Local ID                                : - 
    Remote ID type                          : - 
    Remote ID                               : - 
   ......

   View the Remote IP field and the remote device's local address. By default, the device uses the primary IP address of an interface as the local address.

   • If not, run the remote-address command in the IKE peer view to change the remote address.
   • If so, go to step 2.
2. When IPSec negotiation is performed based on tunnel interfaces, view the destination address configured on the local tunnel interface and the remote address configured in the IKE peer view.

   If no destination address is configured on the local tunnel interface, enable the local device to use the remote address configured in the IKE peer view to initiate negotiation. If no destination address is configured for the local tunnel interface and no remote address is configured in the IKE peer view, the local device can only accept the negotiation initiated by the remote device.

   If the destination address is configured on the local tunnel interface, ensure that the destination address is the same as the remote address configured in the IKE peer view.

Description

The IKE proposal is mismatched.

Possible Causes

The IKE proposal parameters used by IKE peers on both ends are inconsistent, including the authentication method, authentication algorithm, and encryption algorithm.

Solution

1. Run the display ike proposal command to view the IKE proposal parameters used on both ends.

   <sysname> display ike proposal number 10 
   ------------------------------------------- 
    IKE Proposal: 10 
    Authentication Method      : PRE_SHARED 
    Authentication Algorithm : SHA2-256 
    Encryption Algorithm       : AES-256 
    Diffie-Hellman Group       : MODP-2048 
    SA Duration(Seconds)       : 86400 
    Integrity Algorithm        : HMAC-SHA2-256 
    Prf Algorithm              : HMAC-SHA2-256 
   -------------------------------------------

2. Run the required command in the IKE proposal view to change the inconsistent IKE proposal parameters to be consistent.
   • Run the authentication-method command to change the authentication method.
   • Run the authentication-algorithm command to change the authentication algorithm used in IKEv1 negotiation.
   • Run the encryption-algorithm command to change the encryption algorithm.
   • Run the dh command to change the DH algorithm.
   • Run the integrity-algorithm command to change the integrity algorithm used in IKEv2 negotiation.
   • Run the prf command to change the PRF algorithm used in IKEv2 negotiation.

Description

The security ACL, IPSec proposal, or PFS algorithm is mismatched.

Possible Causes

• Security ACLs of IKE peers on both ends are mismatched.
• The IPSec proposal parameters used by IKE peers on both ends are inconsistent, including the authentication algorithm and encryption algorithm.
• The PFS algorithms of the two IKE peers are inconsistent.

Solution

1. Run the display ipsec policy command to view security ACLs on both ends and then run the display acl command to check whether security ACL rules on both ends match.

   <sysname> display ipsec policy name map1 
   =========================================== 
   IPSec policy group: "map1"  
   Using interface: GigabitEthernet0/0/1  
   =========================================== 
        Sequence number: 10 
        Policy Alias: map1-10 
        Security data flow: 3000  
   ......  
    
   <sysname> display acl 3000  
   Advanced ACL 3000, 1 rule                                 
   Acl's step is 5                                                                   
    rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.2.2.0 0.0.0.255  

   • If not, run the rule command in the ACL view to change security ACL rules.
   • If so, go to step 2.
2. Run the display ipsec proposal command to check whether the IPSec proposal parameters used on both ends are consistent.

   <sysname> display ipsec proposal name tran1 
   IPSec proposal name: tran1 
    Encapsulation mode: Tunnel 
    Transform         : esp-new 
    ESP protocol      : Authentication SHA2-HMAC-256 
                        Encryption AES-256

   • If not, run the required command in the IPSec proposal view to change the inconsistent IPSec proposal parameters to be consistent.
   • Run the encapsulation-mode command to change the encapsulation mode.
   • Run the transform command to change the security protocol.
   • Run the ah authentication-algorithm command to change the authentication algorithm used in AH.
   • Run the esp authentication-algorithm command to change the authentication algorithm used in ESP.
   • Run the esp encryption-algorithm command to change the encryption algorithm used in ESP.
   • If so, go to step 3.
3. Run the display ipsec policy, display ipsec profile, or display ipsec policy-template command to view the PFS algorithms used on both ends.

   For example, run the display ipsec policy command to view the Perfect forward secrecy field.

   <sysname> display ipsec policy name map 
   =========================================== 
   IPSec policy group: "map" 
   Using interface: 
   =========================================== 
    
    Sequence number: 10 
    Policy Alias: map-10 
    Security data flow: 3000/IPv4 
    Peer name : - 
    Perfect forward secrecy: DH group 14 
    Proposal name:  tran1 
   ......

   Run the pfs command in the ISAKMP IPSec policy view, IPSec policy template view, or IPSec profile view to change the PFS algorithms used on both ends to be consistent.

Description

The IPSec proposal is mismatched or IKEv2 uses the SM algorithm.

Possible Causes

• The IKE proposals used by IKE peers on both ends are mismatched.
• The IPSec proposals used by IKE peers on both ends are mismatched.
• IKEv2 uses the unsupported SM algorithm.

Solution

1. Run the display ike proposal command to check whether the IKE proposal parameters used on both ends are consistent.

   <sysname> display ike proposal number 10 
   ------------------------------------------- 
    IKE Proposal: 10 
    Authentication Method      : PRE_SHARED 
    Authentication Algorithm : SHA2-256 
    Encryption Algorithm       : AES-256 
    Diffie-Hellman Group       : MODP-2048 
    SA Duration(Seconds)       : 86400 
    Integrity Algorithm        : HMAC-SHA2-256 
    Prf Algorithm              : HMAC-SHA2-256 
   -------------------------------------------

   • If so, go to step 2.
   • If not, run the required command in the IKE proposal view to change the inconsistent IKE proposal parameters to be consistent.
   • Run the authentication-method command to change the authentication method.
   • Run the authentication-algorithm command to change the authentication algorithm used in IKEv1 negotiation.
   • Run the encryption-algorithm command to change the encryption algorithm.

     During IKEv2 negotiation, ensure that the encryption algorithm is not the SM algorithm.

   • Run the dh command to change the DH algorithm.
   • Run the integrity-algorithm command to change the integrity algorithm used in IKEv2 negotiation.
   • Run the prf command to change the PRF algorithm used in IKEv2 negotiation.
2. Run the display ipsec proposal command to check whether the IPSec proposal parameters used on both ends are consistent.

   <sysname> display ipsec proposal name tran1 
   IPSec proposal name: tran1 
    Encapsulation mode: Tunnel 
    Transform         : esp-new 
    ESP protocol      : Authentication SHA2-HMAC-256 
                        Encryption AES-256

   • If so, go to step 3.
   • If not, run the required command in the IPSec proposal view to change the inconsistent IPSec proposal parameters to be consistent.
   • Run the encapsulation-mode command to change the encapsulation mode.
   • Run the transform command to change the security protocol.
   • Run the ah authentication-algorithm command to change the authentication algorithm used in AH.
   • Run the esp authentication-algorithm command to change the authentication algorithm used in ESP.
   • Run the esp encryption-algorithm command to change the encryption algorithm used in ESP.
3. According to the preceding command outputs, run the required command to change the authentication algorithm and encryption algorithm used in IKEv2 to non-SM algorithms.

Description

IPSec SA renegotiation failed.

Possible Causes

During IPSec SA renegotiation, the initiator did not receive any response packet from the responder.

• The link between two IKE peers is unreachable.
• The device is not working properly.

Solution

1. Perform a ping operation to check whether the link between both ends is reachable.
   • If not, ensure that the network configurations, including interfaces and IP addresses, are correct.
   • If so, go to step 2.
2. Check whether the responder is working properly, for example, whether it is faulty or its interfaces are Down.
   • If not, ensure that the responder is working properly.
   • If so, go to step 3.
3. Collect required information and contact technical support personnel.

Description

The old IPSec SA was not found during IPSec SA renegotiation.

Possible Causes

The old IPSec SA was deleted during IPSec SA renegotiation. If the old IPSec SA cannot be found, the device initiates IPSec SA negotiation again.

Solution

• This symptom is normal and no operation is required.

Description

The DH algorithm of the responder is mismatched.

Possible Causes

The DH algorithms of IKE peers on both ends are mismatched.

Solution

1. Run the display ike proposal command to view the DH algorithms used on both ends.

   <sysname> display ike proposal number 10 
   ------------------------------------------- 
    IKE Proposal: 10 
   ...... 
    Diffie-Hellman Group       : MODP-2048 
   ......

2. Run the dh command in the IKE proposal view to change the DH algorithms to be consistent.

Description

The negotiation mode in IKEv1 phase 1 is mismatched.

Possible Causes

The negotiation modes in IKEv1 phase 1 used by IKE peers on both ends are mismatched.

Solution

1. Run the display ike peer command to view the negotiation modes in IKEv1 phase 1 used on both ends.

   <sysname> display ike peer name peer1 
   ----------------------------------------------------------- 
    Peer name                               : peer1 
   ...... 
    Exchange mode                           : main on phase 1 
   ......

2. Run the exchange-mode command in the IKE peer view to change the negotiation modes in IKEv1 phase 1 to be consistent on both ends.

Description

The number of IPSec injected routes reached the limit.

Possible Causes

After the route injection function was configured, the number of routes generated based on IPSec tunnel information exceeded the limit.

Solution

1. Properly plan the routes generated after the route injection function is configured.
2. If the fault persists, collect required information and contact technical support personnel.

Description

Unknown negotiation mode in IKEv1 phase 1.

Possible Causes

The negotiation mode in the received IKEv1 negotiation packet is not the main or aggressive mode.

Solution

1. Set the negotiation mode in IKEv1 phase 1 of the remote device to the main or aggressive mode.
2. If the fault persists, collect required information and contact technical support personnel.

Description

The IKE version is not supported.

Possible Causes

The IKE version in the received negotiation packet is not IKEv1 or IKEv2.

Solution

1. Set the IKE version of the remote device to IKEv1 or IKEv2.
2. If the fault persists, collect required information and contact technical support personnel.

Description

The IKE version is unmatched.

Possible Causes

The IKE versions of IKE peers on both ends are inconsistent.

Solution

1. Run the display ike peer command to view the IKE versions used on both ends.

   <sysname> display ike peer name peer1 
   ----------------------------------------------------------- 
    Peer name                               : peer1 
    IKE version                             : v1v2 
   ......

   If both IKEv1 and IKEv2 are enabled, the device initiates negotiation using IKEv2 and responds to negotiation using IKEv1 or IKEv2.

2. Run the version command in the IKE peer view to change the IKE versions of both ends to be consistent.

Description

XAUTH authentication failed.

Possible Causes

The server failed to verify XAUTH authentication parameters.

• The user name and password are incorrect.
• The XAUTH authentication configuration is incorrect.

Solution

1. Check whether the user name and password are consistent with those on the server.
   • If not, change the user name and password.
   • If so, go to step 2.
2. Check whether the XAUTH authentication configuration is correct, for example, the XAUTH configuration in the IKE peer view and XAUTH-used domain configuration in the AAA view.
   • If not, modify the XAUTH authentication configuration to ensure that it is correct.
   • If so, go to step 3.
3. Collect required information and contact technical support personnel.

Description

XAUTH authentication expired.

Possible Causes

The device did not receive packets from the client or server during XAUTH authentication.

• The link from the device to the client or server is unreachable.
• The client or server is not working properly.

Solution

1. Perform a ping operation to check whether the link from the device to the client or server is reachable.
   • If not, ensure that the network configurations, including interfaces and IP addresses, are correct.
   • If so, go to step 2.
2. Check whether the client or server is working properly. For example, check whether the server is not functioning properly.
   • If not, ensure that the client and server are working properly.
   • If so, go to step 3.
3. Collect required information and contact technical support personnel.

Description

The AAA module forces users to go offline.

Possible Causes

• The cut access-user command is executed on the device.
• The authentication server notifies users to go offline.

Solution

1. Run the display aaa offline-record command to check whether users go offline normally based on the offline causes.
   • If so, no action is required.
   • If not, go to step 2.
2. Run the display aaa abnormal-offline-record command to view the causes of unexpected offline events.

   Rectify the fault based on the causes.

Description

The configuration was modified or a SA was manually cleared.

Possible Causes

• The IPSec configuration was modified by a user.
• The reset command was executed to manually clear a SA.
• The IPSec policy applied to an interface was cancelled manually.
• The IP address of the interface to which an IPSec policy was applied changed.

Solution

1. Check whether a user manually cleared the SA.
   • If so, no action is required.
   • If not, go to step 2.
2. Check whether the IPSec policy applied to an interface was cancelled manually.
   • If so, check whether this operation is appropriate.
   • If so, no action is required.
   • If not, apply the IPSec policy on the interface again.
     • If not, go to step 3.
3. Check whether the IPSec configuration was modified as expected.
   • If so, go to step 4.
   • If not, modify the IPSec configuration to ensure that it is correct.
4. Check whether the IP address of the interface to which the IPSec policy was applied changed as expected.
   • If so, no action is required.
   • If not, ensure that the IP address of the interface is correct.

Description

CPU entries were updated.

Possible Causes

Removing an SPU caused CPU entries to be updated and the SA of a non-local CPU to be deleted.

Solution

• This symptom is normal and no operation is required.

Description

An IPSec tunnel was torn down based on the NQA test instance, NQA group, VRRP group, BFD session, or BFD group status.

Possible Causes

IPSec was associated with NQA, VRRP, or BFD, and the IPSec tunnel was torn down based on the NQA test instance, NQA group, VRRP group, BFD session, or BFD group status.

Solution

• This symptom is normal and no operation is required.

Description

The DNS resolution status changed.

Possible Causes

• The link between the device and DNS server is abnormal.
• The DNS server is not working properly.
• The domain name configured using the remote-address command is incorrect.

Solution

1. Perform a ping operation to check whether the link between the device and DNS server is reachable.
   • If not, ensure that the network configurations, including interfaces and IP addresses, are correct.
   • If so, go to step 2.
2. Check whether the DNS server is working properly.
   • If not, ensure that the DNS server is working properly.
   • If so, go to step 3.
3. Check whether the domain name configured using the remote-address command is incorrect.
   • If not, run the remote-address command in the IKE peer view to change the domain name.
   • If so, go to step 4.
4. Collect required information and contact technical support personnel.

Description

DPD detection expired.

Possible Causes

• The link between two IKE peers is unreachable.
• The sequence of the payload in DPD packets on two IKE peers is inconsistent.

Solution

1. Perform a ping operation to check whether the link between both ends is reachable.
   • If not, ensure that the network configurations, including interfaces and IP addresses, are correct.
   • If so, go to step 2.
2. Run the display ike peer command to check whether the sequence of the payload in DPD packets on both ends is consistent.

   <sysname> display ike peer name peer1 
   ----------------------------------------------------------- 
    Peer name                               : peer1 
    IKE version                             : v1v2 
   ...... 
    DPD                                     : Enable 
    DPD type                                : on-demand 
    DPD retry-limit                         : 3 
    DPD retransmit-interval(s)              : 30 
    DPD idle-time(s)                        : 60 
    DPD message                             : seq-hash-notify 
   ......

   • If not, run the dpd msg command in the IKE peer view to change the sequence of the payload in DPD packets on both ends to be consistent.
   • If so, go to step 3.
3. Collect required information and contact technical support personnel.

Description

The old SA was deleted during EAP authentication.

Possible Causes

When the remote device performed EAP authentication repeatedly, the local device deleted the old SA.

Solution

• This symptom is normal and no operation is required.

Description

Packet exchange timed out.

Possible Causes

• The link between two IKE peers is unreachable.
• The IPSec configuration is incorrect.

Solution

1. Perform a ping operation to check whether the link between both ends is reachable.
   • If not, ensure that the network configurations, including interfaces and IP addresses, are correct.
   • If so, go to step 2.
2. Check whether the IPSec configurations of both ends are correct.
   • If not, modify the configurations to ensure that they are correct.
   • If so, go to step 3.
3. Collect required information and contact technical support personnel.

Description

Flows overlap.

Possible Causes

Multiple overlapped Securtiy ACL rules exist on the device.

Solution

1. Run the display ipsec policy command to view security ACLs on both ends and then run the display acl command to view security ACL rules on both ends.

   <sysname> display ipsec policy name map1 
   =========================================== 
   IPSec policy group: "map1"  
   Using interface: GigabitEthernet0/0/1  
   =========================================== 
        Sequence number: 10 
        Policy Alias: map1-10 
        Security data flow: 3000  
   ......  
    
   <sysname> display acl 3000  
   Advanced ACL 3000, 1 rule                                 
   Acl's step is 5                                                                   
    rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.2.2.0 0.0.0.255  

   Find the overlapping security ACL rules based on the security ACL rule information.

2. Run the rule command in the ACL view to change security ACL rules.

Description

Hard expiry occurred due to the mismatched NAT port number.

Possible Causes

The port number changed after the intermediate NAT device was replaced.

Solution

• This symptom is normal and no operation is required.

Description

Hash factors were adjusted.

Possible Causes

Removing or resetting SPUs changed the number of SPUs and caused SAs to be deleted.

Solution

• This symptom is normal and no operation is required.

Description

Heartbeat detection expired.

Possible Causes

• The link between two IKE peers is unreachable.
• The heartbeat configurations of two IKE peers are inconsistent.

Solution

1. Perform a ping operation to check whether the link between both ends is reachable.
   • If not, ensure that the network configurations, including interfaces and IP addresses, are correct.
   • If so, go to step 2.
2. Check whether the heartbeat configurations on both ends are consistent.
   • If not, modify the configurations to ensure that they are correct.
   • Run the ike heartbeat command to modify heartbeat packet parameters.
   • Run the ike heartbeat-timer interval command to change the interval for sending heartbeat packets.
   • Run the ike heartbeat-timer timeout command to change the timeout interval of heartbeat packets.

   When configuring the ike heartbeat-timer interval and ike heartbeat-timer timeout commands, you need to configure the ike heartbeat-timer interval command on the remote device if you have configured the ike heartbeat-timer timeout command on the local device.

   The timeout interval of heartbeat packets is often longer than the interval for sending heartbeat packets. Packets will not be lost on the network for three consecutive times. You can set the timeout interval of heartbeat packets on the local device to be three times the interval for sending heartbeat packets on the remote device.

   • If so, go to step 3.
3. Collect required information and contact technical support personnel.

Description

The device deleted the associated IPSec SA when deleting an IKEv1 SA.

Possible Causes

Dependency between IPSec SA and IKE SA during IKEv1 negotiation has been enabled. That is, deleting an IKEv1 SA will delete the associated IPSec SA.

Solution

• Run the display ike offline-info command to check whether there are multiple failure causes for the same address.
  • If not, no action is required.
  • If so, locate the fault.

Description

IP address synchronization failed.

Possible Causes

The IP addresses in the IP address pool are inconsistent with the IP address information recorded by IPSec.

Solution

• Collect required information and contact technical support personnel.

Description

The old SA was deleted when the same data flow was received.

Possible Causes

The function of allowing new users with the same data flow as online users to quickly access the headquarters has been enabled. This function will enable the IPSec SA that has been established between two IKE peers to be aged quickly so that a new IPSec tunnel can be established.

Solution

1. Run the display ipsec policy command to view security ACLs on both ends and then run the display acl command to check whether security ACL rules of multiple branches overlap.

   <sysname> display ipsec policy name map1 
   =========================================== 
   IPSec policy group: "map1"  
   Using interface: GigabitEthernet0/0/1  
   =========================================== 
        Sequence number: 10 
        Policy Alias: map1-10 
        Security data flow: 3000  
   ......  
    
   <sysname> display acl 3000  
   Advanced ACL 3000, 1 rule                                 
   Acl's step is 5                                                                 
    rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.2.2.0 0.0.0.255 

   • If so, run the rule command in the ACL view to change security ACL rules.
   • If not, go to step 2.
2. Check whether the IP address used by the same branch for IPSec negotiation is changed correctly.
   • If so, go to step 3.
   • If not, ensure that the IP address is configured correctly.
3. Collect required information and contact technical support personnel.

Description

The lease of the server-assigned IP address expired.

Possible Causes

The lease of the IP address obtained by the remote device from the server expired, and the remote device will request another IP address.

Solution

• This symptom is normal and no operation is required.

Description

NHRP notifies the deletion of a SA.

Possible Causes

There is no service traffic between branches. After NHRP entries are aged, the DSVPN tunnel is deleted.

Solution

• This symptom is normal and no operation is required.

Description

The remote address is changed.

Possible Causes

Multiple remote addresses have been configured in the IKE peer view for backup. If the remote device with the active address becomes unreachable, the local device establishes an IPSec tunnel with the remote device with the standby address and deletes the old IPSec tunnel.

Solution

1. Check whether the active/standby IP address switchover is normal.
   • If not, go to step 2.
   • If so, no action is required.
2. Check whether the link between both ends is reachable.
   • If not, ensure that the network configurations, including interfaces and IP addresses, are correct.
   • If so, go to step 3.
3. Collect required information and contact technical support personnel.

Description

The remote device sends a message to notify the local device to delete a SA.

Possible Causes

The local device receives from the remote device a request message that notifies the local device to delete a SA.

Solution

• Check whether the remote device has deleted the SA correctly.
  • If so, no action is required.
  • If not, run the display ike offline-info command to locate the fault based on other causes.

Description

Phase 1 hard lifetime expired.

Possible Causes

IKE SA hard lifetime expired.

Solution

1. Run the display ike proposal command to check whether the IKE SA hard lifetime is correct.

   <sysname> display ike proposal number 10 
   ------------------------------------------- 
    IKE Proposal: 10 
   ...... 
    SA Duration(Seconds)       : 86400 
   ...... 
   -------------------------------------------

   • If so, no action is required.
   • If not, go to step 2.
2. Run the sa duration command in the IKE proposal view to change the IKE SA hard lifetime on both ends to be consistent.

Description

The new IKE SA replaces the old one.

Possible Causes

The newly generated IKE SA replaces the old one.

Solution

• This symptom is normal and no operation is required.

Description

Phase 2 hard lifetime expired.

Possible Causes

IPSec SA hard lifetime expired.

Solution

1. Run the display ike global config, display ipsec policy, display ipsec policy-template, or display ipsec profile command to check whether the IPSec SA hard lifetime is correct.

   For example, run the display ike global config command to view the IPSec SA hard lifetime.

   <sysname> display ipsec global config 
   IPSec Global Config: 
   -------------------------------------------------------------- 
     IPSec sa global-duration time-based(seconds)        : 3600 
     IPSec sa global-duration traffic-based(kbytes)      : 1843200 
   ......

   • If so, no action is required.
   • If not, go to step 2.
2. Run the required command to change the IPSec SA hard lifetime on both ends to be consistent.
   • Run the ipsec sa global-duration command in the system view.
   • Run the sa duration command in the ISAKMP IPSec policy view, IPSec policy template view, or IPSec profile view.

Description

The new IPSec SA replaces the old one.

Possible Causes

The newly generated IPSec SA replaces the old one.

Solution

• This symptom is normal and no operation is required.

Description

IKEv2 reauthentication expired.

Possible Causes

• The link between two IKE peers is unreachable.
• The remote device is not working properly.
• IPSec negotiation parameters on both IKE peers are inconsistent.

Solution

1. Perform a ping operation to check whether the link between both ends is reachable.
   • If not, ensure that the network configurations, including interfaces and IP addresses, are correct.
   • If so, go to step 2.
2. Check whether the remote device is working properly.
   • If not, ensure that the remote device is working properly.
   • If so, go to step 3.
3. Check whether IPSec negotiation parameters on both ends are consistent.
   • If not, change the IPSec negotiation parameters to be consistent.
   • If so, go to step 4.
4. Collect required information and contact technical support personnel.

Description

The standby device received a backup SA deletion message from the active device.

Possible Causes

The active device sent a backup SA deletion message to the standby device.

Solution

• This symptom is normal and no operation is required.

Description

An invalid SPI notification was received.

Possible Causes

When the IPSec SA of Gateway_1 on one end of an IPSec tunnel is lost, the corresponding IKE SA still exists on Gateway_1. However, Gateway_2 on the other end of the IPSec tunnel retains the IPSec SA. If Gateway_1 receives an IPSec packet encapsulated by Gateway_2 using the IPSec SA, Gateway_1 discards the packet because it cannot find the corresponding IPSec SA. At the same time, Gateway_1 sends a DELETE SA INFORMATIONAL message to Gateway_2 by default. After receiving the message, Gateway_2 immediately deletes the IPSec SA matching the invalid SPI. When Gateway_2 continues sending IPSec packets to Gateway_1, the two ends renegotiate an IPSec SA to restore the IPSec service.

Solution

• This symptom is normal and no operation is required.

Description

An SPI conflict occurred.

Possible Causes

The SPI carried in the IKE negotiation packet sent by the remote device is the same as the existing SPI.

Solution

• This symptom is normal and no operation is required.