No relevant resource is found in the selected language.

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

Reminder

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

upgrade

AR Router Troubleshooting Guide

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

Appendix

IPSec Failure Analysis

IPSec Tunnel Setup Failure

ISAKMP Packet Format

Internet Security Association and Key Management Protocol (ISAKMP) are basis of IKE. IKE uses ISAKMP packets for security association (SA) negotiation, key exchange, and peer identity verification.

Figure 26-13 shows the ISAKMP packet format.

Figure 26-13  ISAKMP packet format

IP Header

Source address: indicates the IP address that initiates IKE negotiation. It can be an interface IP address or an IP address configured using the local-address command.

Destination address: indicates the IP address of the remote device. It is configured using the remote-address command.

UDP Header

IKE uses port 500 to initiate negotiation and respond to negotiation. In the NAT traversal scenario, the gateway converts the detected port number 500 to 4500.

ISAKMP Header

Initiator's Cookie (SPI): specifies a number used by the initiator to uniquely identify an IKE SA. The SPI cannot be 0.

Responder's Cookie (SPI): specifies a number used by the responder to uniquely identify an IKE SA. The SPI in the first message is 0, and in later messages cannot be 0.

Next Payload: indicates the type of next payload in a message. If the current payload is the last one in a message, the value of this field is 0. This field provides the linking capability between payloads. To add a new payload to the end of a message, specify the type of the new payload at the end of the previous payload.

Table 26-2 and Table 26-3 list the next payload types in IKEv1 and IKEv2.

Table 26-2  Next payloads in IKEv1

Next Payload

Abbreviation

Value

Function

None

-

0

Indicate that the current payload is the last one in the message.

Security Association

SA

1

Negotiate an IKE or IPSec proposal.

Proposal

P

2

Negotiate the security protocol and security mechanism used by an SA.

Transform

T

3

Transmit SA attributes for negotiating the proposal supported by both parties.

Key Exchange

KE

4

Exchange the Diffie-Hellman (DH) public number as part of a DH key exchange.

Identification

IDi, IDr

5

Send an identity ID for access control. There is no need to match this payload in certificate authentication.

Certificate

CERT

6

Transmit the certificate or other authentication-related information.

Certificate-Request

CERTREQ

7

Request the preferred certificate.

Hash

HASH_I, HASH_R

8

Verify integrity of an IKE message, or authenticate the peer.

Signature

SIG_I, SIG_R

9

Verify integrity of an IKE message and provide the non-repudiation service.

Norigication

N

10

Announce errors and status changes.

Nonce

Ni, Nr

11

Transmit the temporary random number.

Delete

D

12

Indicate that the SA with the specified SPI has been deleted.

Vendor ID

V

13

Indicate that the sender can accept protocol extensions.

Properties

-

14

Indicate an attribute payload.

NAT Discovery

NAT-D

20

Determine whether the device is connected to a NAT device.

NAT Original Address

NAT-OA

21

Specify the original address of an IPSec session party.

Reserved

-

15-127

Reserved.

Private Use

-

128-255

Private use.

Table 26-3  Next payloads in IKEv2

Next Payload

Abbreviation

Value

Function

No Next Payload

-

0

Indicate that the current payload is the last one in the message.

Reserved

-

1-32

Reserved.

Security Association

SA

33

Negotiate an IKE or IPSec proposal.

Key Exchange

KE

34

Exchange the DH public number as part of a DH key exchange.

Identification-Initiator

IDi

35

Send an identity ID for access control. There is no need to match this payload in certificate authentication.

Identification-Responder

IDr

36

Certificate

CERT

37

Transmit the certificate or other authentication-related information.

Certificate-Request

CERTREQ

38

Request the preferred certificate.

Authentication

Auth

39

Send the authentication method and data (hash values).

Nonce

Ni, Nr

40

Transmit the temporary random number.

Notify

N

41

Announce errors and status changes.

Delete

D

42

Indicate that the SA with the specified SPI has been deleted.

Vendor ID

V

43

Indicate that the sender can accept protocol extensions. Currently, this payload is used to negotiate the NAT-T capability.

Traffic Selector-Initiator

TSi

44

Specify data flows to be protected by IPSec.

Traffic Selector-Responder

TSr

45

Encrypted

E

46

Transmit encrypted values of other payloads.

Configuration

CP

47

Include CFG_REQUEST, CFG_REPLAY, CFG_SET, and CFG_ACK for address allocation request and reply.

Extensible-Authentication

EAP

48

Carry Extensible Authentication Protocol (EAP) information.

Reserved to

IANA

49-127

Reserved.

Private Use

-

128-255

Private use.

Maj Ver/Min Ver: identifies the ISAKMP version by numbers of the Maj Ver and Min Ver fields. In IKE, the two fields are combined.

Version: In IKEv1, the value of this field is 1.0. In IKEv2, the value of this field is 2.0.

Exchange Type: indicates the exchange type. This field constrains the payloads sent in each message and orderings of messages in an exchange.

Table 26-4 and Table 26-5 list exchange types in IKEv1 and IKEv2.

Table 26-4  Exchange types in IKEv1

Exchange Type

Value

None

0

Base

1

Identity protection

2

Authentication only

3

Aggressive

4

Informational

5

Future use

6-31

DOI specific use

32-239

Private use

240-255

Table 26-5  Exchange types in IKEv2

Exchange Type

Value

Reserved

0-33

IKE_SA_INIT

34

IKE_SA_AUTH

35

Create_CHILD_SA

36

Informational

37

Reserved to IANA

38-239

Reserved for Private Use

240-255

Flags: indicates specific options for ISAKMP exchange. For flags in this field, the meanings of each bit starting from the least significant bit are as follows:

  • IKEv1: Bit 0 is the encryption bit. When set to 1, it means the payload is encrypted. Bit 1 is the commit bit and, if set, it ensures that encrypted material is not received prior to SA establishment. Bit 2 is the authentication bit and implies, if set, that the payload will be only authenticated and not encrypted. The other bits are not defined, and must be set to 0.
  • IKEv2: Bit 3, if set to 1, indicates the initiator. Bit 4 indicates IKEv2 and must be set to 0. Bit 5, if set to 1, indicates the responder. The other bits are not defined, and must be set to 0.

Message ID: The value of this field is 0 in phase 1 and a random number generated by the initiator in phase 2. As the unique identifier of a message, it identifies the protocol status in phase 2 negotiation.

Message Length: indicates the length of the total ISAKM message, which is the header plus the payloads.

Negotiation Process in IKEv1 Phase 1

The purpose of IKEv1 phase 1 negotiation is to establish an IKE SA. After an IKE SA is established, all the Internet Security Association and Key Management Protocol (ISAKMP) messages transmitted between two IKE peers will be encrypted and authenticated. The secure tunnel established in phase 1 enables IKE peers to communicate securely in phase 2.

Negotiation Process in Main Mode

The main mode uses six ISAKMP messages to implement three bidirectional exchanges, as shown in Figure 26-14.

  1. Policy exchange: messages (1) and (2)
  2. Key information exchange: messages (3) and (4)
  3. Identity and authentication information exchange: messages (5) and (6)
Figure 26-14  Negotiation process in main mode (pre-shared key authentication)

Policy Exchange

Message (1): The initiator sends an SA payload containing one or more IKE proposals to negotiate an IPSec proposal. The SA carries parameters, such as the encryption algorithm, authentication method, authentication algorithm, Diffie-Hellman (DH) group, and IKE SA lifetime.

Message (2): The responder finds the first matched IKE proposal and sends an SA payload to indicate that it accepts the negotiated IKE proposal.

Figure 26-15  Messages (1) and (2)

Key Information Exchange

Messages (3) and (4): The initiator and responder exchange DH public number (KE payload) and temporary random number (Ni, Nr). Ni and Nr are used to calculate the encryption key and authentication key.

Figure 26-16  Messages (3) and (4)

Identity and Authentication Information Exchange

Messages (5) and (6): The initiator and responder exchange the identity ID (ID payload) and verify hash values (AUTH payload). Information transmitted in messages (5) and (6) is encrypted using the key generated based on key information exchanged in messages (3) and (4), so identity information is protected. As the ID payload is encrypted in main mode, you cannot view its value in the obtained packet header.

Figure 26-17  Messages (5) and (6)

Negotiation Process in Aggressive Mode

In aggressive mode, only three messages are used in the exchange process, as shown in Figure 26-18.

Messages (1) and (2) are used to negotiate IKE proposal and exchange the Diffie-Hellman public number, mandatory auxiliary information, and identity information. Message (2) also contains the identity information sent by the responder to the initiator for authentication. Message (3) is used by the responder to authenticate the initiator.

Figure 26-18  Negotiation process in aggressive mode (pre-shared key authentication)

