Made4it

22/02/2023

Túnel GRE + IPSec entre Cisco IOS y Huawei NE40

En este post vamos a discutir un escenario muy común (y poco documentado), que consiste en utilizar un túnel GRE protegido con IPSec entre un router Cisco IOS ASR1002 y un router Huawei NE40.

La topología de este ejemplo se describe a continuación. Se ha mantenido simple para que podamos discutir los detalles de GRE+IPSEC, sin entrar en los otros puntos de la red.

En ella contamos con el router Cisco, con la dirección IP pública 198.51.100.2, y el router Huawei NE40, con la dirección IP pública 203.0.113.66. Ambos están conectados a Internet y disponen de conectividad entre sí. Debemos establecer un túnel GRE entre los routers y protegerlo mediante IPSec en modo túnel. El espacio de direcciones del túnel es 172.31.31.0/30.

A continuación hablaremos de GRE e IPSec. El objetivo no es detallar por completo estos protocolos, sino ofrecer una visión general y, principalmente, una base para el resto del artículo. No te precipites, hay información muy relevante entre medias.

GRE

Generic Routing Encapsulation (GRE) es un protocolo de tunelización que puede encapsular diversos protocolos de red (por ejemplo, ATM, IPX, IPv6 e incluso IPv4) dentro de paquetes IPv4. Estos paquetes pueden transmitirse a través de redes IPv4 comunes (por ejemplo, Internet).

Algunos casos de uso del GRE:
interconectar redes internas desconectadas entre sí
interconectar redes IPv6 aisladas a través de redes IPv4
establecer la comunicación entre la sede central y las sucursales a través de Internet
enlaces de mitigación
con VPN cuando sea necesario protocolos de enrutamiento

IPSEC

IPSec es un marco de seguridad desarrollado por el IETF que trata de resolver problemas de seguridad que el protocolo IPv4 no pudo solucionar, como el cifrado, la integridad de los datos, la validación de fuentes y la antirrepetición.
En realidad, IPSec no es un único protocolo, sino una combinación de protocolos y algoritmos. Los principales son IKEv1, IKEv2, ESP y AH.

IPSec se utiliza ampliamente en las VPN, tanto de acceso remoto como de sitio a sitio.

En el ciclo de vida de un túnel, tenemos 5 etapas bien definidas:

Definición de «tráfico de interés»
El tráfico de interés es el desencadenante que hace que se establezca el túnel. El router o el cortafuegos, al detectar tráfico de interés, inicia las siguientes etapas de la negociación de IPSec.
El tráfico de interés suele configurarse en forma de ACL, o políticas de tráfico.
IKE fase 1
En la fase 1, el protocolo establece un canal de comunicación seguro con el par remoto. Una vez establecido este canal seguro, se permite el intercambio de mensajes de la fase 2.
Es en la fase 1 cuando se protegen los peers, se autentican y se comparan las políticas ISAKMP (y tienen que coincidir). Hay dos modos, principal y agresivo.

Términos que verás sobre la fase 1: ike, isakmp, grupo DH, clave precompartida, integridad, política isakmp
Fase 2 de IKE
En esta fase, una vez establecido el túnel seguro en la fase 1, podemos negociar lo que denominamos «SA de IPSec», que no son más que los «acuerdos» sobre el tipo de tráfico que será protegido por el túnel IPSec, negociados de forma dinámica. Un ejemplo podría ser: «Voy a proteger el tráfico de la red 192.168.1.0/24 cuando el destino sea 192.168.2.0/24 utilizando el algoritmo de cifrado X y el de autenticación Y», y el par remoto establece la regla en sentido inverso.

Otra función de la fase 2 es mantener las SAs, así como expirar claves y sesiones si se alcanza algún parámetro (ej: expirar SAs y negociar nuevas cada x horas, o cada N kilobytes).

Términos que veremos sobre la fase 2: ipsec, ipsec sa, crypto acl, transform set, mode tunnel, authentication, encryption, ipsec policy
Transferencia de datos
En esta fase tiene lugar la transferencia de datos propiamente dicha. Tan pronto como el tráfico relevante llega al router y se completan las fases 1 y 2, los paquetes se envían de acuerdo con los acuerdos establecidos en las SA de IPSec, transmitiéndose hasta el par remoto.
Cierre del túnel
El cierre del túnel se produce de forma manual, o bien cuando algún parámetro de IPSec caduca o alcanza su límite. En este caso, se descartan todas las claves, se rescinden los contratos y, si es necesario redirigir el tráfico, debe establecerse un nuevo túnel IPSec.

Para más detalles sobre GRE e IPSEC, consulte las referencias citadas al final del artículo.

