Made4it

22/02/2023

GRE + IPSec tunnel between Cisco IOS and Huawei NE40

In this post we will discuss a very common (and little documented) scenario, which is to use a GRE tunnel secured with IPSec between a Cisco IOS ASR1002 router and a Huawei NE40 router.

The topology for this example is described below. It has been kept simple so that we can discuss the details of GRE+IPSEC without getting into the rest of the network.

In this setup, we have a Cisco router with the public IP address 198.51.100.2 and a Huawei NE40 router with the public IP address 203.0.113.66. Both are connected to the Internet and are connected to each other. We need to establish a GRE tunnel between the routers and secure it using IPSec in tunnel mode. The tunnel’s address space is 172.31.31.0/30.

In the next lines below we will talk about GRE and IPSec. The objective is not to completely detail these protocols, but to give an overview and, mainly, a basis for the rest of the article. Don’t be hasty, there is very relevant information in there.

GRE

Generic Routing Encapsulation (GRE) is a tunneling protocol that can encapsulate a variety of network protocols (eg ATM, IPX, IPv6 and even IPv4) within IPv4 packets. These packets can then be transmitted over common IPv4 networks (eg Internet).

Some use cases for GRE:
connecting internal networks that are not directly connected to each other
connecting isolated IPv6 networks via IPv4 networks
establishing communication between headquarters and branches over the Internet
mitigation links
using VPNs when routing protocols are required

IPSEC

IPSec is a security framework developed by the IETF that seeks to solve security problems that the IPv4 protocol failed to address, such as encryption, data integrity, source validation, and anti-replay.
IPSec is actually not a single protocol, but a combination of protocols and algorithms. The main ones are IKEv1, IKEv2, ESP and AH.

IPSec is widely used in VPNs, both remote-access and site-to-site.

In the life cycle of a tunnel, we have 5 well-defined stages:

Definition of interesting traffic
Interesting traffic is the trigger that causes the tunnel to be established. When the router or firewall detects interesting traffic, it initiates the next steps in the IPSec negotiation.
Interesting traffic is usually configured in the form of ACLs, or traffic policies.
IKE Phase 1
In Phase 1, the protocol establishes a secure communication channel with the remote peer. Once this secure channel is established, Phase 2 message exchanges are permitted.
It is in phase 1 that peers are protected, authenticated, and ISAKMP policies are compared (and need to match). There are two modes, main and aggressive.

Terms you will see about phase 1: ike, isakmp, DH group, pre-shared-key, integrity, isakmp policy
IKE Phase 2
In this phase, with the secure tunnel already established in Phase 1, we can negotiate what are called IPSec SAs, which are essentially dynamically negotiated “contracts” specifying the type of traffic that will be protected by the IPSec tunnel. An example might be “I will protect traffic from the 192.168.1.0/24 network when the destination is 192.168.2.0/24 using encryption algorithm X and authentication algorithm Y,” and the remote peer establishes the rule in the opposite direction.

Another function of phase 2 is to maintain SAs, as well as expire keys and sessions if some parameter is reached (e.g. expire SAs and trade new ones every x hours, or every N kilobytes).

Terms we will see about phase 2: ipsec, ipsec sa, crypto acl, transform set, mode tunnel, authentication, encryption, ipsec policy
Data Transfer This phase involves the data transfer itself. Once the relevant traffic arrives at the router and phases 1 and 2 are complete, the packets are sent in accordance with the agreements established in the IPSec SAs and transmitted to the remote peer.
Tunnel Termination The tunnel is terminated manually, or when an IPSec parameter expires or reaches its limit. In this case, all keys are discarded, the agreements are terminated, and if traffic needs to be routed, a new IPSec tunnel must be established.

For more details on GRE and IPSEC, please refer to the references cited at the end of the article.

The GRE and IPSEC configurations agreed upon by the parties

The example below is how VPN information is agreed upon. These are usually forms that are filled out with information about the tunnel.

VPN Device	Site A VPN Device	Site B VPN Device
VPN Peer IP Address *	198.51.100.2	203.0.113.66
Device *	Cisco ASR 1004	Huawei NE40-M2K
Version *	V3.0.6


