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 Cases

Troubleshooting Cases

Service Interruptions Due to IPSec Tunnel Setup Failure

In NAT Traversal Scenarios, an IPSec Tunnel Fails to Be Set Up Between Two AR Routers Because No Authenticated IP Address Is Configured

Keywords

NAT traversal, authenticated address, IKEv2 negotiation failure, IPSec tunnel setup failure, and service interruption

Abstract

When a NAT device is deployed between two AR routers and an IKEv2 IPSec policy is used on the two routers, an IPSec tunnel fails to be established between the two routers if no authenticated address is configured.

Problem Description

In the following figure, AR1 and AR2 function as gateways of the branch and headquarters respectively. AR1 connects to AR2 across a NAT device. After an IKEv2 IPSec policy is deployed, an IPSec tunnel fails to be established between AR1 and AR2, and PCs cannot communicate with each other. As a result, services are interrupted.

Run the display ike sa command. The command output shows that IKE SA negotiation fails.

<AR2> display ike sa
IKE SA information :                       
   Conn-ID    Peer           VPN             Flag(s)     Phase 
  --------------------------------------------------------------- 
   1342       1.1.1.1                        NEG|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
Troubleshooting Procedure
  1. Run the display ike error-info command to check the IKE negotiation failure reason.
    <AR2> display ike error-info 
      current info Num :2 
      Ike error information: 
      current ike Error-info number :2 
    ------------------------------------------------------------------ 
     peer    port error-reason             version error-time 
    ------------------------------------------------------------------ 
     1.1.1.1 500  authentication fail       v2     2017-09-05 15:22:32 
     1.1.1.1 500  config ID mismatch        v2     2017-09-05 15:22:32 
    ------------------------------------------------------------------

    The command output shows that the IKE negotiation failure reason is authentication fail or config ID mismatch, indicating that AR2 does not find the matching IKE peer based on the ID. Check whether the remote-address is correct.

  2. Run the display ike peer command to check whether the remote-address is correct.
    <AR2> display ike peer  
    Number of IKE peers: 1 
     
    ------------------------------------------------ 
     Peer name                    : spua 
     IKE version                  : v1v2 
     VPN instance                 : 
     Remote IP                    : 1.1.1.1 
     Authentic IP address         :  
     Proposal                     : 5 
     Pre-shared-key               : %^%#w.]D%IU@fYUn2H->a2iJe$W02.Z%G/L_O+JQvc0<%^ 
    %# 
     Local ID type                : IP 
     Local ID                     : 
     Remote ID type               : 
     Remote ID                    : 
     certificate peer-name        : 
     PKI realm                    : NULL 
     Inband OCSP                  : Disable 
     Inband CRL                   : Disable 
     cert-request empty-payload : Disable 
     VPN instance bound to the SA : 
     NAT-traversal                : Enable 
     AAA authorization domain     : 
     DSCP                         : 
     Lifetime-notification-message: Disable 
     DPD                          : Disable 
     RSA encryption-padding       : PKCS1 
     RSA signature-padding        : PKCS1 
     ipsec sm4 version            : draft-standard 
       Certificate-check            : Enable 
    ------------------------------------------------

    The command output shows that the Remote IP field displays 1.1.1.1. This remote-address configuration is correct because in NAT traversal scenarios, remote-address configured on AR2 is the post-NAT IP address. However, the authentication fails because the local IP address in the IKE packet sent by AR1 is 10.4.1.1, which is different from the IP address 1.1.1.1 configured on AR2. You need to run the remote-address authentication-address command to set the authenticated IP address to 10.4.1.1.

  3. Run the remote-address authentication-address command to set the authenticated IP address to 10.4.1.1.
    <AR2> system-view 
    [AR2] ike peer spua 
    [AR2-ike-peer-spua] remote-address authentication-address 10.4.1.1

    After the preceding configuration is complete, an IPSec tunnel is established successfully, and PCs can ping each other successfully. This indicates that services between AR1 and AR2 can be forwarded normally.

Root Cause

In IPSec NAT traversal scenarios, the local IP address in the IKE packet sent by AR1 is 10.4.1.1, which does not match the IP address 1.1.1.1 configured on AR2.

Solution

Run the remote-address authentication-address command to configure the authenticated IP address as 10.4.1.1.

Summary and Suggestions

In IKEv2 scenarios, if the remote device uses an internal IP address, connects to the local device across a NAT device, and needs to use this IP address for authentication, specify the authentication-address parameter to configure the pre-NAT IP address as the remote authenticated address. In this situation, the post-NAT IP address needs to be used as the remote address.

In IPSec NAT traversal scenarios, it is recommended that IP addresses not be used for authentication during IKE negotiation or that AR2 use an IPSec policy configured using an IPSec policy template.

An IPSec Tunnel Fails to Be Set Up Between Two AR Routers Because of Inconsistent IPSec Parameters

Keywords

IPSec parameter, IPSec tunnel setup failure, service interruption

Abstract

Inconsistent IPSec parameters on both ends cause a failure to establish an IPSec tunnel between the two ends and lead to service interruption.

Problem Description

In the following figure, IPSec is deployed between AR1 and AR2 (a non-Huawei device). AR1 functions as the branch gateway, and AR2 functions as the headquarters gateway. An IPSec tunnel fails to be established between AR1 and AR2. PC1 and PC2 cannot communicate with each other, and services are interrupted.

Run the display ike sa command. The command output shows that IKE SA negotiation fails.

<AR1> display ike sa
IKE SA information :                       
   Conn-ID    Peer           VPN             Flag(s)     Phase 
  --------------------------------------------------------------- 
   1342      0.0.0.0                         RD|A        v1: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
