Um roteador de filial Huawei AR com endereço público atribuído por DHCP, situado atrás de um dispositivo NAT, estabelecendo um túnel IPSec para um roteador Cisco de endereço fixo na matriz — modo agressivo, travessia de NAT, o modelo de mapa dinâmico do lado Cisco, e os modos de falha que só aparecem quando NAT e um IP que muda coexistem.
Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026
A nota anterior Huawei-Cisco assumia que ambos os lados tinham um endereço IP conhecido. Tire isso e o projeto muda.
Uma filial raramente recebe um IP público fixo do seu provedor, e geralmente fica atrás de algum dispositivo NAT — um CPE de operadora, uma caixa NAT dedicada, ou NAT rodando na própria interface WAN do roteador AR. A negociação IKE em modo principal, que identifica peers por endereço IP, não tolera bem nenhuma das duas condições: um endereço dinâmico significa que a matriz não pode pré-configurar um endereço de peer fixo para essa filial, e o NAT reescreve exatamente o endereço de origem que o IKE usaria para escolher a chave pré-compartilhada certa.
Esta nota percorre a configuração que resolve os dois problemas juntos — um gateway de filial Huawei AR com endereço WAN atribuído por DHCP, atrás de um dispositivo NAT separado, negociando em modo agressivo IKEv1 com travessia de NAT habilitada para um roteador Cisco na matriz que aceita a filial por meio de um modelo de mapa dinâmico — além do que muda quando o próprio roteador da filial faz NAT em vez de usar uma caixa separada, e do que muda de novo quando é a matriz, não a filial, que fica atrás de NAT.
Desta vez são três dispositivos, não dois — o roteador da filial, um dispositivo NAT e o roteador Cisco da matriz.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
Endereçamento — RouterA e RouterB
| Item | RouterA — gateway Huawei da filial | RouterB — gateway Cisco da matriz |
|---|---|---|
| Endereço público (WAN) | Atribuído por DHCP, acessado através do NATer | 60.1.2.1 (static) |
| Sub-rede privada | 10.1.1.0/24 | 10.1.2.0/24 |
| Identidade IKE | local-name huawei | espera o nome de peer remoto RouterB |
Dispositivo NAT (NATer)
| Item | Valor (este exemplo) |
|---|---|
| Interface WAN (para a internet) | 60.1.1.1/24 — nat outbound |
| Interface LAN (para o RouterA) | 192.168.1.1/24 — dhcp select interface |
| Rota estática | 0.0.0.0/0 via 60.1.1.2 |
Fase 1 — Parâmetros de negociação IKE
| Parâmetro | Valor (este exemplo) |
|---|---|
| Versão IKE | IKEv1 |
| Modo de negociação | Modo agressivo |
| Método de autenticação | Chave pré-compartilhada |
| Chave pré-compartilhada (este exemplo) | YsHsjx_202206 — a chave do exemplo de origem; defina sempre sua própria chave exclusiva. |
| Algoritmo de criptografia | aes-cbc-128 |
| Algoritmo de autenticação | sha2-256 |
| Grupo DH | group14 |
| Travessia de NAT | Ativado (nat traversal) |
| Identidade do peer | Baseada em nome (local-id-type name / remote-name) |
Fase 2 — Parâmetros de negociação IPSec
| Parâmetro | Valor (este exemplo) |
|---|---|
| Protocolo de segurança | ESP |
| Modo de encapsulamento | Túnel (padrão) |
| Algoritmo de criptografia | aes-128 |
| Algoritmo de autenticação | sha2-256 |
| Fluxo protegido (ACL 3000) | 10.1.1.0/24 ↔ 10.1.2.0/24 |
O modo agressivo mais a travessia de NAT substituem as suposições de IP fixo do modo principal.
#
sysname RouterA
#
ipsec authentication sha2 compatible enable
#
ike local-name huawei
#
acl number 3000
rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0 0.0.0.255
#
ipsec proposal prop1
esp authentication-algorithm sha2-256
esp encryption-algorithm aes-128
#
ike proposal 1
encryption-algorithm aes-cbc-128
dh group14
authentication-algorithm sha2-256
#
ike peer peer1 v1
exchange-mode aggressive
pre-shared-key cipher
ike-proposal 1
local-id-type name
remote-name RouterB
nat traversal
remote-address 60.1.2.1
#
ipsec policy policy1 10 isakmp
security acl 3000
ike-peer peer1
proposal prop1
#
interface GigabitEthernet0/0/1
ipsec policy policy1
ip address dhcp-alloc
#
interface GigabitEthernet0/0/2
ip address 10.1.1.1 255.255.255.0
#
return
Uma caixa dedicada entre o roteador da filial e a internet. Não precisa saber nada sobre o fluxo protegido por IPSec — ela simplesmente traduz todo pacote de saída e atribui ao roteador da filial um endereço privado por DHCP.
#
sysname NATer
#
dhcp enable
#
acl number 3000
rule 5 permit ip
#
interface GigabitEthernet0/0/1
ip address 60.1.1.1 255.255.255.0
nat outbound 3000
#
interface GigabitEthernet0/0/2
ip address 192.168.1.1 255.255.255.0
dhcp select interface
#
ip route-static 0.0.0.0 0.0.0.0 60.1.1.2
#
return
Como o endereço da filial pode mudar e outras filiais podem precisar se conectar da mesma forma, o lado Cisco aceita por identidade em vez de por um endereço de peer fixo, através de um crypto map dinâmico.
!
hostname RouterB
!
crypto isakmp policy 1
encryption aes 128
hash sha256
authentication pre-share
group 14
crypto isakmp key YsHsjx_202206 hostname huawei
!
crypto isakmp identity hostname
!
crypto ipsec transform-set p1 esp-sha256-hmac esp-aes 128
!
crypto dynamic-map p1 1
set transform-set p1
match address 102
!
crypto map p1 1 ipsec-isakmp dynamic p1
!
interface GigabitEthernet0/0
ip address 60.1.2.1 255.255.255.0
duplex auto
speed auto
crypto map p1
!
interface GigabitEthernet0/1
ip address 10.1.2.1 255.255.255.0
duplex auto
speed auto
!
ip route 0.0.0.0 0.0.0.0 60.1.2.2
!
access-list 102 permit ip 10.1.2.0 0.0.0.255 10.1.1.0 0.0.0.255
!
end
A 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.
O exemplo acima faz a filial Huawei iniciar. Se o roteador Cisco precisar iniciar o modo agressivo em direção a uma filial atrás de NAT, ele precisa de um bloco específico para o peer em vez do mapa dinâmico.
crypto isakmp peer ip-address 60.1.1.1
set aggressive-mode client-endpoint fqdn huawei
set aggressive-mode password YsHsjx_202206
Algumas filiais não têm um dispositivo NAT separado — o próprio roteador AR faz NAT na mesma interface que carrega o tráfego protegido por IPSec. Nesse caso a ordem de processamento importa: o NAT é executado antes da criptografia IPSec, então, a menos que o fluxo protegido seja explicitamente excluído da ACL do NAT, o NAT reescreve o endereço de origem antes que a própria ACL do IPSec o veja, e a ACL de segurança do túnel deixa de corresponder. A ACL usada para o NAT deve negar o fluxo protegido por IPSec e permitir apenas todo o resto:
acl number 3001
rule 5 deny ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0 0.0.0.255
rule 10 permit ip
#
interface GigabitEthernet0/0/1
ipsec policy policy1
nat outbound 3001
ip address dhcp-alloc
Esses são os problemas que surgem especificamente ao adicionar NAT e um endereço IP que muda a um túnel Huawei-Cisco normal.
SINTOMAA negociação da fase 1 falha ou escolhe a chave pré-compartilhada errada assim que há um dispositivo NAT entre a filial e a matriz — mesmo que os mesmos parâmetros exatos funcionassem bem em um link IP público direto.
CAUSAO modo principal seleciona a chave pré-compartilhada com base no endereço IP do peer. Assim que o NAT reescreve esse endereço em trânsito, a extremidade remota deixa de procurar a chave pelo endereço que o lado próximo realmente configurou.
SOLUÇÃOMude para o modo agressivo e identifique o peer por nome em vez de por endereço IP — um nome sobrevive à tradução NAT, um endereço IP não.
[RouterA] ike peer peer1 v1
[RouterA-ike-peer-peer1] exchange-mode aggressive
[RouterA-ike-peer-peer1] local-id-type name
[RouterA-ike-peer-peer1] remote-name RouterB
SINTOMAO comando nat traversal é rejeitado em um dispositivo, ou o NAT-T se comporta como se nunca tivesse sido configurado em outro, mesmo que ambos sejam roteadores Huawei AR.
CAUSANo V200R008, a travessia de NAT vem habilitada por padrão e o próprio comando não é suportado. Nas versões posteriores ao V200R008, ela precisa ser configurada explicitamente com o comando nat traversal sob o peer IKE.
SOLUÇÃOVerifique a versão do software antes de assumir o estado do NAT-T — não copie um bloco de peer IKE de uma ramificação de firmware AR para outra sem confirmar se o comando se aplica.
[RouterA-ike-peer-peer1] nat traversal
SINTOMAA filial faz seu próprio NAT (sem uma caixa NATer separada), e o tráfego que deveria ser criptografado sai intacto — ou o túnel nunca vê o tráfego que deveria proteger.
CAUSAQuando IPSec e NAT são configurados na mesma interface de saída, o roteador processa primeiro o NAT e depois a criptografia IPSec. Se a ACL do NAT não excluir explicitamente o fluxo protegido por IPSec, o NAT reescreve o endereço de origem antes que a ACL de segurança do próprio túnel tenha chance de corresponder a ele.
SOLUÇÃONegue primeiro o fluxo protegido por IPSec na ACL do NAT, depois permita todo o resto — assim o NAT só toca no tráfego que não deveria passar pelo túnel.
acl number 3001
rule 5 deny ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0 0.0.0.255
rule 10 permit ip
SINTOMAO túnel funciona bem e depois para de passar tráfego após um período de baixa atividade — sem nenhuma mudança de configuração em nenhum dos lados.
CAUSAOs dispositivos NAT expiram vinculações UDP ociosas. Se nenhum dos lados estiver sondando ativamente o peer, a entrada de tradução do dispositivo NAT para a sessão IKE/IPSec pode expirar enquanto a própria SA ainda parece «estabelecida» — o próximo pacote da matriz não tem para onde ir.
SOLUÇÃOHabilite a detecção periódica de peer inativo no peer IKE para que os dois lados continuem se sondando e a vinculação NAT permaneça renovada.
[RouterA-ike-peer-peer1] dpd type periodic
SINTOMAA fase 1 nunca é concluída, ou o roteador Cisco registra uma incompatibilidade de identidade, mesmo com a chave pré-compartilhada digitada corretamente nos dois lados.
CAUSAPor padrão, a identidade ISAKMP da Cisco é baseada em endereço. Se a filial Huawei apresentar uma identidade baseada em nome (como o modo agressivo exige aqui), o roteador Cisco não vai combiná-la com a chave certa, a menos que seja informado para esperar um nome de host.
SOLUÇÃODefina a identidade ISAKMP como hostname no roteador Cisco, e vincule o segredo pré-compartilhado a esse mesmo nome de host em vez de a um endereço IP.
crypto isakmp key YsHsjx_202206 hostname huawei
crypto isakmp identity hostname
«Estabelecida» na tabela SA é necessário, mas não suficiente atrás de NAT — as portas NAT-T também precisam estar realmente sendo encaminhadas.
[RouterA] display ike sa
Conn-ID Peer VPN Flag(s) Phase
---------------------------------------------------------
8 60.1.2.1 0 RD|ST 2
6 60.1.2.1 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 UP
Se o túnel não se estabelecer de forma alguma atrás de NAT, confirme se o dispositivo NAT está realmente encaminhando UDP 500 e UDP 4500 para a filial — o NAT-T normalmente muda o tráfego IKE para a porta 4500 assim que a tradução é detectada, e um dispositivo que só abre a porta 500 vai quebrar a negociação silenciosamente.
Cinco perguntas que surgem quase toda vez que essa combinação exata — IP dinâmico, NAT, Huawei para Cisco — é montada.
Se houver um dispositivo NAT em qualquer ponto do caminho, não — o modo principal seleciona a chave pré-compartilhada pelo endereço IP do peer, e o NAT reescreve esse endereço antes que ele chegue à outra ponta. O modo agressivo identifica o peer por nome, o que sobrevive à tradução NAT. Se realmente não houver NAT e apenas o IP for dinâmico, o modo principal com uma chave pré-compartilhada coringa vinculada a qualquer endereço ainda pode funcionar.
Ambos funcionam. Um dispositivo NAT separado, como no exemplo principal desta nota, mantém IPSec e NAT bem separados. Se o roteador AR fizer seu próprio NAT na mesma interface, lembre-se de que o NAT roda antes do IPSec — a ACL do NAT deve negar explicitamente o fluxo protegido por IPSec, ou o NAT o reescreverá antes que o túnel tenha chance de protegê-lo.
Então o dispositivo na frente da matriz precisa de encaminhamento de porta estático em vez do NAT de saída usado para a filial: encaminhe UDP 500 e UDP 4500 para o endereço privado do roteador Cisco para que o tráfego IKE e NAT-T realmente o alcance, mais ICMP se os testes de conectividade precisarem passar.
nat server protocol udp global current-interface 500 inside 192.168.1.2 500
nat server protocol udp global current-interface 4500 inside 192.168.1.2 4500
nat server protocol icmp global current-interface inside 192.168.1.2
Como configurado aqui, a chave pré-compartilhada está vinculada ao nome IKE da filial (crypto isakmp key ... hostname huawei), então esse mapa dinâmico efetivamente aceita apenas essa filial identificada. Para que o mesmo mapa aceite qualquer filial, vincule a chave a um endereço coringa em vez de a um nome de host — o mesmo modelo de mapa dinâmico combinado com uma identidade baseada em IP do lado da filial aceitará qualquer peer que apresente a chave correspondente.
Cisco IOS Software, C3900e-UNIVERSALK9-M, versão 15.2(4)M1. IOS-XE e ASA usam sintaxe parecida, mas não idêntica. O guia de configuração de origem também aponta MD5, SHA-1, DES e 3DES como algoritmos com fraquezas conhecidas — evite-os se a outra ponta puder negociar algo mais forte.
Esta nota se baseia na combinação de modo agressivo, travessia de NAT e mapa dinâmico do guia de configuração de origem, além das variantes de NAT do lado da filial e do lado da matriz que ele documenta. Não cobre IKEv2 atrás de NAT, cadeias de NAT duplo, compartilhamento de endereços de NAT de nível operadora (CGN), nem um dispositivo NAT de um fabricante terceiro cujo comportamento de tradução não corresponda exatamente a esta configuração de teste Huawei-para-Huawei NATer.
Filial atrás de NAT, IP dinâmico, uma versão específica do Cisco IOS — mande pelo WhatsApp e a gente ajuda a alinhar os parâmetros dos dois lados.