No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

AR Router Troubleshooting Guide

This Product Documentation provides guidance for maintaining AR Enterprise Router, covering common information collection and fault diagnostic commands, typical fault troubleshooting guide, and troubleshooting.
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Troubleshooting Guide

Troubleshooting Guide

Troubleshooting Index

This section sorts out the IPSec troubleshooting guidelines, classifies faults based on the fault symptom, and establishes an index table, as shown in Table 26-1.

Figure 26-4  IPSec networking diagram

In Figure 26-4, the display ipsec sa command is run on Router1 and Router2 to check the SA status.

Table 26-1  Troubleshooting index table

Fault Symptom

Detailed Processing Guide

No information is displayed on Router1 and the IPSec tunnel fails to be established. After the display ipsec statistics command is run on Router1, the value of outbound ok is 0 in the command output, indicating that the local end does not send IKE negotiation packets and the IPSec tunnel negotiation is not triggered.

No Data Flow to Trigger IKE Negotiation

The IKE SA is not established on Router1 and the IPSec tunnel fails to be established. After the display ipsec statistics command is run on Router1, the value of outbound ok is not 0 in the command output, indicating that the IKE packets have been sent.

IKE SA Negotiation Failure

The IPSec SA is not established on Router1 and the IPSec tunnel fails to be established.

IPSec SA Negotiation Failure

The SA is successfully established on Router1 and the SA fails to be established on Router2.

Successful IKE Renegotiation in Only One Direction After Unexpected Device Restart

The IPSec SA information on Router1 and Router2 indicates that the IPSec tunnel has been successfully established but the following faults occur:
  • Users of the branches and headquarters cannot communicate with each other.
  • Only unidirectional communication is implemented between users of the branches and headquarters. For example, users of the headquarters can access servers in the branch, but users of the branches cannot access servers in the headquarters.
  • Users of the branch and headquarters can access only some network segments.
  • On a point-to-multipoint network, users of the branches may communicate with the headquarters normally, but users of different branches cannot communicate with each other.
  • In a scenario where the IPSec gateway also functions as the NAT gateway, all traffic may be translated using NAT before being forwarded and no traffic enters the VPN.

Service Interruption After Successful IPSec Tunnel Setup

The IPSec SA information on Router1 and Router2 indicates that the IPSec tunnel has been successfully established but the following faults occur:
  • The service access speed is slow.
  • The service access is intermittent or interrupted.

Poor Service Quality After Successful IPSec Tunnel Setup

No Data Flow to Trigger IKE Negotiation

Fault Symptom

In Figure 26-5, after IPSec is deployed between Routers, PCs cannot communicate with each other.

Figure 26-5  IPSec networking

Run the display ike sa command on Router1, finding that no information is displayed. This indicates that an IPSec tunnel fails to be established.

<Router1> display ike sa

Run the display ipsec statistics command on Router1 to check IPSec statistics.

<Router1> display ipsec statistics
.......
  negotiate about packet statistics:
    IKE fwd packet ok: 0, err: 0
    IKE ctrl packet inbound ok: 0, outbound ok: 0
    SoftExpr: 0, HardExpr: 0, DPDOper: 0
    trigger ok: 0, switch sa: 0, sync sa: 0
    recv IKE nat keepalive: 0, IKE input: 0 
  • Automatic IPSec SA triggering mode

    If the outbound ok field displays 0, the local end does not send IKE negotiation packets and does not trigger IPSec tunnel negotiation.

  • Traffic-based IPSec SA triggering mode

    If the trigger ok field displays 0, no traffic triggers IKE negotiation. If the outbound ok field displays 0 and the trigger ok field does not display 0, the local end does not send IKE negotiation packets and does not trigger IPSec tunnel negotiation.

Possible Causes

Troubleshooting Procedure