Message (1): The initiator sends an SA payload containing one IKE proposal. In aggressive mode, the SA payload contains only one proposal (encryption algorithm, authentication method, authentication algorithm, DH group, and IKE SA lifetime). The responder can accept or reject this proposal. This message also carries the DH public number (KE payload), temporary random number (Ni payload), and identity ID (ID payload). Identity information is not encrypted in aggressive mode, so you can view the information in the obtained packet header.

Figure 26-19  Message (1)

Message (2): The responder sends an SA payload containing the recommended IKE proposal. This message also carries the DH public number (KE payload), temporary random number (Nr payload), identity ID (ID payload), and hash value (AUTH payload).

Figure 26-20  Message (2)

Message (3): The initiator sends this message to verify the hash value and confirm negotiation success.

Figure 26-21  Message (3)

Summary

After IKEv1 phase 1 negotiation is complete, run the display ike sa command to view the IKE SA establishment. If Flag is displayed as RD or RD|ST, IKE SAs are established successfully. The value ST indicates that the local end initiates SA negotiation.

<Huawei> display ike sa
IKE SA information : 
      Conn-ID      Peer                 VPN    Flag(s)        Phase
  ------------------------------------------------------------------
      16           2.1.1.1:500                 RD|ST          v1:2
      14           2.1.1.1:500                 RD|ST          v1:1
                                               
   Number of IKE SA : 2
  -------------------------------------------------------------------
  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  

If negotiation fails, the output of this command is empty, the Flag parameter is empty, or the Peer parameter is displayed as 0.0.0.0.

If parameters such as the IKE proposal and pre-shared key on two ends of a tunnel do not match, an IKE SA cannot be established. Common debugging information for inconsistent IKE parameters is as follows:

  • The IKE proposals configured on two ends are different.

    <Huawei> debugging ikev1 error
    Aug 17 2017 14:29:15.800.1 Huawei IKE/7/IKE_Debug:
    IKE_ERROR 17:5773 Message from peer 2.1.1.1: Got NOTIFY of type NO_PROPOSAL_CHOS
    EN  
    
    Aug 17 2017 14:29:15.800.3 Huawei IKE/7/IKE_Debug:
    IKE_ERROR 0:9946 Ikev1 error-info record(peer address: 2.1.1.1, error reason: ph
    ase1 proposal mismatch,list number: 11). 
  • The pre-shared keys configured on two ends are different.

    <Huawei> debugging ikev1 error
    Aug 17 2017 15:18:09.800.1 Huawei IKE/7/IKE_Debug:
    IKE_ERROR 17:5773 Message from peer 2.1.1.1: Got NOTIFY of type PAYLOAD_MALFORME
    D  
    <Huawei> debugging ikev1 error
    Aug 17 2017 15:24:53.940.2 Huawei IKE/7/IKE_Debug:
    IKE_ERROR 17:1053 Message from peer 1.1.1.1: Invalid Next Payload of Type 60 in 
    Payload Type 5
                                                                                    
    Aug 17 2017 15:24:53.940.3 Huawei IKE/7/IKE_Debug:
    IKE_ERROR 17:6847 Message from peer 1.1.1.1: dropping Message due to notificatio
    n type INVALID_PAYLOAD_TYPE
        
    Aug 17 2017 15:24:53.940.4 Huawei IKE/7/IKE_Debug:
    IKE_ERROR 17:4538 Message from peer 1.1.1.1: Message Sort Error Occurred        
                          
    Aug 17 2017 15:24:53.940.5 Huawei IKE/7/IKE_Debug:
    IKE_ERROR 0:9946 Ikev1 error-info record(peer address: 1.1.1.1, error reason: ma
    lformed payload,list number: 200). 
  • The remote-address command is not configured on one end.

    <Huawei> debugging ikev1 error
    Aug 17 2017 16:13:33.940.3 Huawei IKE/7/IKE_Debug:
    IKE_ERROR 0:9946 Ikev1 error-info record(peer address: 1.1.1.1, error reason: pe
    er address mismatch,list number: 200).                                          
                                                                                    
    Aug 17 2017 16:13:33.940.4 Huawei IKE/7/IKE_Debug:
    IKE_ERROR 0:3595 Phase 1 Exchange: ike peer configuration not found for peer "1.
    1.1.1" 
  • The remote-id parameter value on the local end differs from the name of the remote end.

    <Huawei> debugging ikev1 error
    Aug 17 2017 16:25:01.850.2 Huawei IKE/7/IKE_Debug:
    IKE_ERROR 25:6956 ERROR - Received remote-name(fw2) does not match with peer rem
    ote-name(fw3)                                                                   
                                                                                    
    Aug 17 2017 16:25:01.850.3 Huawei IKE/7/IKE_Debug:
    IKE_ERROR 0:9946 Ikev1 error-info record(peer address: 2.1.1.1, error reason: co
    nfig ID mismatch,list number: 148). 
Negotiation Process in IKEv1 Phase 2

In IKEv1 phase 2, IPSec SAs are established for data transmission. In this phase, quick exchange mode is used and the exchanged payloads are encrypted.

Negotiation Process

Figure 26-22 shows the exchange process in quick mode.

Figure 26-22  Negotiation process in IKEv1 phase 2

Messages (1) and (2): The two messages are used to negotiate an IPSec proposal (SA payload) and negotiate the DH key group (KE payload) used in the perfect forward secrecy (PFS) function. The two messages also exchange the identity ID (ID payload, which is optional) and hash value for integrity verification (AUTH payload).

IDi and IDr are included in the ID payload, and are used to exchange the traffic selector. They ensure that data flows protected by both parties are the same. (This function is similar to that of the TS payload in IKEv2.)

Figure 26-23  Messages (1) and (2)

Message (3): The initiator sends this message to verify the hash value and confirm negotiation success. The packet format is similar to the format of message (1).

Summary

After IKEv1 phase 2 negotiation is complete, run the display ike sa command to view the IPSec SA establishment in phase 2. If Flag is displayed as RD or RD|ST, IPSec SAs are established successfully. The value ST indicates that the local end initiates SA negotiation.

<Huawei> display ike sa
IKE SA information : 
      Conn-ID      Peer                 VPN    Flag(s)        Phase
  ------------------------------------------------------------------
      16           2.1.1.1:500                 RD|ST          v1:2
      14           2.1.1.1:500                 RD|ST          v1:1
                                               
   Number of IKE SA : 2
  -------------------------------------------------------------------
  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  

If negotiation fails, the Flag parameter in the command output is empty.

Inconsistent IPSec proposals, PFS algorithms, and ACL rules on two ends may lead to the IPSec SA establishment failure. Packets in phase 2 are encrypted, so you cannot check the IPSec proposal configuration by obtaining the packet headers.

Common debugging information for inconsistent IPSec parameters is as follows:

  • ACL rules on two ends do not match.

    <Huawei> debugging ikev1 error
    Aug 17 2017 17:35:52.350.1 Huawei IKE/7/IKE_Debug:
    IKE_ERROR 17:5773 Message from peer 1.1.1.1: Got NOTIFY of type INVALID_ID_INFOR
    MATION
                                                                                    
    Aug 17 2017 17:35:52.350.2 Huawei IKE/7/IKE_Debug:
    IKE_ERROR 0:9946 Ikev1 error-info record(peer address: 1.1.1.1, error reason: fl
    ow mismatch,list number: 200).  
    <Huawei> debugging ipsec error
    Aug 17 2017 17:35:17.800.1 Huawei IPSEC/7/IPSEC-DEBUG: 
    [IPSEC-Error] acl mismatch.(Ifindex=[7], SeqNum=[10],PeerAddress=[2.1.1.1], Peer
    Port=[500])   
  • The IPSec proposals or PFS algorithms on two ends are different.

    <Huawei> debugging ikev1 error
    Aug 18 2017 09:28:45.350.2 Huawei IKE/7/IKE_Debug:
    IKE_ERROR 0:9946 Ikev1 error-info record(peer address: 2.1.1.1, error reason: ph
    ase2 proposal or pfs mismatch,list number: 200).                                
                                                                                    
    Aug 18 2017 09:28:45.350.3 Huawei IKE/7/IKE_Debug:
    IKE_ERROR 17:6847 Message from peer 2.1.1.1: dropping Message due to notificatio
    n type NO_PROPOSAL_CHOSEN
    <Huawei> debugging ipsec error
    Aug 18 2017 09:29:26.800.1 Huawei IPSEC/7/IPSEC-DEBUG:
    [IPSEC-Error] ipsec proposal or pfs mismatch.(Ifindex=[7], SeqNum=[10],PeerAddre
    ss=[2.1.1.1], PeerPort=[500]) 
IKEv2 Negotiation Process
Negotiation Process

IKEv1 goes through two phases to establish a pair of IPSec SAs: "main mode + quick mode" or "aggressive mode + quick mode". When IKEv1 phase 1 uses the main mode, IKE peers exchange at least nine messages. When IKEv1 phase 1 uses the aggressive mode, IKE peers exchange at least six messages. IKEv2, without the main mode or aggressive mode, establishes an IKE SA and a pair of IPSec SAs by exchanging four messages at two times. Figure 26-24 shows the IKEv2 negotiation process.