Las configuraciones GRE e IPSEC acordadas entre las Partes

El siguiente ejemplo muestra cómo se acuerda la información de la VPN. Suelen ser formularios que se rellenan con información sobre el túnel.

Dispositivo VPN	Sitio A Dispositivo VPN	Sitio B Dispositivo VPN
Dirección IP del par VPN *	198.51.100.2	203.0.113.66
Dispositivo *	Cisco ASR 1004	Huawei NE40-M2K
Versión *	V3.0.6


Propiedades del túnel		Sitio A Dispositivo VPN	Sitio B Dispositivo VPN
Fase 1	Método de autenticación	APasswordWellS3gur@	APasswordWellS3gur@
	Versión de IKE	IKEv2	IKEv2
	Grupo Diffie-Hellman	grupo 14	grupo 14
	Algoritmo de cifrado *	AES 256	AES 256
	Algoritmo Hashing *	SHA-1	SHA-1
	Modo principal o agresivo *	Modo principal	Modo principal
	*SA Lifetime (para renegociación) sin kbytes rekeying**	86400 segundos	86400 segundos
Fase 2	*Encapsulación (ESP o AH)**	ESP	ESP
	Algoritmo de cifrado *	AES 256	AES 256
	Algoritmo de autenticación *	SHA-1	SHA-1
	Perfect Forward Secrecy para reintroducir *	Discapacitados	Discapacitados
	Grupo Diffie-Hellman *	grupo 14	grupo 14
	*SA Lifetime (para renegociación) ) sin kbytes rekeying**	3600 segundos	3600 segundos
GRE	Dirección	172.31.31.1/30	172.31.31.2/30
	Keepalives	Discapacitados	Discapacitados
	MTU	1400	1400
	Ajustar SMS	1360	1360

Información importante sobre la licencia y los módulos

Consulte con el fabricante de su equipo para ver si no se requiere algún tipo de tarjeta de servicio, o licencia.

En el caso del equipo de este laboratorio, el router NE40-M2K no necesitaba ningún módulo físico adicional, sólo la licencia IPSec. En el router Cisco tampoco fue necesaria ninguna licencia, ya que su IOS ya estaba en ADVIPSERVICES-K9 (que contiene toda la base para Ipsec).

*Información útil*: si desea ejecutar IKEv1, en el router Huawei necesita un módulo de software para IKEv1 (que se obtiene del proveedor de Huawei).

Configuraciones de Cisco IOS XE

Así que vamos a configurar el router Cisco para establecer la VPN. No entraré en detalles sobre las interfaces físicas, sólo sobre la VPN. Al final del artículo hay un bloque con su correspondiente conf.

Configuraciones de la fase 1 según la tabla anterior:

# 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

Todo lo anterior se refiere a la Fase 1. Así que, cuando esté diagnosticando problemas y estos pertenezcan a esta fase, ya sabrá dónde realizar los cambios 🙂.

Ahora preparando la fase 2:

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

¡Demasiado simple en Cisco! Ahora combinaremos las dos fases en un solo perfil:

# 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

Creación del túnel GRE y adición de la protección IPSec:

# 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

Configuraciones Huawei

A continuación, vamos a configurar el router Huawei para establecer la VPN. Como en el caso de Cisco, no entraré en detalles sobre las interfaces físicas, sólo sobre la VPN. Al final del artículo hay un bloque con su correspondiente conf.

La configuración en el router Huawei es un poco más compleja, ya que crea un túnel para el protocolo GRE, y un túnel para IPSec. Además, queremos utilizar la misma IP para ambos túneles, por lo que se necesita un VRF. 😮

Creación de una instancia de servicio para utilizar la VPN (sólo aplicable en NE40):

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

service-instance-group group1
 service-location 1

Actualización del nuevo 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

Creación de las dos interfaces Loopback con la misma IP (magia VRF). El looback con el túnel IPSec estará en la tabla de enrutamiento público, mientras que el del túnel GRE estará en la tabla VPNA.

# 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

Ahora llegamos a IPSec.

La ACL de tráfico interesante define el tráfico que será protegido por IPSec. En el caso entonces, tendremos el tráfico GRE entre las IPs del sitio A y el sitio B. Tenga en cuenta que sólo hago la comunicación en una dirección – la dirección del router proteger su tráfico).

# 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

El ACL anterior puede leerse así:

«Proteger los datos del protocolo GRE procedentes del VRF vpna entre el origen 203.0.113.66 y el destino 198.51.100.2»

