Troubleshooting IPSec Issues

Procedure

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

   <sysname> display ike sa 
   =========================================== 
   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.

   <sysname> 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.

   <sysname> 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    
   ......
   <sysname> 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 flow.

   During packet forwarding, the IPSec module is behind the NAT module (NAT server, destination NAT, and source NAT). You need to ensure that the NAT server and destination NAT do not affect the processing of IPSec-protected data flow. The following requirements must be met:

   • Run the display firewall server-map command to check the source and destination IP addresses in the servermap table.

     Ensure that the IPSec-protected data flow does not match the servermap table or reverse servermap table created on the NAT server. Otherwise, destination addresses of packets will be translated.

   • Run the display zone and display acl acl-number commands to check ACL information of the destination NAT policy.

     Ensure that the IPSec-protected data flow does not match the destination NAT policy. Otherwise, destination addresses of packets will be translated.

   • Run the display current-configuration configuration policy-nat command to check source NAT policy information.

     Ensure that the IPSec-protected data flow does not match the source NAT policy.

   If NAT is required for the IPSec-protected data flow, the security ACL needs to match the post-NAT IP address.

6. Check whether the interzone configuration is correct.

   Run the display current-configuration configuration policy-security command to check the interzone configuration. Ensure that the IPSec-protected data flow can be transmitted from a trust zone to an untrust zone.

7. 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.

      <sysname> terminal monitor 
      <sysname> terminal debugging 
      <sysname> debugging ikev1 all //Debugging information collected when IKEv1 negotiation is used 
      <sysname> debugging ikev2 all //Debugging information collected when IKEv2 negotiation is used 
      <sysname> debugging ipsec all

   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.

         <sysname> 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.

         <sysname> 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.

      <sysname> system-view 
      [sysname] acl 3100 
      [sysname-acl-adv-3100] acl 3100 //Define data flows. 
      [sysname-acl-adv-3100] rule 5 permit ip source 10.1.1.1 0 destination 10.2.1.1 0  
      [sysname-acl-adv-3100] rule 5 permit ip source 10.2.1.1 0 destination 10.1.1.1 0  
      [sysname-acl-adv-3100] quit 
      [sysname] packet-capture ipv4-packet 3100 interface GigabitEthernet 1/0/1 
      [sysname] packet-capture startup packet-num 1500 //Enable the function of obtaining packet header information. 
      [sysname] 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.

References

Analysis of traffic-triggered IKE negotiation:

IPSec Packet Forwarding Process

Cases:

When IPSec and NAT Are Configured on the Same Device, Service Packets Cannot Match Security ACLs After NAT Is Performed

Troubleshooting Flowchart

Run the display ike error-info command to check the IKE SA negotiation failure reason for fast fault location or locate the fault according to Figure 1-6.

Figure 1-6 Troubleshooting flowchart

Procedure

1. Check whether security policies permit IKE packets.

   Run the display firewall session table verbose command to check whether IKE sessions exist (the default UDP port number is 500 or 4500). The IKE session aging time is 120s. After the aging time expires, this command cannot display required information. You are advised to run the reset ike sa command before running the display firewall session table verbose command.

   <sysname> display firewall session table verbose 
    udp  VPN: public --> public  ID: a68f5bd4603f01f756c5ab54663 
    Zone: local --> trust  TTL: 00:02:00  Left: 00:01:58 
    Recv Interface: InLoopBack0 
    Interface: GigabitEthernet0/0/2  NextHop: 1.1.1.2  MAC: 2cab-0078-c406 
    <--packets: 0 bytes: 0 --> packets: 0 bytes: 0 //Check whether IKE negotiation packets are sent or received. 
    1.1.1.1:500 --> 2.1.1.1:500 PolicyName: default

   If IKE sessions exist, IKE policies have permitted IKE packets. Otherwise, you need to run the service protocol udp destination-port port command in the service view to configure an IKE policy and run the service service-name command in the security policy rule view to reference a self-defined service.

2. 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.

   • 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 FW1 and FW2 are unreachable. Go to step 3.
     • 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 4.
   • 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 4.
     • Security policies do not permit IKE packets. Go to step 1.
   • 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 FW2 is configured on FW1, but no route to FW1 is configured on FW2. Go to step 3.

3. 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.

4. 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.

   <sysname> 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.

5. 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.

   <sysname> 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 signature-padding or rsa encryption-padding command in the IKE peer view to change them to be consistent.

   • In IPSec VPN for remote mobile user access, to authenticate and assign IP addresses to mobile users through an AAA server, you also need to run the display radius-server configuration and display domain commands to check the server configuration and user group configuration.

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

6. 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.

   <sysname> 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 
   -------------------------------------------

7. 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.

      <sysname> terminal monitor 
      <sysname> terminal debugging 
      <sysname> debugging ikev1 all //Debugging information collected when IKEv1 negotiation is used 
      <sysname> debugging ikev2 all //Debugging information collected when IKEv2 negotiation is used 
      <sysname> debugging ipsec all

   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.

         <sysname> 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.

         <sysname> 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.

      <sysname> system-view 
      [sysname] acl 3100 
      [sysname-acl-adv-3100] acl 3100 //Define data flows. 
      [sysname-acl-adv-3100] rule 5 permit ip source 10.1.1.1 0 destination 10.2.1.1 0  
      [sysname-acl-adv-3100] rule 5 permit ip source 10.2.1.1 0 destination 10.1.1.1 0  
      [sysname-acl-adv-3100] quit 
      [sysname] packet-capture ipv4-packet 3100 interface GigabitEthernet 1/0/1 
      [sysname] packet-capture startup packet-num 1500 //Enable the function of obtaining packet header information. 
      [sysname] 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.

References

IKE Proposal Parameters on Both Ends Are Inconsistent

Pre-Shared Keys on Both Ends Are Inconsistent

IKE Peer IP Addresses on Both Ends Do Not Match

In L2TP over IPSec Scenarios, a Security ACL Does Not Match the IP Address Used After L2TP Encapsulation

Context

Run the display ike error-info 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.

   <sysname> 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    
   ......
   <sysname> 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, a SA can be successfully established after any party initiates negotiation. If ACL rules on both ends do not mirror each other, a 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 or there is an overlapping address range between the two ACL rules. 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:
     • For IKEv1, mirroring is not necessary. SAs can be set up successfully as long as the address range defined in the ACL rule of the initiator is included in that of the responder. Both ends use the overlapping ACL rule range as the negotiation result.
     • For IKEv2, mirroring is not necessary as long as there is an overlapping ACL rule range between ACL rules on both ends. Both ends use the overlapping ACL rule range 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.

   <sysname> 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. For IKEv1, check whether the PFS configurations on both ends are consistent.

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

   <sysname> 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.

      <sysname> terminal monitor 
      <sysname> terminal debugging 
      <sysname> debugging ikev1 all //Debugging information collected when IKEv1 negotiation is used 
      <sysname> debugging ikev2 all //Debugging information collected when IKEv2 negotiation is used 
      <sysname> debugging ipsec all

   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.

         <sysname> 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.

         <sysname> 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.

      <sysname> system-view 
      [sysname] acl 3100 
      [sysname-acl-adv-3100] acl 3100 //Define data flows. 
      [sysname-acl-adv-3100] rule 5 permit ip source 10.1.1.1 0 destination 10.2.1.1 0  
      [sysname-acl-adv-3100] rule 5 permit ip source 10.2.1.1 0 destination 10.1.1.1 0  
      [sysname-acl-adv-3100] quit 
      [sysname] packet-capture ipv4-packet 3100 interface GigabitEthernet 1/0/1 
      [sysname] packet-capture startup packet-num 1500 //Enable the function of obtaining packet header information. 
      [sysname] 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.

References

IKE Proposal Parameters on Both Ends Are Inconsistent

Pre-Shared Keys on Both Ends Are Inconsistent

IKE Peer IP Addresses on Both Ends Do Not Match

In L2TP over IPSec Scenarios, a Security ACL Does Not Match the IP Address Used After L2TP Encapsulation

Troubleshooting Flowchart

Rectify the fault according to the troubleshooting flowchart in Figure 1-10.

Figure 1-10 Troubleshooting flowchart

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.

   <sysname> 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 
   ......     
   <sysname> 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 the interzone configuration is correct.

   Run the display current-configuration configuration policy-security command to check the interzone configuration of a trust zone. Ensure that the IPSec-protected data flow can be transmitted from a trust zone to an untrust zone and that the IPSec-negotiated data flow can be transmitted between the untrust zone and local zone.

5. 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.

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

6. Check whether the NAT policy configuration affects the IPSec-protected data flow.

   During packet forwarding, the IPSec module is behind the NAT module (NAT server, destination NAT, and source NAT). You need to ensure that the NAT server and destination NAT do not affect the processing of IPSec-protected data flow. The following requirements must be met:

   • Run the display firewall server-map command to check the source and destination IP addresses in the servermap table.

     Ensure that the IPSec-protected data flow does not match the servermap table or reverse servermap table created on the NAT server. Otherwise, destination addresses of packets will be translated.

   • Run the display zone and display acl acl-number commands to check ACL information of the destination NAT policy.

     Ensure that the IPSec-protected data flow does not match the destination NAT policy. Otherwise, destination addresses of packets will be translated.

   • Run the display current-configuration configuration policy-nat command to check source NAT policy information.

     Ensure that the IPSec-protected data flow does not match the source NAT policy.

   If NAT is required for the IPSec-protected data flow, the security ACL needs to match the post-NAT IP address.

7. 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.

   <sysname> 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 
   ......

8. Check whether the security protocol is AH during NAT traversal when a NAT device exists between two ends.

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

   Only the security protocol ESP is supported during NAT traversal.

   <sysname> 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             

