Início / Notas técnicas / Túnel IPSec Huawei-Cisco atrás de NAT

IPSec de Huawei AR para Cisco atrás de NAT / IP dinâmico: uma configuração de túnel de filial que realmente funciona

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

Quando a filial não tem um endereço fixo

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.

Topologia e plano de dados

Desta vez são três dispositivos, não dois — o roteador da filial, um dispositivo NAT e o roteador Cisco da matriz.

RouterAHuawei branch · dynamic IP NATerNAT device RouterBCisco HQ gateway Internet DHCP · 192.168.1.0/24 60.1.1.1 60.1.2.1 IPSec Tunnel · Aggressive Mode + NAT-T Branch private subnet10.1.1.0/24 HQ private subnet10.1.2.0/24

Os rótulos do diagrama permanecem em inglês para clareza técnica.

Endereçamento — RouterA e RouterB

ItemRouterA — gateway Huawei da filialRouterB — gateway Cisco da matriz
Endereço público (WAN)Atribuído por DHCP, acessado através do NATer60.1.2.1 (static)
Sub-rede privada10.1.1.0/2410.1.2.0/24
Identidade IKElocal-name huaweiespera o nome de peer remoto RouterB

Dispositivo NAT (NATer)

ItemValor (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ática0.0.0.0/0 via 60.1.1.2

Fase 1 — Parâmetros de negociação IKE

ParâmetroValor (este exemplo)
Versão IKEIKEv1
Modo de negociaçãoModo agressivo
Método de autenticaçãoChave pré-compartilhada
Chave pré-compartilhada (este exemplo)YsHsjx_202206a chave do exemplo de origem; defina sempre sua própria chave exclusiva.
Algoritmo de criptografiaaes-cbc-128
Algoritmo de autenticaçãosha2-256
Grupo DHgroup14
Travessia de NATAtivado (nat traversal)
Identidade do peerBaseada em nome (local-id-type name / remote-name)

Fase 2 — Parâmetros de negociação IPSec

ParâmetroValor (este exemplo)
Protocolo de segurançaESP
Modo de encapsulamentoTúnel (padrão)
Algoritmo de criptografiaaes-128
Algoritmo de autenticaçãosha2-256
Fluxo protegido (ACL 3000)10.1.1.0/24 ↔ 10.1.2.0/24

Configuração — RouterA (filial, IP dinâmico, atrás de NAT)

O modo agressivo mais a travessia de NAT substituem as suposições de IP fixo do modo principal.

  1. Defina o nome do dispositivo, habilite a compatibilidade SHA-2 e defina o nome de identidade IKE local que o lado Cisco irá reconhecer.
  2. Defina o tráfego protegido em uma ACL — da sub-rede da filial para a da matriz.
  3. Defina a proposta IPSec — ESP, autenticação SHA2-256, criptografia AES-128.
  4. Defina a proposta IKE — criptografia AES-CBC-128, autenticação SHA2-256, grupo DH14.
  5. Defina o peer IKE em modo agressivo, com travessia de NAT habilitada, uma identidade local/remota baseada em nome, e o endereço público fixo do roteador da matriz como endereço remoto.
  6. Aplique a política IPSec à interface WAN, e habilite o cliente DHCP para que a interface possa obter seu endereço dinâmico.
#
 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

Configuração do dispositivo NAT (NATer)

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

Configuração — RouterB (matriz Cisco, modelo de mapa dinâmico)

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.

Se for o Cisco a iniciar o modo agressivo

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
Quando a filial faz seu próprio NAT

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

5 armadilhas reais atrás de NAT e IP dinâmico

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.

1. O modo principal não sobrevive a um dispositivo NAT no caminho

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

2. A travessia de NAT não é automática em todas as versões de software

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

3. IPSec e NAT na mesma interface de saída entram em conflito

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

4. Sem detecção de peer inativo, uma vinculação NAT pode expirar silenciosamente

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

5. É preciso dizer ao Cisco para esperar um nome, não apenas um IP

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

Projetos de soluções relacionadas

Como confirmar que realmente está funcionando

«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.

  1. No RouterA, execute display ike sa; no RouterB, execute show crypto isakmp sa. A fase 1 e a fase 2 devem aparecer como estabelecidas — uma SA em modo agressivo mostra as mesmas flags RD|ST que uma em modo principal.
  2. display ipsec sa no RouterA (show crypto ipsec sa no RouterB) confirma o mesmo na camada IPSec.
  3. A partir de um host da filial, faça ping em um host da matriz através do túnel, depois execute display ipsec statistics no RouterA — os contadores de pacotes encap/decap devem ser diferentes de zero, confirmando que o tráfego está realmente sendo criptografado e decriptografado, não apenas que a SA existe.
  4. Se o DPD estiver configurado, confirme que ele realmente está sondando, e não apenas presente na configuração — um túnel que para de funcionar silenciosamente após um período ocioso geralmente significa que a vinculação NAT expirou antes que o DPD a renovasse.
[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.

Perguntas frequentes

Cinco perguntas que surgem quase toda vez que essa combinação exata — IP dinâmico, NAT, Huawei para Cisco — é montada.

Preciso usar o modo agressivo, ou posso manter o modo principal se apenas o IP da filial for dinâmico?

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.

O roteador da filial precisa de um dispositivo NAT separado, ou o roteador AR pode fazer NAT sozinho?

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.

E se for a matriz, não a filial, que está atrás de NAT?

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

O modelo de mapa dinâmico do lado Cisco aceita qualquer filial, ou apenas esta?

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.

Com qual versão do Cisco IOS isso foi validado?

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.

Limites honestos desta nota

Limites honestos desta nota

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.

Envie-nos sua combinação exata

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.

WhatsApp com um engenheiro →

Leitura relacionada

Usamos cookies apenas para análises anônimas — sem anúncios, sem rastreamento entre sites.Política de privacidade