Início / Notas técnicas / Solução de problemas do túnel IPSec

O túnel VPN IPSec não sobe? Um fluxograma de solução de problemas e as causas mais frequentes

Um túnel que se recusa a subir, ou que sobe e mesmo assim não deixa o tráfego passar, é um dos problemas mais comuns em IPSec site a site. Esta é a ordem de diagnóstico que encontra a falha mais rápido — o que verificar em cada etapa, os comandos display a executar, e as causas que respondem pela maioria desses chamados.

Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026

Por que adivinhar custa mais do que ler a árvore de falhas

Eu sempre volto à mesma sequência curta de verificações — não porque o IPSec seja simples, mas porque as formas como ele falha se repetem.

Um túnel IPSec que não sobe, ou que sobe e mesmo assim não deixa o tráfego passar, é um dos problemas mais comuns na conectividade site a site. O instinto é mudar a configuração dos dois lados ao mesmo tempo — mas é bem mais rápido percorrer as etapas de negociação em ordem: se a negociação IKE sequer é disparada, se a fase 1 (a IKE SA) se completa, se a fase 2 (a IPSec SA) se completa, e só então se o tráfego protegido realmente está fluindo.

A seguir está a árvore de falhas na qual isto se baseia, as verificações de cada etapa com os comandos exatos, as causas que aparecem repetidamente depois das primeiras verificações, e algumas respostas de perguntas frequentes tiradas de casos reais de campo.

Leia a árvore de falhas antes de mexer em qualquer configuração

As falhas de IPSec se dividem em exatamente duas formas: o túnel nunca sobe, ou ele sobe e algo ainda está errado.

Colocar primeiro o sintoma nesta árvore evita muito retrabalho depois — ela indica qual das seções abaixo realmente se aplica ao que você está vendo.

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

A falha de negociação da IKE SA ou da IPSec SA é o núcleo da maioria das falhas de IPSec, e vale a pena analisá-la diretamente junto ao processo de negociação. Quase tudo o mais nessa árvore — uma interface, uma rota, uma ACL, uma regra de NAT — é um simples erro de configuração de outro recurso, que precisa ser rastreado em seu próprio contexto, não no processo de IPSec em si.

Percorrendo cada etapa

Quatro etapas, quatro conjuntos diferentes de coisas a verificar — e o comando que indica em qual etapa você está realmente travado.

Etapa 0 — Confirmar se a negociação IKE sequer foi disparada

Se display ike sa não mostrar absolutamente nada, não presuma que a fase 1 falhou — primeiro verifique se a negociação sequer foi disparada.

Verifique o modo de acionamento da SA com display ipsec policy. O padrão é acionado por tráfego, o que significa que a negociação só começa quando o tráfego real tenta atravessar o túnel — um Ping já basta. Se preferir não depender do tráfego aparecer primeiro, configure sa trigger-mode auto.
Verifique display ipsec statistics. Se outbound ok for 0 (ou trigger ok for 0 no modo acionado por tráfego), nenhum pacote IKE realmente saiu ainda deste roteador — isso é a etapa 0, não uma falha de fase 1.
Use Ping para confirmar que tanto a rota da rede privada quanto a da rede pública estão realmente alcançáveis.
Verifique display ipsec interface brief para confirmar que a política IPSec está realmente aplicada na interface voltada ao túnel, e não apenas configurada em algum lugar.
Verifique display ipsec policy para encontrar o número da ACL de segurança, depois display acl acl-number para confirmar que essa ACL realmente corresponde ao tráfego real que você quer proteger — e que nenhuma regra de NAT na mesma interface o intercepta antes.

<Huawei> display ipsec policy
===========================================
IPSec policy group: "10"
Using interface: GigabitEthernet1/0/0
===========================================
       Sequence number: 10
       Security data flow: 3100/IPv4
       SA trigger mode: Traffic-based            // default trigger mode

<Huawei> display ipsec statistics
   negotiate about packet statistics:
     IKE ctrl packet inbound ok: 0, outbound ok: 0
     trigger ok: 0, switch sa: 0, sync sa: 0
// outbound ok = 0 -> no IKE packet has left this router yet