Tunnel Properties		Site A VPN Device	Site B VPN Device
Phase 1	Authentication Method	APasswordWellS3gur@	APasswordWellS3gur@
	IKE version	IKEv2	IKEv2
	Diffie-Hellman Group	group 14	group 14
	Encryption Algorithm *	AES 256	AES 256
	Hashing Algorithm *	SHA-1	SHA-1
	Main or Aggressive Mode *	Main mode	Main mode
	*SA Lifetime (for renegotiation) with no kbytes rekeying**	86400 seconds	86400 seconds
Phase 2	*Encapsulation (ESP or AH)**	ESP	ESP
	Encryption Algorithm *	AES 256	AES 256
	Authentication Algorithm *	SHA-1	SHA-1
	Perfect Forward Secrecy for rekeying *	Disabled	Disabled
	Diffie-Hellman Group *	group 14	group 14
	*SA Lifetime (for renegotiation) ) with no kbytes rekeying**	3600 seconds	3600 seconds
GRE	Addressing	172.31.31.1/30	172.31.31.2/30
	Keepalives	Disabled	Disabled
	MTU	1400	1400
	Adjust MSS	1360	1360

Important License/Module Information

Check with the manufacturer of your equipment to see if some kind of service card, or license is not required.

In the case of the equipment in this lab, the NE40-M2K router did not need an additional physical module, just the IPSec license. On the Cisco router no license was needed either, because its IOS was already in ADVIPSERVICES-K9 (which contains the entire basis for Ipsec).

*Helpful information*: if you want to run IKEv1, on the Huawei router you need a software module for IKEv1 (which you get from the Huawei vendor).

Cisco IOS XE Configurations

So let’s configure the Cisco router to establish the VPN. I won’t go into detail about the physical interfaces, only about the VPN. At the end of the article there is a block with the relevant conf of them.

Phase 1 settings, according to the table above:

# PROPOSAL PARA fase 1
crypto ikev2 proposal ikev2proposal
 encryption aes-cbc-256
 integrity sha1
 group 14

# policy de fase 1
crypto ikev2 policy ikev2policy
 match fvrf any
 proposal ikev2proposal


# chaveiro com as PSK
crypto ikev2 keyring keys
 peer site_b
  address 203.0.113.66
  pre-shared-key UmaSenhaBemS3gur@
 !

# profile com o PEER
crypto ikev2 profile ikev2profile
 match identity remote address 203.0.113.66 255.255.255.255
 authentication remote pre-share
 authentication local pre-share
 keyring local keys

Everything above applies to Phase 1. So when you’re troubleshooting issues, and the problem is related to this phase, you’ll already know where to look 🙂.

Now setting up phase 2:

# confs da fase 2
crypto ipsec transform-set TS esp-aes 256 esp-sha-hmac
 mode tunnel

Too simple on Cisco! We will now combine the two phases into one profile:

# Profile a ser usado na VPN (combina as confs de fase1 e fase2)
crypto ipsec profile VPN-IKEv2-IPsec-Profile
 set transform-set TS
 set ikev2-profile ikev2profile

Creating the GRE tunnel and adding IPSec protection:

# cria o tunnel GRE e aplica a protecao
interface Tunnel299
 description Tunnel Test Rafael
 bandwidth 10000
 ip address 172.31.31.1 255.255.255.252
 ip mtu 1400
 ip tcp adjust-mss 1360
 tunnel source Port-channel1.536
 tunnel destination 203.0.113.66
 tunnel protection ipsec profile VPN-IKEv2-IPsec-Profile
end

Huawei Settings

So let’s configure the Huawei router to establish the VPN. As with Cisco, I won’t go into detail about the physical interfaces, only the VPN. At the end of the article there is a block with the relevant conf of them.

The configuration on the Huawei router is a bit more complex, as it creates one tunnel for the GRE protocol, and one tunnel for IPSec. Also, we want to use the same IP for both tunnels, so a VRF is needed. 😮

Creating the service instance to use the VPN (only applicable on NE40):

# Cria o service-instance-group (somente NE40)
service-location 1
 location slot 1
 commit

service-instance-group group1
 service-location 1

Upgrading the new VRF (vpn-instance):

ip vpn-instance vpna
 ipv4-family
  route-distinguisher 100:1
  apply-label per-instance
  vpn-target 111:1 export-extcommunity
  vpn-target 111:1 import-extcommunity

Creating the two Loopback interfaces with the same IP (VRF magic). The looback with the IPSec tunnel will be in the public routing table, while the one with the GRE tunnel will be in the VPNA table.

# Lo da tabela global, para uso do IPSec
interface LoopBack1
ip address 203.0.113.66 255.255.255.255
binding tunnel ipsec