Figure 26-24  IKEv2 negotiation process (pre-shared key authentication)

Messages (1) and (2): In the IKE_SA_INIT exchange, the initiator and responder negotiate an IKE proposal (SA payload) and exchange the temporary random number (Ni or Nr payload) and DH public number (KE payload).

Figure 26-25  Messages (1) and (2)

Messages (3) and (4): In the IKE_AUTH exchange, the two parties continue to exchange the identity ID (ID payload) and hash value (AUTH payload), negotiate the IPSec proposal (SA payload), and determine data flows to be protected (TS payload). The N payload is used for error announcement. After negotiation, an IKE SA and a pair of IPSec SAs are established.

Figure 26-26  Messages (3) and (4)

Summary

After IKEv2 negotiation is complete, run the display ike sa command to view the IKE SA establishment. If Flag is displayed as RD or RD|ST, IKE SAs are established successfully. The value ST indicates that the local end initiates SA negotiation.

<Huawei> display ike sa
IKE SA information : 
      Conn-ID      Peer                 VPN    Flag(s)        Phase
  ------------------------------------------------------------------
      16           2.1.1.1:500                 RD|ST          v2:2
      14           2.1.1.1:500                 RD|ST          v2:1
                                               
   Number of IKE SA : 2
  -------------------------------------------------------------------
  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  

If negotiation fails, the following may occur when you run the display ike sa command:

  • If phase 1 negotiation fails, the command output is empty, the Flag parameter is empty, or the Peer parameter is displayed as 0.0.0.0.
  • If phase 2 negotiation fails, information about phase 1 is normally displayed; information about phase 2 is empty or the Flag parameter is empty.

Inconsistent IKE proposals, pre-shared keys, IPSec proposals, PFS algorithms, and ACL rules on two ends may lead to the IKE SA or IPSec SA establishment failure.

Common debugging information for inconsistent IPSec parameters is as follows:

  • The IKE proposals configured on two ends are different.

    <Huawei> debugging ikev2 error
    Aug 18 2017 14:51:00.410.2 Huawei IKE/7/IKE_Debug:
    IKE_ERROR 56:8841 Ikev2 error Info record(peer address: 2.1.1.1, error reason: p
    hase1 proposal mismatch,list number: 200).   
  • The pre-shared keys configured on two ends are different.

    <Huawei> debugging ikev2 error
    Aug 18 2017 15:02:25.540.2 Huawei IKE/7/IKE_Debug:
    IKE_ERROR 63:4087 Authentication failed for the peer 2.1.1.1                    
    
    Aug 18 2017 15:02:25.540.4 Huawei IKE/7/IKE_Debug:
    IKE_ERROR 56:8841 Ikev2 error Info record(peer address: 2.1.1.1, error reason: a
    uthentication fail,list number: 4). 
  • The remote-id parameter value on the local end differs from the name of the remote end.

    <Huawei> debugging ikev2 error
    Aug 18 2017 15:39:32.50.4 Huawei IKE/7/IKE_Debug:
    IKE_ERROR 27:27568 ERROR - Peer remote-name(fw3) does not match with
                                                                                    
    Aug 18 2017 15:39:32.50.5 FW1 IKE/7/IKE_Debug:
    IKE_ERROR 56:8841 Ikev2 error Info record(peer address: 2.1.1.1, error reason: c
    onfig ID mismatch,list number: 151). 
  • The remote-address command is not configured on one end.

    <Huawei> debugging ikev2 error
    Aug 18 2017 15:23:04.400.1 Huawei IKE/7/IKE_Debug:
    IKE_ERROR 56:8841 Ikev2 error Info record(peer address: 2.1.1.1, error reason: p
    eer address mismatch,list number: 107).  
  • ACL rules on two ends do not match.

    <Huawei> debugging ikev2 error
    Aug 18 2017 15:27:40.750.1 Huawei IKE/7/IKE_Debug:
    IKE_ERROR 56:8841 Ikev2 error Info record(peer address: 1.1.1.1, error reason: f
    low mismatch,list number: 200). 
    
    <Huawei> debugging ipsec error
    Aug 18 2017 15:29:46.650.1 Huawei IPSEC/7/IPSEC-DEBUG:
    [IPSEC-Error] acl mismatch.(Ifindex=[7], SeqNum=[0],PeerAddress=[1.1.1.1], PeerP
    ort=[500]) 
  • The IPSec proposals or PFS algorithms on two ends are different.

    <Huawei> debugging ikev2 error
    Aug 19 2017 09:41:40.800.2 Huawei IKE/7/IKE_Debug:
    IKE_ERROR 56:8841 Ikev2 error Info record(peer address: 2.1.1.1, error reason: p
    hase2 proposal or pfs mismatch,list number: 200).    
    <Huawei> debugging ipsec error
    Aug 19 2017 09:44:25.760.2 Huawei IPSEC/7/IPSEC-DEBUG:                             
    [IPSEC-Error] ipsec proposal or pfs mismatch.(Ifindex=[7], SeqNum=[10],PeerAddre
    ss=[2.1.1.1], PeerPort=[500])  
IKE Negotiation with NAT Traversal

When a NAT gateway is deployed between devices on two ends of an IPSec tunnel, IKE automatically completes NAT-T capability negotiation, NAT gateway detection, and SA establishment.

IKEv1 Negotiation with NAT Traversal
In the NAT traversal scenario using IKEv1, the following must be detected in phase 1 negotiation:
  • Support for NAT traversal (NAT-T capability)

    IKEv1 uses the VID payload to determine whether NAT traversal is supported.

  • Presence of a NAT gateway

    IKEv1 uses the NAT-D payload to detect whether a NAT gateway exists between two IKE peers and determine its location (finding the device connecting to the NAT gateway) if available.

As the NAT gateway changes the source port number in IKE UDP packets, the responder must be able to process IKE packets whose source port number is not 500.

Figure 26-27 shows the negotiation process of IKEv1 phase 1 in aggressive mode with NAT traversal.

The negotiation process in main mode with NAT traversal is omitted here. The process is similar to Negotiation Process in Main Mode, with only the following differences: The VID payload is added to messages (1) and (2), and the NAT-D payload is added to messages (3) and (4).

Figure 26-27  Negotiation process of IKEv1 phase 1 in aggressive mode with NAT traversal (pre-shared key authentication)

Message (1): The initiator inserts the VID payload to an IKE message to inform the receiver that it supports NAT traversal. If IKEv1 messages sent by both parties contain the VID payload, both parties support NAT-T. In this case, negotiation continues. Otherwise, the process comes to an end.

Figure 26-28  Message (1)

Message (2): The responder inserts the VID payload to an IKE message to inform the receiver that it supports NAT traversal. The responder also adds two NAT-D payloads to the message. The first NAT-D payload contains the IP address of the IKE peer and the port's hash value; the second NAT-D payload contains the IP address of the local end and the port's hash value. Both the initiator and responder calculate the hash values and compare them with local ones. The device with inconsistent hash values is connected to the NAT gateway.

Figure 26-29  Message (2)

Message (3): After confirming NAT-T support and detecting NAT gateway, the port number in subsequent UDP packets is modified to 4500 if a NAT gateway is detected.

Figure 26-30  Message (3)

The non-ESP marker field (four all-0 bytes) is added under UDP encapsulation of IPSec packets to distinguish from encapsulation of ESP packets.

In IKEv1 phase 2 SA negotiation, whether NAT traversal is used and the encapsulation mode (UDP-Encapsulated-tunnel or UDP-Encapsulated-transport) for NAt traversal must be confirmed. Then, subsequently transmitted ESP packets are encapsulated using UDP (as the AH protocol does not support NAT traversal). After an ESP packet is encapsulated using UDP, the packet does not contain the non-ESP marker field. Instead, this field is replaced by the SPI field, which consists non-0 bytes.

IKEv2 Negotiation with NAT Traversal

In the NAT traversal scenario using IKEv2, the initiator and responder add two N payloads (next to the Ni or Nr payload) in IKE_SA_INIT exchange. One message type is NAT_DETECTION_SOURCE_IP, which identifies the initiator's IP address. The other message type is NAT_DETECTION_DESTINATION_IP, which identifies the responder's IP address.

Figure 26-31 shows the IKEv2 negotiation process with NAT traversal.

Figure 26-31  IKEv2 negotiation process with NAT traversal (pre-shared key authentication)

Messages (1) and (2): Two N payloads are inserted to an IKE message. The first N payload contains the IP address of the local end and the port's hash value; the second N payload contains the IP address of the IKE peer and the port's hash value. Both the initiator and responder calculate the hash values and compare them with local ones. The device with inconsistent hash values is connected to the NAT gateway.