<Huawei> display ipsec interface brief
------------------------------------------------
  IPSec policy       : policy1
  Using interface      : GigabitEthernet1/0/0
------------------------------------------------

<Huawei> display acl 3100
Advanced ACL 3100, 1 rule
 rule 5 permit ip source 10.1.2.0 0.0.0.255 destination 10.1.1.0 0.0.0.255 (0 times matched)

Etapa 1 — Negociação da IKE SA (fase 1)

Três combinações diferentes de contadores em display ipsec statistics apontam para três lugares diferentes a verificar — vale a pena checar isso antes de qualquer coisa.

Compare display ipsec statistics nos dois lados. Se o outbound ok do iniciador for diferente de zero, mas o inbound do respondente ficar em 0, o respondente nunca recebeu nada — verifique o filtro UDP 500/4500 da operadora, a alcançabilidade da rota, ou um remote-address errado no iniciador. Se o respondente recebeu, mas seu próprio outbound fica em 0, provavelmente a política IPSec não está aplicada na interface dele, ou seu remote-address não corresponde. Se os dois lados mostram inbound e outbound se movendo, mas o iniciador nunca recebe resposta, verifique um problema de rota unidirecional.
Verifique display ike peer nos dois lados — IP/domínio remoto, versão IKE, modo de negociação, ID local/remoto, versão SM4. Todos precisam coincidir, não basta que sejam individualmente válidos.
Verifique display ike proposal nos dois lados — método de autenticação, algoritmo de autenticação, algoritmo de criptografia, grupo DH, algoritmo PRF. Uma divergência em qualquer um desses já é suficiente para falhar a fase 1.
Se houver um dispositivo NAT entre os dois peers, confirme que o NAT traversal está habilitado nos dois lados, e que qualquer autenticação de peer baseada em IP aponte para o endereço anterior ao NAT via remote-address authentication-address.

<Router1> display ipsec statistics
   negotiate about packet statistics:
     IKE ctrl packet inbound ok: 0, outbound ok: 4
// outbound ok not 0 but the peer's inbound stays 0 -> peer never received it

<Router> display ike peer name 1
------------------------------------------
  Remote IP           : 1.1.1.1(www.huawei.com)
  IKE version          : v1
  Exchange mode          : main on phase 1
  Local ID type         : IP
  Remote ID type         : any
  NAT-traversal          : Enable

<Router> display ike proposal number 10
-------------------------------------------
 Authentication Method    : PRE_SHARED
 Authentication Algorithm : SHA2-256
 Encryption Algorithm     : AES-256
 Diffie-Hellman Group     : MODP-2048
 Prf Algorithm            : HMAC-SHA2-256
-------------------------------------------

Etapa 2 — Negociação da IPSec SA (fase 2)

A fase 1 é bem-sucedida, display ike sa mostra uma SA estabelecida, mas ainda não há IPSec SA — isso quase sempre é a ACL ou a proposta.

Verifique se as ACLs de segurança dos dois lados são espelhadas entre si — a origem/destino de um lado deve ser o destino/origem do outro. ACLs não espelhadas só negociam com sucesso se o intervalo do iniciador for um subconjunto do respondente.
Verifique display ipsec proposal nos dois lados — protocolo de segurança (AH/ESP), modo de encapsulamento, algoritmo de criptografia, algoritmo de autenticação.
Verifique display ipsec policy brief para o modo de negociação, e confirme que o grupo DH do PFS coincide nos dois lados se o PFS estiver configurado em qualquer um deles.

<Huawei> display acl 3100
Advanced ACL 3100, 1 rule
 rule 5 permit ip source 10.1.2.0 0.0.0.255 destination 10.1.1.0 0.0.0.255
// the peer's rule should mirror this: source 10.1.1.0/24 destination 10.1.2.0/24

<Huawei> display ipsec proposal
IPSec proposal name: p1
 Encapsulation mode: Tunnel
 Transform          : ah-esp-new
 ESP protocol       : Authentication SHA2-HMAC-256
                       Encryption AES-256

<Huawei> display ipsec policy brief
Policy name         Mode      ACL         Peer name
policy1-100         isakmp    3002/IPv4   peer1
// Perfect forward secrecy: DH group 14 -- must match on both ends if configured