# Lo atrelada a vrf, para uso no GRE do mesmo IP.
interface LoopBack10
 ip binding vpn-instance vpna
 ip address 203.0.113.66 255.255.255.255
 binding tunnel gre

Now we come to IPSec.

The interesting traffic ACL defines the traffic that will be protected by IPSec. In this case then, we will have GRE traffic between the IPs of site A and site B. Note that I only communicate in one direction – the direction of the router protecting its traffic).

# ACL de tráfego interessante
acl number 3000
 rule 0 permit gre vpn-instance vpna source 203.0.113.66 0
 destination 198.51.100.2 0

The above ACL can be read like this:

“Protect GRE protocol data coming from VRF vpna between source 203.0.113.66 and destination 198.51.100.2”

Now let’s move on to setting up Phase 1 (remember that Cisco actually starts with this phase—it’s much simpler). In the middle of this phase, there are some VPN-Instance binding configurations, due to the VRF that was created.

# PROPOSAL PARA fase 1
ike proposal 1
 encryption-algorithm aes-cbc 256
 dh group14
 authentication-algorithm sha1
 integrity-algorithm hmac-sha1-96

# chaveiro com as PSK e peer
ike peer teste
 pre-shared-key UmaSenhaBemS3gur@adriano
 ike-proposal 1
 remote-address 198.51.100.2
 sa binding vpn-instance vpna

Everything above applies to Phase 1. So when you’re troubleshooting issues, and the problem is related to this phase, you’ll already know where to look 🙂.

We move on to phase 2:

# confs da fase 2
ipsec proposal comfone
 encapsulation-mode tunnel
 transform esp
 esp authentication-algorithm sha1
 esp encryption-algorithm aes 256

We will now combine the two phases into one profile:

# policy combinando ambas as fases
ipsec policy teste 1 isakmp
 ipsec df-bit clear
 security acl 3000
 ike-peer teste
 proposal comfone
 log enable

Creating GRE and IPSEC tunnels. Let’s not get confused:

Tunnel 900 – is a GRE tunnel, operating inside the vpna.

Tunnel 10 – is an IPSec tunnel, operating on the global table

The idea at Huawei is to have an IPSec tunnel running on the outside and a second GRE tunnel on the inside, with one encapsulated within the other. But the funny thing is that the GRE tunnel runs outside the VRF, and the IPSec tunnel runs inside it. It’s a bit of a mess, isn’t it?

# Tunel GRE (dentro da VRF)
interface Tunnel900
 bandwidth 10000
 mtu 1400
 ip address 172.31.31.2 255.255.255.252
 clear ip df
 tunnel-protocol gre
 source LoopBack10
 destination vpn-instance vpna 198.51.100.2

# Tunel IPsec
interface Tunnel10
 ip address unnumbered interface LoopBack1
 tunnel-protocol ipsec
 ipsec policy teste service-instance-group group1

Then tunnel900 which is the GRE (and which receives the IPs from /30) uses a destination that goes inside the VPNA. And inside the VPNA the destination is reached by the IPSec tunnel. Also note that the IPsec policy has been associated with tunnel 10, using the profile that was created.

Last but not least, a route that is somewhat complex in itself: within the VPNA instance, I specify that to reach the remote peer, I use the newly created IPSec interface, with the peer itself as the next hop.

# Rota para o peer na VPN-Instance para usar o Tunnel
ip route-static vpn-instance vpna 198.51.100.2 255.255.255.255
 Tunnel10 198.51.100.2

And so we set up the Huawei router. Let’s see if it has gone up now.

Operation Validation

In the tunnel validation process, we must always remember that each phase and stage depends on the complete establishment of the other, so there is no point in wanting to have connectivity if phase 1 has not yet established communication.

On both routers, we will validate in sequence:

connectivity
phase1
phase2
GRE connectivity
interface status

Let’s go to the tests.

Cisco Check

Validating connectivity via ICMP ping

RT-CISCO-ASR1004#ping 203.0.113.66
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 203.0.113.66, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 22/24/27 ms
RT-CISCO-ASR1004#

Checking that IKEv2 has established in Phase 1:

RT-CISCO-ASR1004#show crypto ikev2 sa
 IPv4 Crypto IKEv2  SA