9. Check whether the encryption/decryption modes on both ends are consistent if the authentication algorithm used in an IPSec proposal is SHA2-384 or SHA2-512.

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

   <sysname> 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.

     When the FW is connected to an AR router, run the display ipsec statistics command to check whether received encrypted packets are discarded. If received encrypted packets are discarded because of an authentication failure, run the ipsec authentication sha2 compatible enable command in the system view of the AR router to ensure consistent encryption/decryption modes on both ends.

   • The authentication algorithm is SHA2-384 or SHA2-512.

     Run the display ipsec statistics command to check whether received encrypted packets are discarded. If received encrypted packets are discarded because of an authentication failure, run the ipsec sha2 compatible enable or undo ipsec sha2 compatible enable command in the system view to ensure consistent encryption/decryption modes on both ends.

10. Check whether packets reach firewalls or are dropped by firewalls.

    Run the firewall statistic acl acl-number enable and then display firewall statistic acl commands in the diagnostic view to check whether IPSec packets reach firewalls or are dropped by firewalls.

    If no traffic statistics are collected, a fault occurs in the intermediate network that packets pass through and needs to be located. If dropped packet statistics are collected, contact technical support personnel.

11. 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.

       <sysname> terminal monitor 
       <sysname> terminal debugging 
       <sysname> debugging ikev1 all //Debugging information collected when IKEv1 negotiation is used 
       <sysname> debugging ikev2 all //Debugging information collected when IKEv2 negotiation is used 
       <sysname> debugging ipsec all

    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.

          <sysname> 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.

          <sysname> 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.

       <sysname> system-view 
       [sysname] acl 3100 
       [sysname-acl-adv-3100] acl 3100 //Define data flows. 
       [sysname-acl-adv-3100] rule 5 permit ip source 10.1.1.1 0 destination 10.2.1.1 0  
       [sysname-acl-adv-3100] rule 5 permit ip source 10.2.1.1 0 destination 10.1.1.1 0  
       [sysname-acl-adv-3100] quit 
       [sysname] packet-capture ipv4-packet 3100 interface GigabitEthernet 1/0/1 
       [sysname] packet-capture startup packet-num 1500 //Enable the function of obtaining packet header information. 
       [sysname] 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.

References

Analysis of service interruptions:

Abnormal Services After Successful IPSec Tunnel Setup

Cases:

IKE Proposal Parameters on Both Ends Are Inconsistent

Pre-Shared Keys on Both Ends Are Inconsistent

IKE Peer IP Addresses on Both Ends Do Not Match

In L2TP over IPSec Scenarios, a Security ACL Does Not Match the IP Address Used After L2TP Encapsulation

Symptom

In Figure 1-12, after IPSec is deployed between FWs, PCs cannot communicate with each other.

Figure 1-12 IPSec networking

1. Run the display ike sa command on FW1, finding that an IKE SA fails to be established.

   <FW1> 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 ike error-info command on FW1, finding that the IKE negotiation failure reason is phase1 proposal mismatch. This indicates that IKE proposal parameters on both ends are inconsistent.

   <FW1> 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          v2      2017-09-05 15:22:32 
     2.1.1.1           500     phase1 proposal mismatch          v2      2017-09-05 15:22:32 
   -----------------------------------------------------------------------------------------

Possible Causes

IKE proposal parameters, such as the authentication algorithm, encryption algorithm, and Diffie-Hellman (DH) group, are inconsistent on both ends.

Procedure

1. Run the display ike proposal [ number proposal-number ] command to check whether IKE proposal parameters on both ends are consistent.

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

   The preceding command output shows that the Encryption Algorithm field displays different values on both ends.

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

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

   ike proposal 10 
    encryption-algorithm aes-256

   After the change, the two FWs can establish an IPSec tunnel, and PCs can communicate with each other.

Suggestion and Summary

When configuring IPSec, ensure that there are reachable routes between two ends. Otherwise, the two ends fail IKE negotiation.

When configuring IPSec, ensure that IKE proposal 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 ikev2 all command on the local device to view the IKE proposal information sent by the non-Huawei device.

Check the locally resolved IKE proposal in the debugging information. For example:

IKE_INFO 47:2699 Number of proposal : 1 
IKE_INFO 47:2868 
Proposal No 1: 
Protocol ID: ISAKMP 
IKE_INFO 47:2521 ENCRYPTION ALGORITHM: AES_256 //Encryption algorithm 
IKE_INFO 47:2521 ENCRYPTION ALGORITHM: AES_256 //Encryption algorithm 
IKE_INFO 47:2274 INTEGRITY ALGORITHM: SHA_256  //Authentication algorithm
IKE_INFO 47:2243 PRF ALGORITHM: SHA2_256       //Algorithm used to generate the pseudo random number
IKE_INFO 47:2308 GROUP_TYPE: MODP_1024         //DH key exchange parameter   

If IKEv1 is used, run the debugging ikev1 all command to check the locally resolved IKE proposal. For example:

IKE_INFO 17:3513 Message from peer 1.1.1.1: validate payload SA 
IKE_INFO 17:813 Message from peer 1.1.1.1: Parsing payload PROPOSAL 
IKE_INFO 17:813 Message from peer 1.1.1.1: Parsing payload TRANSFORM
IKE_INFO 2:2924 Attribute ENCRYPTION_ALGORITHM value AES_CBC //Encryption algorithm 
IKE_INFO 2:2924 Attribute KEY_LENGTH value 256 //Encryption algorithm length
IKE_INFO 2:2924 Attribute HASH_ALGORITHM value SHA2-256 //Authentication algorithm 
IKE_INFO 2:2924 Attribute AUTHENTICATION_METHOD value PRE_SHARED //Authentication method 
IKE_INFO 2:2924 Attribute GROUP_DESCRIPTION value MODP_1024 //DH key exchange parameter 
IKE_INFO 2:2924 Attribute LIFE_TYPE value SECONDS 
IKE_INFO 2:2924 Attribute LIFE_DURATION value 86400 //IKE SA lifetime

Symptom

In Figure 1-13, after IPSec is deployed between FWs, PCs cannot communicate with each other.

Figure 1-13 IPSec networking

1. Run the display ike sa command on FW1, finding that an IKE SA fails to be established.

   <FW1> 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 ike error-info command on FW1, finding that the IKE negotiation failure reason is authentication fail. This indicates that identity authentication fails.

   <FW1> 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     authentication fail              v2      2017-09-05 15:22:32 
     2.1.1.1           500     authentication fail              v2      2017-09-05 15:22:32 
   -----------------------------------------------------------------------------------------

If both ends use IKEv1 negotiation and different pre-shared keys, the display ike error-info command output shows that the IKE negotiation failure reason is malformed-message.

Possible Causes

Pre-shared keys on both ends are inconsistent.

Procedure

1. Run the display ike proposal [ number proposal-number ] command to check whether pre-shared key authentication is used on both ends.

   For example, run the display ike proposal [ number proposal-number ] command on FW1.

   <FW1> 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                                    
   -------------------------------------------

   If the Authentication Method field displays inconsistent values on both ends, change the values to be consistent. If the fault persists, change pre-shared keys on both ends to be consistent.

2. Change the pre-shared keys on both ends.

   Assume that the pre-shared keys used on both ends are both huawei@123.

   ike peer spub 
    pre-shared-key huawei@123

   After the change, the two FWs can establish an IPSec tunnel, and PCs can communicate with each other.

Symptom

In Figure 1-14, an IPSec tunnel has been established between FWs. After a sub address is added and some configurations are modified on the public network interface of FW1, an IPSec tunnel fails to be established. IPSec and IKE parameter configurations of both ends are correct.

Figure 1-14 IPSec networking

1. Run the display ike sa command on FW2, finding that an IKE SA fails to be established.

   <FW2> display ike sa 
   IKE SA information :                        
    Conn-ID    Peer           VPN             Flag(s)              Phase  
     ---------------------------------------------------------------------- 
                                                                    
    83891196 1.1.1.5:500                    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

2. Run the display ike error-info command on FW2, finding that the IKE negotiation failure reason is peer address mismatch. This indicates that IKE peer IP addresses on both ends do not match.

   <FW2> display ike error-info 
     current info Num :1 
     Ike error information: 
     current ike Error-info number :1 
   ----------------------------------------------------------------------------------------- 
     peer              port    error-reason                     version error-time 
   ----------------------------------------------------------------------------------------- 
     1.1.1.5           500     peer address mismatch            v2      2017-09-05 15:22:32 
   -----------------------------------------------------------------------------------------

3. Check the sub address configured on the interface of FW1.

   interface GigabitEthernet0/0/1 
    ip address 1.1.1.1 255.255.255.0 
    ip address 1.1.1.5 255.255.255.0 sub 
    ipsec policy map1

Possible Causes

The local address of the initiator is inconsistent with the remote address configured for the responder.

Procedure

1. Run the display ike peer [ name peer-name ] command to check whether IKE peer IP addresses on both ends match.

   <FW1> display ike peer name b 
   ------------------------------------------------                                 
    Peer name                    : b 
    IKE version                  : v2                                           
    VPN instance                 : -                                              
    Remote IP                    : 2.1.1.1                                        
    Authentic IP address         : -                                              
    Proposal                     : 10                                             
    Pre-shared-key               : %^%#=Q90U4SSw&~$c]YM.}!$}HWfFOm+G&i@`BW'7ETS%^ 
   %#                                                                               
    Local ID type                : IP                                             
    Local ID                     : -                                              
    Remote ID type               : -                                              
    Remote ID                    : - 
   ......... 
   ------------------------------------------------ 
   <FW2> display ike peer name b 
   ------------------------------------------------ 
    Peer name                    : a 
    IKE version                  : v2 
    VPN instance                 : - 
    Remote IP                    : 1.1.1.5 
    Authentic IP address         : - 
    Proposal                     : 10 
    Pre-shared-key               : %^%#.SBO>Q{o#@_BHQ/%ULL;f3%rOo4+*3fs3TI7sX\'%^ 
   %# 
    Local ID type                : IP 
    Local ID                     : - 
    Remote ID type               : - 
    Remote ID                    : - 
   .......... 
   ------------------------------------------------

   The preceding command output shows that the remote address configured for FW2 is the sub address configured for the interface of FW1. During IKE negotiation, by default, FW1 uses the primary IP address of its interface as the local address. As a result, the local address of the initiator is inconsistent with the remote address configured for the responder, resulting in an IKE SA negotiation failure.