Procedure

  1. Run the display ipsec policy command to check the IPSec SA triggering mode.

    <Huawei> display ipsec policy
    ===========================================
    IPSec policy group: "10"
    Using interface: GigabitEthernet1/0/0
    ===========================================
         Sequence number: 10
         Policy Alias: map1-10
         Security data flow: 3100/IPv4
         Peer name    :  rut2
         Perfect forward secrecy: DH group 14
         Proposal name:  prop1
         IPSec SA local duration(time based): 3600 seconds
         IPSec SA local duration(traffic based): 1843200 kilobytes
         SA trigger mode: Traffic-based   //IPSec SA triggering mode.
    .......

    The default IPSec SA triggering mode is traffic-based triggering, and the prerequisite for triggering IKE negotiation is that service traffic exists. You can trigger IKE negotiation through a ping. Run the sa trigger-mode auto command in the ISAKMP IPSec policy view to set the IPSec SA triggering mode to automatic triggering. This configuration ensures that IKE negotiation can be triggered when no service traffic exists.

  2. Check whether private and public network routes are reachable.

    Run the ping command to check whether private and public network routes are reachable. If not, ensure that the links are normal, interfaces are Up, and network configurations such as the routing configuration are correct.

  3. Check whether an IPSec policy is correctly applied to a tunnel interface.

    Run the display ipsec interface brief command to check whether the tunnel interface has IPSec policy information. If not, apply an IPSec policy to this interface.

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

  4. Check whether the security ACL configuration matches the IPSec-protected data flow.

    Run the display ipsec policy command to check the security ACL number and then run the display acl acl-number command to check whether the security ACL configuration matches the IPSec-protected data flow. If not, modify the configuration.

    <Huawei> display ipsec policy
    ===========================================
    IPSec policy group: "10"
    Using interface: GigabitEthernet1/0/0
    ===========================================
         Sequence number: 10
         Policy Alias: map1-10
         Security data flow: 3100/IPv4   //Security ACL.
         Peer name    :  rut2
         Perfect forward secrecy: DH group 14
         Proposal name:  prop1
         IPSec SA local duration(time based): 3600 seconds
         IPSec SA local duration(traffic based): 1843200 kilobytes
         SA trigger mode: Traffic-based   
    ......
    <Huawei> display acl 3100
    Advanced ACL 3100, 1 rule ( Reference counter 1 )
    Acl's step is 5
     rule 5 permit ip source 10.1.2.0 0.0.0.255 destination 10.1.1.0 0.0.0.255 (0 times matched)
    

  5. Check whether the NAT policy configuration affects the IPSec-protected data flows.

    When IPSec packets are forwarded, NAT and then IPSec encryption are performed on the packets. As a result, the IPSec packets fail to be sent. In this case, ensure that the NAT server and destination NAT do not affect processing of IPSec-protected data flows.

    You can run the display ipsec interface brief command to check the interface to which an IPSec policy is applied, and then run the display current-configuration interface interface-type interface-number command to check whether a NAT policy is configured on the specified IPSec interface.

    If NAT is configured on the interface to which an IPSec policy is applied, IPSec does not take effect because the device executes the NAT configuration first. In this case, you need to ensure:
    • The destination IP address denied in the ACL rule referenced by NAT is the destination IP address in the ACL rule referenced by IPSec. By doing so, the device does not perform NAT on the IPSec-protected data flows.
    • The ACL rule referenced by IPSec matches the post-NAT IP address.

  6. If the fault persists, collect the following information and contact technical support personnel.

    1. Collect the configurations and operation results of the preceding steps, and record the information in a file.

    2. Run the debugging command to collect information about the IPSec tunnel establishment process.

      <Huawei> terminal monitor
      <Huawei> terminal debugging
      <Huawei> debugging ikev1 all   //Debugging information collected when IKEv1 negotiation is used.
      <Huawei> debugging ikev2 all   //Debugging information collected when IKEv2 negotiation is used.
      <Huawei> debugging ipsec all   
      <Huawei> debugging adp-ipsec   //V200R007 and previous versions, execute this command to collect debugging information.
    3. After debugging is disabled, collect all diagnostic information and export the information to a file.

      1. Run the display diagnostic-information file-name command to collect diagnostic information and save the information to a file.

        <Huawei> display diagnostic-information dia-info.txt
        Now saving the diagnostic information to the device
         100%
        Info: The diagnostic information was saved to the device successfully
      2. After a diagnostic information file is generated, export the file from the device using TFTP.

        You can run the dir command in the user view to check whether the file is generated.

    4. Collect the log and trap information on the device and export the information to files.

      1. Run the save logfile command to save the log and trap information in the buffer to files.

        <Huawei> save logfile all
        Info: Save logfile successfully.
        Info: Save diagnostic logfile successfully.
      2. After log and trap information files are generated, export the files using TFTP.

    5. Collect packet information on interfaces and export the information using TFTP.

      <Huawei> system-view
      [Huawei] acl 3100
      [Huawei-acl-adv-3100] acl 3100   //Define data flows.
      [Huawei-acl-adv-3100] rule 5 permit ip source 10.1.1.1 0 destination 10.2.1.1 0 
      [Huawei-acl-adv-3100] rule 5 permit ip source 10.2.1.1 0 destination 10.1.1.1 0 
      [Huawei-acl-adv-3100] quit
      [Huawei] packet-capture ipv4-packet 3100 interface GigabitEthernet 1/0/1
      [Huawei] packet-capture startup packet-num 1500   //Enable the function of obtaining packet header information.
      [Huawei] packet-capture queue 0 to-file 1.cap   //Save the obtained packet header information to the device.
      

      After obtaining packet header information, delete the related configurations.

IKE SA Negotiation Failure

Fault Symptom

In Figure 26-6, after IPSec is deployed between Routers, PCs cannot communicate with each other.

Figure 26-6  IPSec networking

  1. Run the display ike sa command on Router1, finding that no IKE SA is established. This results in a failure to establish an IPSec tunnel.

    <Router1> display ike sa
    IKE SA information :                       
       Conn-ID    Peer           VPN             Flag(s)              Phase 
      ----------------------------------------------------------------------
                                                                    
       1342      0.0.0.0                         RD|A                 v2:1 
                               
      Number of IKE SA : 0
      ----------------------------------------------------------------------
                                              
      Flag Description:                                                   
      RD--READY   ST--STAYALIVE   RL--REPLACED   FD--FADING   TO--TIMEOUT
      HRT--HEARTBEAT   LKG--LAST KNOWN GOOD SEQ NO.   BCK--BACKED UP
      M--ACTIVE   S--STANDBY   A--ALONE  NEG--NEGOTIATING
  2. Run the display ipsec statistics command on Router1 to check IPSec statistics, finding that the outbound ok field does not display 0. This indicates that IKE packets have been sent.

    <Router1> display ipsec statistics
    .......
      negotiate about packet statistics:
        IKE fwd packet ok: 0, err: 0
        IKE ctrl packet inbound ok: 0, outbound ok: 4
        SoftExpr: 0, HardExpr: 0, DPDOper: 0
        trigger ok: 0, switch sa: 0, sync sa: 0
        recv IKE nat keepalive: 0, IKE input: 0 