Figure 26-32  Messages (1) and (2)

Messages (3) and (4): After the IKE_SA_INIT exchange, the port number of UDP packets is modified to 4500 if a NAT device is detected.

Figure 26-33  Messages (3) and (4)

Summary

The NAT traversal function must be enabled on both ends to ensure IKE negotiation success.

After IKE negotiation is complete, run the display ike sa command to view the SA establishment. If Flag is displayed as RD or RD|ST, IKE SAs are established successfully. The value ST indicates that the local end initiates SA negotiation.

<Huawei> display ike sa
IKE SA information : 
      Conn-ID      Peer                 VPN    Flag(s)        Phase
  ------------------------------------------------------------------
      16           2.1.1.1:4500                RD|ST          v2:2
      14           2.1.1.1:4500                RD|ST          v2:1
                                               
   Number of IKE SA : 2
  -------------------------------------------------------------------
  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  

Abnormal Services After Successful IPSec Tunnel Setup

IPSec Packet Forwarding Process

Figure 26-34 shows the IPSec packet forwarding process.

Figure 26-34  IPSec packet forwarding process

In the Router processing procedure, IPSec processes packets after NAT, routing, and security policies. It must be ensured that no NAT policy processes IPSec protected packets, and the packets can match a route and security policy to be forwarded to an interface to which an IPSec policy is applied. The following requirements must be met:

  1. The packet arriving at the Router does not match the destination NAT policy. Otherwise, the destination address of the packet will be converted.
  2. The routing table must have a route (usually a default route) to the private network of the IKE peer. The outbound interface in the route must have an IPSec policy applied. If the packet does not match any route in the routing table, the packet will be discarded. If the outbound interface in the matching route does not have an IPSec policy applied, the packet will not be processed by the IPSec module. Instead, the outbound interface sends the packet in plain text.
  3. The packet entering the IPSec module is protected only if it matches a security ACL. Otherwise, the packet will be discarded.
    NOTE:

    Data flows triggering IKE negotiation follow the preceding procedure too. If a data flow fails in any stage along this procedure, it will not trigger IKE negotiation.

IPSec Working Principles

The security policy database (SPD) is basis for establishment of IPSec SAs, which defines data flows to be protected by IPSec. The security association database (SAD) is used to store all attributes of the IPSec SAs.

This section describes IPSec working principles using point-to-point unidirectional data transmission (in tunnel mode) as an example. In Figure 26-35, Router1 is the branch gateway; Router2 is the simulated carrier device; Router3 is the headquarters gateway. PC1 and PC2 are private network hosts in the branch and headquarters. IPSec is deployed on Router1 and Router3 to protect communication between the network segments where PC1 and PC2 reside. IPSec encrypts packets transmitted between GE0/0/2 on Router1 and GE0/0/2 on Router3.

Figure 26-35  IPSec VPN working principles

  • Router1

    1. PC1 sends an IP packet with PC2's address as the destination address to Router1.

    2. After receiving this packet from PC1, Router1 searches for a route to PC2 in the routing table.

    3. Router1 finds that the outbound interface is GE0/0/2, and forwards the packet to GE0/0/2.

    4. After the packet reaches the outbound interface with the IPSec policy applied, it checks the packet based on packet characteristics to determine whether the packet should be protected by IPSec (using an ACL). If so, the outbound interface encapsulates the packet based on negotiated IPSec parameters. The steps are as follows:

      1. The outbound interface searches the SPD and determines whether to process this packet using IPSec based on the source and destination addresses.

        • If the action is permit, the packet needs to be processed by the IPSec module.
        • If the action is drop, the packet does not need to be processed by the IPSec module.
      2. The outbound interface searches for an SA based on the destination address.

        • If a matching entry is found, go to step c. (In manual mode, the SA and SAD have been generated after the configuration is complete.)
        • If no matching entry is found, the outbound interface initiates IKE negotiation. After successful negotiation, two engaged devices generate their own SA and SAD.
      3. Based on the SPI, the outbound interface searches for a matching IPSec SA in the SAD. Then, it encrypts the packet, calculates the hash value, and encapsulates the packet based on the parameters of the SA.
    5. The outbound interface GE0/0/2 forwards the encapsulated packet along the found route.
  • Router2

    Router2 forwards the packet based on the routing information.

  • Router3

    1. Router3 receives the packet on GE0/0/2, and finds the destination address being its own IP address. So, Router3 sends the packet to the network layer to determine whether it is an IPSec packet (IP protocol number: ESP 50; AH 51). If so, the IPSec module decrypts and decapsulates the packet. The steps are as follows:

      1. (Optional) The IPSec module searches the SPD and performs pre-IPSec check on the (unencrypted) IP packet.

        If the packet needs to be encrypted but not, the packet will be discarded.

      2. The IPSec module searches the SAD and SA based on the SPI, destination IP address, and protocol number. Then, it decapsulates, verifies, and decrypts the packet based on the SA parameter settings.

      3. (Optional) The IPSec module searches the SPD and performs post-IPSec check on the decrypted IP packet.

        If the packet not requiring encryption is encrypted, the packet will be discarded.

    2. After packet decapsulation, Router3 searches for the outbound interface based on the destination address. It finds that the destination address is in the same network segment as the local outbound interface, so it forwards the packet through GE0/0/1 based on the ARP table.
Poor IPSec Service Quality

In Figure 26-36, an IPSec tunnel is successfully established between Routers.

Figure 26-36  Point-to-point IPSec networking