2. Change the local address of FW1.

   ipsec policy map1 10 isakmp  
    tunnel local 1.1.1.5

   After the change, the two FWs can establish an IPSec tunnel, and PCs can communicate with each other.

Suggestion and Summary

For an ISAKMP policy, you do not need to configure a local address for an IPSec tunnel because the local address will be selected based on routing information during SA negotiation. A local IP address needs to be specified in the following situations:

• If the interface to which an IPSec policy is applied has a variable or unknown IP address, run the tunnel local ip-address command to specify the IP address of another interface (such as a loopback interface) on the device as the local IP address of an IPSec tunnel. Alternatively, run the tunnel local applied-interface command to specify the IP address of the interface to which an IPSec policy is applied as the local IP address of an IPSec tunnel.
• If the interface to which an IPSec policy is applied has multiple IP addresses (one primary IP address and several secondary IP addresses), run the tunnel local ip-address command to specify one of these IP addresses as the local IP address of an IPSec tunnel. Alternatively, run the tunnel local applied-interface command to specify the primary IP address of the interface as the local IP address of an IPSec tunnel.
• If equal-cost routes exist between the local and remote ends, run the tunnel local{ ip-address | applied-interface } command to specify a local IP address of an IPSec tunnel.

Symptom

In Figure 1-15, after IPSec is deployed between FWs, PCs cannot communicate with each other.

Figure 1-15 IPSec networking

1. Run the display ike sa command on FW1, finding that an IPSec SA fails to be established.

   <FW1> display ike sa 
   IKE SA information :                        
    Conn-ID    Peer           VPN             Flag(s)              Phase  
     ---------------------------------------------------------------------- 
                                                                    
     83891320    2.1.1.1:500                    RD|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

2. Run the display ike error-info command on FW1, finding that the IKE negotiation failure reason is phase2 proposal or pfs mismatch. This indicates that IPSec proposal parameters or PFS algorithms on both ends are inconsistent.

   <FW1> 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     phase2 proposal or pfs mismatch v2      2017-09-05 15:22:32 
     2.1.1.1           500     phase2 proposal or pfs mismatch v2      2017-09-05 15:22:32 
   -----------------------------------------------------------------------------------------

Possible Causes

IPSec proposal parameters or PFS algorithms on both ends are inconsistent.

Procedure

1. Run the display ipsec proposal [ name proposal-name ] command to check whether IPSec proposal parameters on both ends are consistent.

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

   The preceding command output shows that encryption algorithms used on both ends are inconsistent.

2. Change inconsistent IPSec proposal parameters on both ends to be consistent.

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

   ike proposal 10 
    encryption-algorithm aes-256

   After the change, the two FWs can establish an IPSec tunnel, and PCs can communicate with each other.

Suggestion and Summary

When configuring IPSec, ensure that IPSec proposal 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 IPSec SA negotiation. If configurations of the non-Huawei device cannot be obtained, run the debugging ikev2 all command on the local device to view the IPSec proposal information sent by the non-Huawei device.

Check the locally resolved IPSec proposal in the debugging information. For example:

IKE_INFO 47:2699 Number of proposal : 1 

IKE_INFO 47:2868  

 Proposal No 1: 

 Protocol ID: IPSEC_ESP //Security protocol type 

IKE_INFO 47:2521 ENCRYPTION ALGORITHM: AES_256 //Encryption algorithm 

IKE_INFO 47:2282 AUTHENTICATION ALGORITHM: SHA_256 //Authentication algorithm     

If IKEv1 is used, run the debugging ikev1 all command to check the locally resolved IPSec proposal. For example:

IKE_INFO 17:2267  

 Proposal No: 1    

 Protocol ID: IPSEC_ESP //Security protocol type 

IKE_INFO 2:1997 ENCRYPTION ALGORITHM: AES //Encryption algorithm 

IKE_INFO 2:2924 Attribute SA_LIFE_TYPE value SECONDS    

IKE_INFO 2:2924 Attribute SA_LIFE_DURATION value 3600 //Time-based IPSec SA lifetime 

IKE_INFO 2:2924 Attribute SA_LIFE_TYPE value KILOBYTES 

IKE_INFO 2:2924 Attribute SA_LIFE_DURATION value 1843200 //Traffic-based IPSec SA lifetime 

IKE_INFO 2:2924 Attribute ENCAPSULATION_MODE value TUNNEL //Encapsulation mode 

IKE_INFO 2:2924 Attribute AUTHENTICATION_ALGORITHM value SHA_256  //Authentication algorithm 

IKE_INFO 2:2924 Attribute KEY_LENGTH value 256 //Encryption algorithm length  

Symptom

In Figure 1-16, an IPSec tunnel has been established between FWs. After FW2 starts unexpectedly, its IPSec tunnel established with FW1 exists for a long period. As a result, clients at FW1 side cannot communicate with clients at FW2 side.

Figure 1-16 IPSec networking

Run the display ike sa command, finding that FW1 establishes a SA but FW2 fails to establish a SA.

<FW1> 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

<FW2> display ike sa

FW1 cannot use a source IP address to ping PC2, but FW2 can use a source IP address to ping PC1. Run the display ike sa command on FW1, finding that a SA has been established, and PC1 can ping PC2 successfully.

Possible Causes

If traffic triggers SA negotiation, after FW2 restarts, SAs are deleted. However, the lifetime of the SA on FW1 has not expired, so this SA is not deleted. The default IPSec SA lifetime is 1 hour, and the default IKE SA lifetime is 24 hours. When FW1 initiates access traffic, the traffic matches the original SA. As a result, a new SA cannot be established, and PC1 cannot communicate with PC2. When FW2 initiates access traffic, the traffic triggers the re-establishment of a SA. After a new SA is established, PC1 and PC2 can communicate with each other.

Procedure

1. Manually reset the SA on FW1.

   After the reset ike sa command is executed, both ends establish an IPSec tunnel.

2. Configure dead peer detection (DPD) for IKE peers.

   After the configuration, the IPSec tunnel is disconnected and then the SA is automatically cleared and SA negotiation is triggered again.

   DPD can be configured globally or on an IKE peer. DPD parameters configured on an IKE peer take precedence over those configured globally. When DPD parameters are not configured on an IKE peer, the global DPD parameters settings take effect.

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

   For example, you can configure DPD parameters carried in DPD packets in the system view, including setting the payload sequence to seq-hash-notify, detection mode to periodic, DPD idle time to 20s, DPD packet retransmission interval to 10s, and maximum number of DPD packet retransmissions to 4. Take the display on FW1 as an example.

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

Suggestion and Summary

The device supports two peer detection functions: heartbeat and DPD. You are advised to enable DPD.

Differences between heartbeat detection and DPD detection are as follows: During heartbeat detection, packets need to be sent periodically, and the local and remote configurations must match. During DPD detection, the local and remote configurations do not need to match (except that the sequence of the payload in DPD packets must be the same). When IKE peers exchange IPSec traffic normally, they do not send DPD packets. They send DPD packets only when one end cannot receive IPSec packets from the other end within a specified period, which saves CPU resources.

Symptom

In Figure 1-17, an L2TP over IPSec tunnel has been established between FWs, but PCs cannot communicate with each other.

Figure 1-17 IPSec networking

1. Run the display l2tp tunnel command on FW1, finding that an L2TP tunnel fails to be established.

   <FW1> display l2tp tunnel 
   L2TP::Total Tunnel: 0                                                            
                                                                                    
    LocalTID RemoteTID RemoteAddress    Port Sessions RemoteName  VpnInstance     
    ------------------------------------------------------------------------------  
    ------------------------------------------------------------------------------  
     Total 0, 0 printed 

2. Run the display ike sa command on FW1, finding that an IPSec SA fails to be established.

   <FW1> display ike sa 
   IKE SA information :                        
    Conn-ID    Peer           VPN             Flag(s)              Phase  
     ---------------------------------------------------------------------- 
                                                                    
    83891196 2.1.1.1:500                    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

3. Run the display ike error-info command on FW1, finding that the IKE negotiation failure reason is flow mismatch. This indicates that the security ACL configuration is incorrect.

   <FW1> 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     flow mismatch                    v2      2017-09-05 15:22:32 
     2.1.1.1           500     flow mismatch                    v2      2017-09-05 15:22:32 
   -----------------------------------------------------------------------------------------

Possible Causes

Before establishing an L2TP tunnel, you must establish an IPSec tunnel and perform L2TP encapsulation before IPSec encapsulation during packet forwarding.

The incorrect ACL configuration results in a failure to establish an IPSec tunnel and a failure to establish an L2TP tunnel.

Procedure

1. Run the display ipsec policy and display acl acl-number commands to check whether the security ACL configuration is correct.

   <FW1> display ipsec policy 
   =========================================== 
   IPSec policy group: "map1" 
   Using interface: GigabitEthernet0/0/1 
   =========================================== 
    
       Sequence number: 10 
       Policy Alias: map1-10 
       Security data flow: 3000 
   ...... 
    
   <FW1> display acl 3000 
   Advanced ACL 3000, 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.1.2.0 0.0.0.255 (0 ti 
   mes matched) 

   The configuration of FW2 is similar to that of FW1, and is not mentioned here.

   The preceding command output shows that the protected data flow is traffic destined for the destination network segments of PCs. According to L2TP over IPSec principles, after L2TP encapsulation is performed on the traffic, a new IP header is added to the traffic, which changes the original IP address. Therefore, the data flow protected by IPSec is not the traffic destined for the network segment addresses of PCs but the network segment address in the new IP header.