Possible Causes

Troubleshooting Procedure

Troubleshooting Flowchart

Run the display ike error-info(V200R008 and later versions support this command.) command to check the IKE SA negotiation failure reason for fast fault location or perform the following steps to locate the fault.

Procedure

  1. Check whether the IKE responder receives IKE negotiation packets.

    Run the display ipsec statistics command to check IKE packet statistics on the IKE initiator and responder.

    <Router1> display ipsec statistics
    .......
      negotiate about packet statistics:
        IKE fwd packet ok: 0, err: 0
        IKE ctrl packet inbound ok: 0, outbound ok: 0
        SoftExpr: 0, HardExpr: 0, DPDOper: 0
        trigger ok: 0, switch sa: 0, sync sa: 0
        recv IKE nat keepalive: 0, IKE input: 0 
    • If the outbound ok field on the initiator does not display 0, but the IKE ctrl packet inbound ok field on the responder displays 0, the responder does not receive IKE negotiation packets. Possible causes are as follows:

      • The carrier network denies IKE packets (UDP packets with the default port number 500 or 4500). Contact carriers or technical support personnel.

      • Routes between Router1 and Router2 are unreachable. Go to step 2.

      • The remote gateway of the initiator does not match the local address of the responder. That is, the remote-address command configuration of the initiator is incorrect. Go to step 3.
    • If the outbound ok field on the initiator and the IKE ctrl packet inbound ok field on the responder do not display 0, but the outbound ok field on the responder displays 0, the responder receives IKE negotiation packets but does not send reply packets. Possible causes are as follows:

      • The IPSec policy is incorrectly applied to an interface. Run the display ipsec interface brief command and ensure that the IPSec policy is applied to the interface correctly.

      • The remote gateway of the responder does not match the local address of the initiator. That is, the remote-address command configuration of the responder is incorrect. Go to step 3.

    • If the outbound ok field on the initiator does not display 0 and the IKE ctrl packet inbound ok field displays 0, but the IKE ctrl packet inbound ok and outbound ok fields on the responder do not display 0, the responder receives IKE negotiation packets and sends reply packets but the initiator does not receive reply packets. Possible causes are as follows:

      A route to Router2 is configured on Router1, but no route to Router1 is configured on Router2. Go to step 2.

  2. Check route reachability of IKE peers.

    Run the undo ipsec policy command on interfaces at both ends of the IPSec tunnel to cancel the IPSec policy and then run the ping -a source-ip-address destination-ip-address command to check route reachability.

    If the ping fails, ensure that the links are normal, interfaces are Up, and network configurations such as the routing configuration are correct. After checking that interfaces are up and the routing configuration is correct, run the ipsec policy command on the interfaces to apply the IPSec policy again.

  3. Check whether the remote gateway of the local end matches the local address of the remote end.

    Run the display ike peer command to check whether the remote IP addresses or domain names of IKE peers match. If not, run the remote-address command in the IKE peer view to change the remote IP address.

    <Huawei> display ike peer name 1
    ------------------------------------------ 
       Peer name                       : 1  
       IKE version                     : v1v2
       VPN instance                    :
       Remote IP                       : 1.1.1.1(www.huawei.com)   //Specify the IKE peer address or domain name.
       Authentic IP address            :                           //Specify the authenticated address.
       Proposal                        : 1 
       Pre-shared-key                  : %^%#G7(t:%yFw/PVF>Jsva;"zx]oL!sw-8z\C;I}%%RY%^%#
       Local ID type                   : IP              
       Local ID                        :                   
       Remote ID type                  : any          
       Remote ID                       :  
    ......
    • If the remote end uses an internal IP address and a NAT device exists between the local and remote ends:

      • The local end functions only as the IKE responder.

        The local end uses an IPSec policy configured using an IPSec policy template, and the remote-address command does not need to be configured on the IKE peer referenced in the template.

      • The local end can function as the IKE initiator.

        The local end needs to use an IPSec policy in ISAKMP mode, and the remote IP address specified on the IKE peer is a post-NAT IP address. If IP addresses are used for authentication, you still need to run the remote-address authentication-address command on the local end to specify the pre-NAT IP address as the remote authentication address.

    • If the remote end has a variable IP address and a fixed domain name and the remote domain name is specified using the remote-address host-name command, DDNS needs to be configured on the remote end to bind the domain name to dynamic IP address, and DNS needs to be configured on the local end for domain name resolution.

      If the remote domain name cannot be resolved, run the ip host host-name ip-address command to configure static domain name resolution.

  4. Check whether the IKE peer configurations on both ends are correct.

    Run the display ike peer command to check whether the IKE versions, IKEv1 negotiation modes, identities, or SM4 versions on both ends are consistent. If not, change them to be consistent.

    <Huawei> display ike peer name 1
    ------------------------------------------
       Peer name                       : 1
       IKE version                     : v1   //IKE version
       VPN instance                    :
       Remote IP                       : 1.1.1.1(www.huawei.com)
       Authentic IP address            :
       Proposal                        : 1
       Exchange mode                   : main on phase 1   //IKEv1 negotiation mode
       Pre-shared-key                  : %^%#G7(t:%yFw/PVF>Jsva;"zx]oL!sw-8z\C;I}%%RY%^%#
       Local ID type                   : IP
       Local ID                        :
       Remote ID type                  : any
       Remote ID                       :
    ......
       RSA encryption-padding          : PKCS1   //RSA encryption padding mode
       RSA signature-padding           : PKCS1   //RSA signature padding mode
       ipsec sm4 version               : standard   //SM4 version
    ......
    Identity authentication parameter settings vary depending on authentication modes.
    • If pre-shared key authentication is used, ensure that pre-shared keys on both ends are consistent.

    • If RSA signature or digital envelop authentication is used, ensure that the digital certificate is valid.

      1. Run the display pki certificate and display clock commands to check the certificate expiration date and device time.

        If the device time is not within the certificate validity period, run the clock datetime command in the system view to change the device time.

        If the certificate expires, apply for a new certificate or run the certificate-check disable command in the IKE peer view to disable certificate validity check (this method can be used when users cannot update invalid certificates).

      2. Run the display ike peer command to check whether the padding modes for RSA signature or RSA encryption on both ends are consistent.

        If not, run the rsa encryption-padding or rsa signature-padding command in the IKE peer view to change them to be consistent.

    If a NAT device exists between IKE peers, ensure that NAT traversal is enabled.

  5. Check whether the IKE proposal configurations on both ends are consistent.

    Run the display ike proposal command to check whether the authentication methods, authentication algorithms, encryption algorithms, DH groups, and PRF algorithms on both ends are consistent. If not, change them to be consistent.

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

  6. If the fault persists, collect the following information and contact technical support personnel.

    1. Collect the configurations and operation results of the preceding steps, and record the information in a file.

    2. Run the debugging command to collect information about the IPSec tunnel establishment process.

      <Huawei> terminal monitor
      <Huawei> terminal debugging
      <Huawei> debugging ikev1 all   //Debugging information collected when IKEv1 negotiation is used.
      <Huawei> debugging ikev2 all   //Debugging information collected when IKEv2 negotiation is used.
      <Huawei> debugging ipsec all   
      <Huawei> debugging adp-ipsec   //V200R007 and previous versions, execute this command to collect debugging information.
    3. After debugging is disabled, collect all diagnostic information and export the information to a file.

      1. Run the display diagnostic-information file-name command to collect diagnostic information and save the information to a file.

        <Huawei> display diagnostic-information dia-info.txt
        Now saving the diagnostic information to the device
         100%
        Info: The diagnostic information was saved to the device successfully
      2. After a diagnostic information file is generated, export the file from the device using TFTP.

        You can run the dir command in the user view to check whether the file is generated.

    4. Collect the log and trap information on the device and export the information to files.

      1. Run the save logfile command to save the log and trap information in the buffer to files.

        <Huawei> save logfile all
        Info: Save logfile successfully.
        Info: Save diagnostic logfile successfully.
      2. After log and trap information files are generated, export the files using TFTP.

    5. Collect packet information on interfaces and export the information using TFTP.

      <Huawei> system-view
      [Huawei] acl 3100
      [Huawei-acl-adv-3100] acl 3100   //Define data flows.
      [Huawei-acl-adv-3100] rule 5 permit ip source 10.1.1.1 0 destination 10.2.1.1 0 
      [Huawei-acl-adv-3100] rule 5 permit ip source 10.2.1.1 0 destination 10.1.1.1 0 
      [Huawei-acl-adv-3100] quit
      [Huawei] packet-capture ipv4-packet 3100 interface GigabitEthernet 1/0/1
      [Huawei] packet-capture startup packet-num 1500   //Enable the function of obtaining packet header information.
      [Huawei] packet-capture queue 0 to-file 1.cap   //Save the obtained packet header information to the device.
      

      After obtaining packet header information, delete the related configurations.