Ahora vamos a crear la fase 1 (recuerde que en Cisco ya se empieza por ella, lo cual es mucho más sencillo). En medio de esta fase hay algunas configuraciones de enlace de la instancia VPN, debido a la VRF creada.

# 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

Todo lo anterior se refiere a la Fase 1. Así que, cuando esté diagnosticando problemas y estos pertenezcan a esta fase, ya sabrá dónde realizar los cambios 🙂.

Pasamos a la fase 2:

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

Ahora combinaremos las dos fases en un solo perfil:

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

Creación de túneles GRE e IPSEC. Vamos allá para no confundir:

Túnel 900 – es un túnel GRE, que opera dentro de la vpna.

Túnel 10 – es un túnel IPSec, que funciona en la tabla global

La idea en Huawei es que haya un túnel IPSec funcionando en el exterior y un segundo túnel GRE en el interior, uno encapsulado dentro del otro. Pero lo curioso es que el túnel GRE funciona fuera de la VRF, y el IPSec, dentro. Un poco lioso, ¿verdad?

# 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

Así que tunnel900 que es el GRE (y que recibe las IPs de /30) usa un destino que va dentro de la VPNA. Y dentro de la VPNA se llega al destino por túnel IPSec. Observe también que la política IPsec se asoció con el túnel 10, utilizando el perfil que se creó.

Por último, y no por ello menos importante, una ruta que presenta cierta complejidad en sí misma: dentro de la instancia VPNA, indico que, para llegar al par remoto, utilizo la interfaz IPSec recién creada, siendo el siguiente salto el propio par.

# 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

Y así configuramos el router Huawei. A ver si ahora ha subido.

Validación del funcionamiento

En el proceso de validación del túnel, debemos recordar siempre que cada fase y etapa depende del establecimiento completo de la otra, por lo que no tiene sentido querer tener conectividad si la fase 1 aún no ha establecido la comunicación.

En ambos routers, validaremos en secuencia:

conectividad
fase1
fase2
Conectividad GRE
estado de las interfaces

Pasemos a las pruebas.

Comprobación Cisco

Validación de la conectividad mediante ping ICMP

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#

Comprobación de que IKEv2 se ha establecido en Fase 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

Cuando no aparece nada en la salida, o no está lista, significa que alguno de los parámetros de la Fase 1 no coincidía. Comprueba en ambos lados si están de acuerdo.

Continuamos la validación en la fase 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:

En la salida anterior, vemos que los routers han conmutado el contrato de «tráfico interesante». Cada parte se ha comprometido a proteger una dirección de la comunicación GRE.

En secuencia todavía en Fase 2, hay algunos contadores muy importantes que se refieren a paquetes enviados/recibidos/encapsulados/encriptados/verificados. Se encuentra en la salida del comando «show crypto ipsec sa». Veámoslos.

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

Cuando estos contadores no se incrementan, o siguen incrementando fallos, es porque alguna configuración de Fase 2 no se está casando.

Un buen ejemplo sería que sólo se incrementara el contador de encaps/encrypt, y que el de decaps/decrypt se pusiera a cero. Este va a ser un interesante asunto de tráfico ACL que está divergiendo en ambos lados. O bloqueo de las comunicaciones en la red de transporte u otros factores que no trataremos aquí. Si necesita ayuda, no dude en ponerse en contacto con nosotros.

Por último, ¡validemos la conectividad en sí! ¡Pero ahora dentro del túnel ya protegido!

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#

Y la interfaz del túnel está funcionando:

# 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

Verificación Huawei

Para validar el funcionamiento en el router Huawei NE40, el enfoque es el mismo que para Cisco.

Validación de la conectividad mediante ping ICMP (recuerde utilizar la fuente loopback)

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

Comprobación de que IKEv2 se ha establecido en Fase 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     : -
  -----------------------------------------------

Cuando no aparece nada en la salida, o no está en listo (RD), significa que alguno de los parámetros de la Fase 1 no coincidía. Comprueba en ambos lados si están de acuerdo.

Continuamos la validación en la fase 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

Por último, validemos la conectividad comprobando los contadores de tráfico. ¡Pero ahora dentro del túnel ya protegido!

[~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]

Y la interfaz del túnel está funcionando:

[~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%

¡Con esto llegamos al túnel establecido y en funcionamiento entre el router Cisco IOS XE y el Huawei NE40!

Configuración completa de Cisco

# 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

Configuración completa de Huawei

# 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

Autores

Rafael Ganascim

Julian Eble

Referencias

[1] Descripción general del GRE. NE40E-M2 de Huawei. https://support.huawei.com/hedex/hdx.do?docid=EDOC1100277532&id=EN-US_CONCEPT_0172355906&ui=1