Troubleshooting Procedure
  1. Run the display ike error-info command to check the IKE negotiation failure reason.
    <AR1> display ike error-info 
      current info Num :2 
      Ike error information: 
      current ike Error-info number :2 
    ------------------------------------------------------------------ 
     peer    port error-reason             version error-time 
    ------------------------------------------------------------------ 
     2.1.1.1 500  phase1 proposal mismatch  v1     2017-09-05 15:22:32 
     2.1.1.1 500  phase1 proposal mismatch  v1     2017-09-05 15:22:32 
    ------------------------------------------------------------------

    The command output shows that the IKE negotiation failure reason is phase1 proposal mismatch, indicating that IKE proposal parameters on both ends are inconsistent.

  2. Check IKE proposal parameters of devices on both ends.

    Run the display ike proposal [ number proposal-number ] command on AR1 to check IKE proposal parameters.

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

    Contact the service provider to provide the IKE proposal parameters of AR2. If such parameters cannot be provided, run the debugging ikev1 all command in the user view to check the IKE proposal information sent by AR2.

    Sep 14 2017 11:14:11.630.17 AR1 IKE/7/IKE_Debug: 
    IKE_INFO 2:2969 Attribute ENCRYPTION_ALGORITHM value AES_CBC 
    Sep 14 2017 11:14:11.630.18 AR1 IKE/7/IKE_Debug: 
    IKE_INFO 2:2969 Attribute KEY_LENGTH value 256 
    Sep 14 2017 11:14:11.630.19 AR1 IKE/7/IKE_Debug: 
    IKE_INFO 2:2969 Attribute HASH_ALGORITHM value SHA2-256 
    Sep 14 2017 11:14:11.630.20 AR1 IKE/7/IKE_Debug: 
    IKE_INFO 2:2969 Attribute AUTHENTICATION_METHOD value PRE_SHARED 
    Sep 14 2017 11:14:11.640.1 AR1 IKE/7/IKE_Debug: 
    IKE_INFO 2:2969 Attribute GROUP_DESCRIPTION value MODP_2048 
    Sep 14 2017 11:14:11.640.2 AR1 IKE/7/IKE_Debug: 
    IKE_INFO 2:2969 Attribute LIFE_TYPE value SECONDS 
    Sep 14 2017 11:14:11.640.3 AR1 IKE/7/IKE_Debug: 
    IKE_INFO 2:2969 Attribute LIFE_DURATION value 86400

    The command output shows that encryption algorithms on both ends are inconsistent. Encryption algorithms of AR1 and AR2 are AES-128 and AES-256 respectively.

  3. Change inconsistent IKE proposal parameters on both ends to be consistent.

    The encryption algorithms used on both ends are inconsistent. Change the encryption algorithm used on AR1.

    ike proposal 10 
     encryption-algorithm aes-256 

    After the preceding configuration is complete, an IPSec tunnel is established successfully, and PCs can ping each other successfully. This indicates that services between AR1 and AR2 can be forwarded normally.

Root Cause

Encryption algorithms in the IKE proposals used on both ends are inconsistent.

Solution

Run the encryption-algorithm aes-256 command on AR1 to change the encryption algorithm to be consistent with that of AR2.

Summary and Suggestions

When configuring IPSec, ensure that IKE parameters used on both ends are consistent. Especially when a Huawei device connects to a non-Huawei device, some default parameters on the two devices are different. If the two devices use default parameters, they fail IKE SA negotiation. If configurations of the non-Huawei device cannot be obtained, run the debugging ikev1 all or debugging ikev2 all command on the local device to check the IPSec parameters sent by the non-Huawei device.

After an IPSec Tunnel Is Set Up Between Two AR Routers, One Router Cannot Log In to the Other Remotely Because Protected Data Flows Match a NAT Server Policy

Keywords

NAT server, IPSec tunnel setup, Telnet failure, and remote login

Abstract

IPSec and NAT are deployed on the same device. The protected data flow matches a NAT server policy. As a result, after an IPSec tunnel is established, the PC can ping the server successfully but cannot remotely log in to the server.

Problem Description

In the following figure, AR1 and AR2 function as gateways of the branch and headquarters respectively, and the NAT server and source NAT policy are deployed on AR1. After IPSec is deployed, an IPSec tunnel is established successfully, and the PC can ping the Server successfully but cannot access the port 10.1.2.2 1054 of the Server through Telnet.

Figure 26-11  

The PC can ping the Server successfully but cannot access the Server through Telnet. Check the IPSec, ACL, and routing configurations, finding that the configurations are correct. The possible cause for the Telnet failure is that the data flow does not match the security ACL rule.