IPSec SA Negotiation Failure

Fault Symptom

In Figure 26-7, after IPSec is deployed between Routers, PCs cannot communicate with each other.

Figure 26-7  IPSec networking

Run the display ike sa command on Router1, finding that no IPSec SA is established. This results in a failure to establish an IPSec tunnel.

<Router1> display ike sa
IKE SA information :                       
   Conn-ID    Peer           VPN             Flag(s)              Phase 
  ----------------------------------------------------------------------
                                                                
    8388     2.1.1.1:500                     RD|ST|A              v2:1 
                           
  Number of IKE SA : 1
  ----------------------------------------------------------------------
                                          
  Flag Description:                                                   
  RD--READY   ST--STAYALIVE   RL--REPLACED   FD--FADING   TO--TIMEOUT
  HRT--HEARTBEAT   LKG--LAST KNOWN GOOD SEQ NO.   BCK--BACKED UP
  M--ACTIVE   S--STANDBY   A--ALONE  NEG--NEGOTIATING

Possible Causes

Troubleshooting Procedure 1 2 2 3

Troubleshooting Procedure

Context

Run the display ike error-info(V200R008 and later versions support this command.) command to check the IPSec SA negotiation failure reason for fast fault location or perform the following steps to locate the fault.

Procedure

  1. Check whether ACL configurations on both ends match.

    Run the display ipsec policy command to check the ACL number referenced by IPSec and then run the display acl acl-number command to check whether ACL rules on both ends match.

    <Huawei> display ipsec policy
    ===========================================
    IPSec policy group: "10"
    Using interface: GigabitEthernet1/0/0
    ===========================================
         Sequence number: 10
         Policy Alias: map1-10
         Security data flow: 3100/IPv4   //Security ACL
         Peer name    :  rut2
         Perfect forward secrecy: DH group 14
         Proposal name:  prop1
         IPSec SA local duration(time based): 3600 seconds
         IPSec SA local duration(traffic based): 1843200 kilobytes
         SA trigger mode: Traffic-based   
    ......
    <Huawei> display acl 3100
    Advanced ACL 3100, 1 rule ( Reference counter 1 )
    Acl's step is 5
     rule 5 permit ip source 10.1.2.0 0.0.0.255 destination 10.1.1.0 0.0.0.255 (0 times matched)
    
    When configuring ACL rules, pay attention to the following points:
    • The protocol type defined in the ACL rules on both ends must be consistent. For example, if one device uses the IP protocol, the other device must use the IP protocol too.

    • If ACL rules on both ends mirror each other, an SA can be successfully established after any party initiates negotiation. If ACL rules on both ends do not mirror each other, an SA can be successfully established only when the address range defined in the ACL rule of the initiator is included in that of the responder. It is recommended that ACL rules on both ends mirror each other. That is, the source and destination IP addresses in the ACL rule of one device are the destination and source IP addresses in the ACL rule of the other device, respectively. That is:

      If IPSec policies in ISAKMP mode are configured on both ends, ACL rules on both ends of an IPSec tunnel must mirror each other. If an IPSec policy in ISAKMP mode is configured on one end and an IPSec policy configured using an IPSec policy template is configured on the other end, the ACL rule range of the IPSec policy in ISAKMP mode can be smaller than that of the IPSec policy configured using an IPSec policy template, and the overlapping ACL rule range is used as the negotiation result.

    • The IP address ranges in the ACL rules should not overlap each other. Otherwise, an error will occur when the devices match ACL rules for data flows.

    • The rules for the ACL in the same IPSec policy group must be unique.

    • The ACL rules referenced by all the IPSec policies in the same IPSec policy group cannot overlap. For example, the referenced ACL3001 and ACL3002 overlap:

      acl number 3001
       rule 5 permit ip source 10.1.2.0 0.0.0.255 destination 10.1.1.0 0.0.0.255
      
      acl number 3002
       rule 5 permit ip source 10.1.0.0 0.0.255.255 destination 10.1.0.0 0.0.255.255
      
    • When the responder uses IPSec policies configured using an IPSec policy template, pay attention to the following points:

      Data flows to be protected can be not defined for the responder, which indicates that the responder accepts the data flow protection range defined on the initiator. If you want to define data flows to be protected for the responder, the configuration must mirror or include that of the initiator.

    • If NAT is configured on the interface to which an IPSec policy is applied, IPSec does not take effect because the device executes the NAT configuration first. In this case, you need to ensure:

      • The destination IP address denied in the ACL rule referenced by NAT is the destination IP address in the ACL rule referenced by IPSec. By doing so, the device does not perform NAT on the IPSec-protected data flows.

      • The ACL rule referenced by IPSec matches the post-NAT IP address.

  2. Check whether the IPSec proposal configurations on both ends are consistent.

    Run the display ipsec proposal command to check whether the security protocols, encryption algorithms, authentication algorithms, and encapsulation modes on both ends are consistent. If not, change them to be consistent.

    <Huawei> display ipsec proposal
    Number of proposals: 1
    
    IPSec proposal name: p1
     Encapsulation mode: Tunnel                         //Encapsulation mode
     Transform         : ah-esp-new                     //Security protocol
     AH protocol       : Authentication SHA2-HMAC-256   //AH authentication algorithm
     ESP protocol      : Authentication SHA2-HMAC-256   //ESP authentication algorithm
                         Encryption AES-256             //ESP encryption algorithm

  3. Check whether the security policy configuration at both ends of the IPSec tunnel are consistent.

    Run the display ipsec policy brief command to check the Mode. Ensure that the Mode on both ends are consistent.

    If the two ends are not configured consistently, run the command ipsec policy isakmp to modify the configuration to ensure that the configuration is consistent at both ends.

    <Huawei> display ipsec policy brief
    Number of policies group : 1 
    Number of policies       : 1 
      
    Policy name           Mode     ACL         Peer name   Local address    Remote address
    --------------------------------------------------------------------------------------
    policy1-100           isakmp   3002/IPv4   peer1                                      

    Run the display ipsec policy command to check the PFS algorithm. Ensure that the PFS algorithms on both ends are consistent.

    If the two ends are not configured consistently, run the command pfs to modify the configuration to ensure that the configuration is consistent at both ends.

    <Huawei> display ipsec policy
    ===========================================
    IPSec policy group: "10"
    Using interface: GigabitEthernet1/0/0
    ===========================================
         Sequence number: 10
         Policy Alias: map1-10
         Security data flow: 3100/IPv4
         Peer name    :  rut2
         Perfect forward secrecy: DH group 14   //PFS algorithm

  4. If the fault persists, collect the following information and contact technical support personnel.

    1. Collect the configurations and operation results of the preceding steps, and record the information in a file.

    2. Run the debugging command to collect information about the IPSec tunnel establishment process.

      <Huawei> terminal monitor
      <Huawei> terminal debugging
      <Huawei> debugging ikev1 all   //Debugging information collected when IKEv1 negotiation is used.
      <Huawei> debugging ikev2 all   //Debugging information collected when IKEv2 negotiation is used.
      <Huawei> debugging ipsec all   
      <Huawei> debugging adp-ipsec   //V200R007 and previous versions, execute this command to collect debugging information.
    3. After debugging is disabled, collect all diagnostic information and export the information to a file.

      1. Run the display diagnostic-information file-name command to collect diagnostic information and save the information to a file.

        <Huawei> display diagnostic-information dia-info.txt
        Now saving the diagnostic information to the device
         100%
        Info: The diagnostic information was saved to the device successfully
      2. After a diagnostic information file is generated, export the file from the device using TFTP.

        You can run the dir command in the user view to check whether the file is generated.

    4. Collect the log and trap information on the device and export the information to files.

      1. Run the save logfile command to save the log and trap information in the buffer to files.

        <Huawei> save logfile all
        Info: Save logfile successfully.
        Info: Save diagnostic logfile successfully.
      2. After log and trap information files are generated, export the files using TFTP.

    5. Collect packet information on interfaces and export the information using TFTP.

      <Huawei> system-view
      [Huawei] acl 3100
      [Huawei-acl-adv-3100] acl 3100   //Define data flows.
      [Huawei-acl-adv-3100] rule 5 permit ip source 10.1.1.1 0 destination 10.2.1.1 0 
      [Huawei-acl-adv-3100] rule 5 permit ip source 10.2.1.1 0 destination 10.1.1.1 0 
      [Huawei-acl-adv-3100] quit
      [Huawei] packet-capture ipv4-packet 3100 interface GigabitEthernet 1/0/1
      [Huawei] packet-capture startup packet-num 1500   //Enable the function of obtaining packet header information.
      [Huawei] packet-capture queue 0 to-file 1.cap   //Save the obtained packet header information to the device.
      

      After obtaining packet header information, delete the related configurations.