Tunnel-id Local                 Remote                fvrf/ivrf            Status
1         198.51.100.2/500    203.0.113.66/500    none/none            READY
      Encr: AES-CBC, keysize: 256, PRF: SHA1, Hash: SHA96, DH Grp:14, Auth sign:
 PSK, Auth verify: PSK
      Life/Active Time: 86400/17 sec

When nothing appears in the output, or it is not ready, it means that some of the parameters in Phase 1 did not match. Check on both sides if they agree.

We continue validation in Phase 2:

RT-CISCO-ASR1004#show crypto ipsec sa

interface: Tunnel299
    Crypto map tag: Tunnel299-head-0, local addr 198.51.100.2
   protected vrf: (none)
   local  ident (addr/mask/prot/port): (198.51.100.2/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (203.0.113.66/255.255.255.255/47/0)
   current_peer 203.0.113.66 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 2, #pkts encrypt: 2, #pkts digest: 2
    #pkts decaps: 2, #pkts decrypt: 2, #pkts verify: 2 
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0

     local crypto endpt.: 198.51.100.2, remote crypto endpt.: 203.0.113.66
     plaintext mtu 1438, path mtu 1500, ip mtu 1500, ip mtu idb Port-channel1.535
     current outbound spi: 0x2E41D7D5(776067029)
     PFS (Y/N): N, DH group: none

     inbound esp sas:
      spi: 0x27487883(659060867)
        transform: esp-256-aes esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 2010, flow_id: HW:10, sibling_flags FFFFFFFF80000048, crypto map: Tunnel299-head-0
        sa timing: remaining key lifetime (k/sec): (4607999/3508)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE(ACTIVE)

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0x2E41D7D5(776067029)
        transform: esp-256-aes esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 2009, flow_id: HW:9, sibling_flags FFFFFFFF80000048, crypto map: Tunnel299-head-0
        sa timing: remaining key lifetime (k/sec): (4607999/3508)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE(ACTIVE)

     outbound ah sas:

     outbound pcp sas:

In the output above, we see that the routers have switched the “interesting traffic” contract. Each side has committed to protecting one direction of GRE communication.

Following on still in Phase 2, there are some very important counters that refer to packets sent/received/encrypted/verified. It is in the output of the “show crypto ipsec sa” command. Let’s take a look at them.

RT-CISCO-ASR1004#show crypto ipsec sa  | inc pkts
    #pkts encaps: 2, #pkts encrypt: 2, #pkts digest: 2
    #pkts decaps: 2, #pkts decrypt: 2, #pkts verify: 2
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
RT-CISCO-ASR1004#ping 172.31.31.2 repeat 2
Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 172.31.31.2, timeout is 2 seconds:
!!
Success rate is 100 percent (2/2), round-trip min/avg/max = 22/22/22 ms
RT-CISCO-ASR1004#show crypto ipsec sa  | inc pkts
    #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4
    #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0

When these counters are not incrementing, or still incrementing failures, it is because some Phase 2 configuration is not matching.

A good example would be that only the encaps/encrypt counter is incremented, while the decaps/decrypt is reset to zero. This is going to be an interesting traffic ACL problem that is diverging on both sides. Or a communication blockage in the transport network, or other factors that we won’t go into here. If you need help, be sure to contact us.

Finally, let’s validate the connectivity itself! But now inside the tunnel already protected!

RT-CISCO-ASR1004#ping 172.31.31.2 repeat 100
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 172.31.31.2, timeout is 2 seconds:!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 21/21/23 ms
RT-CISCO-ASR1004#

And the tunnel interface is up, and functional:

# interface UP
RT-CISCO-ASR1004#sh int tun299
Tunnel299 is up, line protocol is up
  Hardware is Tunnel
  Description: Tunnel Test Rafael
  Internet address is 172.31.31.1/30
  MTU 9914 bytes, BW 10000 Kbit/sec, DLY 50000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel linestate evaluation up
  Tunnel source 198.51.100.2 (Port-channel1.536), destination 203.0.113.66
   Tunnel Subblocks:
      src-track:
         Tunnel299 source tracking subblock associated with Port-channel1.536
          Set of tunnels with source Port-channel1.536, 1 member (includes iterators), on interface <OK>
  Tunnel protocol/transport GRE/IP
    Key disabled, sequencing disabled
    Checksumming of packets disabled
  Tunnel TTL 255, Fast tunneling enabled
  Tunnel transport MTU 1414 bytes
  Tunnel transmit bandwidth 8000 (kbps)
  Tunnel receive bandwidth 8000 (kbps)
  Tunnel protection via IPSec (profile "VPN-IKEv2-IPsec-Profile")
  Last input never, output never, output hang never
  Last clearing of "show interface" counters 19:14:47
  Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/0 (size/max)
  5 minute input rate 1000 bits/sec, 1 packets/sec
  5 minute output rate 1000 bits/sec, 1 packets/sec
     253 packets input, 22764 bytes, 0 no buffer
     Received 0 broadcasts (0 IP multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     13497 packets output, 659844 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     0 output buffer failures, 0 output buffers swapped out

Huawei Check

To validate operation on the Huawei NE40 router, the approach is the same as for the Cisco.

Validating connectivity via ICMP ping (remember to use loopback source)

<~RT-HUAWEI-NE40> ping -a 203.0.113.66 198.51.100.2
  PING 198.51.100.2: 56  data bytes, press CTRL_C to break
    Reply from 198.51.100.2: bytes=56 Sequence=1 ttl=62 time=1 ms
    Reply from 198.51.100.2: bytes=56 Sequence=2 ttl=62 time=1 ms
    Reply from 198.51.100.2: bytes=56 Sequence=3 ttl=62 time=1 ms
    Reply from 198.51.100.2: bytes=56 Sequence=4 ttl=62 time=1 ms
    Reply from 198.51.100.2: bytes=56 Sequence=5 ttl=62 time=2 ms

  --- 198.51.100.2 ping statistics ---
    5 packet(s) transmitted
    5 packet(s) received
    0.00% packet loss
    round-trip min/avg/max = 1/1/2 ms

Checking that IKEv2 has established in Phase 1:

[~RT-HUAWEI-NE40]dis ike sa
Slot 3, IKE SA Information:
Current IKE SA number: 2
-----------------------------------------------------------------------------
conn-id    peer                    flag                phase   ext    vpn
-----------------------------------------------------------------------------
1212       198.51.100.2          RD                  v2:2    -      vpna
1211       198.51.100.2          RD                  v2:1    -      vpna

[~RT-HUAWEI-NE40]dis ike sa verbose remote 198.51.100.2
Slot 3, IKE SA Verbose Information:
  ----------------------------
  Establish Time : 2022-12-03 09:49:43
  PortCfg Name   : Tunnel10
  IKE Peer Name  : teste
  Connection Id  : 1211
  Version        : v2
  Flow VPN       : vpna
  Peer VPN       : -
  Instance ID    : 0
  -----------------------------------------------
    Initiator Cookie        : 0xefaf822684f391e7
    Responder Cookie        : 0xdac01cc355e9c8ad
    Local Address           : 203.0.113.66
    Remote Address          : 198.51.100.2
    Peer Identity           : ip, 198.51.100.2
    Authentication Method   : PRE_SHARED
    Diffie-Hellman Group    : MODP_2048
    Encryption Algorithm    : AES256_CBC
    Authentication Algorithm: SHA1
    Integrity Algorithm     : SHA1_96
    Send/Receive Message_id : 0/2
    Remaining Duration      : 85680
    Reference Counter       : 2
    Flags                   : RD
    Is Backuped             : 0
    InBound SpeedLimit      : -
    OutBound SpeedLimit     : -
  -----------------------------------------------

When nothing appears in the output, or it is not in ready (RD), it means that some of the Phase 1 parameters did not match. Check on both sides if they agree.

We continue validation in Phase 2:

[~RT-HUAWEI-NE40]  dis ipsec sa

IKE IP Security Association :
==================================
IPsec SA Information for Slot : 3
==================================

===============================
Interface: Tunnel10
===============================

  -----------------------------
  IPsec policy name: "teste"
  sequence number: 1
  instance id: 0
  mode: isakmp
  vpn: vpna
  ext: -
  -----------------------------
    connection id: 1212
    rule number: 0
    encapsulation mode: tunnel
    tunnel local: 203.0.113.66    tunnel remote: 198.51.100.2
    flow      source: 203.0.113.66/255.255.255.255 0-65535 47 0xFF
    flow destination: 198.51.100.2/255.255.255.255 0-65535 47 0xFF
    input/output security packets: 104/104
    input/output security kilobytes: 18/18
    input/output bandwidth limit drop packets: 0/0
    input/output bandwidth limit drop kilobytes: 0/0

    [inbound ESP SAs]
      establish: 2022-12-03 09:49:43
      spi: 776067029 (0x2e41d7d5)
      vpn: vpna said: 53
      proposal: ESP-ENCRYPT-256-AES ESP-AUTH-SHA1
      sa remaining key duration (kilobytes/sec): 1843182/2862
      max received sequence-number: 104
      udp encapsulation used for nat traversal: N

    [outbound ESP SAs]
      establish: 2022-12-03 09:49:43
      spi: 659060867 (0x27487883)
      vpn: vpna said: 54
      proposal: ESP-ENCRYPT-256-AES ESP-AUTH-SHA1
      sa remaining key duration (kilobytes/sec): 1843182/2862
      max sent sequence-number: 104
      udp encapsulation used for nat traversal: N

Finally, let’s validate the connectivity itself by checking the traffic counters! But now inside the tunnel already protected!

[~RT-HUAWEI-NE40]dis inter Tunnel 900 | i packets
Info: It will take a long time if the content you search is too much or the string you input is too long, you can press CTRL_C to break.
Checksumming of packets disabled
    300 seconds input rate 64 bits/sec, 1 packets/sec
    300 seconds output rate 0 bits/sec, 0 packets/sec
    0 seconds input rate 0 bits/sec, 0 packets/sec
    0 seconds output rate 0 bits/sec, 0 packets/sec
    223 packets input,  22712 bytes
    227 packets output,  29534 bytes
      Unicast: 223 packets, Multicast: 0 packets
      Unicast: 227 packets, Multicast: 0 packets
[~RT-HUAWEI-NE40]ping -a 172.31.31.2 172.31.31.1
  PING 172.31.31.1: 56  data bytes, press CTRL_C to break
    Reply from 172.31.31.1: bytes=56 Sequence=1 ttl=255 time=22 ms
    Reply from 172.31.31.1: bytes=56 Sequence=2 ttl=255 time=22 ms
    Reply from 172.31.31.1: bytes=56 Sequence=3 ttl=255 time=22 ms
    Reply from 172.31.31.1: bytes=56 Sequence=4 ttl=255 time=22 ms
    Reply from 172.31.31.1: bytes=56 Sequence=5 ttl=255 time=21 ms

  --- 172.31.31.1 ping statistics ---
    5 packet(s) transmitted
    5 packet(s) received
    0.00% packet loss
    round-trip min/avg/max = 21/21/22 ms

[~RT-HUAWEI-NE40]dis inter Tunnel 900 | i packets
Info: It will take a long time if the content you search is too much or the string you input is too long, you can press CTRL_C to break.
Checksumming of packets disabled
    300 seconds input rate 64 bits/sec, 1 packets/sec
    300 seconds output rate 0 bits/sec, 0 packets/sec
    0 seconds input rate 0 bits/sec, 0 packets/sec
    0 seconds output rate 0 bits/sec, 0 packets/sec
    228 packets input,  23152 bytes
    232 packets output,  30074 bytes
      Unicast: 228 packets, Multicast: 0 packets
      Unicast: 232 packets, Multicast: 0 packets
[~RT-HUAWEI-NE40]

And the tunnel interface is up, and functional:

[~RT-HUAWEI-NE40]dis inter Tunnel 900 extensive
Tunnel900 current state : UP (ifindex: 112)
Line protocol current state : UP
Last line protocol up time : 2022-12-03 09:39:38
Description:
Route Port,The Maximum Transmit Unit is 1400
Internet Address is 172.31.31.2/30
Encapsulation is TUNNEL, loopback not set
Tunnel source 203.0.113.66 (LoopBack10), destination vrf vpna 198.51.100.2
Tunnel protocol/transport GRE/IP, key disabled
keepalive disabled
Checksumming of packets disabled
Current system time: 2022-12-03 10:03:48
    300 seconds input rate 64 bits/sec, 1 packets/sec
    300 seconds output rate 0 bits/sec, 0 packets/sec
    0 seconds input rate 0 bits/sec, 0 packets/sec
    0 seconds output rate 0 bits/sec, 0 packets/sec
    228 packets input,  23152 bytes
    0 input error
    232 packets output,  30074 bytes
    0 output error
    Input:
      Unicast: 228 packets, Multicast: 0 packets
    Output:
      Unicast: 232 packets, Multicast: 0 packets
    Input bandwidth utilization  :    0%
    Output bandwidth utilization :    0%

With this we arrive at the established and functioning tunnel between the Cisco IOS XE router and the Huawei NE40!

Complete Cisco Configuration

# interface WAN
interface Port-channel1.536
 description WAN-If
 encapsulation dot1Q 536
 ip address 198.51.100.2 255.255.255.252
 no shutdown

# PROPOSAL PARA fase 1
crypto ikev2 proposal ikev2proposal
 encryption aes-cbc-256
 integrity sha1
 group 14

# policy de fase 1
crypto ikev2 policy ikev2policy
 match fvrf any
 proposal ikev2proposal


# chaveiro com as PSK
crypto ikev2 keyring keys
 peer site_b
  address 203.0.113.66
  pre-shared-key UmaSenhaBemS3gur@
 !

# profile com o PEER
crypto ikev2 profile ikev2profile
 match identity remote address 203.0.113.66 255.255.255.255
 authentication remote pre-share
 authentication local pre-share
 keyring local keys

# confs da fase 2
crypto ipsec transform-set TS esp-aes 256 esp-sha-hmac
 mode tunnel

# Profile a ser usado na VPN (combina as confs de fase1 e fase2)
crypto ipsec profile VPN-IKEv2-IPsec-Profile
 set transform-set TS
 set ikev2-profile ikev2profile


# cria o tunnel GRE e aplica a protecao
interface Tunnel299
 description Tunnel Test Rafael
 bandwidth 10000
 ip address 172.31.31.1 255.255.255.252
 ip mtu 1400
 ip tcp adjust-mss 1360
 tunnel source Port-channel1.536
 tunnel destination 203.0.113.66
 tunnel protection ipsec profile VPN-IKEv2-IPsec-Profile
end

Huawei Complete Configuration

# Cria o service-instance-group (somente NE40)
service-location 1
 location slot 1
 commit

service-instance-group group1
 service-location 1

# PROPOSAL PARA fase 1
ike proposal 1
 encryption-algorithm aes-cbc 256
 dh group14
 authentication-algorithm sha1
 integrity-algorithm hmac-sha1-96

# ACL de tráfego interessante
acl number 3000
 rule 0 permit gre vpn-instance vpna source 203.0.113.66 0 destination 198.51.100.2 0


# policy de fase 1
ipsec policy teste 1 isakmp
 ipsec df-bit clear
 security acl 3000
 ike-peer teste
 proposal comfone
 log enable


# chaveiro com as PSK e peer
ike peer teste
 pre-shared-key <senha>
 ike-proposal 1
 remote-address 198.51.100.2
 sa binding vpn-instance vpna


# confs da fase 2
ipsec proposal comfone
 encapsulation-mode tunnel
 transform esp
 esp authentication-algorithm sha1
 esp encryption-algorithm aes 256


# Para uso de Gre over IPSEC com o local address sendo compartilhado, para não haver conflito, será necessario criar uma vrf.
ip vpn-instance vpna
 ipv4-family
  route-distinguisher 100:1
  apply-label per-instance
  vpn-target 111:1 export-extcommunity
  vpn-target 111:1 import-extcommunity

# Neste cenario o IP de saida será uma lo (atentar que a config bindando o tunel ipsec, será feita quando atrelar o tunel a esta interface)

interface LoopBack1
 ip address 203.0.113.66 255.255.255.255
 binding tunnel ipsec

# Lo atrelada a vrf, para uso no GRE do mesmo IP.
interface LoopBack10
 ip binding vpn-instance vpna
 ip address 203.0.113.66 255.255.255.255
 binding tunnel gre
 
 # Tunel GRE do Teste
interface Tunnel900
 bandwidth 10000
 mtu 1400
 ip address 172.31.31.2 255.255.255.252
 clear ip df
 tunnel-protocol gre
 source LoopBack10
 destination vpn-instance vpna 198.51.100.2


# Tunel IPsec do teste
interface Tunnel10
ip address unnumbered interface LoopBack1
tunnel-protocol ipsec
ipsec policy teste service-instance-group group1

# Rota para o peer na VPN-Instance para usar o Tunnel
ip route-static vpn-instance vpna 198.51.100.2 255.255.255.255 Tunnel10 198.51.100.2

Authors

Rafael Ganascim

Julian Eble

References

[1] Overview of the GRE. NE40E-M2 Huawei. https://support.huawei.com/hedex/hdx.do?docid=EDOC1100277532&id=EN-US_CONCEPT_0172355906&ui=1