Troubleshooting Procedure
  1. Run the display ipsec sa and display acl commands to check whether the data flow matches the security ACL rule during Telnet.
    <AR1> display ipsec sa 
    ipsec sa information:  
    =============================== 
    Interface: GigabitEthernet0/0/2 
    =============================== 
     ----------------------------- 
      IPSec policy name: "pc2"    
      Sequence number  : 1 
      Acl group        : 3101 
      Acl rule         : 5 
      Mode             : Template 
      ----------------------------- 
        Connection ID     : 67108879 
        Encapsulation mode: Tunnel 
        Holding time      : 0d 0h 4m 29s 
        Tunnel local      : 1.1.1.1:500 
        Tunnel remote     : 2.1.1.1:500 
        Flow source       : 10.1.1.0/255.255.255.0 17/1701 
        Flow destination  : 10.1.2.0/255.255.255.0 17/39725 
                                              
        [Outbound ESP SAs]         
          SPI: 4055669516 (0xf1bc9b0c)  
          Proposal: ESP-ENCRYPT-3DES-192 SHA2-256-128 
          SA remaining key duration (kilobytes/sec): 1840323/2420 
          Outpacket count       : 0 
          Outpacket encap count : 0 
          Outpacket drop count  : 0
          Max sent sequence-number: 0  
          ......
     
    <AR1> display acl 3101      
    Advanced ACL 3101, 1 rule     
    Acl's step is 5                                                    
     rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0 0.0.0.255 (0 matches) 

    The command output shows that an IPSec tunnel has been established, but the data flow does not match the security ACL rule when the PC accesses the Server through Telnet. This is because AR1 also functions as the NAT gateway and the protected data flow may have matched the NAT policy.

  2. Run the display nat outbound and display acl to check whether the NAT policy contains the protected data flow.
    <AR1> display  nat outbound  
    NAT Outbound Information:    
     ----------------------------------------------------------------  
     Interface            Acl Address-group/IP/Interface      Type 
     ---------------------------------------------------------------- 
     GigabitEthernet0/0/2 3300                    1.1.1.1     easyip 
     ---------------------------------------------------------------- 
      Total : 1     
     
    <AR1> display acl 3300 
    Advanced ACL 3300, 1 rule 
    Acl's step is 5     
     rule 10 permit ip (4 matches) 
     
    <AR1> display acl 3300      
    Advanced ACL 3300, 1 rule     
    Acl's step is 5                                                    
      rule 5 deny ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0 0.0.0.255         
     rule 10 permit ip 
     (0 matches) 

    The command output shows that the protected data flow has been denied in the NAT policy.

  3. Run the display nat server command to check whether the source IP address of the protected data flow is translated by NAT.
    <AR1> display nat server  
        Nat Server Information: 
        Interface  : GigabitEthernet0/0/2     
        Global IP/Port     : current-interface/8080 (Real IP : 1.1.1.1) 
        Inside IP/Port     : 10.1.1.2/8080 
        Protocol : 6(tcp) 
        VPN instance-name  : ---- 
        Acl number         : ---- 
        Vrrp id            : ---- 
        Description : ---- 
     
      Total :    1 

    The command output shows that the source address of the packet matches the NAT server policy. Therefore, NAT is performed on the data flow during Telnet. Therefore, you are advised to change the NAT server function to static NAT. That is, NAT is performed on a packet only when the source address and port number of the packet are matched.

  4. Run the nat static command to configure static NAT mapping.
    <AR1> system-view 
    [AR1] interface gigabitethernet 0/0/2 
    [AR1-GigabitEthernet0/0/2] nat static protocol tcp global current-interface 8080 inside 10.1.1.2 8080

    After the preceding configuration is complete, the PC can access the port 10.1.2.2 1054 of the Server through Telnet.

Root Cause

When the PC attempts to access the Server through Telnet, the data flow matches the NAT server policy, and the source address is translated by NAT.

Solution

Change the NAT server function to static NAT. That is, NAT is performed on a packet only when the source address and port number of the packet are matched.

Summary and Suggestions

When IPSec and NAT are configured on the same device, you need to check whether NAT needs to be performed on the IPSec-encapsulated data flow.

  • If so, the configured security ACL needs to match the post-NAT IP address.
  • If not, the configured security ACL needs to match the pre-NAT IP address, and NAT is not performed on the data flow transmitted over an IPSec tunnel.

Service Interruptions After Successful IPSec Tunnel Setup

After IPSec Is Configured on the AR, Traffic Forwarding Fails

This section provides a case that traffic forwarding fails after IPSec is configured on the AR.

Networking

Main configuration on RouterA:

#
acl number 3000 
 rule 10 permit ip source 192.168.10.0 0.0.0.255 destination 192.168.0.0 0.0.255.255
 rule 20 permit ip source 192.168.20.0 0.0.0.255 destination 192.168.0.0 0.0.255.255
 rule 30 permit ip source 192.168.202.0 0.0.0.255 destination 192.168.0.0 0.0.255.255
 rule 40 permit ip source 192.168.201.0 0.0.0.255 destination 192.168.0.0 0.0.255.255
 rule 50 deny ip
#
ipsec proposal 2
#
ike proposal 2
#
ike peer aaa v1
 pre-shared-key huawei
#
ipsec policy-template hrui 10
 security acl 3000
 ike-peer aaa
 proposal 2
#
ipsec policy huir 10 isakmp template hrui
#
Fault Symptom
  1. After an IPSec tunnel is set up, users cannot access the public network (such traffic does not need to be encrypted using IPSec). After the IPSec policy is unbound from the interface, users can access the public network.
  2. Four permit ACL rules are configured, but traffic matching only one permit rule can be transmitted.
Fault Analysis
  1. The ACL bound to the IPSec policy defines a deny rule. RouterA of V200R001C01SPC500 does not support the deny rule and discards packets matching the deny rule by default. After the deny rule is deleted, the fault is rectified.

    V200R002 does not use IPSec to encapsulate packets matching the deny rule and does not discard such packets.

  2. There are differences between versions. One end uses V200R001, and the other end uses V200R002. In V200R001, an SA is negotiated based on the ACL number. In V200R002, an SA is negotiated based on the ACL rule. Therefore, one SA is negotiated on the AR of V200R001, and four SAs are negotiated on the AR of V200R002. In this case, only traffic matching one ACL rule can be transmitted. After the AR is upgraded to V200R002, the fault is rectified.
Procedure
  1. Upgrade the ARs at both ends to V200R002 or later.
Suggestion

There are feature differences between versions. It is recommended that connected devices use the same version.

After an IPSec Tunnel Is Set Up Between Two AR Routers, Services Are Interrupted Because the Security ACL and NAT Policy Conflict

Keywords

NAT, IPSec tunnel setup, service interruption

Abstract

IPSec and NAT are deployed on the same device. A security ACL conflicts with the NAT policy. As a result, services are interrupted after an IPSec tunnel is established between two ends.

Problem Description

In the following figure, AR1 and AR2 function as gateways of the branch and headquarters respectively, and AR1 also functions as the NAT gateway. After IPSec is deployed, an IPSec tunnel is established between AR1 and AR2 successfully, but PCs cannot communicate with each other and services are interrupted.