Successful IKE Renegotiation in Only One Direction After Unexpected Device Restart

Fault Symptom

In Figure 26-8, an IPSec tunnel is successfully established between Router1 and Router2. After Router2 restarts unexpectedly, PC1 cannot ping PC2.

Figure 26-8  IPSec networking

Run the display ike sa command. You can find that SAs are successfully established on Router1, but fail to be established on Router2.

<Router1> display ike sa
IKE SA information :                       
   Conn-ID    Peer           VPN             Flag(s)              Phase 
  ----------------------------------------------------------------------
                                                                
    8388     2.1.1.1:500                     RD|ST|A              v2:2 
    8378     2.1.1.1:500                     RD|ST|A              v2:1 
                           
  Number of IKE SA : 2
  ----------------------------------------------------------------------
                                          
  Flag Description:                                                   
  RD--READY   ST--STAYALIVE   RL--REPLACED   FD--FADING   TO--TIMEOUT
  HRT--HEARTBEAT   LKG--LAST KNOWN GOOD SEQ NO.   BCK--BACKED UP
  M--ACTIVE   S--STANDBY   A--ALONE  NEG--NEGOTIATING
<Router2> display ike sa

Possible Causes

This symptom frequently occurs if a device restarts unexpectedly when traffic triggers SA negotiation. Abnormal device restart will automatically trigger IPSec SA negotiation, without processing.

