En un firewall, IPSec no funciona por sí solo — cada paquete que el túnel envía o protege primero tiene que pasar por el motor de security-policy. Esta es la configuración en la que se basa esta nota: zonas de seguridad e interfaces, parámetros IKE e IPSec, y — la parte que a alguien con solo experiencia en routers se le escapa — las reglas de security-policy que permiten por separado el tráfico de negociación propio del túnel y el tráfico privado que protege.
Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026
En un firewall, la security-policy decide si el propio tráfico de negociación del túnel — y el tráfico que protege — siquiera tiene permitido llegar a IPSec.
En un router, IPSec es en gran parte autónomo: dirigir el tráfico a una ACL, negociar, listo. Un firewall añade una capa de por medio por diseño — cada paquete, incluidos los propios paquetes de negociación IKE y la carga encapsulada en ESP, todavía tiene que pasar el motor de security-policy y sus reglas de zona a zona antes de que IPSec tenga siquiera la oportunidad de procesarlo. Eso significa que una configuración de IPSec que funcionaría perfectamente en un router — proposal, peer, policy, ACL, todo correcto — puede quedarse ahí, completamente configurada en un firewall, y aun así no dejar pasar ni un solo paquete, porque la security-policy lo denegó antes de que IPSec tuviera algo que hacer.
Esta nota está escrita específicamente para el lado del firewall: configurar zonas de seguridad, reglas de security-policy y VPN IPSec juntas en un Huawei USG para que ambas capas concuerden entre sí. Si en cambio está construyendo el túnel entre un router Huawei AR y el firewall de otro fabricante, vea nuestra guía de configuración de interoperabilidad Huawei-Fortinet; si un túnel ya está activo pero algo sigue mal, vea nuestro diagrama de flujo de solución de problemas de túnel IPSec — ambas están escritas desde el lado del router de este mismo problema, no desde el lado del firewall que se cubre aquí.
Dos firewalls, dos LAN privadas, un túnel IPSec a través de internet — además del mapa de zonas que decide si todo eso realmente tiene permiso de ocurrir.
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
Direccionamiento
| Elemento | Valor (este ejemplo) |
|---|---|
| Interfaz trust de FW1 — GigabitEthernet1/0/0 | 10.1.1.1/24 |
| Interfaz untrust (pública) de FW1 — GigabitEthernet1/0/1 | 1.1.1.1/24 |
| Interfaz untrust (pública) de FW2 — el peer del túnel | 2.1.1.1/24 |
| Subred protegida detrás de FW1 | 10.1.1.0/24 |
| Subred protegida detrás de FW2 | 10.1.2.0/24 |
Asigne las interfaces a las zonas, configure IKE e IPSec, aplique la política — luego, el paso que un router no necesita, escriba las reglas de security-policy tanto para el propio tráfico del túnel como para el tráfico que 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 es la parte que a alguien con experiencia en IPSec solo de routers se le escapa por completo — dos pares de reglas separados, no uno, y ninguno es 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 patrón exacto de reglas — un par para el propio tráfico IKE/ESP del túnel en la zona local, un par para el tráfico privado en trust/untrust — proviene directamente de un caso de falla real donde el túnel se mostraba establecido en ambos extremos, pero las dos LAN privadas todavía no podían alcanzarse entre sí, porque solo se había configurado el primer par.
Las que convierten una configuración de IPSec funcional en un túnel que negocia bien y aun así no deja pasar ni un solo paquete.
SÍNTOMAdisplay ike sa muestra la SA IKE como establecida en ambos firewalls, pero nada parece negociarse nunca, o la negociación se reinicia constantemente.
CAUSALos paquetes de negociación IKE (UDP 500/4500) y los propios paquetes del protocolo ESP tienen que llegar al firewall y ser permitidos, exactamente igual que cualquier otro tráfico destinado al dispositivo. Si la security-policy no permite explícitamente el tráfico UDP 500/4500 y del protocolo AH/ESP hacia y desde la propia dirección pública del firewall, el túnel no tiene ningún camino para negociar en primer lugar.
SOLUCIÓNConfigure un par dedicado de reglas de security-policy que permitan el tráfico UDP 500/4500 y del protocolo AH/ESP entre la propia dirección del firewall y la del peer — esto es independiente de, y adicional a, la regla que permite el tráfico privado en sí.
SÍNTOMAdisplay ike sa muestra el túnel como completamente establecido en ambos extremos, pero los hosts en las dos LAN privadas todavía no pueden alcanzarse entre sí.
CAUSALa ACL de IPSec solo define qué tráfico se cifra y se envía al túnel — no dice nada sobre si el motor de security-policy realmente permite ese tráfico entre zonas. Sin una regla de security-policy separada que permita las subredes privadas entre las zonas trust y untrust, el tráfico nunca llega al punto en que IPSec lo cifraría.
SOLUCIÓNConfigure el par de reglas de security-policy de trust a untrust y de untrust a trust para las subredes privadas reales, además de la ACL de IPSec — las dos cumplen propósitos distintos y ninguna sustituye a la otra.
SÍNTOMASe escribió una regla de security-policy de untrust a trust o de trust a untrust para cubrir el tráfico del túnel, y aun así no funciona, aunque las direcciones parecen correctas.
CAUSAEl tráfico destinado a la propia dirección IP del firewall — que es exactamente lo que son la negociación IKE y el extremo de terminación de ESP — se evalúa contra la zona local, sin importar por qué interfaz física o zona haya llegado. Una regla escrita con trust o untrust como zona de destino nunca coincidirá con este tráfico.
SOLUCIÓNEscriba el par de reglas para el propio tráfico del túnel con local como la zona en el lado que es este dispositivo, y confírmelo en display firewall session table verbose — una sesión IKE funcional muestra Zone: local --> untrust (o al revés), no 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-outSÍNTOMALa fase 1 negocia con éxito en un modo de intercambio durante las pruebas, luego falla una vez que la configuración del peer cambia ligeramente, o al cambiar a un modo de intercambio diferente.
CAUSAComo iniciador, si el ike peer tiene un ike-proposal referenciado explícitamente, se envía exactamente esa propuesta para la negociación. Si no está referenciada, el modo principal envía todas las propuestas IKE configuradas localmente para que el peer elija, mientras que el modo agresivo envía solo la propuesta por defecto — dos comportamientos distintos por la misma línea de configuración faltante, según qué modo de intercambio esté activo.
SOLUCIÓNReferencie siempre un ike-proposal explícito bajo el ike peer en lugar de depender de valores predeterminados que dependen del modo de intercambio, para que se ofrezca el mismo conjunto de parámetros sin importar qué modo termine usándose.
ike peer huawei
ike-proposal 10
remote-address 2.1.1.1SÍNTOMAParte del tráfico entre los dos sitios pasa por el túnel cifrado como se espera; otra parte del tráfico entre lo que parecen ser las mismas dos subredes se descarta, o sale sin cifrar.
CAUSALa ACL de IPSec y las direcciones de la regla de security-policy se configuraron en momentos diferentes, por personas diferentes, o se copiaron de ejemplos diferentes, y sus rangos de subred ya no describen exactamente el mismo tráfico. El tráfico que coincide con la security-policy pero queda fuera del rango de la ACL de IPSec nunca se cifra; el tráfico que coincide con la ACL pero queda fuera del rango de la security-policy nunca llega ahí siquiera.
SOLUCIÓNMantenga la regla permit de la ACL de IPSec y las direcciones de origen/destino de la regla de security-policy definidas desde la misma fuente de verdad, y vuelva a verificar ambas juntas cada vez que una cambie — no solo la que se editó.
Una SA IKE establecida es necesaria pero no suficiente — confirme que las reglas de security-policy son las que realmente están recibiendo hits, no solo que están 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 basa en una configuración concreta: dos firewalls Huawei serie USG, IPSec IKEv1 basado en ACL, un par de subredes protegidas en cada lado, reglas de security-policy que cubren el túnel y el tráfico privado. No cubre matices de configuración específicos de IKEv2, IPSec VTI (basado en enrutamiento) en un firewall, la coexistencia de NAT con esta misma política de IPSec en la misma interfaz, la separación de políticas específica de sistemas virtuales (vsys), ni pares de firewalls de alta disponibilidad/activo-activo — cada uno de esos temas cambia lo suficiente la configuración como para merecer su propio tratamiento.
Extraídas de los mismos casos de configuración en los que se basa esta nota.
Sí, siempre ambas. La regla IKE/ESP permite que la propia negociación del túnel y su carga cifrada lleguen al dispositivo (zona local); la regla de tráfico privado permite que el tráfico de negocio real cruce de trust a untrust para que IPSec tenga algo que cifrar en primer lugar. Si falta cualquiera de las dos, se produce un túnel que se ve bien en display ike sa pero que aun así no hace nada útil.
Local — porque va destinado a la propia dirección IP pública del firewall, no enrutado a través de él. Esto es cierto sin importar qué interfaz física o qué zona se le asignó a esa interfaz; una regla escrita con trust o untrust como zona de destino para este tráfico nunca coincidirá con él.
Técnicamente el tráfico pasaría de cualquier forma, pero un default permit amplio no es la postura segura para producción que asume esta nota, y hace que solucionar problemas después sea mucho más difícil — los conteos de hits de display security-policy rule pierden sentido cuando todo coincide con una sola regla general. Configure de todos modos los pares de reglas específicos, y pase a default action deny una vez que se confirme que funcionan.
Los propios parámetros de IKE e IPSec — proposal, peer, policy, ACL — son esencialmente los mismos conceptos en ambas plataformas. Lo que un router no tiene es la capa de security-policy delante de IPSec: en un router, una vez que la ACL y la configuración de la interfaz son correctas, el tráfico llega directamente a IPSec. En este firewall, la security-policy tiene que permitir por separado tanto el propio tráfico del túnel como el tráfico protegido antes de que IPSec tenga la oportunidad de actuar sobre cualquiera de los dos. Vea nuestra guía de configuración Huawei-Fortinet y nuestro diagrama de flujo de solución de problemas de túnel IPSec para la versión del lado del router de esta misma lógica de túnel.
Sí, pero la misma regla que rige a los routers se aplica aquí también: el NAT se evalúa antes que IPSec en el orden de reenvío, así que la ACL de coincidencia de la política de NAT debe excluir explícitamente el tráfico destinado a las subredes protegidas del túnel, o ese tráfico se traduce y se envía a internet en lugar de cifrarse dentro del túnel — sin ningún error que señalar, salvo un contador de cifrado que no avanza.
Cuéntenos su distribución de zonas y qué subredes necesitan cruzar el túnel, y le ayudamos a acertar las reglas de security-policy desde el primer intento.