Impact by CPU Performance
  • IPSec service quality deterioration caused by CPU resource consumption during packet fragmentation

    • By maximum transmission unit (MTU) value

      The MTU value supported by a link is determined by the smallest MTU value of an interface on this link, while the interface MTU value varies with the interface type. (For example, the default MTU value of an Ethernet interface is 1500 bytes.) If the size of a packet exceeds the interface MTU, the device fragments the encrypted packet before sending it. The receiver needs to reassemble all the fragments of an IP packet before decrypting it. Fragmentation and reassembly consume CPU resources.

      In the IPSec packet encapsulation process, the cost increases each time the IPSec module encapsulates the received original IP packets. The increased cost varies with the encapsulation protocol. For details, see Table 26-6. Assume that the cost increases by 80 bytes after IPSec processing. Packets containing more than 1420 bytes will carry more than 1500 bytes after IPSec encapsulation; therefore, they need to be fragmented. When most packets in data flows are large packets exceeding 1420 bytes, a large number of CPU resources are consumed. This will lead to decrease of the IPSec service access speed and service quality deterioration.

      Table 26-6  Cost of bytes by protocol

      Protocol

      Increased Bytes

      ESP

      Default value: 56

      The increased cost of ESP depends on the encryption algorithm and whether an authentication algorithm is used.

      AH 24
      GRE 24
      NAT-T 8
      L2TP 12
      PPPoE 8
      IPSec tunnel mode 20
      TCP 8
    • By Transmission Control Protocol maximum segment size (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.

  • IPSec service quality deterioration caused by CPU resource consumption by other features

    Features such as IPSec, deep packet inspection (DPI), Unified Threat Management (UTM), and attack defense consume large CPU resources. Therefore, if IPSec, DPI, UTM, and other features are enabled simultaneously, the IPSec service access speed will become slow. The larger the data volume, the more obvious the problem.

Impact by Internet Quality

IPSec is used to secure communication between virtual networks over the Internet. The transmission quality of the Internet has a direct import on the IPSec service quality. You can deploy the VPN in bypass mode to determine whether the poor IPSec quality is caused by the poor transmission quality on the Internet. If the transmission quality on the Internet is poor, contact the carrier. The Internet may encounter the following problems:

  • The Internet encounters network congestion, leading to packet loss or network interruption. Packet loss has a huge impact on the quality of voice and video services, and obviously slows down web browsing and file transfer. Network interruption will directly lead to service interruption.
  • The carrier denies packets of specific types, for example, UDP packets. If so, IKE negotiation will fail in the NAT traversal scenario.
  • The carrier disables ports such as ports 500 and 4500 used by the IPSec service. If port 500 is disabled, IKE negotiation will fail. If port 4500 is disabled, IKE negotiation will fail in the NAT traversal scenario.

Debugging Information

The following describes the IKE negotiation packet exchange process based on debugging information. Figure 26-37 shows IPSec networking. Router1 is the IKE initiator, and Router2 is the IKE responder.

Figure 26-37  IPSec networking

IKEv1 Phase 1 Negotiation

Main mode

During IKEv1 phase 1 negotiation, the main mode uses six messages to implement three bidirectional exchanges.

  1. The initiator sends an SA payload containing IKE proposals to the responder for IKE proposal negotiation.

    Sep 28 2017 21:05:59.550.3+08:00 Huawei IKE/7/IKE_Debug:
    IKE_PACKET 17:4686 IKE Packet Contents sent to 2.1.1.1 for message type Send_SA : f317d868 c8f3069a 00000000 00000000 01100200 00000000 000000d0 0d00003c 00000001 00000001 00000030 01010001 00000028 00010000 80010007 800e0100 80020004 80030001 8004000e 800b0001 000c0004 00015180 0d000014 4a131c81 07035845 5c5728f2 0e95452f 0d000014 90cb8091 3ebb696e 086381b5 ec427b1f 0d000014 4485152d 18b6bbcd 0be8a846 9579ddcc 0d000014 12f5f28c 457168a9 702d9fe2 74cc0100 0d000014 afcad713 68a1f1c9 6b8696fc 77570100 00000014 48554157 45492d49 4b457631 44534350 

    The responder receives the SA payload sent from the initiator and parses the IKE proposal.

    Sep 28 2017 21:23:39.960.14+00:00 Huawei IKE/7/IKE_Debug:
    IKE_PACKET 17:4930 IKE Packet Contents sent to 1.1.1.1 for message type Send_SA : f317d868 c8f3069a 7396dfa0 3f8f51ac 01100200 00000000 000000a8 0d00003c 00000001 00000001 00000030 01010001 00000028 00010000 80010007 800e0100 80020004 80030001 8004000e 800b0001 000c0004 00015180 0d000014 4a131c81 07035845 5c5728f2 0e95452f 0d000014 12f5f28c 457168a9 702d9fe2 74cc0100 0d000014 afcad713 68a1f1c9 6b8696fc 77570100 00000014 48554157 45492d49 4b457631 44534350
    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
    
  2. The responder searches for the first matching IKE proposal and sends an SA payload containing this accepted IKE proposal to the initiator.

    Sep 28 2017 21:23:39.960.14+00:00 Huawei IKE/7/IKE_Debug:
    IKE_PACKET 17:4930 IKE Packet Contents sent to 1.1.1.1 for message type Send_SA : f317d868 c8f3069a 7396dfa0 3f8f51ac 01100200 00000000 000000a8 0d00003c 00000001 00000001 00000030 01010001 00000028 00010000 80010007 800e0100 80020004 80030001 8004000e 800b0001 000c0004 00015180 0d000014 4a131c81 07035845 5c5728f2 0e95452f 0d000014 12f5f28c 457168a9 702d9fe2 74cc0100 0d000014 afcad713 68a1f1c9 6b8696fc 77570100 00000014 48554157 45492d49 4b457631 44534350 

    The initiator receives the SA payload containing an accepted IKE proposal from the responder.

    Sep 28 2017 21:05:59.640.3+08:00 Huawei IKE/7/IKE_Debug:
    IKE_PACKET 17:4508 IKE Packet Contents received from 2.1.1.1 for message type Recv_SA : f317d868 c8f3069a 7396dfa0 3f8f51ac 01100200 00000000 000000a8 0d00003c 00000001 00000001 00000030 01010001 00000028 00010000 80010007 800e0100 80020004 80030001 8004000e 800b0001 000c0004 00015180 0d000014 4a131c81 07035845 5c5728f2 0e95452f 0d000014 12f5f28c 457168a9 702d9fe2 74cc0100 0d000014 afcad713 68a1f1c9 6b8696fc 77570100 00000014 48554157 45492d49 4b457631 44534350 
  3. The initiator sends the KE_NONCE payload containing key generation information to the responder to exchange DH public keys and random values.

    Sep 28 2017 21:05:59.640.17+08:00 Huawei IKE/7/IKE_Debug:
    IKE_PACKET 17:4686 IKE Packet Contents sent to 2.1.1.1 for message type Send_KE_NONCE : f317d868 c8f3069a 7396dfa0 3f8f51ac 04100200 00000000 0000017c 0a000104 df472637 7fa66305 d2384b82 b84d4353 68def6ae c4268e3f 67c14e13 806ae6bc 5cc688d4 41a8432b dba680c6 ebda9743 122c7455 f23506e0 48f48f12 c47ec9c7 ded96633 9243bf39 cfc0d4d1 17e90213 6a5f63b8 8515d842 a0700a2e bdb99617 7415fecb c97729df 1da1f800 c5eb8a26 69ac9eb6 8f41b6ee ec7edeed ecc41809 472abea5 77535f28 c00a0b10 ad762132 f46b71f2 ac90f9c4 acb41a85 a7234845 03f436e6 504deb10 61563be5 7272b2d5 9114401a 423b18a4 f0d21ecd bbafc3a1 f28fe579 9341b6ac b21ce40a 97e546c5 213947a6 85d7b0b0 4f1f417b 720277f4 823649ea 419f2e30 ca64b8ac 480f8793 9a145154 bfeba9ac bc9eeb68 752bb8c8 14000014 ab3c6161 89aada4f ddd6d33d 36bdb605 14000024 45adbbf1 55321d99 5b9c9aaf ada3c518 eed6994c 3f45c4d2 696207

    The responder receives the KE_NONCE payload from the initiator.

    Sep 28 2017 21:23:40.90.12+00:00 Huawei IKE/7/IKE_Debug:
    IKE_PACKET 17:4752 IKE Packet Contents received from 1.1.1.1 for message type Recv_KE_NONCE : f317d868 c8f3069a 7396dfa0 3f8f51ac 04100200 00000000 0000017c 0a000104 df472637 7fa66305 d2384b82 b84d4353 68def6ae c4268e3f 67c14e13 806ae6bc 5cc688d4 41a8432b dba680c6 ebda9743 122c7455 f23506e0 48f48f12 c47ec9c7 ded96633 9243bf39 cfc0d4d1 17e90213 6a5f63b8 8515d842 a0700a2e bdb99617 7415fecb c97729df 1da1f800 c5eb8a26 69ac9eb6 8f41b6ee ec7edeed ecc41809 472abea5 77535f28 c00a0b10 ad762132 f46b71f2 ac90f9c4 acb41a85 a7234845 03f436e6 504deb10 61563be5 7272b2d5 9114401a 423b18a4 f0d21ecd bbafc3a1 f28fe579 9341b6ac b21ce40a 97e546c5 213947a6 85d7b0b0 4f1f417b 720277f4 823649ea 419f2e30 ca64b8ac 480f8793 9a145154 bfeba9ac bc9eeb68 752bb8c8 14000014 ab3c6161 89aada4f ddd6d33d 36bdb605 14000024 45adbbf1 55321d99 5b9c9aaf ada3c518 eed6994c 3f45c4d2
  4. The responder sends the KE_NONCE payload containing key generation information to the initiator to exchange DH public keys and random values.

    Sep 28 2017 21:23:40.130.5+00:00 Huawei IKE/7/IKE_Debug:
    IKE_PACKET 17:4930 IKE Packet Contents sent to 1.1.1.1 for message type Send_KE_NONCE : f317d868 c8f3069a 7396dfa0 3f8f51ac 04100200 00000000 0000017c 0a000104 7e6d6a34 5c2d75ac 99191319 b70fa1f5 1ef90be5 dd9ce7a3 72212d62 3b2c72f2 63eb8814 d8cbc79d f36f7eca b2a48213 23a1fdd0 88f8d9d9 7ce43440 a575a8fa b7f53fb5 3eaaea9f 697a46c7 c17b8485 862b8d10 5af8408c 4f956aff a9aa2ca7 97dc36ae 8531c1f6 0ce3bc6b b512598b 23310897 c2e7c175 5389cd01 4825f232 5eac6d43 2a0cbd0d eae4dde3 996bed59 d11e8c0c 31d5324b e832228d 7d3df4fa e117a789 3849c861 681ec20e 627dbbdc e6b74a8b 82f19bd8 22be4e35 8cbe07af 62b3bbc7 10c9ab38 5a6d6203 61586945 c6b436d6 d9c786cc e54a4dc4 bf37ef88 d77786a8 af8986d2 25434234 aca11cad 8822f627 ae0b3154 1ba2939b dce25b94 14000014 ab4da180 3e475ced 49674378 13c48755 14000024 76104f49 2e45250e cd0cb85f f02a5cc9 f76f4563 df2874b2 45411b

    The initiator receives the KE_NONCE payload from the responder.

    Sep 28 2017 21:05:59.800.6+08:00 Huawei IKE/7/IKE_Debug:
    IKE_PACKET 17:4508 IKE Packet Contents received from 2.1.1.1 for message type Recv_KE_NONCE : f317d868 c8f3069a 7396dfa0 3f8f51ac 04100200 00000000 0000017c 0a000104 7e6d6a34 5c2d75ac 99191319 b70fa1f5 1ef90be5 dd9ce7a3 72212d62 3b2c72f2 63eb8814 d8cbc79d f36f7eca b2a48213 23a1fdd0 88f8d9d9 7ce43440 a575a8fa b7f53fb5 3eaaea9f 697a46c7 c17b8485 862b8d10 5af8408c 4f956aff a9aa2ca7 97dc36ae 8531c1f6 0ce3bc6b b512598b 23310897 c2e7c175 5389cd01 4825f232 5eac6d43 2a0cbd0d eae4dde3 996bed59 d11e8c0c 31d5324b e832228d 7d3df4fa e117a789 3849c861 681ec20e 627dbbdc e6b74a8b 82f19bd8 22be4e35 8cbe07af 62b3bbc7 10c9ab38 5a6d6203 61586945 c6b436d6 d9c786cc e54a4dc4 bf37ef88 d77786a8 af8986d2 25434234 aca11cad 8822f627 ae0b3154 1ba2939b dce25b94 14000014 ab4da180 3e475ced 49674378 13c48755 14000024 76104f49 2e45250e cd0cb85f f02a5cc9 f76f4563 df2874b2 
  5. The initiator sends the ID_AUTH payload containing its identity and hash authentication information to the responder.

    Sep 28 2017 21:05:59.830.6+08:00 Huawei IKE/7/IKE_Debug:
    IKE_PACKET 17:4686 IKE Packet Contents sent to 2.1.1.1 for message type Send_ID_AUTH : f317d868 c8f3069a 7396dfa0 3f8f51ac 05100200 00000000 0000004c 0800000c 01000000 01010101 00000024 3b69c54a d8478f81 bd61cf3d 9ee8bf59 32846302 a306e6e2 e3645724 9db520af 

    The responder receives the ID_AUTH payload from the initiator.

    Sep 28 2017 21:23:40.210.9+00:00 Huawei IKE/7/IKE_Debug:
    IKE_PACKET 17:4752 IKE Packet Contents received from 1.1.1.1 for message type Recv_ID_AUTH : f317d868 c8f3069a 7396dfa0 3f8f51ac 05100201 00000000 0000004c 0800000c 01000000 01010101 00000024 3b69c54a d8478f81 bd61cf3d 9ee8bf59 32846302 a306e6e2 e3645724 9db520af 
  6. The responder sends the ID_AUTH payload containing its identity and hash authentication information to the initiator.

    Sep 28 2017 21:23:40.220.12+00:00 Huawei IKE/7/IKE_Debug:
    IKE_PACKET 17:4930 IKE Packet Contents sent to 1.1.1.1 for message type Send_ID_AUTH : f317d868 c8f3069a 7396dfa0 3f8f51ac 05100200 00000000 0000004c 0800000c 01000000 02010101 00000024 ec4df8c8 6b4ec863 36b71e01 57857ef6 20ea5aec 3713bc3e 79867e66 3b489fbe 

    The initiator receives the ID_AUTH payload from the responder.

    Sep 28 2017 21:05:59.890.15+08:00 Huawei IKE/7/IKE_Debug:
    IKE_PACKET 17:4508 IKE Packet Contents received from 2.1.1.1 for message type Recv_ID_AUTH : f317d868 c8f3069a 7396dfa0 3f8f51ac 05100201 00000000 0000004c 0800000c 01000000 02010101 00000024 ec4df8c8 6b4ec863 36b71e01 57857ef6 20ea5aec 3713bc3e 79867e66 3b489fbe 

Aggressive mode

During IKEv1 phase 1 negotiation, the aggressive mode uses three messages.

  1. The initiator sends the SA_KE_NONCE_ID_VID payload containing IKE proposals, key generation information, and its identity to the responder.

    Sep 28 2017 21:21:03.960.11+08:00 Huawei IKE/7/IKE_Debug:
    IKE_PACKET 17:4686 IKE Packet Contents sent to 2.1.1.1 for message type Send_SA_KE_NONCE_ID_VID : a1588ac6 a6a062d4 00000000 00000000 01100400 00000000 000001f4 0400003c 00000001 00000001 00000030 01010001 00000028 00010000 80010007 800e0100 80020004 80030001 8004000e 800b0001 000c0004 00015180 0a000104 e932c0c6 ad23a42e 52150f0e ce602358 12b88390 ea4ec8d3 3b53063b c1e87f8c 1fa61767 f6b4e370 cac38dd7 0515a745 1d01dd83 6ba29a3a 3a9bdc2c 3b061c58 14ce8cab ae289fb4 70f10c3d 7f6d2b13 1e76eeeb c9110651 d6445cd4 1f48d7b4 84112da5 42cb440d dce58d57 6bc2030a 45fa4dd3 c1ec0853 9b66b104 0a87eaea b81aea68 d0e8ff2e 8634a006 2beba703 4259d6ec f9b878aa 6349e8fa e8dc81ee f3b1f752 0fb99206 be7736d3 45c98c7c 2a092112 73efbc93 b7f778b6 1f07f98c 58261a12 99dae705 0374926a 0a3ae551 ea6435fa 04fd2a9a 0a7626a0 e1833473 8e7c1cdf 53f8c1b0 300adde1 c3e5780c 083e6

    The responder receives the SA_KE_NONCE_ID_VID payload sent from the initiator and parses the IKE proposal.

    Sep 28 2017 21:38:44.370.5+00:00 Huawei IKE/7/IKE_Debug:
    IKE_PACKET 17:4752 IKE Packet Contents received from 1.1.1.1 for message type Recv_SA_KE_NONCE_ID_VID : a1588ac6 a6a062d4 00000000 00000000 01100400 00000000 000001f4 0400003c 00000001 00000001 00000030 01010001 00000028 00010000 80010007 800e0100 80020004 80030001 8004000e 800b0001 000c0004 00015180 0a000104 e932c0c6 ad23a42e 52150f0e ce602358 12b88390 ea4ec8d3 3b53063b c1e87f8c 1fa61767 f6b4e370 cac38dd7 0515a745 1d01dd83 6ba29a3a 3a9bdc2c 3b061c58 14ce8cab ae289fb4 70f10c3d 7f6d2b13 1e76eeeb c9110651 d6445cd4 1f48d7b4 84112da5 42cb440d dce58d57 6bc2030a 45fa4dd3 c1ec0853 9b66b104 0a87eaea b81aea68 d0e8ff2e 8634a006 2beba703 4259d6ec f9b878aa 6349e8fa e8dc81ee f3b1f752 0fb99206 be7736d3 45c98c7c 2a092112 73efbc93 b7f778b6 1f07f98c 58261a12 99dae705 0374926a 0a3ae551 ea6435fa 04fd2a9a 0a7626a0 e1833473 8e7c1cdf 53f8c1b0 300adde1 c3e5780c
    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
    
  2. The responder searches for the first matching IKE proposal and sends the SA_KE_NONCE_ID_VID_NATD_AUTH payload containing this accepted IKE proposal, key generation information, its identity, and authentication information to the initiator.

    Sep 28 2017 21:38:44.420.6+00:00 Huawei IKE/7/IKE_Debug:
    IKE_PACKET 17:4930 IKE Packet Contents sent to 1.1.1.1 for message type Send_SA_KE_NONCE_ID_VID_NATD_AUTH : a1588ac6 a6a062d4 60fd9a0c d0d75e72 01100400 00000000 00000238 0400003c 00000001 00000001 00000030 01010001 00000028 00010000 80010007 800e0100 80020004 80030001 8004000e 800b0001 000c0004 00015180 0a000104 a0bd8569 a2ec9c8e 66509d14 11cdf928 a165526e 6866be8e 846becb3 fe0e9aec 0eef08e4 4b3209b3 45e38d39 5e3c84b5 50025fa9 0352a987 f4b26ec5 49981fcd d07040cd 031f1829 460eaa77 8e3e69d6 b9dba239 889e2708 96f0473f de5867fe 6f5ca16b 00ab7133 4c864f03 aab59f1c 0e3f369c 78f73985 c9862cea 0dda80d7 21451b5b 7cbea87e 7585dd89 2f6795e7 2c06cc0a a4846da0 ced85686 75c51116 173fb7d8 8fe8f460 e66bedcc 67afd20f 90b15ba2 557f9fb6 c0929fc6 d8618b64 054bcdc9 b3e3762e 0d130bcb d1977450 3d64bdb9 cb2587b5 f87a97dc 561e78e4 876e0d45 b68a8ca6 0b3ef91c ac3d

    The initiator receives the SA_KE_NONCE_ID_VID_NATD_AUTH payload from the responder.

    Sep 28 2017 21:21:04.100.10+08:00 Huawei IKE/7/IKE_Debug:
    IKE_PACKET 17:4508 IKE Packet Contents received from 2.1.1.1 for message type Recv_SA_KE_NONCE_ID_VID_NATD_AUTH : a1588ac6 a6a062d4 60fd9a0c d0d75e72 01100400 00000000 00000238 0400003c 00000001 00000001 00000030 01010001 00000028 00010000 80010007 800e0100 80020004 80030001 8004000e 800b0001 000c0004 00015180 0a000104 a0bd8569 a2ec9c8e 66509d14 11cdf928 a165526e 6866be8e 846becb3 fe0e9aec 0eef08e4 4b3209b3 45e38d39 5e3c84b5 50025fa9 0352a987 f4b26ec5 49981fcd d07040cd 031f1829 460eaa77 8e3e69d6 b9dba239 889e2708 96f0473f de5867fe 6f5ca16b 00ab7133 4c864f03 aab59f1c 0e3f369c 78f73985 c9862cea 0dda80d7 21451b5b 7cbea87e 7585dd89 2f6795e7 2c06cc0a a4846da0 ced85686 75c51116 173fb7d8 8fe8f460 e66bedcc 67afd20f 90b15ba2 557f9fb6 c0929fc6 d8618b64 054bcdc9 b3e3762e 0d130bcb d1977450 3d64bdb9 cb2587b5 f87a97dc 561e78e4 876e0d45 b68a8ca6 0b3ef91
  3. The initiator sends the NATD_AUTH payload containing authentication information to the responder.

    Sep 28 2017 21:21:04.140.3+08:00 Huawei IKE/7/IKE_Debug:
    IKE_PACKET 17:4686 IKE Packet Contents sent to 2.1.1.1 for message type Send_NATD_AUTH : a1588ac6 a6a062d4 60fd9a0c d0d75e72 14100400 00000000 00000088 14000024 f4cc10b9 7b1188c7 c16262a0 a09d5ffb 081754a1 35112614 588dbea3 65fa8099 08000024 877f64e2 d1475aab 08081f20 0d4ba079 cdb78f79 0a70b6b8 9385f12b 9de1c9ab 00000024 f74224a0 14d354e2 6a999f6b 626b158c 71d23e63 80cc8463 cba6eeae 51638100

    The responder receives the NATD_AUTH payload from the initiator.

    Sep 28 2017 21:38:44.540.13+00:00 Huawei IKE/7/IKE_Debug:
    IKE_PACKET 17:4752 IKE Packet Contents received from 1.1.1.1 for message type Responder_recv_NATD_AUTH : a1588ac6 a6a062d4 60fd9a0c d0d75e72 14100401 00000000 00000088 14000024 f4cc10b9 7b1188c7 c16262a0 a09d5ffb 081754a1 35112614 588dbea3 65fa8099 08000024 877f64e2 d1475aab 08081f20 0d4ba079 cdb78f79 0a70b6b8 9385f12b 9de1c9ab 00000024 f74224a0 14d354e2 6a999f6b 626b158c 71d23e63 80cc8463 cba6eeae 51638100 00000000 

IKEv1 Phase 2 Negotiation

During IKEv1 phase 2 negotiation, only three messages are used.

  1. The initiator sends the HASH_SA_NONCE payload containing IPSec proposals, its identity, and authentication information to the responder.

    Sep 28 2017 21:21:04.160.5+08:00 Huawei IKE/7/IKE_Debug:
    IKE_PACKET 17:4686 IKE Packet Contents sent to 2.1.1.1 for message type Send_HASH_SA_NONCE : a1588ac6 a6a062d4 60fd9a0c d0d75e72 08102000 2e398765 000000b8 01000024 a385a80b ae4d3d24 3e63ad1d c749c575 ec522e64 ed8d91ea 5fd1c0d3 52f00bd9 0a000044 00000001 00000001 00000038 01030401 00d7609a 0000002c 010c0000 80010001 00020004 00000e10 80010002 00020004 001c2000 80040001 80050005 80060080 05000014 65426071 2d47e2a9 045c83bd 21534540 05000010 04000000 0a010100 ffffff00 00000010 04000000 0a010200 ffffff00 

    The responder receives the HASH_SA_NONCE payload sent from the initiator and parses the IPSec proposal.

    Sep 28 2017 21:38:44.600.3+00:00 Huawei IKE/7/IKE_Debug:
    IKE_PACKET 17:4752 IKE Packet Contents received from 1.1.1.1 for message type Recv_HASH_SA_NONCE : a1588ac6 a6a062d4 60fd9a0c d0d75e72 08102001 2e398765 000000b8 01000024 a385a80b ae4d3d24 3e63ad1d c749c575 ec522e64 ed8d91ea 5fd1c0d3 52f00bd9 0a000044 00000001 00000001 00000038 01030401 00d7609a 0000002c 010c0000 80010001 00020004 00000e10 80010002 00020004 001c2000 80040001 80050005 80060080 05000014 65426071 2d47e2a9 045c83bd 21534540 05000010 04000000 0a010100 ffffff00 00000010 04000000 0a010200 ffffff00 00000000 
    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
    
  2. The responder searches for the first matching IPSec proposal and sends the HASH_SA_NONCE payload containing this accepted IPSec proposal, its identity, and authentication information to the initiator.

    Sep 28 2017 21:38:44.630.10+00:00 Huawei IKE/7/IKE_Debug:
    IKE_PACKET 17:4930 IKE Packet Contents sent to 1.1.1.1 for message type Send_HASH_SA_NONCE : a1588ac6 a6a062d4 60fd9a0c d0d75e72 08102000 2e398765 000000b8 01000024 4ae6231b 8ecc7d32 6b652050 1287c765 9ad89e4a 31a9c0bc e0047c96 b7d0bf7f 0a000044 00000001 00000001 00000038 01030401 00cd88b8 0000002c 010c0000 80010001 00020004 00000e10 80010002 00020004 001c2000 80040001 80050005 80060080 05000014 89e510df 9582036a db91abe2 1dd56bca 05000010 04000000 0a010100 ffffff00 00000010 04000000 0a010200 ffffff00 

    The initiator receives the HASH_SA_NONCE payload from the responder.

    Sep 28 2017 21:21:04.310.2+08:00 Huawei IKE/7/IKE_Debug:
    IKE_PACKET 17:4508 IKE Packet Contents received from 2.1.1.1 for message type Recv_HASH_SA_NONCE : a1588ac6 a6a062d4 60fd9a0c d0d75e72 08102001 2e398765 000000b8 01000024 4ae6231b 8ecc7d32 6b652050 1287c765 9ad89e4a 31a9c0bc e0047c96 b7d0bf7f 0a000044 00000001 00000001 00000038 01030401 00cd88b8 0000002c 010c0000 80010001 00020004 00000e10 80010002 00020004 001c2000 80040001 80050005 80060080 05000014 89e510df 9582036a db91abe2 1dd56bca 05000010 04000000 0a010100 ffffff00 00000010 04000000 0a010200 ffffff00 00000000
  3. The initiator sends the HASH payload containing authentication information to the responder.

    Sep 28 2017 21:21:04.330.5+08:00 Huawei IKE/7/IKE_Debug:
    IKE_PACKET 17:4686 IKE Packet Contents sent to 2.1.1.1 for message type Send_HASH : a1588ac6 a6a062d4 60fd9a0c d0d75e72 08102000 2e398765 00000040 00000024 fa2b29f7 22f0d27f 25e9e1e1 9c46fbdb d57ebeff 53d7317e 3baaaeea 047189e2 

    The responder receives the HASH payload from the initiator.

    Sep 28 2017 21:38:44.720.11+00:00 Huawei IKE/7/IKE_Debug:
    IKE_PACKET 17:4752 IKE Packet Contents received from 1.1.1.1 for message type Recv_HASH : a1588ac6 a6a062d4 60fd9a0c d0d75e72 08102001 2e398765 00000040 00000024 fa2b29f7 22f0d27f 25e9e1e1 9c46fbdb d57ebeff 53d7317e 3baaaeea 047189e2 00000000 00000000 00000000 

IKEv2 Phase

IKEv2 negotiation is much simpler than IKEv1 negotiation. IKEv1 goes through two phases to establish a pair of IPSec SAs: "main mode + quick mode" or "aggressive mode + quick mode". The first one requires nine messages to be exchanged, whereas the second one requires at least six messages to be exchanged. IKEv2 requires two exchanges and four messages to establish a pair of IPSec SAs. If more than one pair of IPSec SAs needs to be set up, CREATE_CHILD_SA Exchanges are performed. One CREATE_CHILD_SA Exchange establishes one pair of IPSec SAs, that is, only two more messages are required to establish an additional pair of IPSec SAs.

  1. The initiator sends the SA_INIT payload containing IKE proposals, key generation information, and authentication information to the responder.

    Sep 28 2017 21:25:09.790.14+08:00 Huawei IKE/7/IKE_Debug:
    IKE_INFO 47:6660 IKEv2 Exch Type: SA_INIT
    
    Sep 28 2017 21:25:09.800.2+08:00 Huawei IKE/7/IKE_Debug:
    IKE_INFO 47:6570 Sent Msg: SA | KE | NONCE | NOTIFY | NOTIFY | V_ID | V_ID | 

    The responder receives the SA_INIT payload sent from the initiator and parses the IKE proposal.

    Sep 28 2017 21:42:50.180.10+00:00 Huawei IKE/7/IKE_Debug:
    IKE_INFO 47:6733 IKEv2 Exch Type: SA_INIT
    
    Sep 28 2017 21:42:50.180.1+00:00 Huawei IKE/7/IKE_Debug:
    IKE_INFO 47:6636 Recv Msg: SA | KE | NONCE | NOTIFY | NOTIFY | V_ID | V_ID | 
    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:2274 INTEGRITY ALGORITHM: SHA_256   //Authentication algorithm
    IKE_INFO 47:2243 PRF ALGORITHM: SHA2_256   //Pseudo-random function algorithm
    IKE_INFO 47:2308 GROUP_TYPE: MODP_1024   //DH key exchange parameter
    
  2. The responder searches for the first matching IKE proposal and sends the SA_INIT payload containing this accepted IKE proposal, its identity, and authentication information to the initiator.

    Sep 28 2017 21:42:50.190.9+00:00 Huawei IKE/7/IKE_Debug:
    IKE_INFO 47:6774 IKEv2 Exch Type: SA_INIT
    
    Sep 28 2017 21:42:50.190.11+00:00 Huawei IKE/7/IKE_Debug:
    IKE_INFO 47:6684 Sent Msg: SA | KE | NONCE | NOTIFY | NOTIFY | V_ID | V_ID | 

    The initiator receives the SA_INITE payload from the responder.

    Sep 28 2017 21:25:09.870.13+08:00 Huawei IKE/7/IKE_Debug:
    IKE_INFO 47:6619 IKEv2 Exch Type: SA_INIT
    
    Sep 28 2017 21:25:09.870.14+08:00 Huawei IKE/7/IKE_Debug:
    IKE_INFO 47:6522 Recv Msg: SA | KE | NONCE | NOTIFY | NOTIFY | V_ID | V_ID | 
  3. The initiator sends the IKE_AUTH payload containing IPSec proposals, its identity, and authentication information to the responder.

    Sep 28 2017 21:25:09.920.5+08:00 Huawei IKE/7/IKE_Debug:
    IKE_INFO 47:6660 IKEv2 Exch Type: IKE_AUTH
    
    Sep 28 2017 21:25:09.920.7+08:00 Huawei IKE/7/IKE_Debug:
    IKE_INFO 47:6570 Sent Msg: NOTIFY | NOTIFY | ID_I | AUTH | SA | TS_I | TS_R | 

    The responder receives the IKE_AUTH payload sent from the initiator and parses the IPSec proposal.

    Sep 28 2017 21:42:50.330.1+00:00 Huawei IKE/7/IKE_Debug:
    IKE_INFO 47:6733 IKEv2 Exch Type: IKE_AUTH
    
    Sep 28 2017 21:42:50.330.2+00:00 Huawei IKE/7/IKE_Debug:
    IKE_INFO 47:6636 Recv Msg: NOTIFY | NOTIFY | ID_I | AUTH | SA | TS_I | TS_R | 
    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
    
  4. The responder searches for the first matching IPSec proposal and sends the IKE_AUTH payload containing this accepted IPSec proposal, its identity, and authentication information to the initiator.

    Sep 28 2017 21:42:50.360.9+00:00 Huawei IKE/7/IKE_Debug:
    IKE_INFO 47:6774 IKEv2 Exch Type: IKE_AUTH
    
    Sep 28 2017 21:42:50.360.11+00:00 Huawei IKE/7/IKE_Debug:
    IKE_INFO 47:6684 Sent Msg: NOTIFY | NOTIFY | ID_R | AUTH | SA | TS_I | TS_R | 

    The initiator receives the IKE_AUTH payload from the responder.

    Sep 28 2017 21:25:10.50.10+08:00 Huawei IKE/7/IKE_Debug:
    IKE_INFO 47:6619 IKEv2 Exch Type: IKE_AUTH
    
    Sep 28 2017 21:25:10.50.11+08:00 Huawei IKE/7/IKE_Debug:
    IKE_INFO 47:6522 Recv Msg: NOTIFY | NOTIFY | ID_R | AUTH | SA | TS_I | TS_R | 

Common Failure Debugging Information and Troubleshooting Suggestions

Table 26-7 shows common failure debugging information and troubleshooting suggestions.

Table 26-7  Common failure debugging information

Debugging Information

Description

Troubleshooting Suggestions

Message from peer peer-ip: Got NOTIFY of type NO_PROPOSAL_CHOSEN

Message received from a specified peer: obtains the notification of the NO_PROPOSAL_CHOSEN type.

peer-ip specifies the IP address of an IKE peer.

IKE proposals on both ends are inconsistent. Ensure that the IKE proposals are consistent.

Message from peer peer-ip: Got NOTIFY of type PAYLOAD_MALFORMED

Message received from a specified peer: obtains the notification of the PAYLOAD_MALFORME type.

peer-ip specifies the IP address of an IKE peer.

Pre-shared keys on both ends are inconsistent. Ensure that the pre-shared keys are consistent.

Message from peer peer-ip: Invalid Next Payload of Type 60 in Payload Type 5

Message received from a specified peer: indicates the invalid next payload of type 60 in payload type 5.

Pre-shared keys on both ends are inconsistent. Ensure that the pre-shared keys are consistent.

Message from peer peer-ip: dropping Message due to notification type INVALID_PAYLOAD_TYPE

Message received from a specified peer: indicates that messages are dropped due to the notification of the INVALID_PAYLOAD_TYPE type.

peer-ip specifies the IP address of an IKE peer.

Pre-shared keys on both ends are inconsistent. Ensure that the pre-shared keys are consistent.

Phase 1 Exchange: ike peer configuration not found for peer "peer-ip"

Phase 1 exchange: indicates that the peer peer-ip is not found in the peer configuration.

peer-ip specifies the IP address of an IKE peer.

The local remote-address configuration is incorrect. Ensure that the configuration is correct.

ERROR - Received remote-name(remote-name) does not match with peer remote-name(remote-name)

The received remote-name does not match the peer remote-name.

remote-name: specifies the peer name.

The local remote-id and remote-name are inconsistent. Ensure that they are consistent.

Message from peer peer-ip: Got NOTIFY of type INVALID_ID_INFORMATION

Message received from a specified peer: obtains the notification of the INVALID_ID_INFORMATION type.

peer-ip specifies the IP address of an IKE peer.

ACL rules on both ends do not match. Ensure that the ACL rules match.

Message from peer peer-ip: dropping Message due to notification type NO_PROPOSAL_CHOSEN

Message received from a specified peer: indicates that messages are dropped due to the notification of the NO_PROPOSAL_CHOSEN type.

peer-ip specifies the IP address of an IKE peer.

IPSec proposals or PFS algorithms on both ends are inconsistent. Ensure that the IPSec proposals or PFS algorithms match.

Authentication failed for the peer peer-ip

The specified peer fails authentication.

peer-ip specifies the IP address of an IKE peer.

Pre-shared keys on both ends are inconsistent. Ensure that the pre-shared keys are consistent.

Unable to find IPSEC Policy for peer peer-ip

Failed to find an IPSec policy for the specified peer.

peer-ip specifies the IP address of an IKE peer.

One end does not have remote-address configured. Ensure that both ends have remote-address configured.

ERROR - Peer remote-name(remote-name) does not match with

The peer remote-name does not match.

remote-name: specifies the peer name.

The local remote-id and remote-name are inconsistent. Ensure that they are consistent.

Ikev1 error-info record(peer address: peer-address, error reason: error-reason,list number: list-number)

Ikev2 error-info record(peer address: peer-address, error reason: error-reason,list number: list-number)

IKEv1/IKEv2 negotiation failure information.
  • peer-address: indicates the IP address of a peer.
  • error-reason: indicates an IKE negotiation failure reason.
  • list-number: indicates the sequence number.
Rectify faults based on common IKE negotiation failure reasons:
  • phase1 proposal mismatch: IKE proposal parameters on both ends do not match.
  • phase2 proposal mismatch: IPSec proposal parameters on both ends do not match.
  • responder dh mismatch: The responder's DH algorithm does not match.
  • initiator dh mismatch: The initiator's DH algorithm does not match.
  • encapsulation mode mismatch: Encapsulation modes on both ends do not match.
  • flow mismatch: Security ACLs on both ends do not match.
  • version mismatch: IKE versions on both ends do not match.
  • peer address mismatch: IKE peer addresses on both ends do not match.
  • config ID mismatch: The local remote-id and remote-name do not match.
  • role mismatch: Negotiation modes on both ends do not match.
  • authentication fail: Pre-shared keys on both ends are inconsistent.
  • unsupported version: The IKE version is not supported.
  • malformed payload: Pre-shared keys on both ends are inconsistent.
  • route limit: The number of injected routes has reached the upper limit.
  • local address mismatch: The local IP address and interface IP address do not match during IKE negotiation.
Translation
Download
Updated: 2019-05-10

Document ID: EDOC1000079719

Views: 455549

Downloads: 4321

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