Procedure

Procedure

  1. On Router1, manually reset SAs.

    Run the reset ike sa command. You can find that an IPSec tunnel is established between two ends.

  2. Configure the dead peer detection (DPD) function for IKE peers on two ends.

    After DPD is configured, breakdown of the IPSec tunnel will automatically clear SAs and trigger SA negotiation again.

    DPD should be configured on an IKE peer.

    The two ends must use the same sequence of the payloads in DPD packets; otherwise, DPD does not take effect.

    For example, the sequence of the payloads in DPD packets in the global configuration under IKE peer Huawei is as follows: seq-hash-notify, detection mode (periodic), idle time for DPD detection (20s), DPD packet retransmission interval (10s), and umber of DPD packet retransmissions (4). The following shows the commands on Router1:

    <Router1> system-view
    [Router1] ike peer huawei
    [Router1-ike-peer-huawei] dpd msg seq-hash-notify
    [Router1-ike-peer-huawei] dpd type periodic
    [Router1-ike-peer-huawei] dpd idle-time 20
    [Router1-ike-peer-huawei] dpd retransmit-interval 10
    [Router1-ike-peer-huawei] dpd retry-limit 4
    

Service Interruption After Successful IPSec Tunnel Setup

Fault Symptom

In Figure 26-9, run the display ipsec sa command on Router1 and Router2 to view IPSec SA information. You can find that an IPSec tunnel is established. The following problems may exist:

  • Users of the branch and headquarters cannot communicate with each other.
  • Only unidirectional communication is implemented between users of the branch and headquarters. For example, users of the headquarters can access servers in the branch, but users of the branch cannot access servers in the headquarters.
  • Users of the branch and headquarters can access only some network segments.
  • On a P2MP network, users of the branch cannot communicate with each other but can communicate with users of the headquarters.
  • When an IPSec gateway functions as a NAT gateway, all traffic may be sent out after NAT is performed, without entering VPNs.
Figure 26-9  IPSec networking

Possible Causes



