Un router de sucursal Huawei serie AR que construye un túnel IPSec basado en ACL hacia un firewall Fortinet FortiGate en la sede — cómo se corresponde la terminología de ambos fabricantes para versión IKE, conjunto de cifrado, PFS y duración, la configuración de cada lado, y 5 problemas de interoperabilidad.
Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026
Una línea de comandos Huawei y un asistente de FortiGate describen la misma negociación de fase 1 / fase 2 — el truco está en saber qué campo corresponde a cuál.
El propio IPSec es un estándar IETF neutral respecto al fabricante, pero cada fabricante nombra sus parámetros de forma distinta y los configura por defecto de forma distinta. Emparejar un router Huawei AR en una sucursal con un firewall Fortinet FortiGate en la sede significa que el mismo túnel debe describirse una vez en la CLI de Huawei y otra en la GUI web de FortiGate — y las dos interfaces de configuración no usan las mismas palabras para lo mismo.
A continuación, la configuración en la que se basa esta nota: un router de sucursal Huawei que usa IPSec basado en ACL (no una interfaz de túnel — vea nuestra nota VTI aparte para esa variante), un firewall de sede FortiGate configurado mediante su GUI, una tabla de alineación terminológica para que el mismo parámetro no se configure dos veces con dos nombres distintos, y los 5 problemas de interoperabilidad que aparecen con más frecuencia en este emparejamiento exacto.
Una ACL en el router Huawei define el tráfico protegido; un túnel IPSec personalizado de FortiGate lo refleja como Phase 2 Selectors.
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
Direccionamiento
| Elemento | Router — puerta de enlace Huawei de la sucursal | FW — puerta de enlace Fortinet de la sede |
|---|---|---|
| Dirección pública (WAN) | 1.1.1.1 | 2.1.1.1 |
| Puerta de enlace de la subred privada | 10.1.1.2 | 10.1.2.1 |
Este es el direccionamiento publicado en la propia tabla de plan de datos de la guía de configuración de origen. Si una ruta estática o entrada de ACL copiada de una guía hace referencia a una subred distinta de la de su propia tabla de plan de datos, trátelo como un descuido de documentación que hay que verificar, no como un valor de confianza ciega — vea el Problema 5 más abajo.
Fase 1 — Parámetros de negociación IKE
| Parámetro | Valor (este ejemplo) |
|---|---|
| Versión IKE | IKEv1 |
| Modo de negociación | Modo principal |
| Método de autenticación | Clave precompartida |
| Clave precompartida (este ejemplo) | huawei@123 — la clave del ejemplo de origen; configure siempre su propia clave única. |
| Algoritmo de cifrado | aes-cbc-256 |
| Algoritmo de autenticación | sha2-512 |
| Grupo DH | group14 |
| Duración de la SA IKE | 28800 seconds |
| DPD | Habilitado |
Fase 2 — Parámetros de negociación IPSec
| Parámetro | Valor (este ejemplo) |
|---|---|
| Protocolo de seguridad | ESP |
| Modo de encapsulación | Túnel |
| Algoritmo de cifrado | aes-256 |
| Algoritmo de autenticación | sha2-512 |
| Duración de la SA IPSec | 3600 seconds |
| PFS | Deshabilitado |
Mismo campo, nombre distinto — y, para la duración, distintas unidades por defecto que los ingenieros dan por hecho sin comprobar.
| Término de la CLI Huawei | Qué controla | Equivalente en la GUI de FortiGate |
|---|---|---|
| ike proposal (encryption-algorithm / authentication-algorithm / dh) | Conjunto de cifrado y grupo DH de la fase 1 (SA IKE) | Phase 1 Proposal — combinación de algoritmos, DH Group |
| ike-proposal sa duration | Duración de la fase 1 (SA IKE) | Phase 1 Proposal — Key Lifetime (segundos) |
| ipsec proposal (esp authentication-algorithm / esp encryption-algorithm) | Conjunto de cifrado de la fase 2 (SA IPSec) | Phase 2 Proposal — Cifrado / Autenticación |
| ipsec policy ... sa duration time-based | Duración de la fase 2 (SA IPSec) | Phase 2 Proposal — Key Lifetime, segundos/KBytes/ambos |
| dpd type / dpd msg | Comportamiento de detección de peer muerto y formato de paquete | Dead Peer Detection — On Idle / On Demand, bajo Phase 1 |
| acl number (advanced ACL, permit rule) | Qué tráfico es «interesante» y queda protegido | Phase 2 Selectors — dirección local/remota |
| ike peer ... v1 | Versión del protocolo IKE usada para negociar | Sección Network / IKE — campo IKE Version (1 o 2) |
Los nombres de menú de FortiGate mostrados aquí siguen el recorrido de la GUI en la guía de configuración de Huawei en la que se basa esta nota — las pantallas «Authentication», «IKE», «Phase 1 Proposal» y «Phase 2 Selectors / Phase 2 Proposal» bajo VPN > IPSec > Tunnels. La redacción exacta puede variar ligeramente entre versiones de FortiOS.
Seis pasos, guiados por la ACL: defina primero el tráfico interesante, luego envuélvalo en una política IPSec.
<Huawei> system-view
[Huawei] sysname Router
[Router] interface gigabitethernet 0/0/1
[Router-GigabitEthernet0/0/1] ip address 1.1.1.1 255.255.255.0
[Router-GigabitEthernet0/0/1] quit
[Router] interface gigabitethernet 0/0/2
[Router-GigabitEthernet0/0/2] ip address 10.1.1.1 255.255.255.0
[Router-GigabitEthernet0/0/2] quit
[Router] ip route-static 2.1.1.0 255.255.255.0 1.1.1.2
[Router] ip route-static 10.2.1.0 255.255.255.0 1.1.1.2
[Router] acl number 3101
[Router-acl-adv-3101] rule permit ip source 10.1.1.0 0.0.0.255 destination 10.2.1.0 0.0.0.255
[Router-acl-adv-3101] quit
[Router] ipsec authentication sha2 compatible enable
[Router] ipsec proposal tran1
[Router-ipsec-proposal-tran1] transform esp
[Router-ipsec-proposal-tran1] esp authentication-algorithm sha2-512
[Router-ipsec-proposal-tran1] esp encryption-algorithm aes-256
[Router-ipsec-proposal-tran1] encapsulation-mode tunnel
[Router] ike proposal 5
[Router-ike-proposal-5] encryption-algorithm aes-cbc-256
[Router-ike-proposal-5] authentication-algorithm sha2-512
[Router-ike-proposal-5] dh group14
[Router-ike-proposal-5] sa duration 28800
[Router-ike-proposal-5] authentication-method pre-share
[Router-ike-proposal-5] quit
[Router] ike peer feita v1
[Router-ike-peer-feita] ike-proposal 5
[Router-ike-peer-feita] pre-shared-key cipher huawei@123
[Router-ike-peer-feita] remote-address 2.1.1.1
[Router-ike-peer-feita] exchange-mode main
[Router-ike-peer-feita] dpd type periodic
[Router-ike-peer-feita] dpd msg seq-hash-notify
[Router-ike-peer-feita] quit
[Router] ipsec policy map1 10 isakmp
[Router-ipsec-policy-isakmp-map1-10] ike-peer feita
[Router-ipsec-policy-isakmp-map1-10] proposal tran1
[Router-ipsec-policy-isakmp-map1-10] security acl 3101
[Router-ipsec-policy-isakmp-map1-10] sa duration time-based 3600
[Router-ipsec-policy-isakmp-map1-10] quit
[Router] interface gigabitethernet 0/0/1
[Router-GigabitEthernet0/0/1] ipsec policy map1
[Router-GigabitEthernet0/0/1] quitComprobación del resultado en el lado Huawei tras aplicar:
[Router] display ike proposal number 5
-------------------------------------------
IKE Proposal: 5
Authentication method : pre-shared
Authentication algorithm : SHA2-512
Encryption algorithm : AES-CBC-256
DH group : MODP-2048
SA duration : 28800
PRF : PRF-HMAC-SHA2-256
-------------------------------------------
[Router] display ipsec proposal
Number of proposals: 1
IPsec proposal name: tran1
Encapsulation mode: Tunnel
Transform : esp-new
ESP protocol : Authentication SHA2-HMAC-512
Encryption AES-256Aquí FortiGate se configura mediante su GUI web en lugar de la CLI — la guía de origen en la que se basa esta nota recorre las pantallas del asistente, no la sintaxis de comandos.
Los nombres de menú y el diseño de pantalla pueden variar entre versiones de FortiOS; la secuencia de conceptos — Network, Authentication, IKE, Phase 1 Proposal, Phase 2 Selectors, Phase 2 Proposal — se mantiene igual en las versiones recientes.
Estos explican la mayoría de los túneles que se establecen bien y aun así no dejan pasar el tráfico que deberían.
SÍNTOMALa detección de peer muerto (DPD) está habilitada, y el túnel se comporta de forma impredecible en lugar de detectar limpiamente un peer caído.
CAUSAEl formato de paquete DPD predeterminado de Fortinet no es el mismo que el predeterminado del router Huawei. Si se deja en su valor por defecto, el lado Huawei en realidad no habla el mismo dialecto DPD que el lado FortiGate.
SOLUCIÓNEn el router Huawei, configure el formato de mensaje DPD como seq-hash-notify para que coincida con lo que espera el lado FortiGate.
[Router-ike-peer-feita] dpd type periodic
[Router-ike-peer-feita] dpd msg seq-hash-notifySÍNTOMASin la corrección de abajo, este emparejamiento exacto mostraría la fase 1 y la fase 2 como establecidas, y luego no dejaría pasar el tráfico, o solo parte de él — el síntoma clásico de «el túnel está activo, los datos no».
CAUSACuando el router Huawei y el dispositivo del otro fabricante usan un algoritmo SHA-2 en la propuesta de seguridad IPSec — SHA2-512 en este ejemplo — sus implementaciones de cifrado/descifrado SHA-2 pueden diferir lo suficiente como para que el túnel se negocie bien pero el plano de datos no.
SOLUCIÓNHabilite el modo de compatibilidad SHA-2 en el router Huawei como paso estándar siempre que SHA-2 esté en la propuesta, en lugar de esperar a un reporte de tráfico roto.
[Router] ipsec authentication sha2 compatible enableSÍNTOMALa fase 1 (IKE) se establece limpiamente, pero la fase 2 (modo rápido / SA IPSec) nunca se levanta, o se levanta y se cae repetidamente.
CAUSALa ACL de Huawei define el tráfico protegido como origen 10.1.1.0/24 hacia destino 10.2.1.0/24; los Phase 2 Selectors de FortiGate deben definir la imagen especular exacta — local 10.2.1.0/24 (o la subred real de la sede), remoto 10.1.1.0/24. Si los dos selectores de tráfico no son simétricos en sentido inverso, la coincidencia de la propuesta de fase 2 falla aunque la fase 1 haya tenido éxito.
SOLUCIÓNCompare los selectores de tráfico de ambos lados uno junto al otro antes de solucionar cualquier otro problema en la fase 2 — un desajuste aquí es mucho más común que un desajuste de cifrado.
SÍNTOMAEl peer se configuró esperando IKEv1 específicamente, pero la negociación se comporta como si estuviera en juego IKEv2, o los dos extremos no logran ponerse de acuerdo en una versión.
CAUSAPor defecto, un peer IKE de Huawei tiene habilitados tanto IKEv1 como IKEv2. Cuando inicia la negociación usa IKEv2; cuando responde, admite ambos. Necesitar IKEv1 específicamente — como en este ejemplo, coincidiendo con el campo IKE Version del lado FortiGate configurado en 1 — debe configurarse de forma explícita.
SOLUCIÓNConfigure el peer explícitamente para v1, y confirme que el campo IKE Version del lado FortiGate también está configurado en 1, no en 2.
[Router] ike peer feita v1SÍNTOMAUna ruta estática o regla de ACL copiada de una guía de configuración hace referencia a una subred que no coincide con la propia tabla de direccionamiento de la guía para el mismo escenario.
CAUSALas guías de configuración se construyen con frecuencia adaptando un ejemplo anterior ya validado. Una ruta o regla puede terminar apuntando todavía a una subred usada en un ejemplo anterior distinto en lugar de la que realmente documenta la tabla de plan de datos actual.
SOLUCIÓNVuelva a derivar cada dirección de una ACL o ruta estática copiada a partir del plan de direccionamiento de su propia red antes de aplicarla — nunca dé por sentada la coherencia interna propia de un ejemplo ya validado.
Que la tabla de SA muestre «establecido» es necesario pero no suficiente — revise también los contadores de paquetes.
[Router] display ike sa
Conn-ID Peer VPN Flag(s) Phase
---------------------------------------------------------
16 2.1.1.1 0 RD|ST 2
14 2.1.1.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 UPSi el túnel no se establece en absoluto, las dos primeras cosas que hay que revisar son siempre las mismas: si la ruta subyacente hacia la dirección pública del peer es realmente alcanzable, y si las configuraciones de ambos extremos realmente coinciden, parámetro por parámetro — incluido el reflejo ACL/Phase 2 Selectors descrito en el Problema 3.
Las preguntas más frecuentes sobre este emparejamiento Huawei-Fortinet exacto.
En principio, cualquiera de los dos puede funcionar, pero el ejemplo validado en el que se basa esta nota usa IPSec basado en ACL en el lado Huawei, correspondiendo a un túnel IPSec personalizado de FortiGate con Phase 2 Selectors definidos en el lado de la GUI. Si prefiere el enfoque de interfaz de túnel (VTI), consulte nuestra nota aparte de Huawei a Cisco VTI para la lógica — el mismo razonamiento guiado por enrutamiento aplica frente a un FortiGate que admita VPN basada en rutas.
Porque este ejemplo ya usa SHA2-512 tanto en la propuesta IKE como en la IPSec. La compatibilidad SHA-2 entre fabricantes es exactamente el tipo de cosa que levanta un túnel bien pero rompe el plano de datos en silencio, así que habilitarla de entrada — en lugar de esperar un reporte de tráfico roto — es la opción por defecto más segura siempre que ambos extremos negocien un algoritmo SHA-2.
En la GUI de FortiGate, Phase 1 Proposal cubre lo mismo que una propuesta ike de Huawei — cifrado, autenticación, grupo DH y duración de clave para la SA IKE. Phase 2 Proposal cubre lo mismo que una propuesta ipsec de Huawei — cifrado, autenticación y duración para la SA IPSec. Phase 2 Selectors es el equivalente en FortiGate de la ACL que define el tráfico protegido en el lado Huawei.
Sí, en sentido inverso. La ACL de Huawei permite el tráfico desde la subred de la sucursal hacia la subred de la sede; los Phase 2 Selectors de FortiGate deben definir la imagen especular — subred de la sede como local, subred de la sucursal como remota. Si el selector de tráfico de cualquiera de los dos lados no coincide en sentido inverso con el de su peer, la negociación de la fase 2 falla aunque la fase 1 haya tenido éxito.
Copie la sintaxis de los comandos, no el direccionamiento. Las guías de configuración se adaptan con frecuencia de otros ejemplos ya validados, y una referencia de ruta estática o subred puede terminar apuntando a una dirección sobrante de un ejemplo anterior en lugar de la que realmente está en uso. Vuelva a derivar siempre el direccionamiento a partir de su propia red antes de aplicar una configuración copiada.
Esta nota se basa en una configuración verificada: un router Huawei (IKEv1, modo principal, clave precompartida, AES-256 / SHA2-512, basado en ACL) que llega a un firewall Fortinet FortiGate. La redacción de los menús de FortiOS varía ligeramente entre versiones; IKEv2, la VPN VTI/basada en rutas del lado FortiGate, el traspaso de NAT y una sucursal con IP dinámica cambian aún más los detalles. Esta nota cubre el método basado en ACL frente a Fortinet, no todas las combinaciones.
Modelos de equipo, versión de FortiOS y el conjunto de cifrado que intenta usar — envíelo por WhatsApp y le ayudamos a alinear los parámetros en ambos extremos.