Túnel VPN IPSec entre um roteador Huawei e um roteador Cisco: configuração e 5 armadilhas reais de interoperabilidade entre fabricantes
Um gateway de filial Huawei da série AR estabelecendo um túnel IPSec com um roteador Cisco na matriz pela internet pública — as etapas de configuração, o plano de dados e cinco problemas de interoperabilidade que costumam travar o tráfego mesmo quando o túnel aparece «ativo».
Por Atlas Yuwen Zhang, fundador da AtlasCommTech — 18 anos em ICT, 13 deles em redes de operadoras · Atualizado em julho de 2026
Por que este túnel geralmente não é a parte difícil
Já fiz exatamente essa combinação entre fabricantes mais de uma vez — Huawei de um lado, Cisco do outro.
Fazer um túnel IPSec subir entre um roteador Huawei e um roteador Cisco geralmente não é a parte difícil — os dois lados estabelecem a fase 1 e a fase 2 sem muito drama assim que os parâmetros básicos batem. O que realmente consome tempo é o que acontece depois que o túnel mostra «ativo»: tráfego que ainda não passa, ou um túnel que funciona por um tempo e depois para silenciosamente.
Abaixo está a configuração na qual este texto se baseia — um gateway de filial Huawei se conectando a um gateway de matriz Cisco pela internet pública — além dos cinco problemas de interoperabilidade que explicam a maioria dos chamados de «o túnel sobe mas não funciona» que já vi nessa combinação.
Topologia e plano de dados
Uma interface de túnel em cada lado, transportando o tráfego entre a sub-rede da filial e a da matriz.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
Endereçamento
| Item | RouterA — gateway Huawei da filial | RouterB — gateway Cisco da matriz |
|---|---|---|
| Endereço público (WAN) | 1.1.2.10 | 1.1.1.10 |
| Endereço da interface de túnel | 10.2.1.2 | 10.2.1.1 |
| Gateway da sub-rede privada | 10.1.1.1 | 10.1.2.1 |
Fase 1 — Parâmetros de negociação IKE
| Parâmetro | Valor (este exemplo) |
|---|---|
| Versão IKE | IKEv1 |
| Modo de negociação | Modo principal |
| Método de autenticação | Chave pré-compartilhada |
| Chave pré-compartilhada (este exemplo) | Ex@mpleKey26 — uma chave fictícia para este exemplo; defina sempre sua própria chave exclusiva. |
| Algoritmo de criptografia | aes-cbc-128 |
| Algoritmo de autenticação | sha1 |
| Grupo DH | group5 |
| DPD | Ativado |
Fase 2 — Parâmetros de negociação IPSec
| Parâmetro | Valor (este exemplo) |
|---|---|
| Protocolo de segurança | ESP |
| Modo de encapsulamento | Túnel |
| Algoritmo de criptografia | aes-128 |
| Algoritmo de autenticação | sha1 |
| Tempo de vida da SA | 3600 segundos (padrão) |
| PFS | Desativado |
Pontos-chave da configuração — lado Huawei
Seis etapas transformam uma interface de túnel simples em uma realmente protegida por IPSec.
- Configure os endereços IP das interfaces e uma rota estática para que os dois lados sejam alcançáveis pela rede pública.
- Crie a interface de túnel do tipo IPSec e aponte sua origem e destino para os dois endereços IP públicos.
- Opcional: execute um protocolo de roteamento dinâmico (OSPF, neste exemplo) sobre o túnel para que a sub-rede privada remota fique alcançável sem rotas estáticas — útil quando a sub-rede da filial é grande.
- Defina uma proposta IKE e um peer IKE — os atributos da fase 1: criptografia, autenticação, grupo DH, chave pré-compartilhada e DPD.
- Defina uma proposta IPSec (ESP, modo túnel, criptografia, autenticação) e um perfil IPSec que referencie tanto a proposta quanto o peer IKE.
- Aplique o perfil IPSec à interface de túnel para que ela realmente receba a proteção IPSec.
<Huawei> system-view
[Huawei] sysname RouterA
[RouterA] interface gigabitethernet 1/0/0
[RouterA-GigabitEthernet1/0/0] ip address 1.1.2.10 255.255.255.0
[RouterA-GigabitEthernet1/0/0] quit
[RouterA] interface gigabitethernet 2/0/0
[RouterA-GigabitEthernet2/0/0] ip address 10.1.1.1 255.255.255.0
[RouterA-GigabitEthernet2/0/0] quit
[RouterA] ip route-static 0.0.0.0 0.0.0.0 1.1.2.1
[RouterA] interface Tunnel0/0/0
[RouterA-Tunnel0/0/0] ip address 10.2.1.2 255.255.255.0
[RouterA-Tunnel0/0/0] tunnel-protocol ipsec
[RouterA-Tunnel0/0/0] source gigabitethernet 1/0/0
[RouterA-Tunnel0/0/0] destination 1.1.1.10
[RouterA-Tunnel0/0/0] quit
[RouterA] ike proposal 5
[RouterA-ike-proposal-5] encryption-algorithm aes-cbc-128
[RouterA-ike-proposal-5] authentication-algorithm sha1
[RouterA-ike-proposal-5] dh group5
[RouterA-ike-proposal-5] authentication-method pre-share
[RouterA-ike-proposal-5] quit
[RouterA] ike peer RouterA v1
[RouterA-ike-peer-RouterA] ike-proposal 5
[RouterA-ike-peer-RouterA] pre-shared-key cipher Ex@mpleKey26
[RouterA-ike-peer-RouterA] dpd type periodic
[RouterA-ike-peer-RouterA] dpd msg seq-hash-notify
[RouterA-ike-peer-RouterA] quit
[RouterA] ipsec proposal RouterA
[RouterA-ipsec-proposal-RouterA] transform esp
[RouterA-ipsec-proposal-RouterA] encapsulation-mode tunnel
[RouterA-ipsec-proposal-RouterA] esp authentication-algorithm sha1
[RouterA-ipsec-proposal-RouterA] esp encryption-algorithm aes-128
[RouterA] ipsec profile profile1
[RouterA-ipsec-profile-profile1] ike-peer RouterA
[RouterA-ipsec-profile-profile1] proposal RouterA
[RouterA-ipsec-profile-profile1] quit
[RouterA] interface tunnel 0/0/0
[RouterA-Tunnel0/0/0] ipsec profile profile1Como isso fica do lado Cisco
Os mesmos cinco ingredientes, família de comandos diferente: crypto isakmp policy ocupa o lugar da proposta IKE, crypto ipsec transform-set o da proposta IPSec, e um crypto ipsec profile vinculado à interface de túnel com tunnel protection ipsec profile substitui a etapa ipsec profile do lado Huawei.
RouterB#configure
RouterB(config)#interface gigabitethernet 0/1
RouterB(config-if)#ip address 1.1.1.10 255.255.255.0
RouterB(config-if)#exit
RouterB(config)#interface gigabitethernet 0/2
RouterB(config-if)#ip address 10.1.2.1 255.255.255.0
RouterB(config-if)#exit
RouterB(config)#ip route 0.0.0.0 0.0.0.0 1.1.1.1
RouterB(config)#interface tunnel 0
RouterB(config-if)#ip address 10.2.1.1 255.255.255.0
RouterB(config-if)#tunnel mode ipsec ipv4
RouterB(config-if)#tunnel source gigabitethernet0/1
RouterB(config-if)#tunnel destination 1.1.2.10
RouterB(config-if)#exit
RouterB(config)#crypto isakmp policy 10
RouterB(config-isakmp)#hash sha
RouterB(config-isakmp)#encryption aes 128
RouterB(config-isakmp)#group 5
RouterB(config-isakmp)#authentication pre-share
RouterB(config-isakmp)#exit
RouterB(config)#crypto isakmp key Ex@mpleKey26 address 0.0.0.0 no-xauth
RouterB(config)#crypto isakmp keepalive 10 periodic
RouterB(config)#crypto ipsec transform-set tran1 esp-sha-hmac esp-aes 128
RouterB(cfg-crypto-trans)#mode tunnel
RouterB(cfg-crypto-trans)#exit
RouterB(config)#crypto ipsec profile profile1
RouterB(ipsec-profile)#set transform-set tran1
RouterB(ipsec-profile)#exit
RouterB(config)#interface tunnel 0
RouterB(config-if)#tunnel protection ipsec profile profile1
RouterB(config-if)#exitA sintaxe do lado Cisco desta nota foi verificada no Cisco IOS Software, C3900e-UNIVERSALK9-M, versão 15.2(4)M1 — IOS-XE e ASA usam sintaxe parecida, mas não idêntica.
5 armadilhas reais de interoperabilidade entre fabricantes
Esses cinco pontos explicam a maioria dos chamados de «o túnel está ativo, mas o tráfego não» e «ontem funcionava» que já vi nessa combinação exata.
1. O formato dos pacotes DPD não coincide entre fabricantes
SINTOMAA detecção de peer inativo (DPD) está habilitada, e o túnel se comporta de forma imprevisível em vez de detectar corretamente um peer inativo.
CAUSAO formato de pacote DPD padrão da Cisco não é o mesmo do roteador Huawei. Deixado no padrão, o lado Huawei não está realmente falando o mesmo dialeto DPD que o lado Cisco.
SOLUÇÃONo roteador Huawei, defina o formato de mensagem DPD como seq-hash-notify para que corresponda ao que o lado Cisco espera.
[RouterA-ike-peer-RouterA] dpd type periodic
[RouterA-ike-peer-RouterA] dpd msg seq-hash-notify2. Os dois lados usam SHA-2: o túnel sobe, o tráfego não passa
SINTOMAdisplay ike sa (ou show crypto isakmp sa) mostra a fase 1 e a fase 2 estabelecidas, mas um ping através do túnel falha, ou só parte do tráfego passa.
CAUSAQuando o roteador Huawei e o dispositivo do outro fabricante usam um algoritmo SHA-2 na proposta de segurança IPSec, suas implementações de criptografia/decriptografia SHA-2 podem diferir o suficiente para que o túnel negocie bem, mas o plano de dados não.
SOLUÇÃONo roteador Huawei, habilite o modo de compatibilidade SHA-2 para que os dois lados processem o SHA-2 da mesma forma.
[RouterA] ipsec authentication sha2 compatible enable3. Origem do túnel configurada com IP dinâmico quebra na próxima troca de endereço
SINTOMAO túnel cai sem nenhuma mudança de configuração nos dois lados — geralmente logo depois que o IP público da filial muda em uma renovação DHCP ou PPPoE.
CAUSAA origem da interface de túnel foi configurada como um endereço IP fixo, mas esse endereço é atribuído dinamicamente na interface de saída. Quando o endereço muda, a origem configurada do túnel deixa de corresponder à realidade.
SOLUÇÃOConfigure source como a própria interface de saída, não seu endereço IP atual, para que o túnel acompanhe a interface em vez de uma foto do seu endereço.
[RouterA-Tunnel0/0/0] source gigabitethernet 1/0/04. A negociação de versão IKE não acontece como você esperava
SINTOMAO peer foi configurado esperando IKEv1 para combinar com uma configuração Cisco antiga, mas a negociação se comporta como IKEv2 — ou os dois lados simplesmente não concordam em uma versão.
CAUSAPor padrão, um peer IKE da Huawei tem tanto IKEv1 quanto IKEv2 habilitados. Ao iniciar a negociação, ele usa IKEv2; ao responder, suporta ambos. Precisar especificamente do IKEv1 precisa ser configurado explicitamente — isso não acontece automaticamente só porque o outro lado é um equipamento Cisco mais antigo.
SOLUÇÃODesabilite explicitamente o IKEv2 para que o peer apenas inicie e aceite IKEv1.
[RouterA-ike-peer-RouterA] version 1
[RouterA-ike-peer-RouterA] undo version 25. O comando copiado de um guia antigo não existe aqui
SINTOMAUm comando de um exemplo de configuração — remote-name, local-id-type name, ou um pre-shared-key simples — é rejeitado, ou se comporta de forma diferente, no equipamento à sua frente.
CAUSAA Huawei renomeou vários comandos de peer IKE entre versões de software. O comportamento funcional é o mesmo; a palavra-chave não.
SOLUÇÃOCombine a sintaxe com a versão de software realmente em execução antes de copiar uma linha de configuração.
| Sintaxe anterior | Sintaxe atual (verifique sua versão) |
|---|---|
| ike peer peer-name [ v1 | v2 ] | ike peer peer-name + version { 1 | 2 } (V200R008+) |
| remote-name | remote-id (V200R008+) |
| local-id-type name | local-id-type fqdn (V200R008+) |
| pre-shared-key key | pre-shared-key { simple | cipher } key (V200R003C00+) |
As palavras-chave dos comandos e os números de versão permanecem na forma original em todos os idiomas, para referência exata.
Projetos de soluções relacionadas
Como confirmar que está realmente funcionando
«Estabelecido» na tabela de SA é necessário, mas não suficiente — verifique também os contadores de pacotes.
- No roteador Huawei, execute display ike sa; no roteador Cisco, execute show crypto isakmp sa. As associações de segurança da fase 1 e da fase 2 devem aparecer como estabelecidas — a Huawei marca uma SA saudável como RD|ST (pronta, mantida ativa).
- display ipsec sa no roteador Huawei (show crypto ipsec sa no roteador Cisco) confirma o mesmo na camada IPSec.
- A partir de um host da filial, faça ping em um host da matriz através do túnel e depois execute display ipsec statistics esp no roteador Huawei. Os campos Inpacket decap count e Outpacket encap count devem ser diferentes de zero — isso confirma que o tráfego está realmente sendo criptografado e decriptografado, não apenas que a SA existe.
[RouterA] display ike sa
Conn-ID Peer VPN Flag(s) Phase
---------------------------------------------------------
8 1.1.1.10 0 RD|ST 2
6 1.1.1.10 0 RD|ST 1
Flag Description:
RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT
HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UPSe o túnel não se estabelecer de forma alguma, as duas primeiras coisas a verificar são sempre as mesmas: se a rota subjacente até o endereço público do peer é realmente alcançável, e se as configurações dos dois lados realmente coincidem, parâmetro por parâmetro.
Limites honestos desta nota
Esta nota se baseia em uma configuração validada: um roteador Huawei (IKEv1, modo principal, chave pré-compartilhada, AES-128 / SHA-1) para um roteador Cisco. As combinações de fabricantes, versões de software e conjuntos de criptografia se multiplicam rápido — IKEv2, modo agressivo, travessia de NAT, uma filial com IP dinâmico, ou um fabricante homólogo totalmente diferente (Fortinet, por exemplo) mudam os detalhes. Esta nota cobre a combinação mais comum, não todas.
Referências
Normas e documentos do fabricante em que esta nota se baseia. A sintaxe dos comandos segue a documentação do fabricante; verifique o comportamento exato na sua versão de firmware.
Envie-nos sua combinação exata
Modelos de equipamento, versões de software e o conjunto de criptografia que você está tentando usar — mande pelo WhatsApp e a gente ajuda a alinhar os parâmetros dos dois lados.