2. Change the security ACL configuration.

   FW1:

   acl number 3000 
    rule 5 permit ip source 1.1.1.0 0.0.0.255 destination 2.1.1.0 0.0.0.255

   FW2:

   acl number 3000 
    rule 5 permit ip source 2.1.1.0 0.0.0.255 destination 1.1.1.0 0.0.0.255

   After the change, the two FWs establish an IPSec tunnel and an L2TP tunnel. PCs can communicate with each other.

Suggestion and Summary

In L2TP over IPSec scenarios, IPSec negotiation must be performed first to establish IKE SAs and IPSec SAs, and then an L2TP tunnel needs to be established. L2TP encapsulation and then IPSec encapsulation are performed on packets transmitted over the L2TP tunnel. IPSec needs to protect the data flows sent from the source IP address to the destination IP address of an L2TP tunnel. The IP header added to packets during L2TP encapsulation are the source and destination IP addresses of the L2TP tunnel.

In L2TP over IPSec scenarios, if mobile users use devices with the Android 6.0 OS to establish IPSec tunnels with the firewall, only the SHA-1 authentication algorithm can be used. This is because the SHA2-256 algorithm of the Android 6.0 OS is implemented based on the draft, inconsistent with the RFC standard. If a mobile device uses SHA2-256 to establish an IPSec tunnel with the firewall, the two ends of the tunnel cannot properly communicate with each other.

Symptom

In Figure 1-18, PCs access the Internet after FWs perform NAT. IPSec is deployed between FWs, and traffic triggers negotiation to establish an IPSec tunnel. However, the PCs cannot communicate with each other.

Figure 1-18 IPSec networking

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

   <FW1> display ike sa

2. Run the display ipsec statistics command on FW1, finding that the outbound ok field displays 0. This indicates that IKE negotiation is not initiated.

   <FW1> 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

3. Find that there are reachable public and private routes and the IPSec configuration is correct.

Possible Causes

• The security ACL configuration does not match the IPSec-protected data flow.
• The NAT policy configuration affects the IPSec-protected data flow.

Procedure

1. Run the display ipsec policy and display acl acl-number commands to check whether the security ACL configuration matches the IPSec-protected data flow.

   <FW1> display ipsec policy 
   =========================================== 
   IPSec policy group: "map1" 
   Using interface: GigabitEthernet0/0/1 
   =========================================== 
    
       Sequence number: 10 
       Policy Alias: map1-10 
       Security data flow: 3000 
   ...... 
    
   <FW1> display acl 3000 
   Advanced ACL 3000, 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.1.2.0 0.0.0.255 (0 ti 
   mes matched) 
   <FW2> display ipsec policy 
   =========================================== 
   IPSec policy group: "map1" 
   Using interface: GigabitEthernet0/0/1 
   =========================================== 
    
       Sequence number: 10 
       Policy Alias: map1-10 
       Security data flow: 3000 
   ...... 
    
   <FW2> display acl 3000 
   Advanced ACL 3000, 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 ti 
   mes matched) 

   The preceding command output shows that the security ACL configuration matches the IPSec-protected data flow.

2. Run the display current-configuration configuration policy-nat command to check whether the NAT policy contains the IPSec-protected data flow.

   <FW1> display current-configuration configuration policy-nat 
    rule name policy_nat2                                                           
     source-zone trust                                                              
     destination-zone untrust                                                       
     source-address 10.1.1.0 0.0.0.255                                              
     action source-nat easy-ip 

   The configuration of FW2 is similar to that of FW1, and is not mentioned here.

   The preceding command output shows that the NAT policy contains the IPSec-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 flows requiring IPSec encapsulation. Take the display on FW1 as an example.

   [FW1] system-view 
   [FW1] nat-policy 
   [FW1-policy-nat] rule name policy_nat1 
   [FW1-policy-nat-rule-policy_nat1] source-zone trust 
   [FW1-policy-nat-rule-policy_nat1] destination-zone untrust 
   [FW1-policy-nat-rule-policy_nat1] source-address 10.1.1.0 0.0.0.255 
   [FW1-policy-nat-rule-policy_nat1] destination-address 10.1.2.0 0.0.0.255 
   [FW1-policy-nat-rule-policy_nat1] action no-nat 
   [FW1-policy-nat-rule-policy_nat1] quit 
   [FW1-policy-nat] rule move policy_nat2 after policy_nat1

   After a new NAT rule is configured, you need to run the rule move command to move this rule so that policy_nat1 takes effect first.

   After the change, the two FWs can establish an IPSec tunnel, and PCs can communicate with each other.

Suggestion and Summary

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

• 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.

If negotiation is automatically triggered to establish an IPSec tunnel, you can see that an IPSec tunnel has been established using the display ike sa command, but PCs cannot communicate with each other.

Symptom

In Figure 1-19, after IPSec is deployed between FWs, PCs cannot communicate with each other.

Figure 1-19 IPSec networking

1. Run the display ike sa command on FW1, finding that IKE SA negotiation succeeds but IPSec SA negotiation fails. This indicates that an IPSec tunnel fails to be established.

   <FW1> display ike sa 
   IKE SA information : 
    Conn-ID    Peer             VPN              Flag(s)     Phase      
     --------------------------------------------------------------- 
    151003222  2.1.1.1:500                       NEG|A       v1:2  
    151003215  2.1.1.1:500                       RD|A        v1: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 

2. Run the display ike error-info command on FW1, finding that the IKE negotiation failure reason is flow mismatch. This indicates that ACL rule ranges on both ends do not match.

   <FW1> 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     flow or peer mismatch            v2      2017-09-05 15:22:32 
     2.1.1.1           500     flow or peer mismatch            v2      2017-09-05 15:22:32 
   -----------------------------------------------------------------------------------------

Possible Causes

ACL rule ranges on both ends do not match.

Procedure

1. Run the display ipsec policy and display acl acl-number commands to check whether security ACL rule ranges on both ends match.

   <FW1> display ipsec policy 
   =========================================== 
   IPSec policy group: "map1" 
   Using interface: GigabitEthernet0/0/1 
   =========================================== 
    
       Sequence number: 10 
       Policy Alias: map1-10 
       Security data flow: 3000 
   ...... 
    
   <FW1> display acl 3000 
   Advanced ACL 3000, 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.2.0 0.0.0.255 (0 ti 
   mes matched) 
   <FW2> display ipsec policy 
   =========================================== 
   IPSec policy group: "map1" 
   Using interface: GigabitEthernet0/0/1 
   =========================================== 
    
       Sequence number: 10 
       Policy Alias: map1-10 
       Security data flow: 3000 
   ...... 
    
   <FW2> display acl 3000 
   Advanced ACL 3000, 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 ti 
   mes matched) 

   The preceding command output shows that security ACL rule ranges on both ends do not match.

   For IKEv1, if an IPSec policy in ISAKMP mode is configured on both ends, the ACL rule range configured at the initiator must be included in that at the responder. 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.

2. Change the security ACL rule range.

   According to the networking, find that the security ACL rule range configured on FW1 is incorrect.

   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

   After the change, the two FWs can establish an IPSec tunnel, and PCs can communicate with each other.

Suggestion and Summary

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, a SA can be successfully established after any party initiates negotiation. If ACL rules on both ends do not mirror each other, a 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 or there is an overlapping address range between the two ACL rules. 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:
  • For IKEv1, mirroring is not necessary. SAs can be set up successfully as long as the address range defined in the ACL rule of the initiator is included in that of the responder. Both ends use the overlapping ACL rule range as the negotiation result.
  • For IKEv2, mirroring is not necessary as long as there is an overlapping ACL rule range between ACL rules on both ends. Both ends use the overlapping ACL rule range 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.

Symptom

In Figure 1-20, a NAT device is deployed between FWs. FW1 is connected to FW2 after NAT is performed. After IPSec is deployed, PCs cannot communicate with each other.

Figure 1-20 IPSec networking

1. Run the display ike sa command on FW2, finding that no information is displayed. This indicates that no IPSec tunnel has been established.

   <FW2> display ike sa

2. Run the display ike error-info command on FW2 to check the IKE negotiation failure reason.

   <FW2> display ike error-info 
     current info Num :3 
     Ike error information: 
     current ike Error-info number :3 
   ----------------------------------------------------------------------------------------- 
     peer              port    error-reason                     version error-time 
   ----------------------------------------------------------------------------------------- 
     1.1.1.1           2049    authentication fail               v2      2017-09-05 15:22:32 
     1.1.1.1           2049    config ID mismatch                v2      2017-09-05 15:22:32 
     10.4.1.1          2049    peer address mismatch             v2      2017-09-05 15:22:32 
   -----------------------------------------------------------------------------------------

   If the IKE negotiation failure reason is authentication fail or config ID mismatch, FW2 fails to verify the ID information sent by FW1.

   Additionally, the IKE negotiation failure reason is peer address mismatch and peer is 10.4.1.1. This indicates that the ID carried by FW1 is a private IP address 10.4.1.1. As a result, the IKE negotiated address 1.1.1.1 is inconsistent with the authenticated address 10.4.1.1, causing a failure to establish an IPSec tunnel.

Possible Causes

The IKE negotiated address is inconsistent with the authenticated address.

