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).
In the DSVPN over IPSec Scenario, If the Hub Device Uses Different Tunnel Interfaces to Connect to Spoke Devices, IKE Negotiation Fails Between the Headquarters and Branches

In the DSVPN over IPSec Scenario, If the Hub Device Uses Different Tunnel Interfaces to Connect to Spoke Devices, IKE Negotiation Fails Between the Headquarters and Branches

This section provides a troubleshooting case for the following fault: In the DSVPN over IPSec scenario, if the hub device uses different tunnel interfaces to connect to spoke devices, IKE negotiation fails between the headquarters and branches.

Networking

Figure 25-30 Establishing DSVPN over IPSec tunnels between the headquarters and branches of an enterprise

Fault Description

In the DSVPN over IPSec scenario, if the hub device uses different tunnel interfaces to connect to spoke devices, IKE negotiation fails between the headquarters and branches. If you run the display ike sa command on the hub device, the information indicating that the IKE SA fails to be established is displayed.

<Hub> display ike sa
   Conn-ID    Peer                  VPN                             Flag(s)               Phase
  ----------------------------------------------------------------------------------------------
   1381       0.0.0.0:0                                             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

Fault Analysis

  1. The output of the debugging command executed on the hub device indicates that different IKE peer names are specified in the IPSec policy.
    <Hub> terminal debugging 
    <Hub> terminal monitor   
    <Hub> debugging ipsec all
    <Hub> debugging ikev1 all
    <Hub>Nov 17 2017 17:03:26.450.5+00:00 HQ-H IKE/7/IKE_Debug Info:5:2607 IKE check ike peer same, get ike peer name (peer-name = ipsec1, ifindex = 18).
    <Hub>Nov 17 2017 17:03:26.450.6+00:00 HQ-H IKE/3/IKE_Debug Error:5:2628 IKE check ike peer same, the binding ike peer is different(ifindex = 27, peer name = ipsec3).
  2. The IPSec configuration on the hub device indicates that two tunnel interfaces on the hub device connecting to the two spoke devices use the same IP address 1.1.1.1 but the names of the IPSec profiles specified for the two tunnel interfaces are different. As a result, IKE negotiation fails. Therefore, you need to configure an identity filter set and GRE tunnel keys on the hub device, and configure the same GRE tunnel keys on the spoke devices. In addition, you need to configure the same IPSec profile for different tunnel interfaces and configure the profile to specify the peers that can be connected based on the specified identity filter set. After the configuration, IKE negotiation is successful and IPSec tunnels are established successfully between spoke devices 1 and 2. Then, the fault is rectified.
    <Hub> system-view 
    [Hub] interface Tunnel0/0/0
    [Hub-Tunnel0/0/0] mtu 1360
    [Hub-Tunnel0/0/0] ip address 10.17.1.1 255.255.255.0
    [Hub-Tunnel0/0/0] tunnel-protocol gre p2mp
    [Hub-Tunnel0/0/0] source vpn-instance test 1.1.1.1
    [Hub-Tunnel0/0/0] ipsec profile ipsec1
    [Hub-Tunnel0/0/0] quit 
    [Hub] interface Tunnel0/0/100
    [Hub-Tunnel0/0/100] ip address 100.17.1.1 255.255.255.0
    [Hub-Tunnel0/0/100] tunnel-protocol gre p2mp
    [Hub-Tunnel0/0/100] source vpn-instance test 1.1.1.1
    [Hub-Tunnel0/0/100] ipsec profile ipsec2
    [Hub-Tunnel0/0/100] quit
    [Hub] ipsec profile ipsec1
    [Hub-ipsec-profile-ipsec1] ike-peer ipsec1
    [Hub-ipsec-profile-ipsec1] proposal pro1
    [Hub-ipsec-profile-ipsec1] quit
    [Hub] ipsec profile ipsec2
    [Hub-ipsec-profile-ipsec2] ike-peer ipsec2
    [Hub-ipsec-profile-ipsec2] proposal pro2

Procedure

  1. On the hub device, configure an identity filter set and GRE tunnel keys for the spoke devices respectively.
    <Hub> system-view 
    [Hub] ike identity i1
    [Hub-ike-identity-i1] fqdn spoke1
    [Hub-ike-identity-i1] quit
    [Hub] ike identity i2
    [Hub-ike-identity-i2]] fqdn spoke2
    [Hub-ike-identity-i2] quit
    [Hub] ipsec profile ipsec1
    [Hub-ipsec-profile-ipsec1] ike-peer ipsec1
    [Hub-ipsec-profile-ipsec1] proposal pro1
    [Hub-ipsec-profile-ipsec1] match ike-identity i1
    [Hub-ipsec-profile-ipsec1] quit
    [Hub] ipsec profile ipsec2
    [Hub-ipsec-profile-ipsec2] ike-peer ipsec1
    [Hub-ipsec-profile-ipsec2] proposal pro2
    [Hub-ipsec-profile-ipsec2] match ike-identity i2
    [Hub-ipsec-profile-ipsec2] quit
    [Hub] interface Tunnel0/0/0
    [Hub-Tunnel0/0/0] gre key cipher AAA
    [Hub-Tunnel0/0/0] quit
    [Hub] interface Tunnel0/0/100
    [Hub-Tunnel0/0/100] gre key cipher BBB
    [Hub-Tunnel0/0/100] quit
  2. On spoke device 1, configure a GRE tunnel key.
    <Spoke1> system-view 
    [Spoke1] ike peer ipsec1
    [Spoke1-ike-peer-ipsec1] undo version 2
    [Spoke1-ike-peer-ipsec1] pre-shared-key cipher AAA
    [Spoke1-ike-peer-ipsec1] ike-proposal 1
    [Spoke1-ike-peer-ipsec1] local-id-type fqdn
    [Spoke1-ike-peer-ipsec1] local-id spoke1
    [Spoke1-ike-peer-ipsec1] dpd type periodic
    [Spoke1-ike-peer-ipsec1] dpd idle-time 40
  3. On spoke device 2, configure a GRE tunnel key.
    <Spoke2> system-view 
    [Spoke2] ike peer ipsec2
    [Spoke2-ike-peer-ipsec2] undo version 2
    [Spoke2-ike-peer-ipsec2] pre-shared-key cipher BBB
    [Spoke2-ike-peer-ipsec2] ike-proposal 1
    [Spoke2-ike-peer-ipsec2] local-id-type fqdn
    [Spoke2-ike-peer-ipsec2] local-id spoke2
    [Spoke2-ike-peer-ipsec2] dpd type periodic
    [Spoke2-ike-peer-ipsec2] dpd idle-time 40

Conclusions and Suggestions

In the DSVPN over IPSec scenario, if the hub device uses different tunnel interfaces to connect to spoke devices and the tunnel interfaces use the same IP address, an identity filter set and GRE tunnel keys need to be configured on the hub device, and the same GRE tunnel keys need to be configured on the spoke devices respectively. In this way, IKE negotiation can be successful.

Translation
Download
Updated: 2019-08-09

Document ID: EDOC1000079719

Views: 499140

Downloads: 4547

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