Troubleshooting Procedure

Procedure

  1. Check whether IPSec packets are denied on the carrier network.

    Check whether AH packets or ESP packets are dropped based on obtained packet headers to determine whether IPSec packets are denied on the carrier network. If IPSec packets are permitted on the carrier network, go to step 2.

  2. Check there are reachable routes from PCs to their gateways and from IPSec peers to protected private networks.

    Run the ping command to check whether routes are reachable. If the ping fails, run the display interface and display ip routing-table commands to ensure that interfaces are Up and the routing configuration is correct.

    If multiple egresses exist, you also need to run the display current-configuration configuration policy-pbr command to check whether packets match PBR and so do not enter the IPSec tunnel.

  3. Check whether security ACLs are correctly configured.

    Run the display ipsec sa command to check whether source and destination network segments of the protected data flows matching security ACLs include actual service flows. If not, run the display acl acl-number command to check whether ACLs are correctly configured on both ends.

    <Huawei> display ipsec sa
    ===============================
    Interface: GigabitEthernet1/0/0
    ===============================
    
      -----------------------------
      IPSec policy name: "map1"
      Sequence number  : 1
      Acl group        : 3100
      Acl rule         : 5
      Mode             : ISAKMP
      -----------------------------
        Connection ID     : 83893872
        Encapsulation mode: Tunnel
        Holding time      : 0d 0h 32m 4s
        Tunnel local      : 1.1.3.1:500
        Tunnel remote     : 1.1.5.1:500
        Flow source       : 10.1.0.0/255.255.0.0 0/0
        Flow destination  : 10.2.0.0/255.255.0.0 0/0
    ......
    
    <Huawei> display acl 3100
    Advanced ACL 3100, 1 rule ( Reference counter 1 )
    Acl's step is 5
     rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.2.1.0 0.0.0.255 (0 times matched)
    

  4. Check whether an IPSec policy is correctly applied to an IPSec tunnel interface.

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

    <Huawei> display ipsec policy
    ===========================================
    IPSec policy group: "10"
    Using interface: GigabitEthernet1/0/0   //Interface to which an IPSec policy is applied
    ===========================================
    ......

  5. Check whether the NAT policy configuration affects the IPSec-protected data flows.

    When IPSec packets are forwarded, NAT and then IPSec encryption are performed on the packets. As a result, the IPSec packets fail to be sent. In this case, ensure that the NAT server and destination NAT do not affect processing of IPSec-protected data flows.

    You can run the display ipsec interface brief command to check the interface to which an IPSec policy is applied, and then run the display current-configuration interface interface-type interface-number command to check whether a NAT policy is configured on the specified IPSec interface.

    If NAT is configured on the interface to which an IPSec policy is applied, IPSec does not take effect because the device executes the NAT configuration first. In this case, you need to ensure:
    • The destination IP address denied in the ACL rule referenced by NAT is the destination IP address in the ACL rule referenced by IPSec. By doing so, the device does not perform NAT on the IPSec-protected data flows.
    • The ACL rule referenced by IPSec matches the post-NAT IP address.

  6. Check whether NAT traversal is enabled on both ends if a NAT device exists between both ends.

    Run the display ike peer command to check whether NAT traversal is enabled on both ends. If not, run the nat traversal command in the IKE peer view.

    <Huawei> display ike peer
    Number of IKE peers: 1
    ------------------------------------------
       Peer name                       : 1
       IKE version                     : v1v2
       VPN instance                    : 
       Remote IP                       : 1.1.1.1(www.huawei.com)
       Authentic IP address            :
       Proposal                        : 1
       Pre-shared-key                  : %^%#G7(t:%yFw/PVF>Jsva;"zx]oL!sw-8z\C;I}%%RY%^%#
       Local ID type                   : IP
       Local ID                        :
       Remote ID type                  : any
       Remote ID                       :
    ......
       NAT-traversal                   : Enable   //NAT traversal
    ......

  7. Check whether the security protocol is AH when a NAT device exists between both ends and NAT traversal is enabled.

    Run the display ipsec proposal command to check the security protocol.

    The security protocol can only be ESP during NAT traversal.

    If the security protocol is AH, run the transform command to change the security protocol to ESP.

    <Huawei> display ipsec proposal
    Number of proposals: 1
    
    IPSec proposal name: p1
     Encapsulation mode: Tunnel                         
     Transform         : esp-new                     //Security protocol
     ESP protocol      : Authentication SHA2-HMAC-256   
                         Encryption AES-256             
    [Huawei] ipsec proposal p1
    [Huawei-ipsec-proposal-p1] transform esp

  8. Check whether the encryption/decryption modes on both ends are consistent if the authentication algorithm used in an IPSec proposal is SHA2.

    Run the display ipsec proposal command to check whether the authentication algorithm is SHA2-256, SHA2-384, or SHA2-512.

    <Huawei> display ipsec proposal
    Number of proposals: 1
    
    IPSec proposal name: p1
     Encapsulation mode: Tunnel                         
     Transform         : esp-new                     
     ESP protocol      : Authentication SHA2-HMAC-256   //Authentication algorithm
                         Encryption AES-256             

    The authentication algorithm is SHA2-256, SHA2-384, or SHA2-512. Then run the display ipsec statistics command to check whether received encrypted packets are discarded. If the received encrypted packets are discarded because of an authentication failure, run the ipsec authentication sha2 compatible enable or undo ipsec authentication sha2 compatible enable command in the system view to ensure consistent encryption/decryption modes on both ends.

    When IPSec uses the SHA-2 algorithm, if the devices on both ends of an IPSec tunnel are from different vendors or run different software versions, they may use different encryption/decryption modes. In this situation, IPSec traffic between the devices will be interrupted.

    To solve the problem, run the ipsec authentication sha2 compatible enable command in the system view to enable SHA-2 to be compatible with earlier versions, so that the encryption/decryption modes on both ends are consistent.

    [Huawei] ipsec authentication sha2 compatible enable

  9. If the fault persists, collect the following information and contact technical support personnel.

    1. Collect the configurations and operation results of the preceding steps, and record the information in a file.

    2. Run the debugging command to collect information about the IPSec tunnel establishment process.

      <Huawei> terminal monitor
      <Huawei> terminal debugging
      <Huawei> debugging ikev1 all   //Debugging information collected when IKEv1 negotiation is used.
      <Huawei> debugging ikev2 all   //Debugging information collected when IKEv2 negotiation is used.
      <Huawei> debugging ipsec all   
      <Huawei> debugging adp-ipsec   //V200R007 and previous versions, execute this command to collect debugging information.
    3. After debugging is disabled, collect all diagnostic information and export the information to a file.

      1. Run the display diagnostic-information file-name command to collect diagnostic information and save the information to a file.

        <Huawei> display diagnostic-information dia-info.txt
        Now saving the diagnostic information to the device
         100%
        Info: The diagnostic information was saved to the device successfully
      2. After a diagnostic information file is generated, export the file from the device using TFTP.

        You can run the dir command in the user view to check whether the file is generated.

    4. Collect the log and trap information on the device and export the information to files.

      1. Run the save logfile command to save the log and trap information in the buffer to files.

        <Huawei> save logfile all
        Info: Save logfile successfully.
        Info: Save diagnostic logfile successfully.
      2. After log and trap information files are generated, export the files using TFTP.

    5. Collect packet information on interfaces and export the information using TFTP.

      <Huawei> system-view
      [Huawei] acl 3100
      [Huawei-acl-adv-3100] acl 3100   //Define data flows.
      [Huawei-acl-adv-3100] rule 5 permit ip source 10.1.1.1 0 destination 10.2.1.1 0 
      [Huawei-acl-adv-3100] rule 5 permit ip source 10.2.1.1 0 destination 10.1.1.1 0 
      [Huawei-acl-adv-3100] quit
      [Huawei] packet-capture ipv4-packet 3100 interface GigabitEthernet 1/0/1
      [Huawei] packet-capture startup packet-num 1500   //Enable the function of obtaining packet header information.
      [Huawei] packet-capture queue 0 to-file 1.cap   //Save the obtained packet header information to the device.
      

      After obtaining packet header information, delete the related configurations.

