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

Neste post iremos discutir um cenário muito comum (e pouco documentado), que é utilizar um túnel GRE protegido com IPSec entre um roteador Cisco IOS ASR1002 e um Roteador Huawei NE40.

A topologia deste exemplo é descrita abaixo. Ela foi mantida simples para que possamos discutir os detalhes do GRE+IPSEC, sem entrar nos demais pontos da rede.

Nela temos o roteador Cisco com endereço IP público 198.51.100.2 e o roteador Huawei NE40 com o IP público 203.0.113.66. Ambos estão conectados a Internet, e com conectividade entre si. Precisamos estabelecer um túnel GRE entre os roteadores e protegê-lo através do IPSec no modo tunnel. O endereçamento do túnel é 172.31.31.0/30.

Nas próximas linhas abaixo iremos falar sobre o GRE e IPSec. O objetivo não é detalhar completamente estes protocolos, mas dar um overview e principalmente, uma base para o restante do artigo. Não seja apressado, há informações bem relevantes ali no meio.

GRE

O Generic Routing Encapsulation (GRE) é um protocolo de tunelamento que consegue encapsular uma variedade de protocolos de rede (ex: ATM, IPX, IPv6 e até mesmo IPv4) dentro de pacotes IPv4. Estes pacotes então podem ser transmitidos através das redes IPv4 comuns (ex Internet).

Alguns casos de uso do GRE:
interligar redes internas desconectadas entre si
interligar redes IPv6 isoladas por meio de redes IPv4
estabelecer comunicação Matriz x Filial pela Internet
links de mitigação
com VPNs quando necessários protocolos de roteamento

IPSEC

O IPSec é um framework de segurança desenvolvido pelo IETF que busca resolver problemas de segurança que o protocolo IPv4 não conseguiu tratar, como por exemplo encriptação, integridade de dados, validação de origem e anti-replay.
Na realidade o IPSec não é um único protocolo, e sim uma combinação de protocolos e algoritmos. Os principais são o IKEv1, IKEv2, ESP e o AH.

O IPSec é usado amplamente nas VPNs, sejam elas de remote-access e também nas site-to-site.

No ciclo de vida de um túnel, temos 5 etapas bem definidas:

Definição do tráfego interessante
O tráfego interessante é o gatilho que faz com que o túnel seja estabelecido. O roteador ou firewall, ao notar um tráfego interessante, inicia as próximas etapas da negociação do IPSec.
O tráfego interessante geralmente é configurado na forma de ACLs, ou policies de tráfego.
IKE fase 1
Na fase 1 o protocolo estabelece um canal seguro de comunicação com o peer remoto. Uma vez estabelecido este canal seguro, as trocas de mensagens da fase 2 são permitidas.
É na fase 1 que são protegidos os peers, autenticados, e as policies de ISAKMP são comparadas (e precisam casar). Existem dois modos, main e aggressive.

Termos que você vai ver sobre a fase 1: ike, isakmp, DH group, pre-shared-key, integrity, isakmp policy
IKE fase 2
Nesta fase, já com o túnel seguro protegido estabelecido na fase 1, podemos negociar o que chamamos de IPSec SAs, que nada mais são os “contratos” do tipo de tráfego que serão protegidos pelo túnel IPSec, negociados dinamicamente. Um exemplo pode ser “vou proteger o tráfego da rede 192.168.1.0/24 quando o destino for 192.168.2.0/24 usando o algorítimo de encriptação X e de autenticação Y”, e o peer remoto faz a regra no sentido inverso.

Outra função da fase 2 é manter os SAs, assim como expirar as chaves e as sessões caso algum parâmetro seja alcançado (ex: expire os SAs e negocie novos a cada x horas, ou a cada N kilobytes).