Procedure

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

   <FW1> display ike peer 
   Number of IKE peers: 1 
    
   ----------------------------------------------------------- 
    Peer name                               : spr 
    IKE version                             : v1v2 
    VPN instance                            : - 
    Remote IP                               : 2.1.1.1 
    Authentic IP address                    : - 
    Proposal                                : 10 
    Pre-shared-key                          : %^%#VGKG:L@YD(|F>VCrTw2W"Qx<&;6dU2(`ZP9!B"HT%^%# 
    Local ID type                           : IP 
   ......
   <FW1> display ike peer 
   Number of IKE peers: 1 
    
   ----------------------------------------------------------- 
    Peer name                               : spr 
    IKE version                             : v1v2 
    VPN instance                            : - 
    Remote IP                               : 1.1.1.1 
    Authentic IP address                    : - 
    Proposal                                : 10 
    Pre-shared-key                          : %^%#VGKG:L@YD(|F>VCrTw2W"Qx<&;6dU2(`ZP9!B"HT%^%# 
    Local ID type                           : IP 
   ......

   The preceding command output indicates that IKE peer IP addresses on both ends match. This is because the negotiated address of FW1 deployed behind the NAT device changes from 10.4.1.1 to 1.1.1.1 during IKE negotiation.

   However, the IKE negotiation failure reason indicates that the IKE negotiated address is inconsistent with the authenticated address. Check the IPSec configurations on both ends, finding that both devices are using IPSec policies in ISAKMP mode. You need to run the remote-address authentication-address command on FW2 to configure an authenticated address. FW1 is deployed behind the NAT device and initiates an IKE negotiation packet carrying its ID information (private IP address) to FW2 when FW1 and FW2 use IP addresses for authentication. FW2 then compares the received ID information with the configured remote-address and finds that the two addresses are inconsistent. As a result, the IP address authentication fails.

2. Run the remote-address authentication-address command on FW2 to configure an authenticated address.

   ike peer spr 
    remote-address authentication-address 10.4.1.1 10.4.1.255

   After the configuration, the two FWs establish an IPSec tunnel successfully, and PCs can communicate with each other.

Suggestion and Summary

When two devices establish an IPSec tunnel through IKEv2 negotiation, one device uses an intranet IP address, and a NAT device is deployed between the two devices, pay attention to the following if the two devices use IPSec policies in ISAKMP mode:

• You need to run the remote-address ip-address command on the local end to set the specified remote IP address as the post-NAT IP address.
• Run the remote-address authentication-address command on the local end to set the pre-NAT IP address as the remote authenticated address.

In this scenario, it is recommended that the local end use an IPSec policy configured using an IPSec policy template. This is because you do not need to run the remote-address ip-address command to specify the remote address in the IPSec policy template.

Symptom

In Figure 1-21, after IPSec is deployed between FWs, PCs cannot communicate with each other.

Figure 1-21 IPSec networking

1. Run the display ike sa command on FW1, finding that an IPSec tunnel has been established.

   <FW1> display ike sa 
   IKE SA information : 
    Conn-ID    Peer             VPN              Flag(s)     Phase      
    --------------------------------------------------------------- 
    151003222  2.1.1.1:500                       RD|ST|A     v1:2  
    151003215  2.1.1.1:500                       RD|ST|A     v1: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 

2. Run the display ipsec statistics command on FW1, finding that received IPSec packets are dropped and the reason is authentication. This indicates that IPSec packet authentication fails.

   <FW1> display ipsec statistics 
    IPSec statistics information:                                                   
    Number of IPSec tunnels: 1                                                      
    the security packet statistics:                                                 
    input/output security packets: 5/0                                            
    input/output security bytes: 0/0                                              
    input/output dropped security packets: 5/0                                    
   ...... 
    dropped security packet detail:                                               
        can not find SA: 0, wrong SA: 0                                             
        authentication: 5, replay: 0                                                
        front recheck: 0, after recheck: 0                                          
   ......

Possible Causes

Encryption/decryption modes of SHA2-384 or SHA2-512 authentication algorithms on both ends are inconsistent.

Procedure

1. Run the display ipsec proposal command to check whether the authentication algorithm used in the IPSec proposal is SHA2-384 or SHA2-512.

   <FW1> 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 configuration of FW2 is similar to that of FW1, and is not mentioned here.

   The preceding command output shows that the authentication algorithm used in the IPSec proposal is SHA2-512.

2. Change the encryption/decryption mode of the SHA2-512 authentication algorithm.

   You can run the ipsec sha2 compatible enable or undo ipsec sha2 compatible enable command as required to ensure that encryption/decryption modes of SHA2-512 authentication algorithms on both ends are inconsistent.

   The following example runs the undo ipsec sha2 compatible enable command on FW1 to ensure that the encryption/decryption mode of SHA2-512 authentication algorithm on FW1 is consistent with that on FW2.

   [FW1] system-view 
   [FW1] undo ipsec sha2 compatible enable

   After the change, PCs can communicate with each other.

Suggestion and Summary

When the authentication algorithm used in an IPSec proposal is specified as SHA2-384 or SHA2-512 on both ends, 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 sha2 compatible enable or undo ipsec sha2 compatible enable command.

When the FW is connected to an AR router and IPSec uses the SHA2-256 algorithm, IPSec packets will be discarded if the encryption/decryption modes on the two ends are different. In this case, run the ipsec authentication sha2 compatible enable command on the AR router to change the SHA-2 encryption/decryption modes on two ends to be the same.

Symptom

In Figure 1-22, multiple branches are connected to FW1 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 FW3 cannot communicate with the headquarters.

Figure 1-22 IPSec networking

Run the display ike sa command on FW3, finding that an IPSec tunnel has been established.

<FW3> display ike sa
IKE SA information : 
 Conn-ID    Peer             VPN              Flag(s)     Phase
 --------------------------------------------------------------- 
 151003222  1.1.3.1:500                       RD|ST|A     v1:2  
 151003215  1.1.3.1:500                       RD|ST|A     v1: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 

Possible Causes

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.

Procedure

1. Run the display ipsec sa command to check whether the protected data flows negotiated based on the security ACL conflict.

   Check whether the protected data flows negotiated based on the security ACL configured on FW1 conflict.

   <FW1> 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 preceding 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 FW1. 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 change, PC3 can communicate with PC1 in the headquarters.

Suggestion and Summary

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 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.

Symptom

In Figure 1-23, a NAT device exists between two FWs, and FW1 communicates with FW2 after NAT is performed. After IPSec is deployed, PCs cannot communicate with each other normally.

Figure 1-23 IPSec networking

1. Run the display ike sa command on FW1, finding that an IPSec tunnel has been established.

   <FW1> display ike sa 
   IKE SA information : 
    Conn-ID    Peer             VPN              Flag(s)     Phase      
     --------------------------------------------------------------- 
    151003222  2.1.1.1:500                       RD|ST|A     v1:2  
    151003215  2.1.1.1:500                       RD|ST|A     v1: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

2. Check that the routing and IPSec configurations are correct.

Possible Causes

• The NAT policy configuration affects the IPSec-protected data flow.
• Security ACL configurations on both ends are incorrect.
• NAT traversal is disabled.

Procedure

1. Check whether the NAT policy configuration affects the IPSec-protected data flow.

   Check the NAT configuration, finding that the NAT policy configuration does not affect the IPSec-protected data flow.

2. Run the display ipsec sa and display acl acl-number commands to check the source and destination network segments of the protected data flow negotiated by the security ACL contain real service flows.

   FW2 uses an IPSec policy configured using an IPSec policy template, does not have an ACL configured, and accepts the protected data flow range defined on FW1. Therefore, you only need to check the security ACL of FW1.

   <FW1> display ipsec sa 
   ipsec sa information:  
   ===============================                                                  
   Interface: GigabitEthernet0/0/2                                                 
   ===============================                                                  
    -----------------------------                                                  
     IPSec policy name: "map1"                                                       
     Sequence number  : 1                                                           
     Acl group        : 3101 
     Acl rule         : 5                                                           
     Mode             : ISAKMP  
     -----------------------------                                                  
       Connection ID     : 67108879                                                 
       Encapsulation mode: Tunnel 
       Holding time      : 0d 0h 4m 29s 
       Tunnel local      : 10.4.1.1:500 
       Tunnel remote     : 2.1.1.1:500 
       Flow source       : 10.1.1.0/255.255.255.0 0/0  
       Flow destination  : 10.1.2.0/255.255.255.0 0/0  
       Flow dscp         : -  
                                                                                    
       [Outbound ESP SAs]                                                           
         SPI: 4055669516 (0xf1bc9b0c)                                               
         Proposal: ESP-ENCRYPT-3DES-192 SHA2-256-128                                 
         SA remaining key duration (kilobytes/sec): 1840323/2420                    
         Max sent sequence-number: 0 
         UDP encapsulation used for NAT traversal: N                                
         SA encrypted packets (number/kilobytes): 2376/2877                         
                                                                                    
       [Inbound ESP SAs]                                                            
         SPI: 1050491168 (0x3e9d3920)                                               
         Proposal: ESP-ENCRYPT-3DES-192 SHA2-256-128                                
         SA remaining key duration (kilobytes/sec): 1840323/2420                    
         Max received sequence-number: 0 
         UDP encapsulation used for NAT traversal: N                                
         SA decrypted packets (number/kilobytes): 2376/2877                         
         Anti-replay : Enable                                                       
         Anti-replay window size: 1024  
   <FW1> 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 (1 matches)

   The preceding command output shows that the security ACL configuration of FW1 is correct.

3. Run the display ipsec sa command to check whether NAT traversal is enabled.

   <FW1> display ipsec sa 
   ipsec sa information:  
   ===============================                                                  
   Interface: GigabitEthernet0/0/2                                                 
   ===============================                                                  
    -----------------------------                                                  
     IPSec policy name: "map1"                                                       
     Sequence number  : 1                                                           
     Acl group        : 3101 
     Acl rule         : 5                                                           
     Mode             : ISAKMP  
     -----------------------------                                                  
       Connection ID     : 67108879                                                 
       Encapsulation mode: Tunnel 
       Holding time      : 0d 0h 4m 29s 
       Tunnel local      : 10.4.1.1:500 
       Tunnel remote     : 2.1.1.1:500 
       Flow source       : 10.1.1.0/255.255.255.0 0/0  
       Flow destination  : 10.1.2.0/255.255.255.0 0/0  
       Flow dscp         : -  
                                                                                    
       [Outbound ESP SAs]                                                           
         SPI: 4055669516 (0xf1bc9b0c)                                               
         Proposal: ESP-ENCRYPT-3DES-192 SHA2-256-128                                 
         SA remaining key duration (kilobytes/sec): 1840323/2420                    
         Max sent sequence-number: 0 
         UDP encapsulation used for NAT traversal: N 
         SA encrypted packets (number/kilobytes): 2376/2877                         
                                                                                    
       [Inbound ESP SAs]                                                            
         SPI: 1050491168 (0x3e9d3920)                                               
         Proposal: ESP-ENCRYPT-3DES-192 SHA2-256-128                                
         SA remaining key duration (kilobytes/sec): 1840323/2420                    
         Max received sequence-number: 0 
         UDP encapsulation used for NAT traversal: N                                
         SA decrypted packets (number/kilobytes): 2376/2877                         
         Anti-replay : Enable                                                       
         Anti-replay window size: 1024  

   The preceding command output shows that NAT traversal is disabled on both ends. As a result, IPSec packets passing through the intermediate network are discarded or the NAT device deletes this NAT session entry. This makes the peer at the Internet side of the NAT device unable to transmit the packets.