Troubleshooting Procedure
  1. Run the display ipsec sa command to check IPSec tunnel information.
    <AR1> display ipsec sa 
    ipsec sa information:  
    =============================== 
    Interface: GigabitEthernet0/0/2 
    =============================== 
     ----------------------------- 
      IPSec policy name: "pc2"    
      Sequence number  : 1 
      Acl group        : 3101 
      Acl rule         : 5 
      Mode             : Template 
      ----------------------------- 
        Connection ID     : 67108879 
        Encapsulation mode: Tunnel 
        Holding time      : 0d 0h 4m 29s 
        Tunnel local      : 1.1.1.1:500 
        Tunnel remote     : 2.1.1.1:500 
        Flow source       : 10.1.1.0/255.255.255.0 17/1701 
        Flow destination  : 10.1.2.0/255.255.255.0 17/39725 
                                              
        [Outbound ESP SAs]         
          SPI: 4055669516 (0xf1bc9b0c)  
          Proposal: ESP-ENCRYPT-3DES-192 SHA2-256-128 
          SA remaining key duration (kilobytes/sec): 1840323/2420 
          Outpacket count       : 0 
          Outpacket encap count : 0 
          Outpacket drop count  : 0
          Max sent sequence-number: 0  
          ...... 

    The command output shows that an IPSec tunnel has been established, but no encrypted packets are sent when PC1 pings PC2.

    Run the display acl command to check whether the security ACL configuration matches the protected data flow.

    <AR1> display acl 3101      
    Advanced ACL 3101, 1 rule     
    Acl's step is 5                                                    
     rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0 0.0.0.255 (0 matches) 

    The command output shows that the security ACL configuration matches the protected data flow, but the data flow does not enter the IPSec tunnel. This is because AR1 also functions as the NAT gateway and the protected data flow may match the NAT policy.

  2. Run the display nat outbound and display acl to check whether the NAT policy contains the protected data flow.
    <AR1> display  nat outbound  
    NAT Outbound Information:    
     ----------------------------------------------------------------  
     Interface            Acl     Address-group/IP/Interface  Type     
     ---------------------------------------------------------------- 
     GigabitEthernet0/0/2 3300                     1.1.1.1    easyip 
     ---------------------------------------------------------------- 
      Total : 1     
     
    <AR1> display acl 3300 
    Advanced ACL 3300, 1 rule 
    Acl's step is 5     
     rule 10 permit ip (4 matches)

    The command output shows that the NAT policy contains and matches the protected data flow. Devices first handle the NAT process. Before IPSec encapsulation, NAT is performed on the data flows transmitted between PCs. Therefore, NAT is not performed on the data flow transmitted over an IPSec tunnel.

  3. Modify the NAT ACL of AR1 to prevent the protected data flow from matching the NAT policy.
    acl number 3300 
     rule 5 deny ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0 0.0.0.255         
     rule 10 permit ip 

    After the preceding configuration is complete, PCs can ping each other successfully, indicating that services between AR1 and AR2 can be forwarded normally.

Root Cause

The NAT policy contains the protected data flow. Devices first handle the NAT process. Before IPSec encapsulation, NAT is performed on the data flows transmitted between PCs.

Solution

Modify the NAT ACL of AR1 to prevent the protected data flow from matching the NAT policy.

Summary and Suggestions

When IPSec and NAT are configured on the same device, you need to check whether NAT needs to be performed on the IPSec-encapsulated data flow.

  • If so, the configured security ACL needs to match the post-NAT IP address.
  • If not, the configured security ACL needs to match the pre-NAT IP address, and NAT is not performed on the data flow transmitted over an IPSec tunnel.

After an IPSec Tunnel Is Set Up Between Two AR Routers, Services Are Interrupted Because of Inconsistent SHA2 Encryption/Decryption Modes

Keywords

SHA2 algorithm, IPSec tunnel setup, service interruption

Abstract

If IPSec uses the SHA2 authentication algorithm, inconsistent SHA2 encryption/decryption modes on both ends cause service interruption after an IPSec tunnel is set up between the two ends.

Problem Description

In the following figure, AR1 (Huawei router) functions as the branch gateway, and AR2 (Cisco router) functions as the headquarters gateway. After an IPSec tunnel is set up between the two routers, PCs cannot communicate with each other and services are interrupted.