Termos que vamos ver sobre a fase 2: ipsec, ipsec sa, crypto acl, transform set, mode tunnel, authentication, encryption, ipsec policy
Transferência de dados
Nesta fase é a transferência de dados em si. Assim que o tráfego interessante chega no roteador, e as fases 1 e 2 são completas, os pacotes são enviados de acordo com os contratos estabelecidos nos IPSec SA, sendo transmitidos até o peer remoto.
Encerramento do túnel
O encerramento do túnel acontece por processo manual, ou quando algum parâmetro do IPSec expira ou chega ao seu limite. Neste caso, todas as chaves são descartadas, os contratos desfeitos e se o tráfego precisar ser encaminhado, um novo túnel IPSec precisa ser estabelecido.

Para mais detalhes do GRE e IPSEC, consulte as referências citadas no final do artigo.

As configurações de GRE e IPSEC acordadas entre as partes

O exemplo abaixo é de como as informações de VPN são acordadas. Geralmente são formulários que são preenchidos com as informações sobre o túnel.

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


Tunnel Properties		Site A VPN Device	Site B VPN Device
Phase 1	Authentication Method	<Pre-Shared Key> UmaSenhaBemS3gur@	<Pre-Shared Key> UmaSenhaBemS3gur@
	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

Informações importantes sobre licença/módulos

Veja com o fabricante dos seus equipamentos se não é necessário algum tipo de placa de serviços, ou licença.

No caso dos equipamentos deste laboratório, o roteador NE40-M2K não precisou de módulo físico adicional, apenas a licença de IPSec. No roteador Cisco também não foi necessário licença, pois o IOS dele já estava no ADVIPSERVICES-K9 (que contém toda a base para o Ipsec).

*informação útil*: se quiser rodar IKEv1, no roteador Huawei você precisa de um módulo de software para IKEv1 (que você consegue com o fornecedor Huawei).

Configurações do Cisco IOS XE

Vamos lá então configurar o roteador Cisco para estabelecer a VPN. Não vou entrar em detalhes das interfaces físicas, somente da VPN. No final do artigo tem um bloco com a conf pertinente delas.

Configurações de fase 1, de acordo com a tabela acima:

# 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

Tudo o que estiver acima é relativo a Fase 1. Então quando estiver diagnosticando problemas, e ele for desta fase, já sabe onde mudar 🙂.

Agora, configurando a fase 2:

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

Simples demais no Cisco! Vamos agora combinar as duas fases em um 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

Criando o túnel GRE e adicionando a proteção 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

Configurações do Huawei

Vamos lá então configurar o roteador Huawei para estabelecer a VPN. Assim como do Cisco, não vou entrar em detalhes das interfaces físicas, somente da VPN. No final do artigo tem um bloco com a conf pertinente delas.

A configuração no roteador Huawei é um pouco mais complexa, pois ele cria um túnel para o protocolo GRE, e um túnel para o IPSec. Além disso, queremos usar o mesmo IP para ambos os túneis, sendo necessária uma VRF. 😮

Criando o service instance para uso da VPN (aplicavel somente no NE40):

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

service-instance-group group1
 service-location 1

Subindo a nova 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

Criando as duas interfaces Loopback com o mesmo IP (magias da VRF). A looback com o túnel IPSec ficará na tabela de roteamento pública, enquanto que a com o túnel GRE ficará na tabela 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

Agora sim chegamos ao IPSec.

A ACL de tráfego interessante define o tráfego que será protegido pelo IPSec. No caso então, teremos o tráfego GRE entre os IPs do site A e site B. Perceba que só faço a comunicação em um sentido – o sentido do roteador protegendo o tráfego dele).

# 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

A ACL acima pode ser lida assim:

“Proteja os dados do protocolo GRE, vindo da VRF vpna entre a origem 203.0.113.66 e o destino 198.51.100.2”

Partimos agora criar a fase 1 (lembra que no cisco já até começa com ela, muito mais simples). No meio dela tem algumas configurações de binding de VPN-Instance, por conta da VRF criada.

# 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

Tudo o que estiver acima é relativo a Fase 1. Então quando estiver diagnosticando problemas, e ele for desta fase, já sabe onde mudar 🙂.

Seguimos para a fase 2:

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

Vamos agora combinar as duas fases em um 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