Poor Service Quality After Successful IPSec Tunnel Setup

Fault Symptom

In Figure 26-10, run the display ipsec sa command on Router1 and Router2 to view IPSec SA information. You can find that an IPSec tunnel is established. The following problems may exist:

  • The service access speed is slow.
  • The service access is intermittent or interrupted.
Figure 26-10  IPSec networking

Possible Causes

Procedure

Procedure

  1. Check whether the CPU usage is high.

    Run the display cpu-usage command to view the CPU usage.

    If the CPU usage exceeds 80%, check whether features such as attack defense are configured. If such features are configured, disable the features and check the CPU usage again.

  2. Check whether the Internet discards packets.

    Run the undo ipsec policy command on two IPSec tunnel interfaces to cancel the IPSec policy. Then perform the ping test. If packet loss still occurs, the Internet quality is poor. Contact the carrier to solve the problem.

  3. Check whether IPSec packets are fragmented.

    IPSec encapsulates IP packets. As a result, the IP packet length becomes longer. If the IP packet length exceeds the link MTU during transmission, the IP packets are fragmented and sent. The receiver needs to reassemble and parse the fragments. Fragmentation and reassembly consume CPU resources, and encryption and decryption of fragments also consume many CPU resources. When there are many fragments, CPU resources may be insufficient. In this case, the access is slow and packets are discarded.

    Run the ping -s packetsize -a source-ip-address host command to test packets of different sizes. Find the threshold exceeding which packets are lost or the ping operation fails.

    Run the mtu mtu command in the interface view to change the MTU value based on the threshold.

    After the modification, if some TCP services still have a slow access speed or are intermittent, run the tcp adjust-mss value command in the interface view to modify the TCP MSS.

    If the total packet length (MSS plus various types of costs, including the TCP packet header, IP packet header, and IPSec packet header) exceeds the link MTU, data packets will be fragmented. Fragmentation will lead to consumption of more CPU resources. In addition, encryption and decryption of packet fragments also consume CPU resources of devices on the transmission link. Too much CPU resource consumption will lead to data packet loss.

    Some upper layer applications (such as the application layer protocol HTTP) will set the Don't Fragment (DF) flag of IP packets to valid to prevent TCP packet fragmentation. If the DF flag is set to valid but the interface MTU is smaller than the MSS, the device will discard packets because it cannot forcibly fragment the TCP packets.

Translation
Download
Updated: 2019-05-10

Document ID: EDOC1000079719

Views: 456313

Downloads: 4321

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next