Em um firewall, o IPSec não funciona sozinho — cada pacote que o túnel envia ou protege primeiro precisa passar pelo mecanismo de security-policy. Esta é a configuração na qual esta nota se baseia: zonas de segurança e interfaces, parâmetros IKE e IPSec, e — a parte que uma experiência limitada a roteadores deixa passar — as regras de security-policy que permitem separadamente o tráfego de negociação próprio do túnel e o tráfego privado que ele protege.
Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026
Em um firewall, a security-policy decide se o próprio tráfego de negociação do túnel — e o tráfego que ele protege — sequer tem permissão para chegar ao IPSec.
Em um roteador, o IPSec é em grande parte autônomo: direcionar o tráfego para uma ACL, negociar, pronto. Um firewall adiciona uma camada no caminho por design — cada pacote, incluindo os próprios pacotes de negociação IKE e a carga encapsulada em ESP, ainda precisa passar pelo mecanismo de security-policy e suas regras de zona a zona antes que o IPSec tenha qualquer chance de processá-lo. Isso significa que uma configuração de IPSec que funcionaria perfeitamente em um roteador — proposal, peer, policy, ACL, tudo correto — pode ficar ali, totalmente configurada em um firewall, e ainda assim não deixar passar um único pacote, porque a security-policy o negou antes mesmo de o IPSec ter algo a fazer.
Esta nota é escrita especificamente para o lado do firewall: configurar zonas de segurança, regras de security-policy e VPN IPSec juntas em um Huawei USG para que as duas camadas concordem entre si. Se você está construindo o túnel entre um roteador Huawei AR e o firewall de outro fabricante, veja nosso guia de configuração de interoperabilidade Huawei-Fortinet; se um túnel já está ativo mas algo ainda está errado, veja nosso fluxograma de solução de problemas de túnel IPSec — ambos são escritos do lado do roteador desse mesmo problema, não do lado do firewall abordado aqui.
Dois firewalls, duas LANs privadas, um túnel IPSec pela internet — além do mapa de zonas que decide se tudo isso realmente tem permissão para acontecer.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
Endereçamento
| Item | Valor (este exemplo) |
|---|---|
| Interface trust do FW1 — GigabitEthernet1/0/0 | 10.1.1.1/24 |
| Interface untrust (pública) do FW1 — GigabitEthernet1/0/1 | 1.1.1.1/24 |
| Interface untrust (pública) do FW2 — o peer do túnel | 2.1.1.1/24 |
| Sub-rede protegida atrás do FW1 | 10.1.1.0/24 |
| Sub-rede protegida atrás do FW2 | 10.1.2.0/24 |
Atribua as interfaces às zonas, configure IKE e IPSec, aplique a política — depois, a etapa que um roteador não precisa, escreva as regras de security-policy tanto para o próprio tráfego do túnel quanto para o tráfego que ele protege.
#
firewall zone trust
set priority 85
add interface GigabitEthernet1/0/0
#
firewall zone untrust
set priority 5
add interface GigabitEthernet1/0/1
#
ike proposal 10
authentication-method pre-shared-key
authentication-algorithm sha2-256
encryption-algorithm aes-256
dh group14
prf hmac-sha2-256
#
ike peer huawei
ike-proposal 10
pre-shared-key cipher <same-key-on-both-ends>
remote-address 2.1.1.1
#
ipsec proposal p1
esp authentication-algorithm sha2-256
esp encryption-algorithm aes-256
#
acl number 3100
rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0 0.0.0.255
#
ipsec policy policy1 10 isakmp
security acl 3100
ike-peer huawei
proposal p1
#
interface GigabitEthernet1/0/0
ip address 10.1.1.1 255.255.255.0
#
interface GigabitEthernet1/0/1
ip address 1.1.1.1 255.255.255.0
ipsec policy policy1
#
ip route-static 0.0.0.0 0.0.0.0 1.1.1.254
#Esta é a parte que uma experiência com IPSec limitada a roteadores deixa passar completamente — dois pares de regras separados, não um, e nenhum é opcional.
security-policy
rule name ike-esp-out
source-zone local
destination-zone untrust
source-address 1.1.1.1 mask 255.255.255.255
destination-address 2.1.1.1 mask 255.255.255.255
action permit
rule name ike-esp-in
source-zone untrust
destination-zone local
source-address 2.1.1.1 mask 255.255.255.255
destination-address 1.1.1.1 mask 255.255.255.255
action permit
rule name private-out
source-zone trust
destination-zone untrust
source-address 10.1.1.0 mask 255.255.255.0
destination-address 10.1.2.0 mask 255.255.255.0
action permit
rule name private-in
source-zone untrust
destination-zone trust
source-address 10.1.2.0 mask 255.255.255.0
destination-address 10.1.1.0 mask 255.255.255.0
action permitEste padrão exato de regras — um par para o próprio tráfego IKE/ESP do túnel na zona local, um par para o tráfego privado em trust/untrust — vem diretamente de um caso de falha real em que o túnel aparecia estabelecido em ambas as pontas, mas as duas LANs privadas ainda não conseguiam se alcançar, porque apenas o primeiro par havia sido configurado.
As que transformam uma configuração de IPSec funcional em um túnel que negocia bem e ainda assim não deixa passar um único pacote.
SINTOMAdisplay ike sa mostra a SA IKE como estabelecida em ambos os firewalls, mas nada parece negociar de fato, ou a negociação reinicia constantemente.
CAUSAOs pacotes de negociação IKE (UDP 500/4500) e os próprios pacotes do protocolo ESP precisam chegar ao firewall e serem permitidos, exatamente como qualquer outro tráfego destinado ao dispositivo. Se a security-policy não permitir explicitamente o tráfego UDP 500/4500 e do protocolo AH/ESP de e para o próprio endereço público do firewall, o túnel simplesmente não tem caminho para negociar.
SOLUÇÃOConfigure um par dedicado de regras de security-policy permitindo tráfego UDP 500/4500 e do protocolo AH/ESP entre o próprio endereço do firewall e o do peer — isso é separado de, e adicional a, a regra que permite o próprio tráfego privado.
SINTOMAdisplay ike sa mostra o túnel como totalmente estabelecido em ambas as pontas, mas os hosts nas duas LANs privadas ainda não conseguem se alcançar.
CAUSAA ACL do IPSec só define qual tráfego é criptografado e enviado ao túnel — ela não diz nada sobre se o mecanismo de security-policy realmente permite esse tráfego entre zonas. Sem uma regra de security-policy separada permitindo as sub-redes privadas entre as zonas trust e untrust, o tráfego nunca chega ao ponto em que o IPSec o criptografaria.
SOLUÇÃOConfigure o par de regras de security-policy de trust para untrust e untrust para trust para as sub-redes privadas reais, além da ACL do IPSec — as duas servem propósitos diferentes e nenhuma substitui a outra.
SINTOMAUma regra de security-policy foi escrita de untrust para trust ou trust para untrust para cobrir o tráfego do túnel, e ainda assim não funciona, mesmo que os endereços pareçam corretos.
CAUSAO tráfego destinado ao próprio endereço IP do firewall — que é exatamente o que são a negociação IKE e a extremidade de terminação do ESP — é avaliado em relação à zona local, independentemente de qual interface física ou zona ele chegou. Uma regra escrita com trust ou untrust como zona de destino nunca corresponderá a esse tráfego.
SOLUÇÃOEscreva o par de regras para o próprio tráfego do túnel com local como a zona no lado que é este dispositivo, e confirme em display firewall session table verbose — uma sessão IKE funcional mostra Zone: local --> untrust (ou o inverso), não trust --> untrust.
<FW1> display firewall session table verbose
udp VPN: public --> public ID: a68f5bd4603f01f756c5ab54663
Zone: local --> untrust TTL: 00:02:00 Left: 00:01:58
1.1.1.1:500 --> 2.1.1.1:500 PolicyName: ike-esp-outSINTOMAA fase 1 negocia com sucesso em um modo de troca durante os testes, depois falha assim que a configuração do peer muda ligeiramente, ou ao mudar para um modo de troca diferente.
CAUSAComo iniciador, se o ike peer tiver um ike-proposal explicitamente referenciado, exatamente essa proposta é enviada para a negociação. Se não estiver referenciada, o modo principal envia todas as propostas IKE configuradas localmente para o peer escolher, enquanto o modo agressivo envia apenas a proposta padrão — dois comportamentos diferentes pela mesma linha de configuração ausente, dependendo de qual modo de troca está ativo.
SOLUÇÃOSempre referencie um ike-proposal explícito sob o ike peer em vez de depender de padrões dependentes do modo de troca, para que o mesmo conjunto de parâmetros seja oferecido independentemente de qual modo acabe sendo usado.
ike peer huawei
ike-proposal 10
remote-address 2.1.1.1SINTOMAParte do tráfego entre os dois sites passa pelo túnel criptografado como esperado; outra parte do tráfego entre o que parecem ser as mesmas duas sub-redes é descartada, ou sai sem criptografia.
CAUSAA ACL do IPSec e os endereços da regra de security-policy foram configurados em momentos diferentes, por pessoas diferentes, ou copiados de exemplos diferentes, e seus intervalos de sub-rede não descrevem mais exatamente o mesmo tráfego. O tráfego que corresponde à security-policy mas fica fora do intervalo da ACL do IPSec nunca é criptografado; o tráfego que corresponde à ACL mas fica fora do intervalo da security-policy nunca chega lá.
SOLUÇÃOMantenha a regra permit da ACL do IPSec e os endereços de origem/destino da regra de security-policy definidos a partir da mesma fonte de verdade, e reverifique ambos juntos sempre que um deles mudar — não apenas o que foi editado.
Uma SA IKE estabelecida é necessária mas não suficiente — confirme que as regras de security-policy são as que realmente estão recebendo hits, não apenas que estão presentes.
<FW1> display ike sa
IKE SA information :
Conn-ID Peer VPN Flag(s) Phase
---------------------------------------------------------------
151003222 2.1.1.1:500 RD|ST|A v1:2
151003215 2.1.1.1:500 RD|ST|A v1:1
Number of IKE SA : 2
<FW1> display firewall session table verbose
udp VPN: public --> public ID: a68f5bd4603f01f756c5ab54663
Zone: local --> untrust TTL: 00:02:00 Left: 00:01:58
1.1.1.1:500 --> 2.1.1.1:500 PolicyName: ike-esp-out
<FW1> display current-configuration configuration policy-security
security-policy
rule name ike-esp-out
source-zone local
destination-zone untrust
action permit
rule name private-out
source-zone trust
destination-zone untrust
action permitEsta nota se baseia em uma configuração concreta: dois firewalls Huawei série USG, IPSec IKEv1 baseado em ACL, um par de sub-redes protegidas de cada lado, regras de security-policy cobrindo o túnel e o tráfego privado. Não cobre nuances de configuração específicas do IKEv2, IPSec VTI (baseado em roteamento) em um firewall, a coexistência de NAT com essa mesma política de IPSec na mesma interface, a separação de política específica de sistemas virtuais (vsys), nem pares de firewall de alta disponibilidade/ativo-ativo — cada um desses temas muda o suficiente da configuração para merecer seu próprio tratamento.
Tiradas dos mesmos casos de configuração nos quais esta nota se baseia.
Sim, sempre ambas. A regra IKE/ESP permite que a própria negociação do túnel e sua carga criptografada cheguem ao dispositivo (zona local); a regra de tráfego privado permite que o tráfego de negócio real cruze de trust para untrust para que o IPSec tenha algo para criptografar em primeiro lugar. A ausência de qualquer uma delas produz um túnel que parece bem em display ike sa mas ainda assim não faz nada útil.
Local — porque é destinado ao próprio endereço IP público do firewall, não roteado através dele. Isso é verdade independentemente de qual interface física ou qual zona foi atribuída a essa interface; uma regra escrita com trust ou untrust como zona de destino para esse tráfego nunca corresponderá a ele.
Tecnicamente o tráfego passaria de qualquer forma, mas um default permit amplo não é a postura segura para produção que esta nota assume, e torna a solução de problemas muito mais difícil depois — as contagens de hits de display security-policy rule perdem o sentido quando tudo corresponde a uma única regra abrangente. Configure os pares de regras específicos de qualquer forma, e mude para default action deny assim que estiverem confirmados funcionando.
Os próprios parâmetros de IKE e IPSec — proposal, peer, policy, ACL — são essencialmente os mesmos conceitos em ambas as plataformas. O que um roteador não tem é a camada de security-policy à frente do IPSec: em um roteador, uma vez que a ACL e a configuração da interface estão corretas, o tráfego chega diretamente ao IPSec. Neste firewall, a security-policy precisa permitir separadamente tanto o próprio tráfego do túnel quanto o tráfego protegido antes que o IPSec tenha a chance de agir sobre qualquer um deles. Veja nosso guia de configuração Huawei-Fortinet e nosso fluxograma de solução de problemas de túnel IPSec para a versão do lado do roteador dessa mesma lógica de túnel.
Sim, mas a mesma regra que rege os roteadores se aplica aqui também: o NAT é avaliado antes do IPSec na ordem de encaminhamento, então a ACL de correspondência da política de NAT deve excluir explicitamente o tráfego destinado às sub-redes protegidas do túnel, ou esse tráfego é traduzido e enviado para a internet em vez de criptografado no túnel — sem nenhum erro para apontar, exceto um contador de criptografia parado.
Conte-nos seu layout de zonas e quais sub-redes precisam cruzar o túnel, e ajudamos você a acertar as regras de security-policy logo na primeira vez.