Etapa 3 — O túnel está ativo, o tráfego ainda não passa

display ipsec sa mostra uma SA estabelecida nos dois lados — isso confirma que o túnel existe, não que o tráfego o está usando.

Compare o Flow source / Flow destination de display ipsec sa com as sub-redes reais do negócio — um túnel pode estar ativo protegendo um tráfego completamente diferente.
Faça Ping a partir de um host real, não apenas do gateway, para descartar um problema de rota host-gateway; em desenhos com múltiplas saídas, verifique também se o roteamento baseado em política está enviando o tráfego silenciosamente para outro lugar que não o túnel.
Verifique se uma regra de NAT na mesma interface está processando o tráfego antes que o IPSec o alcance — o NAT roda primeiro na ordem de encaminhamento, então pode engolir silenciosamente tráfego destinado ao túnel.
Se houver um dispositivo NAT no caminho, confirme que o NAT traversal está habilitado nos dois lados, e que o protocolo de segurança é ESP, não AH — o AH não sobrevive ao NAT-T.
Se o algoritmo de autenticação da proposta for uma variante SHA-2, verifique display ipsec statistics em busca de descartes por falha de autenticação; se houver, habilite ipsec authentication sha2 compatible enable.

<Huawei> display ipsec sa
-----------------------------
  Flow source          : 10.1.0.0/255.255.0.0 0/0
  Flow destination      : 10.2.0.0/255.255.0.0 0/0
// compare this against the real business subnets, not just "tunnel is up"

<Huawei> display ike peer
  NAT-traversal        : Enable

<Huawei> display ipsec proposal
 Transform            : esp-new           // must be ESP, not AH, when NAT-T is in play

<Huawei> display ipsec statistics
  dropped security packet detail:
     authentication: 33, replay: 0
// non-zero authentication drops with SHA-2 in the proposal -> compat mode needed
[Huawei] ipsec authentication sha2 compatible enable

6 causas que aparecem repetidamente

Depois que as quatro etapas acima indicarem onde está o problema, essas seis causas explicam a maior parte do que realmente está errado.

1. A chave pré-compartilhada na verdade não coincide

SINTOMAA IKE SA nunca se forma — display ike sa permanece vazio ou mostra a conexão travada negociando, e este é o único parâmetro da fase 1 que ainda parece não confirmado.

CAUSACom a autenticação por chave pré-compartilhada, as chaves dos dois lados precisam ser idênticas, caractere por caractere. Como a chave configurada é armazenada e exibida em forma cifrada, um erro de digitação em qualquer um dos lados não é algo detectável relendo a configuração em execução — os dois lados podem parecer «configurados» e mesmo assim não coincidir.

SOLUÇÃOReinsira deliberadamente a mesma chave em texto simples nos dois lados, em vez de confiar que um valor copiado anteriormente ainda está correto nos dois lados.

[Router] ike peer huawei
[Router-ike-peer-huawei] pre-shared-key cipher <same-key-on-both-ends>

2. Os parâmetros da proposta IKE não coincidem

SINTOMAdisplay ike error-info reporta phase1 proposal mismatch.

CAUSAEm um caso real com exatamente esse código de erro, a proposta IKE de um roteador usava AES-128 enquanto o peer (um equipamento de outro fabricante) usava AES-256 — um único parâmetro divergente já é suficiente para falhar toda a negociação da fase 1.

SOLUÇÃOCompare display ike proposal lado a lado; quando o peer é de outro fabricante e você não consegue obter a configuração dele diretamente, debugging ikev1 all (ou debugging ikev2 all) no seu próprio roteador mostra os atributos da proposta que o outro lado realmente enviou.

<AR1> display ike error-info
 peer      port  error-reason               version  error-time
 2.1.1.1   500   phase1 proposal mismatch   v1       2017-09-05 15:22:32

// debugging ikev1 all on AR1 showed what the peer actually sent:
Attribute ENCRYPTION_ALGORITHM value AES_CBC
Attribute KEY_LENGTH value 256
Attribute HASH_ALGORITHM value SHA2-256
Attribute AUTHENTICATION_METHOD value PRE_SHARED
Attribute GROUP_DESCRIPTION value MODP_2048
// AR1 was configured for AES-128; the peer proposed AES-256 -- align the two
[AR1] ike proposal 10
[AR1-ike-proposal-10] encryption-algorithm aes-256