4. Enable NAT traversal on both ends.

   ike peer spub 
    nat traversal

   After the configuration, PCs can communicate with each other normally.

Suggestion and Summary

If a branch connects to the headquarters through a NAT device, and the headquarters uses an IPSec policy configured using an IPSec policy template, the remote IP address does not need to be specified.

During the NAT traversal configuration, an IPSec proposal can use only the ESP protocol. AH authenticates the entire IP packet. Any modification in the IP header causes an AH check failure. Therefore, NAT traversal cannot be implemented on an IPSec tunnel protected by AH.

Symptom

In Figure 1-24, an IPSec tunnel has been established between FWs. After a NAT server and a source NAT policy are deployed on FW2, PC1 can ping PC2 successfully, but PC2 cannot ping PC1.

Figure 1-24 IPSec networking

1. Run the display ike sa command on FW1, finding that an IPSec tunnel has been established.

   <FW1> display ike sa 
   IKE SA information : 
    Conn-ID    Peer             VPN              Flag(s)     Phase      
     --------------------------------------------------------------- 
    151003222  2.1.1.1:500                       RD|ST|A     v1:2  
    151003215  2.1.1.1:500                       RD|ST|A     v1: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 

2. Check the IPSec configurations on both ends, finding that the configurations are correct. PC1 can ping PC2 successfully, indicating that the link is normal.

Possible Causes

• The source NAT policy does not deny the protected data flow.
• The protected data flow matches the reverse session of a NAT server.

Procedure

1. Run the display firewall session table command to check whether IP addresses in sessions on FW2 are translated by NAT.

   When PC2 pings PC1, run the display firewall session table command on FW2 to check whether the source IP address is translated by NAT.

   <FW2> display firewall session table 
    Current Total Sessions : 3                                                      
    telnet  VPN: public --> public  10.135.21.61:59128 --> 192.168.50.180:23        
    esp  VPN: public --> public  1.1.1.1:0 --> 2.1.1.1:0                            
    icmp  VPN: public --> public  10.1.2.2:44020[2.1.1.10:44020] --> 10.1.10.1:2048

   When PC2 pings PC1, the IP address 10.1.2.2 is translated to a public IP address 2.1.1.10. As a result, PC2 cannot ping PC1.

2. Run the display current-configuration configuration policy-nat command to check whether the source NAT policy contains the protected data flow.

   <FW2> display current-configuration configuration policy-nat 
   nat-policy                                                                       
    rule name policy_nat1                                                           
     source-zone trust                                                              
     destination-zone untrust                                                       
     source-address 10.1.2.0 0.0.0.255                                              
     destination-address 10.1.1.0 0.0.0.255                                         
     action no-nat                                                                  
    rule name policy_nat2 
     source-zone trust  
     destination-zone untrust 
     source-address 10.1.2.0 0.0.0.255 
     action source-nat address-group addressgroup1

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

3. Run the display firewall server-map command to check whether the source IP address of the protected data flow is translated by NAT.

   <FW2> display firewall server-map 
    Current Total Server-map : 2                                                    
    Type: Nat Server,  ANY -> 2.1.1.10:3389[10.1.2.2:3389],  Zone:---,  protocol:tcp 
    Vpn: public -> public                                                           
                                                                                    
    Type: Nat Server Reverse,  10.1.2.2[2.1.1.10] -> ANY,  Zone:---,  protocol:tcp 
    Vpn: public -> public,  counter: 1

   The preceding command output shows that the IP address 10.1.2.2 is translated to 2.1.1.10. Although the protected data flow has been denied in the source NAT policy, the NAT server policy takes precedence over the source NAT policy. Therefore, a private IP address is translated to a public network IP address, causing PC2 unable to ping PC1.

4. Disable the NAT server reverse session function.

   <FW2> system-view  
   [FW2] nat server 0 protocol tcp global 2.1.1.10 3389 inside 10.1.2.2 3389 no-reverse

   After the configuration, PC2 can ping PC1 successfully.

Suggestion and Summary

After the NAT server is deployed, if the no-reverse parameter is not specified and a user accesses a server, the device translates the server's public IP address to a private IP address. When a server accesses the public network, the device translates the server's private IP address to a public IP address. If the no-reverse parameter is specified, the device translates public IP addresses to private IP addresses and does not translate private IP addresses to public IP addresses. When a server accesses the public network, outbound NAT policy must be performed, and the referenced address pool must contain public IP addresses configured on the NAT server. Otherwise, the IP address reversely translated by NAT is inconsistent with the accessed public IP address, causing a network connection failure.

Symptom

In Figure 1-25, an IPSec tunnel has been established between FWs, but PCs cannot communicate with each other.

Figure 1-25 IPSec networking

1. Run the display ike sa command on FW1, finding that an IPSec tunnel has been established.

   <FW1> display ike sa 
   IKE SA information : 
    Conn-ID    Peer             VPN              Flag(s)     Phase      
     --------------------------------------------------------------- 
    151003222  2.1.1.1:500                       RD|ST|A     v1:2  
    151003215  2.1.1.1:500                       RD|ST|A     v1: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 

2. Find that no NAT policy affects the IPSec-protected data flow and the security ACL rule configuration is correct.

Possible Causes

Security policies do not permit private network traffic.

Procedure

1. Run the display current-configuration configuration policy-security command to check the interzone configuration. Ensure that the IPSec-protected data flow can be transmitted from a trust zone to an untrust zone.

   <FW1> display current-configuration configuration policy-security 
   security-policy  
    default action deny  
    rule name policy3                                                               
     source-zone local                                                              
     destination-zone untrust                                                       
     source-address 1.1.1.1 mask 255.255.255.255                                    
     destination-address 2.1.1.1 mask 255.255.255.255                               
     action permit                                                                  
    rule name policy4                                                               
     source-zone untrust                                                            
     destination-zone local                                                         
     source-address 2.1.1.1 mask 255.255.255.255                                    
     destination-address 1.1.1.1 mask 255.255.255.255                               
     action permit

   The preceding command output shows that not all traffic is permitted by default and the security policy permits public network traffic but denies private network traffic. The configuration of FW2 is similar to that of FW1, and is not mentioned here.

2. Change the security policy to permit private network traffic.

   Change the security policy on FW1.

   security-policy 
    rule name policy1                                                               
     source-zone trust                                                              
     destination-zone untrust                                                       
     source-address 10.1.1.0 mask 255.255.255.0                                     
     destination-address 10.1.2.0 mask 255.255.255.0                                
     action permit 
    rule name policy2                                                               
     source-zone untrust                                                            
     destination-zone trust                                                         
     source-address 10.1.2.0 mask 255.255.255.0                                     
     destination-address 10.1.1.0 mask 255.255.255.0                                
     action permit

   The configuration of FW2 is similar to that of FW1, and is not mentioned here.

   After the configuration, PCs can communicate with each other.

Suggestion and Summary

When deploying services, ensure that security policies permit service flows. That is, ensure that data flows can be transmitted from a trust zone to an untrust zone.

Symptom

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

Figure 1-26 IPSec networking

1. Run the display ike sa command on FW1, finding that an IPSec tunnel has been established.

   <FW1> display ike sa 
   IKE SA information : 
    Conn-ID    Peer             VPN              Flag(s)     Phase      
     --------------------------------------------------------------- 
    151003222  2.1.1.1:500                       RD|ST|A     v1:2  
    151003215  2.1.1.1:500                       RD|ST|A     v1: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

2. Run the ping command on FW1, finding that the private network route to the remote end is unreachable.

   <FW1> ping 10.1.1.2 
     PING 10.1.1.2: 56  data bytes, press CTRL_C to break                           
       Reply from 10.1.1.2: bytes=56 Sequence=1 ttl=255 time=1 ms                   
       Reply from 10.1.1.2: bytes=56 Sequence=2 ttl=255 time=1 ms                   
       Reply from 10.1.1.2: bytes=56 Sequence=3 ttl=255 time=1 ms                   
       Reply from 10.1.1.2: bytes=56 Sequence=4 ttl=255 time=1 ms                   
       Reply from 10.1.1.2: bytes=56 Sequence=5 ttl=255 time=1 ms                   
                                                                                    
     --- 10.1.1.2 ping statistics ---                                               
       5 packet(s) transmitted                                                      
       5 packet(s) received                                                         
       0.00% packet loss                                                            
       round-trip min/avg/max = 1/1/1 ms 
   <FW1> ping 10.1.2.2 
     PING 10.1.2.2: 56  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    

Possible Causes

The private network route from FW1 to FW2 is unreachable.

Procedure

