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 tenemos el router Cisco con dirección IP pública 198.51.100.2 y el router Huawei NE40 con IP pública 203.0.113.66. Ambos están conectados a Internet, y con conectividad entre ellos. Necesitamos establecer un túnel GRE entre los routers y protegerlo mediante IPSec en modo túnel. La dirección 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:
interconexión de redes internas desconectadas
interconexión de 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 se requieren 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 interesante
El tráfico interesante es el desencadenante que provoca el establecimiento del túnel. El router o cortafuegos, al detectar tráfico interesante, inicia los siguientes pasos de la negociación 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 homólogo remoto. Una vez establecido este canal seguro, se permiten los intercambios de mensajes de 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 - IKE fase 2
En esta fase, ya con el túnel seguro protegido establecido en la fase 1, podemos negociar lo que llamamos SAs IPSec, que no son más que los «contratos» del tipo de tráfico que será protegido por el túnel IPSec, negociados dinámicamente. Un ejemplo podría ser «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 algoritmo de autenticación Y», y el peer remoto hace la regla en sentido contrario.
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
Esta fase es la transferencia de datos propiamente dicha. Una vez que el tráfico interesante llega al router, y se completan las fases 1 y 2, los paquetes se envían de acuerdo con los contratos establecidos en IPSec SA, y se transmiten al peer remoto. - Cierre del túnel
El cierre del túnel se produce por un proceso manual, o cuando algún parámetro IPSec expira o alcanza su límite. En este caso, se descartan todas las claves, se deshacen los contratos y, si es necesario reenviar tráfico, hay que establecer 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 | <COOL_VERSEO> | |
Propiedades del túnel | Sitio A Dispositivo VPN | Sitio B Dispositivo VPN | |
Fase 1 | Método de autenticación | <Clave precompartida> APasswordWellS3gur@ | <Clave precompartida> 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és diagnosticando problemas, y él sea de esta etapa, ya sabes dónde cambiar 🙂 .
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 ikev2profileCreació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
endConfiguraciones 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 1Actualizació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-extcommunityCreació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 greAhora 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 0El 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 crearemos la fase 1 (recuerda que en cisco incluso se empieza por ella, mucho más sencillo). En el medio tiene algunos ajustes de enlace VPN-Instance, 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 vpnaTodo lo anterior se refiere a la Fase 1. Así que cuando estés diagnosticando problemas, y él sea de esta etapa, ya sabes dónde cambiar 🙂 .
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 256Ahora 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 enableCreació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 hay un túnel IPSec funcionando en el exterior, y un segundo túnel GRE en el interior, uno encapsulado en el otro. Pero lo curioso es que el túnel GRE va por fuera de la VRF, y el ipsec por dentro. ¿Baguncinha ne?
# 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 group1Así 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, una ruta que tiene cierta complejidad en sí misma: dentro de la instancia VPNA, digo que para llegar al peer remoto, uso la interfaz IPSec recién creada, siendo el next-hop el propio peer.
# 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.2Y 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 secCuando 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: 0Cuando 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 outVerificació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 msComprobació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] Visión general de GRE. NE40E-M2 Huawei. https://support.huawei.com/hedex/hdx.do?docid=EDOC1100277532&id=EN-US_CONCEPT_0172355906&ui=1