Criando os túneis GRE e IPSEC. Vamos lá para não confundir:

Tunnel 900 – é um túnel GRE, operando por dentro da vpna.

Tunnel 10 – é um túnel IPSec, operando na tabela global

A ideia na Huawei é de que exista um túnel IPSec rodando por fora, e um segundo túnel GRE por dentro, um encapsulado no outro. Mas o engraçado é que o túnel GRE roda fora da VRF, e o ipsec 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 group1

Então o tunnel900 que é o GRE (e que recebe os IPs do /30) usa um destino que vai por dentro da VPNA. E dentro da VPNA o destino é alcançado pelo túnel IPSec. Também observe que a policy de IPsec foi associada ao tunnel 10, utilizando o profile que foi criado.

Por fim, e não menos importante, uma rota que tem uma certa complexidade em si mesma: dentro da instancia VPNA, eu digo que para chegar ao peer remoto, eu utilizo a interface de IPSec recem criada, com o next-hop o próprio 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.2

E assim configuramos o roteador Huawei. Vamos ver se subiu agora.

Validação do funcionamento

No processo de validação do túnel, devemos sempre lembrar que cada fase e etapa depende do estabelecimento completo da outra, logo, não adianta querer ter conectividade se a fase 1 ainda não estabeleceu a comunicação.

Em ambos os roteadores, vamos validar em sequência:

conectividade
fase1
fase2
conectividade GRE
status das interfaces

Vamos lá para os testes.

Checagem Cisco

Validando a conectividade 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#

Checando se o IKEv2 estabeleceu na 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

Quando não aparecer nada na saída, ou ele não estiver em ready, quer dizer que alguns dos parâmetros da Fase 1 não casaram. Confira em ambos os lados se eles estão de acordo.

Continuamos a validação na 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:

Na saída acima, vemos que os roteadores trocaram o contrato de “tráfego interessante”. Cada lado se comprometeu a proteger um sentido da comunicação GRE.

Em sequência ainda na Fase 2, existem alguns contadores muito importantes que se referem a pacotes enviados/recebidos/encapsulados/encryptados/verificados. Ele fica na saída do comando “show crypto ipsec sa”. Vamos ver eles.

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

Quando estes contadores não estão incrementando, ou ainda incrementando falhas, é porque alguma configuração da Fase 2 não está casando.

Um bom exemplo seria somente o contador de encaps/encrypt ser incrementado, e enquanto o decaps/decrypt ficando zerado. Isto vai ser um problema da ACL de tráfego interessante que está divergindo em ambos os lados. Ou bloqueio da comunicação na rede de transporte ou ainda outros fatores que não vamos tratar aqui. Se precisar de ajuda, não deixe de nos contactar.

Por fim, vamos validar a conectividade em si! Mas agora por dentro do túnel já 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#

E a interface túnel se apresenta up, e funcional:

# 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

Checagem Huawei

Para validar o funcionamento no roteador Huawei NE40, a abordagem é a mesma do Cisco.

Validando a conectividade via ICMP ping (lembrar de usar a origem 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

Checando se o IKEv2 estabeleceu na 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     : -
  -----------------------------------------------

Quando não aparecer nada na saída, ou ele não estiver em ready (RD), quer dizer que alguns dos parâmetros da Fase 1 não casaram. Confira em ambos os lados se eles estão de acordo.

Continuamos a validação na 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 fim, vamos validar a conectividade em si, conferindo os contadores de tráfego! Mas agora por dentro do túnel já 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]

E a interface túnel se apresenta up, e funcional:

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

Com isto chegamos ao túnel estabelecido e funcionando entre o roteador Cisco IOS XE e o Huawei NE40!

Configuração completa do 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

Configuração completa do 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

Referências

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

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

Informações importantes sobre licença/módulos

Configurações do Cisco IOS XE

Configurações do Huawei

Validação do funcionamento

Checagem Cisco

Checagem Huawei

Configuração completa do Cisco

Configuração completa do Huawei

Deixe um comentário Cancelar resposta

Links

Redes Sociais

Contatos