Troubleshooting Procedure
  1. Run the display ipsec sa command to check IPSec tunnel information.
    <AR1> display ipsec sa 
    ipsec sa information:  
    =============================== 
    Interface: GigabitEthernet0/0/2 
    =============================== 
     ----------------------------- 
      IPSec policy name: "pc2"    
      Sequence number  : 1 
      Acl group        : 3061 
      Acl rule         : 5 
      Mode             : Template 
      ----------------------------- 
        Connection ID     : 67108879 
        Encapsulation mode: Tunnel 
        Holding time      : 0d 0h 4m 29s 
        Tunnel local      : 1.1.1.1:500 
        Tunnel remote     : 2.1.1.1:500 
        Flow source       : 10.1.1.0/255.255.255.0 17/1701 
        Flow destination  : 10.1.2.0/255.255.255.0 17/39725 
                                              
        [Outbound ESP SAs]         
          SPI: 4055669516 (0xf1bc9b0c)  
          Proposal: ESP-ENCRYPT-3DES-192 SHA2-256-128 
          SA remaining key duration (kilobytes/sec): 1840323/2420 
          Outpacket count       : 0
          Outpacket encap count : 0
          Outpacket drop count  : 0
          Max sent sequence-number: 0    
          ......                              
        [Inbound ESP SAs]     
          SPI: 1050491168 (0x3e9d3920)    
          Proposal: ESP-ENCRYPT-3DES-192 SHA2-256-128    
          SA remaining key duration (kilobytes/sec): 1840323/2420 
          Inpacket count        : 33
          Inpacket decap count  : 0
          Inpacket drop count : 33
          Max received sequence-number: 33 
          ...... 

    The command output shows that an IPSec tunnel has been established. However, after AR1 receives encrypted packets, it fails to decrypt the packets and discards them without sending encrypted packets.

  2. Run the display ipsec statistics command to check IPSec packet statistics.
    <AR1> display ipsec statistics 
     IPSec statistics information:    
     Number of IPSec tunnels: 1 
     the security packet statistics: 
     input/output security packets: 33/0  
     input/output security bytes: 0/0 
     input/output dropped security packets: 33/0 
     ...... 
     dropped security packet detail: 
         can not find SA: 0, wrong SA: 0    
         authentication: 33, replay: 0 
         front recheck: 0, after recheck: 0    
         ......

    The command output shows that encrypted packets are discarded because the authentication fails. The configuration is correct, so the possible cause is that the IPSec uses the SHA2 authentication algorithm.

    NOTE:

    If the software version is earlier than ARV200R008C00, run the display ipsec statistics esp command to check IPSec packet statistics.

  3. Run the display ipsec proposal command to check whether the authentication algorithm used in the IPSec proposal is SHA2.
    <AR1> display ipsec proposal 
    Number of proposals: 1                                                           
    IPSec proposal name: tran1 
     Encapsulation mode: Tunnel 
     Transform         : esp-new 
     ESP protocol      : Authentication SHA2-HMAC-512     
                         Encryption AES-256 

    The command output shows that the authentication algorithm of the IPSec proposal is SHA2-512. Because the SHA2 algorithm encryption/decryption modes on the Huawei router and Cisco router are different, the two routers fail to decrypt packets. As a result, packets are discarded.

  4. Run the ipsec authentication sha2 compatible enable command to change the SHA2 algorithm encryption/decryption mode on AR1.
    <AR1> system-view 
    [AR1] ipsec authentication sha2 compatible enable

    After the preceding configuration is complete, PCs can ping each other successfully, indicating that services between AR1 and AR2 can be forwarded normally.

Root Cause

The SHA2 algorithm encryption/decryption modes of Huawei and Cisco routers are different. As a result, one end fails to decrypt the received encrypted packets and discards the packets.

Solution

Run the ipsec authentication sha2 compatible enable command in the system view of AR1.

Summary and Suggestions

When the authentication algorithm used in an IPSec proposal is configured as SHA2, ensure that encryption/decryption modes on both ends are consistent. Especially when a Huawei device connects to a non-Huawei device, and inconsistent encryption/decryption modes are used on both ends, you need to run the ipsec authentication sha2 compatible enable command.

After an IPSec Tunnel Is Set Up Between Two AR Routers, Services Are Interrupted Because of Security ACL Conflict

Keywords

Security ACL, IPSec tunnel setup, service interruption

Abstract

When the headquarters connects to multiple branches, two security ACL rules conflict. As a result, services are interrupted after an IPSec tunnel is established between two ends.

Problem Description

In the following figure, multiple branches connect to AR1 in the headquarters through IPSec. These branches use fixed IP addresses and can communicate with each other and with the headquarters except that PCs in the branch with the gateway AR3 cannot communicate with the headquarters.

PC3 can communicate with PCs in other branches but not with PCs in the headquarters. This indicates that the IPSec configurations are correct and links are normal. The possible cause is that security ACL rules on both ends conflict.

Troubleshooting Procedure
  1. Run the display ipsec sa command to check whether the protected data flows negotiated based on the security ACL conflict.
    <AR1> display ipsec sa 
    =============================== 
    Interface: GigabitEthernet1/0/1 
    =============================== 
     
      ----------------------------- 
      IPSec policy name: "map1" 
      Sequence number  : 1 
      Acl group        : 3000 
      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.1.0.0/255.255.0.0 0/0 
        ..... 
     
      ----------------------------- 
      IPSec policy name: "map1" 
      Sequence number  : 2 
      Acl group        : 3001 
      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.6.1:500 
        Flow source       : 10.1.0.0/255.255.0.0 0/0 
        Flow destination  : 10.1.3.0/255.255.255.0 0/0 
        ....... 

    The command output shows that the data flow specified by rule 5 of ACL 3000 includes the data flow specified by rule 5 of ACL 3001. This indicates that the data flow transmitted normally between the headquarters and branches includes the data flow failing to be transmitted between the headquarters and branches, causing a security ACL rule conflict.

  2. Change the security ACL rule.

    Change the security ACL rule on AR1. The security ACL rule configurations of branches are similar to that of the headquarters, and are not mentioned here. Security ACL rules of branches and headquarters mirror each other.

    acl number 3000  
     rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0 0.0.0.255 
     
    acl number 3001 
     rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.1.3.0 0.0.0.255 

    After the preceding configuration is complete, PC3 can communicate with PC1 in the headquarters, indicating that services between AR1 and AR3 can be forwarded normally.

Root Cause

The data flow specified by rule 5 of ACL 3000 includes the data flow specified by rule 5 of ACL 3001. This indicates that the data flow transmitted normally between the headquarters and branches includes the data flow failing to be transmitted between the headquarters and branches, causing a security ACL rule conflict.

Solution

Change the security ACL rule of AR1 in the headquarters so that the IP address ranges in the ACL rules do not overlap.

Summary and Suggestions

If multiple branches establish IPSec tunnels with the headquarters, pay attention to the following points when configuring security ACL rules:

  • The IP address ranges in the ACL rules should not overlap. Otherwise, an error will occur when data flows match ACL rules.
  • The rules for the ACLs 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.

After an IPSec Tunnel Is Set Up Between Two AR Routers, Video Services Are Interrupted Because Packets Cannot Be Fragmented

Keywords

Packet fragmentation, TCP MSS, IPSec tunnel setup, service interruption

Abstract

After an IPSec tunnel is established between two AR routers, video services are interrupted because packets cannot be fragmented.

Problem Description

In the following figure, IPSec is deployed between AR1 and AR2 (a non-Huawei device). AR1 functions as the branch gateway, and AR2 functions as the headquarters gateway. After an IPSec tunnel is established between AR1 and AR2, the headquarters can call the branch in the video conference, but the branch cannot call the headquarters (the peer end rejects the request).