3. As ACLs de segurança não são espelhadas — ou se sobrepõem

SINTOMAA IPSec SA não negocia de forma alguma, ou — em um hub com várias filiais — apenas o tráfego de uma filial não passa enquanto as outras funcionam bem.

CAUSAAs ACLs dos dois lados deveriam ser imagens espelhadas uma da outra (origem e destino invertidos); quando não são, a negociação só tem sucesso se o intervalo do iniciador for um subconjunto do respondente. Além disso, quando um hub tem vários túneis de filiais, intervalos de endereços sobrepostos entre diferentes ACLs no mesmo grupo de políticas fazem com que o tráfego de uma filial seja silenciosamente reivindicado pelo túnel de outra filial.

SOLUÇÃOEspelhe a origem/destino da ACL nos dois lados, e garanta que nenhuma das ACLs referenciadas pelo mesmo grupo de políticas IPSec tenha intervalos de regras sobrepostos.

4. O NAT roda primeiro e rouba o tráfego, ou o NAT traversal não está ativado

SINTOMAO túnel aparece como estabelecido nos dois lados, mas o contador de encapsulamento de saída nunca se move — nenhum pacote criptografado está realmente sendo enviado.

CAUSAEm um roteador que também faz NAT, o NAT é aplicado antes do IPSec na ordem de encaminhamento. Se a ACL do NAT ainda corresponder ao tráfego destinado ao túnel, esse tráfego é traduzido e roteado para a internet em vez de para o túnel — sem erro, sem log, nada a observar exceto um contador de pacotes parado. Além disso, quando há um dispositivo NAT entre os dois peers, os dois lados precisam ter o NAT traversal explicitamente habilitado, e o protocolo de segurança precisa ser ESP — o AH não sobrevive à tradução de endereços.

SOLUÇÃOAdicione uma regra deny para os endereços protegidos do túnel no topo da ACL de NAT para que esse tráfego nunca seja traduzido; habilite nat traversal nos dois peers IKE quando houver um dispositivo NAT no caminho; e use ESP, não AH, sempre que o NAT-T estiver envolvido.

acl number 3300
 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
[Router-ike-peer-huawei] nat traversal

5. O DPD declara falsamente o peer como inativo

SINTOMAO túnel não está caído por nenhuma razão óbvia, mas oscila — cai e se reconstrói — mesmo com o link e os dois roteadores funcionando bem.

CAUSAA detecção de peer inativo (DPD) precisa concordar na sequência de payload de seus próprios pacotes de keepalive. Quando a ordem das mensagens DPD dos dois lados não coincide, o DPD falha silenciosamente em confirmar que o peer está vivo, e o túnel é derrubado e reconstruído por um alarme falso.

SOLUÇÃOConfigure parâmetros DPD idênticos nos dois lados — sequência de mensagem, modo de detecção, tempo ocioso, intervalo de retransmissão, limite de tentativas.

[Router-ike-peer-huawei] dpd msg seq-hash-notify
[Router-ike-peer-huawei] dpd type periodic
[Router-ike-peer-huawei] dpd idle-time 20
[Router-ike-peer-huawei] dpd retransmit-interval 10
[Router-ike-peer-huawei] dpd retry-limit 4

6. O tempo de vida da SA não é o mesmo nos dois lados

SINTOMAOs logs mostram eventos repetidos de phase1 hard expiry ou phase2 hard expiry, e o túnel parece renegociar com mais frequência — ou de forma menos simétrica — do que o esperado.

CAUSATanto a IKE SA quanto a IPSec SA carregam um tempo de vida configurado (sa duration, ou o ipsec sa global-duration global). Se os dois lados não estiverem configurados com o mesmo valor, um lado envelhece sua SA e começa a renegociar enquanto o outro ainda mantém a antiga, o que aparece como uma agitação desnecessária em vez de uma renovação limpa e simultânea.

SOLUÇÃOCompare o campo SA Duration de display ike proposal e a duração equivalente da IPSec SA nos dois lados, e iguale-as com sa duration ou ipsec sa global-duration.