1. Run the display ip routing-table command to check the IP routing table of FW1.

   <FW1> display ip routing-table 
   Route Flags: R - relay, D - download to fib                                      
   ------------------------------------------------------------------------------ 
   Routing Tables: Public                                                           
            Destinations : 15       Routes : 15                                     
                                                                                    
   Destination/Mask    Proto Pre  Cost      Flags NextHop         Interface       
                                                                                    
           0.0.0.0/0 Unr     70 0           D 192.168.1.1     GigabitEthernet1/0/7 
           1.1.1.0/24  Direct  0    0           D 1.1.1.1         GigabitEthernet1/0/1 
           1.1.1.1/32  Direct  0    0           D 127.0.0.1       GigabitEthernet1/0/1  
           2.1.1.0/24  Static  60 0          RD 1.1.1.2         GigabitEthernet1/0/1 
        10.128.0.0/10  Static  60 0          RD 192.168.50.1    GigabitEthernet1/0/5 
         127.0.0.0/8 Direct  0    0           D 127.0.0.1       InLoopBack0     
         127.0.0.1/32  Direct  0    0           D 127.0.0.1       InLoopBack0     
       192.168.1.0/24  Direct  0    0           D 192.168.1.2     GigabitEthernet1/0/7 
       192.168.1.2/32  Direct  0    0           D 127.0.0.1       GigabitEthernet1/0/7 
   ......

   The preceding command output shows that FW1 does not have a private network route to FW2.

2. On FW1, configure a private network route to FW2.

   ip route-static 10.1.2.0 255.255.255.0 1.1.1.2

   After the configuration, PCs can communicate with each other.

Suggestion and Summary

If an IPSec tunnel has been established between services are interrupted, check whether a routing failure occurs. If the local device does not have any route to the private network segment of the remote device, the local device discards packets.

Symptom

In Figure 1-27, FW1 is connected to two service providers through two outbound interfaces. GE0/0/2 of FW1 establishes an IPSec tunnel with FW2. After the IPSec tunnel is established, services are interrupted.

Figure 1-27 IPSec networking

1. Run the display ike sa command on FW1, finding that an IPSec tunnel has been established.

   <FW1> display ike sa 
   IKE SA information :   
      Conn-ID    Peer             VPN              Flag(s)     Phase      
     --------------------------------------------------------------- 
      151003222  2.1.1.1:500                       RD|ST|A     v1:2  
      151003215  2.1.1.1:500                       RD|ST|A     v1: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

2. Run the ping -a 10.1.1.1 10.1.2.2 command on FW1, finding that the ping fails. Check whether the IPSec configuration and security ACL are correct, finding that they are correct.

   <FW1> ping -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     

Possible Causes

Route configurations are incorrect.

Procedure

1. Run the display ipsec sa command to check whether there are encrypted or decrypted packets in the inbound or outbound SA.

   <FW1> display ipsec sa 
   ipsec sa information: 
    
   =============================== 
   Interface: GigabitEthernet0/0/2 
   =============================== 
    
     ----------------------------- 
     IPSec policy name: "test" 
     Sequence number  : 1 
     Acl group        : 3011 
     Acl rule         : 5 
     Mode             : ISAKMP 
     ----------------------------- 
       Connection ID     : 67109470 
       Encapsulation mode: Tunnel 
       Holding time      : 20d 5h 6m 38s 
       Tunnel local      : 1.1.1.1:500 
       Tunnel remote     : 2.1.1.1:500 
       Flow source       : 10.1.1.2/255.255.255.255 0/0 
       Flow destination  : 10.1.2.2/255.255.255.255 0/0 
    
       [Outbound ESP SAs] 
         SPI: 185226861 (0xb0a566d) 
         Proposal: ESP-ENCRYPT-AES-256 ESP-AUTH-SHA2-256-128 
         SA remaining key duration (kilobytes/sec): 20971520/2727 
         Max sent sequence-number: 8 
         UDP encapsulation used for NAT traversal: N 
         SA encrypted packets (number/bytes): 7/588 //There are encrypted packets, indicating that the packets are IPSec-encrypted packets. 
    
       [Inbound ESP SAs] 
         SPI: 196011195 (0xbaee4bb) 
         Proposal: ESP-ENCRYPT-AES-256 ESP-AUTH-SHA2-256-128 
         SA remaining key duration (kilobytes/sec): 20971520/2727 
         Max received sequence-number: 1 
         UDP encapsulation used for NAT traversal: N 
         SA decrypted packets (number/bytes): 0/0    
         Anti-replay : Enable 
         Anti-replay window size: 1024     
   <FW2> display ipsec sa 
   ipsec sa information: 
    
   =============================== 
   Interface: GigabitEthernet0/0/2 
   =============================== 
    
     ----------------------------- 
     IPSec policy name: "test-1" 
     Sequence number  : 1 
     Acl group        : 3011 
     Acl rule         : 5 
     Mode             : ISAKMP 
     ----------------------------- 
       Connection ID     : 50332732 
     Encapsulation mode: Tunnel 
       Holding time      : 20d 5h 17m 34s 
       Tunnel local      : 2.1.1.1:500 
       Tunnel remote     : 1.1.1.1:500 
       Flow source       : 10.1.2.2/255.255.255.255 0/0 
       Flow destination  : 10.1.1.2/255.255.255.255 0/0 
    
       [Outbound ESP SAs] 
         SPI: 196011195 (0xbaee4bb) 
         Proposal: ESP-ENCRYPT-AES-256 ESP-AUTH-SHA2-256-128 
         SA remaining key duration (kilobytes/sec): 20971520/2066 
         Max sent sequence-number: 1 
         UDP encapsulation used for NAT traversal: N 
         SA encrypted packets (number/bytes): 0/0 
    
       [Inbound ESP SAs] 
         SPI: 185226861 (0xb0a566d) 
         Proposal: ESP-ENCRYPT-AES-256 ESP-AUTH-SHA2-256-128 
         SA remaining key duration (kilobytes/sec): 20971520/2066 
         Max received sequence-number: 1 
         UDP encapsulation used for NAT traversal: N 
         SA decrypted packets (number/bytes): 0/0 //IPSec packets that fail to be decrypted.
         Anti-replay : Enable 
         Anti-replay window size: 1024

   The command output shows that packets of FW1 are IPSec protected, but FW2 does not receive IPSec packets. The possible causes are:

   • FW1 did not send IPSec packets.
   • FW1 sent IPSec packets but these packets were dropped on the intermediate networks.

2. Obtain packet information on GE0/0/2 of FW1 to check whether IPSec packets have been sent.

   <FW1> system-view 
   [FW1] acl 3100 
   [FW1-acl-adv-3100] acl 3100 
   [FW1-acl-adv-3100] rule 5 permit ip source 1.1.1.1 0 destination 2.1.1.1 0  
   [FW1-acl-adv-3100] rule 5 permit ip source 2.1.1.1 0 destination 1.1.1.1 0  
   [FW1-acl-adv-3100] quit 
   [FW1] packet-capture ipv4-packet 3100 interface GigabitEthernet 0/0/2 
   [FW1] packet-capture startup packet-num 1500 
   [FW1] packet-capture queue 0 to-file 1.cap

   The obtained packet information indicates that GE0/0/2 did not send IPSec packets. Obtain packet information on GE0/0/3, finding that IPSec packets were sent from GE0/0/3. The two interfaces are connected two different service providers. Therefore, ISP1 cannot identify IPSec packets of ISP2 and dropped IPSec packets.

   Check routing information, finding two equal-cost routes.

   ip route-static 0.0.0.0 0.0.0.0 GigabitEthernet0/0/2 1.1.1.2 track ip-link isp2 
   ip route-static 0.0.0.0 0.0.0.0 GigabitEthernet0/0/3 1.2.1.2 track ip-link isp1     

3. Configure a static route on FW1 and specify the next-hop address 1.1.1.2 for the route 2.1.1.1.

   [FW1] ip route-static 2.1.1.0 24 1.1.1.2

   After the preceding configuration is complete, PCs can ping each other successfully, indicating that services on both ends are forwarded normally.

Suggestion and Summary

• If IPSec traffic is interrupted, check routing information to determine whether routes and outbound interfaces are correct.
• When two outbound interfaces exist, you are advised to specify a certain route during static route configuration and not to use two equal-cost default routes.

Symptom

In Figure 1-28, an IPSec tunnel has been established between FWs. When the PC downloads resources from the file server, services are interrupted.

Figure 1-28 IPSec networking

1. Run the display ike sa command on FW1, finding that an IPSec tunnel has been established.

   <FW1> display ike sa 
   IKE SA information : 
    Conn-ID    Peer             VPN              Flag(s)     Phase      
     --------------------------------------------------------------- 
    151003222  2.1.1.1:500                       RD|ST|A     v1:2  
    151003215  2.1.1.1:500                       RD|ST|A     v1: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 

2. Run the display ike offline-info command on FW1, finding that no information is displayed. This indicates that the IPSec tunnel is not interrupted unexpectedly.

   <FW1> display ike offline-info

3. The PC can ping the Server successfully, indicating that the link is normal and ACL configuration is correct.

Possible Causes

The TCP MSS is incorrect.

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.

   <FW1> 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 
    
   <FW1> 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 preceding 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.

   The file server access service of the PC 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, so services are interrupted when the PC downloads resources from the file server.

2. Change the TCP MSS.

   <FW1> system-view 
   [FW1] firewall tcp-mss 1200

   After the change, the PC can download resources from the file server.

Suggestion and Summary

• 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 fragmented packets cannot be processed in the network where a FW resides, reduce the TCP MSS to prevent packets from being fragmented.

Symptom

In Figure 1-29, PCs access the Internet through FWs. IPSec is deployed between FWs, and they establish an IPSec tunnel in auto-negotiation mode. However, the PCs cannot communicate with each other.

Figure 1-29 IPSec networking

1. Run the display ike sa command on FW2, finding that an IPSec tunnel has been established successfully and the UDP port number is not 500 but 2049. This indicates that NAT has been performed on IPSec negotiation packets.

   <FW2> display ike sa 
   IKE SA information : 
    Conn-ID    Peer             VPN              Flag(s)     Phase      
     --------------------------------------------------------------- 
    151003222  1.1.1.1:2049                      RD|ST|A     v1:2  
    151003215  1.1.1.1:2049                      RD|ST|A     v1: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