Because the branch cannot call the headquarters in the video conference, check whether the ACL and routing configurations are correct. Find that the configurations are correct.

Troubleshooting Procedure
  1. Run the ping -s packetsize -a source-ip-address host command to test packets of different sizes and determine whether packet loss occurs or the ping fails.
    <AR1> ping -s 1418 -a 10.1.1.1 10.1.2.2 
      PING 10.1.2.2: 1418  data bytes, press CTRL+C to break 
        Reply from 10.1.2.2: bytes=1418 Sequence=1 ttl=126 time=67 ms 
        Reply from 10.1.2.2: bytes=1418 Sequence=2 ttl=126 time=50 ms 
        Reply from 10.1.2.2: bytes=1418 Sequence=3 ttl=126 time=50 ms 
        Reply from 10.1.2.2: bytes=1418 Sequence=4 ttl=126 time=50 ms 
        Reply from 10.1.2.2: bytes=1418 Sequence=5 ttl=126 time=50 ms 
     
      --- 10.1.2.2 ping statistics --- 
        5 packet(s) transmitted 
        5 packet(s) received 
        0.00% packet loss 
        round-trip min/avg/max = 50/53/67 ms 
     
    <AR1> ping -s 1419 -a 10.1.1.1 10.1.2.2 
      PING 10.1.2.2: 1419  data bytes, press CTRL+C to break 
        Request time out 
        Request time out 
        Request time out 
        Request time out 
        Request time out 
     
      --- 10.1.2.2 ping statistics --- 
        5 packet(s) transmitted 
        0 packet(s) received 
    100.00% packet loss 

    The command output shows that IPSec packets longer than 1418 bytes cannot be transmitted normally but non-fragmented packets can be transmitted normally. This is because large IPSec-encapsulated packets are larger than the interface MTU. As a result, these IPSec packets are fragmented and cannot be normally transmitted on the network.

  2. Run the display ipsec sa command to check whether the data flow enters the IPSec tunnel when large ping packets are sent.
    <AR1> display ipsec sa 
    ipsec sa information:  
    =============================== 
    Interface: GigabitEthernet0/0/2 
    =============================== 
     ----------------------------- 
      IPSec policy name: "pc2"    
      Sequence number  : 1 
      Acl group        : 3101 
      Acl rule         : 5 
      Mode             : Template 
      ----------------------------- 
        Connection ID     : 67108879 
        Encapsulation mode: Tunnel 
        Holding time      : 0d 0h 4m 29s 
        Tunnel local      : 1.1.1.1:500 
        Tunnel remote     : 2.1.1.1:500 
        Flow source       : 10.1.1.0/255.255.255.0 17/1701 
        Flow destination  : 10.1.2.0/255.255.255.0 17/39725 
                                              
        [Outbound ESP SAs]         
          SPI: 4055669516 (0xf1bc9b0c)  
          Proposal: ESP-ENCRYPT-3DES-192 SHA2-256-128 
          SA remaining key duration (kilobytes/sec): 1840323/2420 
          Outpacket count       : 0 
          Outpacket encap count : 0 
          Outpacket drop count  : 0
          Max sent sequence-number: 0  
          ......

    The command output shows that the data flow does not enter the IPSec tunnel when large ping packets are sent, indicating that IPSec packets are not sent. The data flow can be normally sent when small ping packets are sent. Therefore, it is suspected that IPSec packets cannot be fragmented. As a result, IPSec packets are discarded.

  3. Run the display ipsec global config command to check the DF bit of IPSec packets.
    <AR1> display ipsec global config 
    IPSec Global Config:  
    --------------------------------------------------------------  
      IPSec sa global-duration time-based(seconds) : 3600    
      IPSec sa global-duration traffic-based(kbytes) : 1843200 
      IPSec anti-replay                              : enable 
      IPSec df-bit                                   : copy 
      IPSec fragmentation                            : disable 
      IPSec invalid-spi-recovery                     : disable 
      IPSec nat-traversal source-port                : 8000 
    --------------------------------------------------------------    

    The command output shows that the DF bit of IPSec packets is the flag bit of original packets. It is suspected that the DF bit of original packets is 1, which prohibits packets from being fragmented.

    NOTE:

    IPSec df-bit: DF bit of an IPSec tunnel

    • clear: indicates that the DF bit is set to 0, allowing packets to be fragmented.
    • set: indicates that the DF bit is set to 1, prohibiting packets from being fragmented.
    • copy: indicates that the DF bit is that of original packets.

    IPSec fragmentation: IPSec tunnel packet fragmentation mode

    • enable: Fragmentation before IPSec encryption
    • disable: Fragmentation after IPSec encryption
  4. Run the ipsec df-bit clear command to set the DF bit to 0.
    <AR1> system-view 
    [AR1] ipsec df-bit clear

    After the preceding configuration is complete, the ping operation succeeds when large ping packets are sent, indicating that the branch can call the headquarters in the video conference.

    <AR1> ping -s 1419 -a 10.1.1.1 10.1.2.2 
      PING 10.1.2.2: 1419  data bytes, press CTRL+C to break 
        Reply from 10.1.2.2: bytes=1419 Sequence=1 ttl=126 time=67 ms 
        Reply from 10.1.2.2: bytes=1419 Sequence=2 ttl=126 time=50 ms 
        Reply from 10.1.2.2: bytes=1419 Sequence=3 ttl=126 time=50 ms 
        Reply from 10.1.2.2: bytes=1419 Sequence=4 ttl=126 time=50 ms 
        Reply from 10.1.2.2: bytes=1419 Sequence=5 ttl=126 time=50 ms 
     
      --- 10.1.2.2 ping statistics --- 
        5 packet(s) transmitted 
        5 packet(s) received 
        0.00% packet loss 
        round-trip min/avg/max = 50/53/67 ms

    If services are interrupted or unstable, the network cannot process fragmented packets or processing fragmented packets causes high CPU usage.

    The video conference service is TCP service. If the total packet length (TCP MSS+TCP header+IP header+IPSec header) is larger than the link MTU, data packets are fragmented for transmission. Therefore, you are advised to run the tcp adjust-mss command to adjust the TCP MSS.

    [AR1] interface gigabitethernet 0/0/2 
    [AR1-GigabitEthernet0/0/2] tcp adjust-mss 1200
