Huawei Firewall: Troubleshooting IPSec Issues
This document decribes the most common solutions to IPSec VPN failures and consulting issues, including troubleshooting guidelines, typical troubleshooting cases, and FAQs for IPSec. These solutions come directly from service requests that the Huawei Technical Support have solved. Many of these solutions can be implemented prior to the in-depth troubleshooting of an IPSec VPN connection. As a result, this document provides a checklist of common procedures to try before you begin to troubleshoot a connection and call Huawei Technical Support.
Troubleshooting IPSec Issues
- Introduction
- Prerequisites
- Troubleshooting Roadmap for IPSec
- Troubleshooting Guidelines for IPSec
- Troubleshooting Cases for IPSec
- Troubleshooting Case Indexes
- Service Interruptions Due to IPSec Tunnel Setup Failure
- 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
- IPSec Proposal Parameters on Both Ends Are Inconsistent
- After the Local Device Restarts Unexpectedly, the Remote Device Does Not Delete the Original Tunnel
- In L2TP over IPSec Scenarios, a Security ACL Does Not Match the IP Address Used After L2TP Encapsulation
- When IPSec and NAT Are Configured on the Same Device, Service Packets Cannot Match Security ACLs After NAT Is Performed
- ACL Rule Ranges on Both Ends Do Not Match
- When a NAT Device Is Deployed Between Two FWs, Authenticated Addresses Do Not Match
- Service Interruptions After Successful IPSec Tunnel Setup
- Encryption/Decryption Modes of SHA2-384 or SHA2-512 Authentication Algorithms on Both Ends Are Inconsistent
- Two Security ACL Rules on Both Ends Conflict
- NAT Traversal Is Not Enabled When a NAT Device Exists Between Both Ends
- Data Flows Match the Reverse Session of a NAT Server
- Security Policies Do Not Permit Private Network Traffic
- Private Network Route from an IKE Peer to its Remote End Is Unreachable
- When Multiple Outbound Interfaces Exist, IPSec Packets Are Dropped by Other Service Providers Due to Incorrect Routing
- Poor Service Quality After Successful IPSec Tunnel Setup
- Services Are Interrupted Because an IPSec Tunnel Is Unstable
- FAQs for IPSec
- What Ports Must Be Open to Use IPSec?
- An IPSec Tunnel Is Negotiated But the Matching Count of the ACL Referenced in the IPSec Policy Does Not Increase or Remains 0. Why?
- Why Does the Dial-Up User Fail to Communicate with the Intranet User When the IP Addresses of the Network That the LNS Accesses Reside on the Same Network Segment as the IP Address That the LNS Assigns to the Dial-Up User?
- What Authentication Methods Does L2TP over IPSec Support?
- Why Does the Creation of a Security Tunnel or Communication over a Security Tunnel Fail on Unstable Networks When ACLs Are Correctly Configured at Both Ends and Matched IPSec Proposals Exist?
- What If "IKE_ERROR 58:566 Processing TS Payload Failed" Is Displayed During Debugging?
- What If "IKE_ERROR 56:1545 Initiator receive IKE_SA_INIT response message error" and "IKE_ERROR 58:580 SA negotiation for CHILD SA Failed" Are Displayed During Debugging?
- Is the IPSec Tunnel the Same as Security Association?
- What Are the Restrictions of IPSec on ACLs?
- Can ESP Be Applied Only for Encryption?
- Do IPSec SAs and IKE SAs Generated During Negotiation Need to Be Cleared Orderly?
- What Are the Restrictions for Manual Configuration of Encryption and Authentication Keys?
- Can the Same Name Be Configured for an IPSec Policy Template and IPSec Policy?
- Can a Firewall Set Up an IPSec Tunnel After Referencing an IPSec Policy Template?
- Why Does a Device Restart at One End Result in a Service Interruption for a Period During Manual IPSec Negotiation?
- Can NAT and IPSec VPN Be Used Together?
- Can the Firewall Set Up IPSec Tunnels with Multiple Branches with Changing IP Addresses?
- What Is the Local Name When ike local-name Is Not Specified in Aggressive Mode with ID Type name?
- Must ACLs for Defining Encrypted Data Flows Be Mutually Mirrored When Both Ends of an IPSec Tunnel Are in Non-Template Mode?
- What Does an IKE Peer Use an IKE Proposal for?
- Why the Count of a Matched ACL Deny Rule Is Blank When Packets Match the ACL Deny Rule Referenced in IPSec in Transparent Transmission?
- Related Information
Introduction
This document describes the most common solutions to IPSec VPN failures and consulting issues, including troubleshooting guidelines, typical troubleshooting cases, and FAQs for IPSec. These solutions come directly from service requests that the Huawei Technical Support has solved. Many of these solutions can be implemented prior to the in-depth troubleshooting of an IPSec VPN connection. As a result, this document provides a checklist of common procedures to try before you begin to troubleshoot a connection and call Huawei Technical Support.
Prerequisites
- It is recommended that you have knowledge of IPSec VPN configuration on HUAWEI firewalls.
- This document uses Huawei USG6000 series firewall products of V5 version as an example. There may be differences in the implementation of different products and versions. Please refer to the specific version of the product documentation.
- In this document, FW is short for firewall.
- In this document, public IP addresses may be used and are for reference only unless otherwise specified.
Troubleshooting Roadmap for IPSec
There are two IPSec fault symptoms: IPSec tunnel setup failure and abnormal services after successful IPSec tunnel setup.
Figure 1-1 shows the IPSec troubleshooting roadmap.
The preceding figure analyzes faults by symptom. You can also analyze faults according to the stage in which a fault occurs.
- Service triggering stage: Internet Key Exchange (IKE) negotiation is not triggered.
- Tunnel setup stage: An IKE SA or IPSec SA negotiation failure leads to an IPSec tunnel setup failure.
- Data transmission stage: Services are abnormal (interrupted or of poor quality) after successful IPSec tunnel setup.
IKE SA or IPSec SA negotiation failure is the core issue in IPSec faults. You can carry out in-depth analysis on the IKE negotiation process. Usually, other IPSec faults are caused by incorrect feature configurations, such as interfaces, Access Control Lists (ACLs), routes, and network address translation (NAT). Such faults need to be processed based on the specific scenario.
During routine maintenance or after receiving a fault report, a network administrator can find the troubleshooting guidance by referring to this figure. For complex faults, the network administrator can analyze triggering causes layer by layer based on the fault symptom and IPSec working principles to find the root cause. Understanding the overall troubleshooting roadmap helps network administrators quickly locate and process faults.
The following lists two IPSec fault trees: IPSec tunnel setup failure and abnormal IPSec services.
Fault Tree of IPSec Tunnel Setup Failure
Figure 1-2 shows the fault tree of IPSec tunnel setup failure.
Troubleshooting Guidelines for IPSec
No IKE Negotiation Triggered
Fault Symptom
In Figure 1-4, after IPSec is deployed between FWs, PCs cannot communicate with each other.
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
Run the display ipsec statistics command on FW1 to check IPSec statistics.
<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
- Automatic IPSec SA triggering mode
If the outbound ok field displays 0, the local end does not send IKE negotiation packets and does not trigger IPSec tunnel negotiation.
- Traffic-based IPSec SA triggering mode
If the trigger ok field displays 0, no traffic triggers IKE negotiation. If the outbound ok field displays 0 and the trigger ok field does not display 0, the local end does not send IKE negotiation packets and does not trigger IPSec tunnel negotiation.
If multiple IPSec tunnels are established on the device, the display ipsec statistics command cannot help determine the IPSec tunnel on which IKE negotiation packets have not been sent. You are advised to run the display firewall session table verbose command to check whether an IKE session with the IKE peer IP address exists (the default UDP port number is 500 or 4500). For example:
<FW1> 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
Troubleshooting Procedure
Procedure
- 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.
- 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.
- 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 ------------------------------------------------
- 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) - 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.
- Run the display firewall server-map command to check the source and destination IP addresses in the servermap table.
- 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.
- If the fault persists, collect the following information and contact technical support personnel.
- Collect the configurations and operation results of the preceding steps, and record the information in a file.
- 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
- After debugging is disabled, collect all diagnostic information and export the information to a file.
- 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
- 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.
- Run the display diagnostic-information file-name command to collect diagnostic information and save the information to a file.
- Collect the log and trap information on the device and export the information to files.
- 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.
- After log and trap information files are generated, export the files using TFTP.
- Run the save logfile command to save the log and trap information in the buffer to files.
- 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:
IKE SA Negotiation Failure
Fault Symptom
In Figure 1-5, after IPSec is deployed between FWs, PCs cannot communicate with each other.
- Run the display ike sa command on FW1, finding that no IKE SA is established. This results in a failure to establish an IPSec tunnel.
<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 - Run the display ipsec statistics command on FW1 to check IPSec statistics, finding that the outbound ok field displays 0. This indicates that IKE packets have been sent.
<FW1> display ipsec statistics ....... negotiate about packet statistics: IKE fwd packet ok: 0, err: 0 IKE ctrl packet inbound ok: 0, outbound ok: 4 SoftExpr: 0, HardExpr: 0, DPDOper: 0 trigger ok: 0, switch sa: 0, sync sa: 0 recv IKE nat keepalive: 0, IKE input: 0
If multiple IPSec tunnels are established on the device, the display ipsec statistics command cannot help determine the IPSec tunnel on which IKE negotiation packets have not been sent. You are advised to run the display firewall session table verbose command to check whether an IKE session with the IKE peer IP address exists (the default UDP port number is 500 or 4500). For example:
<FW1> 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
Troubleshooting Procedure
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.
Procedure
- 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.
- 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.
- 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:
- 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.
- 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.
- The local end functions only as the IKE responder.
- 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.
- If the remote end uses an internal IP address and a NAT device exists between the local and remote ends:
- 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.
- 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).
- 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.
- Run the display pki certificate and display clock commands to check the certificate expiration date and device time.
- 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.
- 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 -------------------------------------------
- If the fault persists, collect the following information and contact technical support personnel.
- Collect the configurations and operation results of the preceding steps, and record the information in a file.
- 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
- After debugging is disabled, collect all diagnostic information and export the information to a file.
- 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
- 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.
- Run the display diagnostic-information file-name command to collect diagnostic information and save the information to a file.
- Collect the log and trap information on the device and export the information to files.
- 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.
- After log and trap information files are generated, export the files using TFTP.
- Run the save logfile command to save the log and trap information in the buffer to files.
- 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.
IPSec SA Negotiation Failure
Fault Symptom
In Figure 1-7, after IPSec is deployed between FWs, PCs cannot communicate with each other.
Run the display ike sa command on FW1, finding that no IPSec SA is established. This results in a failure to establish an IPSec tunnel.
<FW1> display ike sa
IKE SA information :
Conn-ID Peer VPN Flag(s) Phase
----------------------------------------------------------------------
8388 2.1.1.1:500 RD|ST|A v2:1
Number of IKE SA : 1
----------------------------------------------------------------------
Flag Description:
RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT
HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UP
M--ACTIVE S--STANDBY A--ALONE NEG--NEGOTIATING
Troubleshooting Procedure
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
- 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.
- 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 - 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 - If the fault persists, collect the following information and contact technical support personnel.
- Collect the configurations and operation results of the preceding steps, and record the information in a file.
- 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
- After debugging is disabled, collect all diagnostic information and export the information to a file.
- 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
- 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.
- Run the display diagnostic-information file-name command to collect diagnostic information and save the information to a file.
- Collect the log and trap information on the device and export the information to files.
- 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.
- After log and trap information files are generated, export the files using TFTP.
- Run the save logfile command to save the log and trap information in the buffer to files.
- 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.
Successful IKE Renegotiation in Only One Direction After Unexpected Device Restart
Symptom
In Figure 1-8, an IPSec tunnel is successfully established between FW1 and FW2. After FW2 restarts unexpectedly, PC1 cannot ping PC2.
Run the display ike sa command. You can find that SAs are successfully established on FW1, but fail to be established on FW2.
<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
Possible Causes
After FW2 restarts, SAs are cleared. However, SAs on FW1 are not released because they do not reach their lifetime (1 hour for IPSec SA and 24 hours for IKE SA by default). When you initiate access on FW1, data flows match existing SAs, so new SAs cannot be established. In this case, PC1 fails to ping PC2. When you initiate access on FW2, data flows trigger re-establishment of SAs. After SAs are successfully established, PC2 can ping PC1.
This symptom frequently occurs if a device restarts unexpectedly when traffic triggers SA negotiation. Abnormal device restart will automatically trigger IPSec SA negotiation.
Procedure
- On FW1, manually reset SAs.
Run the reset ike sa command. You can find that an IPSec tunnel is established between two ends.
- Configure the dead peer detection (DPD) function for IKE peers on two ends.
After DPD is configured, breakdown of the IPSec tunnel will automatically clear SAs and trigger SA negotiation again.
DPD 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 payloads in DPD packets; otherwise, DPD does not take effect.
For example, the sequence of the payloads in DPD packets in the global configuration is as follows: seq-hash-notify, detection mode (periodic), idle time for DPD detection (20s), DPD packet retransmission interval (10s), and umber of DPD packet retransmissions (4). The following shows the commands on FW1:
<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
Service Interruption After Successful IPSec Tunnel Setup
Fault Symptom
In Figure 1-9, an IPSec tunnel has been established between FWs but the following problems exist:
- Users of the branch and headquarters cannot communicate with each other.
- Only unidirectional communication is implemented between users of the branch and headquarters. For example, users of the headquarters can access servers in the branch, but users of the branch cannot access servers in the headquarters.
- Users of the branch and headquarters can access only some network segments.
- On a P2MP network, users of the branch cannot communicate with each other but can communicate with users of the headquarters.
- When an IPSec gateway functions as a NAT gateway, all traffic may be sent out after NAT is performed, without entering VPNs.
Troubleshooting Procedure
Troubleshooting Flowchart
Rectify the fault according to the troubleshooting flowchart in Figure 1-10.
Procedure
- 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.
- 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.
- 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) - 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.
- 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 =========================================== ......
- 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.
- Run the display firewall server-map command to check the source and destination IP addresses in the servermap table.
- 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 ......
- 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 - 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.
- The authentication algorithm is SHA2-256.
- 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.
- If the fault persists, collect the following information and contact technical support personnel.
- Collect the configurations and operation results of the preceding steps, and record the information in a file.
- 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
- After debugging is disabled, collect all diagnostic information and export the information to a file.
- 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
- 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.
- Run the display diagnostic-information file-name command to collect diagnostic information and save the information to a file.
- Collect the log and trap information on the device and export the information to files.
- 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.
- After log and trap information files are generated, export the files using TFTP.
- Run the save logfile command to save the log and trap information in the buffer to files.
- 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
Poor Service Quality After Successful IPSec Tunnel Setup
Symptom
In Figure 1-11, run the display ipsec sa command on the FW to view IPSec SA information. You can find that an IPSec tunnel is established. The following problems may exist:
- The service access speed is slow.
- The service access is intermittent or interrupted.
Possible Causes
Procedure
- Check whether the CPU usage is high.
Run the display cpu-usage command to view the CPU usage.
If the CPU usage exceeds 80%, check whether features such as content security and attack defense are configured. If such features are configured, disable the features and check the CPU usage again.
- Check whether the Internet discards packets.
Run the undo ipsec policy command on two IPSec tunnel interfaces to cancel the IPSec policy. Then perform the ping test. If packet loss still occurs, the Internet quality is poor. Contact the carrier to solve the problem.
- Check whether IPSec packets are fragmented.
IPSec encapsulates IP packets. As a result, the IP packet length becomes longer. If the IP packet length exceeds the link MTU during transmission, the IP packets are fragmented and sent. The receiver needs to reassemble and parse the fragments. Fragmentation and reassembly consume CPU resources, and encryption and decryption of fragments also consume many CPU resources. When there are many fragments, CPU resources may be insufficient. In this case, the access is slow and packets are discarded.
Run the ping -s packetsize -a source-ip-address host command to test packets of different sizes. Find the threshold exceeding which packets are lost or the ping operation fails.
Run the mtu mtu command in the interface view to change the MTU value based on the threshold.
After the modification, if some TCP services still have a slow access speed or are intermittent, run the firewall tcp-mss value command in the system view to modify the TCP MSS.
If the total packet length (MSS plus various types of costs, including the TCP packet header, IP packet header, and IPSec packet header) exceeds the link MTU, data packets will be fragmented. Fragmentation will lead to consumption of more CPU resources. In addition, encryption and decryption of packet fragments also consume CPU resources of devices on the transmission link. Too much CPU resource consumption will lead to data packet loss.
Some upper layer applications (such as the application layer protocol HTTP) will set the Don't Fragment (DF) flag of IP packets to valid to prevent TCP packet fragmentation. If the DF flag is set to valid but the interface MTU is smaller than the MSS, the device will discard packets because it cannot forcibly fragment the TCP packets.
Related Information
Analysis on poor service quality:
Abnormal Services After Successful IPSec Tunnel Setup
Case:
An Incorrect TCP MSS Results in Temporary IPSec Service Interruptions
Troubleshooting Cases for IPSec
Troubleshooting Case Indexes
The following classifies IPSec troubleshooting cases by failure reasons. Table1 shows the troubleshooting case index table.
You can perform IPSec troubleshooting through the web system. For details, see Troubleshooting IPSec on the Web UI. If you cannot locate faults, use commands to locate IPSec faults.
Service Interruptions Due to IPSec Tunnel Setup Failure
IKE Proposal Parameters on Both Ends Are Inconsistent
Symptom
In Figure 1-12, after IPSec is deployed between FWs, PCs cannot communicate with each other.
- 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 - 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
- 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.
- 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
Pre-Shared Keys on Both Ends Are Inconsistent
Symptom
In Figure 1-13, after IPSec is deployed between FWs, PCs cannot communicate with each other.
- 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 - 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
- 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.
- 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.
IKE Peer IP Addresses on Both Ends Do Not Match
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.
- 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 - 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 -----------------------------------------------------------------------------------------
- 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
- 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.
- 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.
IPSec Proposal Parameters on Both Ends Are Inconsistent
Symptom
In Figure 1-15, after IPSec is deployed between FWs, PCs cannot communicate with each other.
- 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 - 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
- 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-256The preceding command output shows that encryption algorithms used on both ends are inconsistent.
- 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
After the Local Device Restarts Unexpectedly, the Remote Device Does Not Delete the Original Tunnel
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.
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
- Manually reset the SA on FW1.
After the reset ike sa command is executed, both ends establish an IPSec tunnel.
- 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.
In L2TP over IPSec Scenarios, a Security ACL Does Not Match the IP Address Used After L2TP Encapsulation
Symptom
In Figure 1-17, an L2TP over IPSec tunnel has been established between FWs, but PCs cannot communicate with each other.
- 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 - 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 - 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
- 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.
- 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.
When IPSec and NAT Are Configured on the Same Device, Service Packets Cannot Match Security ACLs After NAT Is Performed
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.
- 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
- 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 - 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
- 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.
- 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.
ACL Rule Ranges on Both Ends Do Not Match
Symptom
In Figure 1-19, after IPSec is deployed between FWs, PCs cannot communicate with each other.
- 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 - 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
- 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.
- 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.
When a NAT Device Is Deployed Between Two FWs, Authenticated Addresses Do Not Match
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.
- 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
- 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
- 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.
- 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.
Service Interruptions After Successful IPSec Tunnel Setup
Encryption/Decryption Modes of SHA2-384 or SHA2-512 Authentication Algorithms on Both Ends Are Inconsistent
Symptom
In Figure 1-21, after IPSec is deployed between FWs, PCs cannot communicate with each other.
- 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 - 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
- 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-256The 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.
- 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.
Two Security ACL Rules on Both Ends Conflict
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.
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
- 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.
- 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.
NAT Traversal Is Not Enabled When a NAT Device Exists Between Both Ends
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.
- 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 - 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
- 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.
- 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.
- 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: 1024The 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.
- 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.
Data Flows Match the Reverse Session of a NAT Server
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.
- 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 - 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
- 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.
- 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.
- 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: 1The 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.
- 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.
Security Policies Do Not Permit Private Network Traffic
Symptom
In Figure 1-25, an IPSec tunnel has been established between FWs, but PCs cannot communicate with each other.
- 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 - 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
- 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.
- 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.
Private Network Route from an IKE Peer to its Remote End Is Unreachable
Symptom
In Figure 1-26, after IPSec is deployed between FWs, PCs cannot communicate with each other.
- 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 - 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
- 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.
- 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.
When Multiple Outbound Interfaces Exist, IPSec Packets Are Dropped by Other Service Providers Due to Incorrect Routing
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.
- 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 - 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
- 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: 1024The 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.
- 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
- 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.
Poor Service Quality After Successful IPSec Tunnel Setup
An Incorrect TCP MSS Results in Temporary IPSec Service Interruptions
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.
- 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 - 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
- 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
- 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 lossThe 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.
- 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.
Services Are Interrupted Because an IPSec Tunnel Is Unstable
NAT Is Performed on IPSec Negotiation Packets When IPSec and NAT Are Configured on the Same Device
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.
- 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 - 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 - 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
- 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.
- 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.
A Non-Huawei Device Drops NAT-D 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.
- 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 - 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
- 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
- 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.
![]()
- 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.
When a Non-Huawei Device Functions as the Initiator, IKE SA Renegotiation Is Not Initiated After an IKE SA Is Aged Out
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.
- 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
- 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
- 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.
FAQs for IPSec
What Ports Must Be Open to Use IPSec?
Question
What ports must be open to use IPSec on a firewall?
Answer
Enable corresponding ports to send and receive the following packets:
- UDP packets with destination ports 500 and 4500
- IP packets with protocols AH and ESP
For service packets, configure specific interzone policies based on inner packets.
An IPSec Tunnel Is Negotiated But the Matching Count of the ACL Referenced in the IPSec Policy Does Not Increase or Remains 0. Why?
Question
An IPSec tunnel is negotiated but the match count of the ACL referenced in the IPSec policy does not increase or remains 0. Why?
Answer
The ACL referenced in the IPSec policy is used only to trigger the negotiation. The matching count of the ACL increases only when packets match the ACL to trigger IKE negotiation. After a tunnel is negotiated, service packets no longer match the ACL. Therefore, its matching count does not increase. In addition, if the IPSec policy configured on the interface carries the auto-neg parameter, the device will automatically trigger negotiation. In this case, the match count of the ACL does not increase as well.
Why Does the Dial-Up User Fail to Communicate with the Intranet User When the IP Addresses of the Network That the LNS Accesses Reside on the Same Network Segment as the IP Address That the LNS Assigns to the Dial-Up User?
Question
Why does the dial-up user fail to communicate with the intranet user when the IP addresses of the network that the LNS accesses reside on the same network segment as the IP address that the LNS assigns to the dial-up user?
Answer
On the interface (must be an Ethernet interface) connecting the LNS and the intranet, the ARP proxy (arp-proxy enable) and L2TP virtual forwarding (virtual-l2tpforward enable) functions must be configured. After the ARP proxy and L2TP virtual forwarding are configured, the intranet replies to the ARP request from the dial-up user on the same IP address network segment, and the learned MAC address is that of the interface with ARP proxy enabled on the LNS. The L2TP tunnel forwards packets to the peer end.
What Authentication Methods Does L2TP over IPSec Support?
Question
What authentication methods does L2TP over IPSec support?
Answer
- Local authentication
- LDAP authentication
- AD authentication
- RADIUS authentication
- HWTACAS authentication
- SecurID authentication
Why Does the Creation of a Security Tunnel or Communication over a Security Tunnel Fail on Unstable Networks When ACLs Are Correctly Configured at Both Ends and Matched IPSec Proposals Exist?
Question
Why does the creation of a security tunnel or communication over a security tunnel fail on unstable networks when ACLs are correctly configured at both ends and matched IPSec proposals exist?
Answer
After a security tunnel is set up, the firewall at one end may be restarted. Run the display ike sa command to check whether IPSec SAs at phase 1 are already set up at both ends. Run the display ipsec sa policy command to check whether IPSec SAs are already applied to the interface. According to the results, if the SA at one end does not exist, run the reset ipsec sa and reset ike sa commands to clear incorrect SAs and re-launch the negotiation.
What If "IKE_ERROR 58:566 Processing TS Payload Failed" Is Displayed During Debugging?
Question
What if "IKE_ERROR 58:566 Processing TS Payload Failed" is displayed during debugging?
Answer
This is caused by ACL differences on both IPSec interfaces. In actual applications, ACLs are used to establish security tunnels on per data flow basis for data protection. In this case, you need to check the ACLs in the security policies configured at both ends of the tunnel for any ACL mismatch. If the ACLs do not match, set the ACLs at both ends to be mutually mirrored.
In addition, you may see the following information in the log buffer:
Mar 8 2017 11:10:47 sysname IPSEC/4/IPSECNEGOFAIL:1.3.6.1.4.1.2011.6.122.26.6.14 IPSec tunnel negotiation fails. (Ifindex=12, SeqNum=0, Reason="acl configuration mismatch", ReasonCode=4, PeerAddress=1.1.1.1, PeerPort=500)
This is caused by ACL differences on both IPSec interfaces.
What If "IKE_ERROR 56:1545 Initiator receive IKE_SA_INIT response message error" and "IKE_ERROR 58:580 SA negotiation for CHILD SA Failed" Are Displayed During Debugging?
Question
During debugging, the following information is displayed:
1) IKE_ERROR 56:1545 Initiator receive IKE_SA_INIT response message error.
2) IKE_ERROR 58:580 SA negotiation for CHILD SA Failed.
What shall I do?
Answer
This is caused by the lack of matched IPSec proposals between negotiation parties.
1) Check whether the IKE proposals of the involved parities are matched.
2) Check whether the IPSec policy parameters as well as the protocols, encryption algorithms, and authentication algorithms of the referenced IPSec proposals applied on the interfaces of the involved parties are matched.
Is the IPSec Tunnel the Same as Security Association?
Question
Is the IPSec tunnel the same as Security Association (SA)?
Answer
They are totally different. An IPSec tunnel can be established as bidirectional connections, but a SA is only a unidirectional connection. The IPSec tunnel generally consists of a pair of SAs in opposite directions.
What Are the Restrictions of IPSec on ACLs?
Question
What are the restrictions of IPSec on ACLs?
Answer
The restrictions are as follows:
IPSec applies only to the data flows that are permitted by the ACL rule. You are advised to define accurate ACL rules to permit only the data flows that really deserve IPSec protection. Use keyword any sparely. Set the local ACL rule and peer ACL rule to be mutually mirrored.
Can ESP Be Applied Only for Encryption?
Question
Can ESP be applied only for encryption?
Answer
Yes. However, this mode is insecure and therefore not recommended.
Do IPSec SAs and IKE SAs Generated During Negotiation Need to Be Cleared Orderly?
Question
Do IPSec SAs and IKE SAs generated in negotiation need to be cleared orderly?
Answer
You must clear IPSec SAs generated in phase 2 of the negotiation and then IKE SAs in phase 1. During clearance, the firewall notifies the peer end of deleting corresponding SAs.
What Are the Restrictions for Manual Configuration of Encryption and Authentication Keys?
Question
What are the restrictions for manual configuration of encryption and authentication keys?
Answer
The key of the local inbound SA must be the same as that of the peer outbound SA. SA are the local outbound SA and peer inbound SA.
The key must be entered in the same way at both ends of an IPSec tunnel. If the key is input in character string form at one end and in hexadecimal form at the other end, the security tunnel cannot be set up.
Can the Same Name Be Configured for an IPSec Policy Template and IPSec Policy?
Question
Can the same name be configured for an IPSec policy template and IPSec policy?
Answer
No. An attempt to configure the same name for an IPSec policy template and IPSec policy will fail.
[sysname] ipsec policy ipsec 1 isakmp template ipsec//Attempt to configure the same name for them but fail.
Error: The IPSec policy name can't be the same as the IPSec template.
[sysname] ipsec policy ipsec 1 isakmp template temp_ipsec//Success
Can a Firewall Set Up an IPSec Tunnel After Referencing an IPSec Policy Template?
Question
Can a firewall set up an IPSec tunnel after referencing an IPSec policy template?
Answer
No. Currently, the firewall can only passively receive the request for setting up an IPSec tunnel after referencing the IPSec policy template.
Why Does a Device Restart at One End Result in a Service Interruption for a Period During Manual IPSec Negotiation?
Question
Why does device restart at one end result in a service interruption for a period during manual IPSec negotiation?
Answer
In manual mode, devices at both ends of a tunnel do not send negotiation packets to each other. When a device recovers from a restart and sends packets, its peer regards the packets as replay attack packets till the sequence number of a packet reaches the sequence number from where the last communication is interrupted. You can also run the reset ipsec sa command on both ends to reset SA information and the sequence number counter. The IKE negotiation mode is recommended on a live network.
Can NAT and IPSec VPN Be Used Together?
Question
Can NAT and IPSec VPN be used together?
Answer
Yes. When they are used together, the firewall is generally deployed at the network egress and performs NAT over intranet packets destined for the Internet. A packet carrying a private address is transmitted to the headquarters over an IPSec tunnel, and it is transmitted over the Internet with a public IP address added. When receiving the packet, the firewall decapsulates the packet and identifies its home branch based on the private IP header. When specifying an ACL for the Source NAT policy, note that NAT is not required for traffic destined for the headquarters.
Can the Firewall Set Up IPSec Tunnels with Multiple Branches with Changing IP Addresses?
Question
Can the firewall set up IPSec tunnels with multiple branches with changing IP addresses?
Answer
Yes. As long as these branches use the same IKE local name and the headquarters applies the same policy template, the firewall can set up IPSec tunnels with these branches.
What Is the Local Name When ike local-name Is Not Specified in Aggressive Mode with ID Type name?
Question
What is the local name when ike local-name is not specified in aggressive mode with ID type name?
Answer
If ike local-name is not specified, the host name (namely, sysname) will apply.
Must ACLs for Defining Encrypted Data Flows Be Mutually Mirrored When Both Ends of an IPSec Tunnel Are in Non-Template Mode?
Question
Must ACLs for defining encrypted data flows be mutually mirrored when both ends of an IPSec tunnel are in non-template mode?
Answer
Not Necessarily. Mutually mirrored configurations are not required but are recommended for good device and network maintainability.
What Does an IKE Peer Use an IKE Proposal for?
Question
What does an IKE peer use an IKE proposal for?
Answer
If an IKE proposal is configured for an IKE peer (the initiator), the initiator uses the configured IKE proposal to negotiate with the peer. If no IKE proposal is configured, the initiator sends all IKE proposals to the peer for negotiation in main mode or employs the default proposal in aggressive mode. As a receiver, the IKE peer uses all IKE proposals to match the IKE proposal sent from the initiator.
Why the Count of a Matched ACL Deny Rule Is Blank When Packets Match the ACL Deny Rule Referenced in IPSec in Transparent Transmission?
Question
Why the count of a matched ACL deny rule is blank when packets match the ACL deny rule referenced in IPSec in transparent transmission?
Answer
When packets match the shareflow delivered based on the ACLs referenced by IPSec, the packets are IPSec-encapsulated. However, when the packets match the shareflow based on a deny rule, packets do not match the referenced ACL. Therefore, the count of matched ACL deny rule is zero.
- Introduction
- Prerequisites
- Troubleshooting Roadmap for IPSec
- Troubleshooting Guidelines for IPSec
- Troubleshooting Cases for IPSec
- Troubleshooting Case Indexes
- Service Interruptions Due to IPSec Tunnel Setup Failure
- 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
- IPSec Proposal Parameters on Both Ends Are Inconsistent
- After the Local Device Restarts Unexpectedly, the Remote Device Does Not Delete the Original Tunnel
- In L2TP over IPSec Scenarios, a Security ACL Does Not Match the IP Address Used After L2TP Encapsulation
- When IPSec and NAT Are Configured on the Same Device, Service Packets Cannot Match Security ACLs After NAT Is Performed
- ACL Rule Ranges on Both Ends Do Not Match
- When a NAT Device Is Deployed Between Two FWs, Authenticated Addresses Do Not Match
- Service Interruptions After Successful IPSec Tunnel Setup
- Encryption/Decryption Modes of SHA2-384 or SHA2-512 Authentication Algorithms on Both Ends Are Inconsistent
- Two Security ACL Rules on Both Ends Conflict
- NAT Traversal Is Not Enabled When a NAT Device Exists Between Both Ends
- Data Flows Match the Reverse Session of a NAT Server
- Security Policies Do Not Permit Private Network Traffic
- Private Network Route from an IKE Peer to its Remote End Is Unreachable
- When Multiple Outbound Interfaces Exist, IPSec Packets Are Dropped by Other Service Providers Due to Incorrect Routing
- Poor Service Quality After Successful IPSec Tunnel Setup
- Services Are Interrupted Because an IPSec Tunnel Is Unstable
- FAQs for IPSec
- What Ports Must Be Open to Use IPSec?
- An IPSec Tunnel Is Negotiated But the Matching Count of the ACL Referenced in the IPSec Policy Does Not Increase or Remains 0. Why?
- Why Does the Dial-Up User Fail to Communicate with the Intranet User When the IP Addresses of the Network That the LNS Accesses Reside on the Same Network Segment as the IP Address That the LNS Assigns to the Dial-Up User?
- What Authentication Methods Does L2TP over IPSec Support?
- Why Does the Creation of a Security Tunnel or Communication over a Security Tunnel Fail on Unstable Networks When ACLs Are Correctly Configured at Both Ends and Matched IPSec Proposals Exist?
- What If "IKE_ERROR 58:566 Processing TS Payload Failed" Is Displayed During Debugging?
- What If "IKE_ERROR 56:1545 Initiator receive IKE_SA_INIT response message error" and "IKE_ERROR 58:580 SA negotiation for CHILD SA Failed" Are Displayed During Debugging?
- Is the IPSec Tunnel the Same as Security Association?
- What Are the Restrictions of IPSec on ACLs?
- Can ESP Be Applied Only for Encryption?
- Do IPSec SAs and IKE SAs Generated During Negotiation Need to Be Cleared Orderly?
- What Are the Restrictions for Manual Configuration of Encryption and Authentication Keys?
- Can the Same Name Be Configured for an IPSec Policy Template and IPSec Policy?
- Can a Firewall Set Up an IPSec Tunnel After Referencing an IPSec Policy Template?
- Why Does a Device Restart at One End Result in a Service Interruption for a Period During Manual IPSec Negotiation?
- Can NAT and IPSec VPN Be Used Together?
- Can the Firewall Set Up IPSec Tunnels with Multiple Branches with Changing IP Addresses?
- What Is the Local Name When ike local-name Is Not Specified in Aggressive Mode with ID Type name?
- Must ACLs for Defining Encrypted Data Flows Be Mutually Mirrored When Both Ends of an IPSec Tunnel Are in Non-Template Mode?
- What Does an IKE Peer Use an IKE Proposal for?
- Why the Count of a Matched ACL Deny Rule Is Blank When Packets Match the ACL Deny Rule Referenced in IPSec in Transparent Transmission?
- Related Information