2. Run the ping -a 10.1.2.1 10.1.1.2 command on FW2, finding that the ping fails. Run the display ike sa command, finding that the IPSec tunnel fails to be established.

   <FW2> ping -a 10.1.2.1 10.1.1.2 
     PING 10.1.1.2: 56  data bytes, press CTRL+C to break 
       Request time out 
       Request time out 
       Request time out 
       Request time out 
       Request time out 
    
     --- 10.1.1.2 ping statistics --- 
       5 packet(s) transmitted 
       0 packet(s) received 
   100.00% packet loss     
   <FW2> display ike sa 
   IKE SA information : 
    Conn-ID    Peer             VPN              Flag(s)     Phase 
     --------------------------------------------------------------- 
    151003215  1.1.1.1:500                      NEG|A       v1: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

3. Run the display ike offline-info command on FW1, finding that the IPSec tunnel Down reason is port mismatch after inbound sa miss. This indicates that the UDP port number of received packets is inconsistent with that of the inbound SA.

   <FW2> display ike offline-info 
     Current info Num :1 
     Ike offline information: 
   ----------------------------------------------------------------------------- 
     peer        offline-reason                         version offline-time 
   ----------------------------------------------------------------------------- 
     1.1.1.1     port mismatch after inbound sa miss    v1        2018-03-23 17:30:17

Possible Causes

NAT has been performed on IPSec negotiation packets, and the UDP port number has been changed to 2049. After an IPSec tunnel is set up, however, the UDP port number of IPSec service packets is 500, which is different from the UDP port number of the inbound SA. Therefore, the IPSec tunnel becomes Down.

Procedure

1. Run the display current-configuration configuration policy-nat command on FW1 to check whether the NAT policy contains the IPSec-protected data flow.

   <FW1> display current-configuration configuration policy-nat 
    rule name policy_nat2  
     destination-zone untrust 
     action source-nat easy-ip

   The preceding command output shows that NAT is performed on all packets destined for the untrust zone. NAT is also performed on IPSec negotiation packets; however, NAT needs to be performed only on the packets sent from a private network to the Internet. Therefore, the NAT policy is configured incorrectly.

2. Modify the NAT policy on FW1 to ensure that NAT is performed only on the packets sent from the private network to the Internet.

   [FW1] system-view 
   [FW1] nat-policy 
   [FW1-policy-nat] rule name policy_nat2 
   [FW1-policy-nat-rule-policy_nat2] source-zone trust 
   [FW1-policy-nat] rule name policy_nat1 
   [FW1-policy-nat-rule-policy_nat1] source-zone trust 
   [FW1-policy-nat-rule-policy_nat1] destination-zone untrust 
   [FW1-policy-nat-rule-policy_nat1] source-address 10.1.1.0 0.0.0.255 
   [FW1-policy-nat-rule-policy_nat1] destination-address 10.1.2.0 0.0.0.255 
   [FW1-policy-nat-rule-policy_nat1] action no-nat 
   [FW1-policy-nat-rule-policy_nat1] quit 
   [FW1-policy-nat] rule move policy_nat2 after policy_nat1

   After a new NAT rule is configured, you need to run the rule move command to move this rule so that policy_nat1 takes effect first.

   After the modification, the two FWs establish an IPSec tunnel successfully, and the PCs can communicate with each other.

Suggestion and Summary

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

• 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.

Additionally, ensure that NAT is not performed on IPSec negotiation packets.

Symptom

In Figure 1-30, FW1 establishes an IPSec tunnel with a non-Huawei device FW2 through IKEv1. An IPSec tunnel is sometimes established successfully and sometimes is disconnected a long time before it can be re-established. As a result, services are interrupted for a long time.

Figure 1-30 IPSec networking

1. Run the display ike sa command on FW1, finding that an IPSec tunnel fails to be established.

   <FW1> display ike sa
    IKE SA information : 
       Conn-ID    Peer           VPN             Flag(s)              Phase 
    ---------------------------------------------------------------------- 
     
       1342      2.1.1.1:500                     NEG|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

2. Run the debugging ikev1 error command on FW1, finding that FW1 received a lot of retransmitted packets. This indicates that the peer end may fail to process some packets and keep retransmitting the last packet.

   <FW1> debugging ikev1 error
   IKE_ERROR 17:6804 Message from peer 2.1.1.1: Dropping Duplicate
   IKE_ERROR 17:6804 Message from peer 2.1.1.1: Dropping Duplicate

3. Check IPSec configurations, finding that the configurations are correct. After a certain period, an IPSec tunnel has been established successfully. The Flag field indicates that FW1 is the responder.

   <FW1> display ike sa
    IKE SA information : 
       Conn-ID    Peer           VPN             Flag(s)              Phase 
      ---------------------------------------------------------------------- 
        8388     2.1.1.1:500                     RD|A                 v1:2  
        8378     2.1.1.1:500                     RD|A                 v1: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

Possible Causes

FW1 and FW2 can establish an IPSec tunnel successfully only when FW2 functions as the responder. The preceding debugging information shows that FW2 failed to process the IKE negotiation packets sent from FW1 and dropped these packets. For example, when NAT traversal is disabled on some non-Huawei devices, these devices drop the received NAT-D payload.

Procedure

1. Obtain packet information on the interface of FW1 to view the negotiation packets retransmitted multiple times.

   <FW1> system-view 
   [FW1] acl 3100 
   [FW1-acl-adv-3100] acl 3100   //Define data flows. 
   [FW1-acl-adv-3100]  rule 5 permit ip source 1.1.1.1 0 destination 2.1.1.1 0  
   [FW1-acl-adv-3100]  rule 5 permit ip source 2.1.1.1 0 destination 1.1.1.1 0  
   [FW1-acl-adv-3100] quit 
   [FW1] packet-capture ipv4-packet 3100 interface GigabitEthernet 0/0/2 
   [FW1] packet-capture startup packet-num 1500 
   [FW1] packet-capture queue 0 to-file 1.cap  

   The obtained packet information shows that FW1 initiated a key negotiation packet, which contains the NAT-D payload. FW2 did not respond to the received negotiation packet, indicating that FW2 did not have NAT traversal enabled and dropped the negotiation packet.

2. Disable or enable NAT traversal on FW1.

   For example, if there is no NAT device between FW1 and FW2, disable NAT traversal on FW1.

   [FW1] ike peer peer1 
   [FW1-ike-peer-peer1] undo nat traversal

   After the preceding configuration is complete, an IPSec tunnel is established successfully and can be re-established quickly after being disconnected. PCs can ping each other successfully, and services on both ends can be forwarded normally.

Suggestion and Summary

If this problem occurs when a Huawei device is connected to a non-Huawei device, obtain packet information to check whether the local device sends the key negotiation packet that contains the NAT-D payload and keeps retransmitting the last negotiation packet when the peer non-Huawei device does not respond to this packet. If so, enable or disable NAT traversal on both ends simultaneously. For example, in a NAT traversal scenario, enable NAT traversal on both ends simultaneously.

Symptom

In Figure 1-31, a non-Huawei device FW1 in a branch establishes an IPSec tunnel with FW2 at the headquarters through IKEv1. The IPSec tunnel is disconnected almost once a day and can be re-established after being disconnected for a long time. As a result, services are interrupted for a long time.

Figure 1-31 IPSec networking

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

   <FW2> display ike sa

2. Run the display ike offline-info command on FW2, finding that the reason is phase1 hardware expire. This indicates that no new IKE SA is negotiated successfully after hardware timeout occurs on the IKE phase 1 SA.

   <FW2> display ike offline-info 
   Current info number: 2 
   ------------------------------------------------------------------------------------------ 
   peer               port    offline-reason           version     offline-time 
   ------------------------------------------------------------------------------------------ 
   1.1.1.1          500     phase1 hardware expire v1          2018/04/01  16:05:55 
   1.1.1.1            500     phase1 hardware expire v1          2018/04/01  15:05:55 
   ------------------------------------------------------------------------------------------     

   Check the IPSec configuration of FW2, finding that FW2 uses an IPSec policy configured using an IPSec policy template. Therefore, FW2 did not initiate IKE SA renegotiation, deleted the associated IPSec SA when deleting the IKE SA by default, and sent the IPSec SA deletion message to FW1.

Possible Causes

When the IKE SA between both ends is aged out, FW1 does not support IKEv1 phase 1 SA renegotiation, and FW2 does not initiate IKE phase 1 SA renegotiation. Therefore, the aged IKE SA is automatically deleted.

FW2 deleted the IPSec SA associated with the deleted IKE SA by default and sent the IPSec SA deletion message to FW1. The IKE SA of FW1 was aged and deleted, so FW1 did not delete the associated IPSec SA by default. Subsequently, FW1 cannot decrypt the IPSec SA deletion message sent from FW2 and dropped the message. IKE renegotiation failed to be initiated until the IPSec SA was aged, and services are interrupted for a long time.

Procedure

1. Run the undo ikev1 phase1-phase2 sa dependent command on FW2 to disable dependency between IPSec SA and IKE SA during IKEv1 negotiation.

   <FW2> system-view 
   [FW2] undo ikev1 phase1-phase2 sa dependent

   After an IKE SA is aged out, FW2 does not delete the associated IPSec SA when deleting the IKE SA. This ensures that both ends have an IPSec SA and transmit service traffic normally. After the IPSec SA is aged out, FW1 initiates IKE SA renegotiation. In this period, the IPSec tunnel is not interrupted, PCs can ping each other successfully, and services are forwarded normally.

Suggestion and Summary

When a Huawei device uses an IPSec policy configured using an IPSec policy template and is connected to a non-Huawei device, the non-Huawei device does not support IKEv1 SA renegotiation if the SA is aged out and does not delete the IPSec SA associated with the deleted IKE SA by default. To ensure uninterrupted services, ensure that the Huawei device does not delete the associated IPSec SA when deleting the IKE SA.