Root Cause

The DF bit of original packets is 1. As a result, the DF bit of IPSec packets is 1, prohibiting IPSec packets from being fragmented. If the number of IPSec packets exceeds the MTU, IPSec packets are discarded.

Solution

Run the ipsec df-bit clear command to set the DF bit to 0 so that IPSec packets can be fragmented.

Summary and Suggestions
  • Network transmission failures are irrelevant to IPSec tunnels. The problem is that fragmented Ethernet packets cannot be normally transmitted in a WAN.
  • Packets may be fragmented regardless of whether IPSec tunnels exist. After an IPSec header is added to a packet, the packet length increases, which increases the possibility that this packet is fragmented.
  • If the network where AR routers reside cannot properly process fragmented packets, decrease the TCP MSS to avoid a large number of fragmented packets.

Poor Service Quality After Successful IPSec Tunnel Setup

A User Cannot Access a Server Through an IPSec Tunnel Because the TCP MSS Configured on an AR Router Is Improper

Keywords

TCP MSS, IPSec, server access failure

Abstract

When a user uses multiple computers to access the weblogic server in an office, only one computer can access the weblogic server occasionally, and the access pages are blank on the other computers.

Problem Description

In the following figure, the weblogic server is installed on cluster servers App01 to App04 in the application zone of the PIMS Centre. An IPSec tunnel (the blue dotted arrow line in the figure) is set up between XXX-AR12-01 in the Fixed Information Collection Office (FICO) (the red circle in the figure) and PIM001-AR22-01 or PIM001-AR22-02 in the PIMS Centre, and passes through the ISP L2VPN network.

When a user uses three PCs and two laptops in the FICO to access the weblogic server through the IPSec tunnel, only one laptop can access the weblogic server occasionally, and the access pages are blank on the other computers. The client keeps waiting for a response to the HTTP request, as shown in the following figure.

The display ipsec sa command output shows that the IPSec tunnel has been established successfully, and the configuration is correct.

Troubleshooting Procedure
  1. Obtain packet headers on the network interface of the laptop that fails to access the server and the network interface of the laptop that successfully accesses the server, respectively.

    Use the Follow TCP Stream tool to check the packet header file obtained from the laptop that fails to access the server. A failed HTTP request is found, and the server returns a response to the client. As shown in the following figure, the server normally returns HTTP 302 indicating URL redirection, and the client keeps requesting data from the server. The server normally returns HTTP 200, but no text is returned, that is, the server does not send text content to the client after successfully responding to the HTTP request.

  2. Check whether the weblogic server is abnormal.

    The user attempts to access the weblogic server using a PC (in the blue box in the first figure) from the CP Centre. The user can access the server, indicating that the server works properly. The successful access also indicates that the aggregation switch works properly.

  3. Ping the IP address of the server from a PC in the FICO, as shown in the following figure.

    The TTL field in the ping command output displays 252 or 253, indicating that the packet path changes. It is suspected that the firewall blocks ping reply packets as attack packets during session detection.

  4. Check whether the firewall works properly.

    Configure the undo firewall session link-state check tcp command on the firewall, and perform the test again. The fault persists. Therefore, the problem is not caused by the firewall.

  5. Check the L2VPN link of the egress router or ISP.

    Check the packets exchanged between the server and the laptop that fails to access the server. The following suspicious packets are found:

    According to the packet analysis result, the previous segment of the TCP packet returned by the server is lost.

    Ping the server using packets without fragmentation from a PC in the FICO, for example, run the ping 10.248.0.15 l 1446 f command. The ping fails.

    Check the packets exchanged between the server and the laptop that successfully accesses the server. Many respond packets with lost fragments are still found, indicating that there is a possibility that the PC successfully accesses the server.

    It is basically determined that this problem is caused by loss of fragmented packets on the ISP transmission link, indicating that the maximum segment size (MSS) of TCP packets is set improperly.

  6. Change the TCP MSS.

    Run the tcp adjust-mss 1200 command in the interface view of the egress AR router to change the MSS of TCP packets to 1200 bytes on the interface.

    After the configuration is changed, access the weblogic server from a PC in the FICO again. The access is successful. The problem is solved.

Root Cause

The TCP MSS specifies the maximum segment size of TCP packets. If the total length of a packet (including the MSS, TCP packet header, and IP packet header) exceeds the MTU of the link, the packet is fragmented and sent.

In this scenario, the total length of the TCP packet (including the MSS, TCP packet header, IP packet header, and IPSec header) is greater than the MTU of the link. As a result, the packet is fragmented and sent. The fragmentation process consumes more CPU resources, and encryption and decryption of fragmented packets also consume CPU resources of devices on the transmission link. If a lot of CPU resources are consumed, packet loss occurs. Therefore, when the user uses three PCs and two laptops in the FICO to access the weblogic server through the IPSec tunnel, only one laptop can access the weblogic server occasionally, and the access pages are blank on the other computers.

Solution

In an IPSec scenario, you are advised to set the TCP MSS to 1200 bytes in the interface view of the egress router considering that TCP packets contain overheads including TCP and IP headers. This configuration ensures that devices on the ISP link do not perform packet fragmentation again to prevent packet loss caused by too much CPU resource consumption, ensuring normal service running.

Summary and Suggestions