<sysname> display ike proposal number 10
 SA Duration(Seconds)   : 86400
<sysname> display ipsec global config
  IPSec sa global-duration time-based(seconds) : 3600

Cinco perguntas que surgem constantemente

Tiradas diretamente do campo — aquelas para as quais vale a pena ter uma resposta pronta.

Qual é a diferença real entre AH e ESP?

AH (Authentication Header) fornece autenticação de origem de dados, verificação de integridade e anti-replay, mas não criptografa o payload — é para tráfego onde a confidencialidade não importa, mas a violação sim. ESP (Encapsulating Security Payload) faz tudo o que o AH faz, além de poder criptografar o payload, e pode ser configurado apenas para criptografia, apenas para autenticação, ou ambos. Os dois podem ser combinados no mesmo túnel; quando são, o ESP é aplicado primeiro, depois o AH, para garantia extra.

display ipsec sa não mostra absolutamente nada — por onde eu começo?

Primeiro faça Ping para confirmar a alcançabilidade da rede pública. Se o túnel for negociado por IKE, verifique display ike sa — se a fase 1 nem sequer se estabeleceu, essa é a resposta. Se a fase 1 parecer boa, espere cerca de dez segundos e verifique novamente; a instalação da SA nem sempre é instantânea. Depois confirme que a interface que carrega a política IPSec está realmente Up, e só então comece a revisar a configuração do IPSec em si.

Minha filial tem um IP público dinâmico e a matriz tem um fixo — ainda posso construir um túnel IPSec?

Sim. O lado de IP fixo configura uma política IPSec baseada em modelo de política que não exige saber o endereço do peer de antemão, e sua entrada de peer IKE simplesmente omite remote-address. O lado de IP dinâmico se configura normalmente, apontando remote-address para o peer fixo. O lado com o endereço imprevisível precisa ser aquele que inicia.

Um túnel se recusa a se estabelecer de forma alguma até eu reiniciá-lo — por quê?

Isso geralmente significa que uma nova filial está tentando proteger tráfego que se sobrepõe a um fluxo de dados que um túnel existente no hub já está protegendo. O conflito bloqueia totalmente a nova negociação, e só se resolve depois que o túnel antigo é derrubado — o que um reinício força. ipsec remote traffic-identical accept permite que um novo peer com uma definição de fluxo protegido idêntica assuma rapidamente, envelhecendo a SA antiga em vez de ser bloqueado por ela.

O túnel está ativo, mas o acesso está lento ou fica caindo e voltando — o que está realmente acontecendo?

Quatro suspeitos habituais: carga de CPU de outros recursos (defesa contra ataques, outras SAs) rodando junto com o IPSec; uma incompatibilidade na ordem do payload do DPD fazendo o túnel oscilar por falsos alarmes de peer inativo; perda comum no caminho de internet a montante do túnel; e fragmentação IP — a própria sobrecarga de encapsulamento do IPSec empurra os pacotes além do MTU do caminho, e tanto fragmentar quanto remontar tráfego criptografado custa CPU que um roteador ocupado nem sempre tem de sobra. Testar com diferentes tamanhos de ping para encontrar o ponto de quebra, depois ajustar o MTU da interface e o tcp adjust-mss, é a solução padrão para este último caso.

Limites honestos desta nota

Limites honestos desta nota

Esta nota se baseia no modelo de classificação de falhas de IPSec do roteador Huawei série AR e seus comandos display ike sa / ipsec sa / ipsec statistics, além dos casos de campo por trás deles. Se o seu gateway for de outro fabricante, os comandos exatos mudam, mas a lógica de negociação subjacente — acionamento, fase 1, fase 2, correspondência de ACL, interação com NAT, DPD, tempo de vida da SA — se aplica diretamente. Não cobre em profundidade casos específicos do IKEv2, como autenticação EAP ou por envelope digital, nem cenários de overlay SD-WAN.

Travado em um túnel específico?

Conte-nos em qual etapa está travado — fase 1, fase 2, ou ativo mas sem tráfego — junto com a saída de display ike sa / display ipsec sa, e ajudamos você a interpretá-la.

WhatsApp com um engenheiro →