In a VPN scenario, check whether the size of sent packets is too large, which may cause packet fragmentation. The fragmentation process consumes more CPU resources, and encryption and decryption of fragmented packets also consume CPU resources of devices on the transmission link. If a lot of CPU resources are consumed, packet loss occurs. In addition, some upper-layer applications (such as HTTP and other application layer protocols) 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 MTU of the router interface is smaller than the MSS of TCP packets, the router will discard the TCP packets because it cannot forcibly fragment the TCP packets.

Therefore, ensure that the total packet length (including the MSS and various overheads) does not exceed the MTU. The MTU supported by the Ethernet protocol is 1500 bytes and the MTU supported by the PPPoE protocol is 1492 bytes. It is recommended that you set the TCP MSS to 1200 bytes.

Services Are Interrupted Because an IPSec Tunnel Is Unstable

L2TP Dial-up from a Public Network User Fails Due to Incorrect UDP Port Mapping of the NAT Server on the AR

This section provides a troubleshooting case for the fault that Layer 2 Tunneling Protocol (L2TP) dial-up from a public network user fails because User Datagram Protocol (UDP) port mapping for the network address translation (NAT) server is incorrectly configured on an AR router.

Networking
Figure 26-12  Configuring the headquarters and branch to communicate through L2TP dual-up

LAC configuration:

#
 l2tp enable
#
aaa
 local-user huawei password cipher %^%#_<`.CO&(:LeS/$#F\H0Qv8B]KAZja3}3q'RNx;VI%^%#
 local-user huawei privilege level 0  
 local-user huawei service-type ppp
#
interface Virtual-Template1
 ppp authentication-mode chap
#
interface GigabitEthernet1/0/0
 ip address 1.1.2.1 255.255.255.0
#
interface GigabitEthernet2/0/0
 pppoe-server bind Virtual-Template 1
#
l2tp-group 1
 tunnel password cipher %@%@/-#)Lg[S4F:#2~ZNvqa$]\DL%@%@
 tunnel name lac
 start l2tp ip 1.1.1.1 fullusername huawei
#
ip route-static 1.1.1.1 255.255.255.255 1.1.2.2
# 
interface gigabitethernet1/0/0 
 nat server protocol tcp global interface gigabitethernet 1/0/0 www inside 192.168.10.2 www 
 nat server protocol tcp global interface gigabitethernet 1/0/0 pop3 inside 192.168.10.2 pop3 
 nat server protocol tcp global interface gigabitethernet 1/0/0 smtp inside 192.168.10.2 smtp 
 nat server protocol tcp global interface gigabitethernet 1/0/0 ftp inside 192.168.10.2 ftp 
 nat server protocol udp global interface gigabitethernet 1/0/0 any inside 192.168.10.2 any 
 nat outbound 2001 
# 
return
Fault Description

The LAC functions as the egress router of an enterprise, which establishes connections to the headquarters through L2TP dial-up. Users dial up on the outbound interface GE1/0/0 of the LAC through Point-to-Point Protocol over Ethernet (PPPoE) to access the Internet. PC1 on the private network can successfully establish connections to the headquarters through L2TP dial-up. PC2 on the public network fails to establish connections to the headquarters through L2TP dial-up, and error message 800 is displayed. (Packets from PC2 to the LNS are forwarded through GE1/0/0 on the LAC.) When the administrator logs in to the LAC and runs the debugging ppp all and debugging l2tp all commands to collect L2TP debugging information, no information is displayed.

Fault Analysis
  1. Check whether the L2TP configuration is correct. Since PC1 on the private network can successfully initiate L2TP tunnel connections, the L2TP configuration is correct.
  2. Check the outbound interface configuration on the LAC. A command that enables mapping for all UDP packets is configured on the outbound interface GE1/0/0.
    <LAC> system-view 
    [LAC] interface gigabitethernet1/0/0 
    [LAC-GigabitEthernet1/0/0] display this 
    # 
    interface GigabitEthernet1/0/0  
     ip address 1.1.2.1 255.255.255.0  
     nat server protocol tcp global interface gigabitethernet 1/0/0 www inside 192.168.10.2 www 
     nat server protocol tcp global interface gigabitethernet 1/0/0 pop3 inside 192.168.10.2 pop3 
     nat server protocol tcp global interface gigabitethernet 1/0/0 smtp inside 192.168.10.2 smtp 
     nat server protocol tcp global interface gigabitethernet 1/0/0 ftp inside 192.168.10.2 ftp 
     nat server protocol udp global interface gigabitethernet 1/0/0 any inside 192.168.10.2 any  
     nat outbound 2001
  3. UDP port 1701 is used for L2TP tunnel setup. On the LAC, the NAT server is configured to map all UDP packets to the private network. When a public network user initiates an L2TP dial-up to the LNS, the NAT server maps packets reaching GE1/0/0 on the LAC to the private network. As a result, the packets cannot reach the LNS, and the public network user cannot set up L2TP dial-up connections to the headquarters. The fault is rectified after the UDP port mapping configuration is deleted.
Procedure
Delete the UDP port mapping configuration of the NAT server from the outbound interface GE1/0/0 on the LAC.
<LAC> system-view 
[LAC] interface gigabitethernet1/0/0
[LAC-GigabitEthernet1/0/0] undo nat server protocol udp global interface gigabitethernet 1/0/0 any inside 192.168.10.2 any
Conclusions and Suggestions

If L2TP dial-up fails, perform the following steps to locate the fault:

  1. Check the device configuration.
  2. If the device configuration is correct, run the debugging ppp all and debugging l2tp all commands to collect debugging information.
  3. If no information is displayed, check whether the packets are forwarded to another network device or rejected by the LNS.
  4. Check whether the NAT server maps packets from all the ports. To prevent service exception or interruption, port mapping must be disabled for specific features, such as L2TP and Telnet.
Translation
Download
Updated: 2019-05-10

Document ID: EDOC1000079719

Views: 445900

Downloads: 4299

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