Una puerta de enlace de sucursal Huawei serie AR que usa una interfaz de túnel — no una ACL — para transportar una ruta protegida por IPSec hacia un router Cisco en la sede: por qué VTI supera al IPSec basado en políticas en este caso, la configuración en seis pasos, y cómo confirmar que el túnel está realmente protegido.
Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026
El emparejamiento de dos routers aquí es conocido — la decisión real está en cómo se define el tráfico protegido, no en cómo se levanta el túnel.
La forma habitual de construir un túnel IPSec entre una sucursal y la sede es con una ACL: una regla que enumera qué pares de subredes cuentan como «tráfico interesante» que se cifra. Eso funciona bien para un conjunto pequeño y fijo de subredes. En cuanto una sucursal es lo bastante grande — muchas subredes, tráfico que sigue creciendo, una red que sigue cambiando — la propia guía de Huawei para este emparejamiento recomienda cambiar a una interfaz de túnel virtual (VTI): el tráfico bajo la interfaz de túnel obtiene protección IPSec automáticamente, sin ninguna ACL que defina qué califica.
A continuación, la configuración en la que se basa esta nota, por qué VTI encaja mejor en cuanto una sucursal supera un puñado de subredes, y los seis problemas que aparecen con más frecuencia cuando una interfaz de túnel — no una ACL — es la que protege.
Una interfaz de túnel en cada lado — una interfaz de capa 3 realmente enrutable, no un gancho de política sobre un puerto físico.
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
Direccionamiento
| Elemento | RouterA — puerta de enlace Huawei de la sucursal | RouterB — puerta de enlace Cisco de la sede |
|---|---|---|
| Dirección pública (WAN) | 1.1.2.10 | 1.1.1.10 |
| Dirección de la interfaz de túnel | 10.2.1.2 | 10.2.1.1 |
| Puerta de enlace de la subred privada | 10.1.1.1 | 10.1.2.1 |
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-128 |
| Algoritmo de autenticación | sha1 |
| Grupo DH | group5 |
| 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-128 |
| Algoritmo de autenticación | sha1 |
| Duración de la SA | 3600 segundos (por defecto) |
| PFS | Deshabilitado |
El cifrado subyacente es el mismo; la respuesta cambia en «qué tráfico se protege, y cómo se mantiene eso sincronizado con la red».
| Aspecto | IPSec basado en ACL / política | Interfaz de túnel virtual (VTI) |
|---|---|---|
| Qué define el tráfico protegido | Una ACL que enumera pares de subredes origen/destino | Todo lo que se enrute hacia la interfaz de túnel |
| Añadir una nueva subred protegida | Añadir o editar una regla ACL y volver a aplicar la política | Añadir una ruta — estática o mediante un protocolo de enrutamiento — hacia el túnel |
| Protocolos de enrutamiento dinámico a través del túnel | No es compatible de forma nativa — no hay interfaz sobre la que OSPF o BGP puedan ejecutarse | Funciona directamente — la interfaz de túnel es una interfaz de capa 3 normal |
| Tráfico multicast | Necesita soluciones adicionales con GRE u otro perfil | Funciona sobre el túnel igual que sobre cualquier interfaz enrutada |
| Mejor caso de uso | Un número pequeño y fijo de pares de subredes | Sitios de sucursal grandes o en crecimiento, o sitios que ya ejecutan enrutamiento dinámico |
Seis pasos convierten una interfaz de túnel simple en una realmente protegida por IPSec.
<Huawei> system-view
[Huawei] sysname RouterA
[RouterA] interface gigabitethernet 1/0/0
[RouterA-GigabitEthernet1/0/0] ip address 1.1.2.10 255.255.255.0
[RouterA-GigabitEthernet1/0/0] quit
[RouterA] interface gigabitethernet 2/0/0
[RouterA-GigabitEthernet2/0/0] ip address 10.1.1.1 255.255.255.0
[RouterA-GigabitEthernet2/0/0] quit
[RouterA] ip route-static 0.0.0.0 0.0.0.0 1.1.2.1
[RouterA] interface Tunnel0/0/0
[RouterA-Tunnel0/0/0] ip address 10.2.1.2 255.255.255.0
[RouterA-Tunnel0/0/0] tunnel-protocol ipsec
[RouterA-Tunnel0/0/0] source gigabitethernet 1/0/0
[RouterA-Tunnel0/0/0] destination 1.1.1.10
[RouterA-Tunnel0/0/0] quit
[RouterA] ospf 2
[RouterA-ospf-2] area 0.0.0.0
[RouterA-ospf-2-area-0.0.0.0] network 10.1.1.0 0.0.0.255
[RouterA-ospf-2-area-0.0.0.0] network 10.2.1.0 0.0.0.255
[RouterA] ike proposal 5
[RouterA-ike-proposal-5] encryption-algorithm aes-cbc-128
[RouterA-ike-proposal-5] authentication-algorithm sha1
[RouterA-ike-proposal-5] dh group5
[RouterA-ike-proposal-5] authentication-method pre-share
[RouterA-ike-proposal-5] quit
[RouterA] ike peer RouterA v1
[RouterA-ike-peer-RouterA] ike-proposal 5
[RouterA-ike-peer-RouterA] pre-shared-key cipher huawei@123
[RouterA-ike-peer-RouterA] dpd type periodic
[RouterA-ike-peer-RouterA] dpd msg seq-hash-notify
[RouterA-ike-peer-RouterA] quit
[RouterA] ipsec proposal RouterA
[RouterA-ipsec-proposal-RouterA] transform esp
[RouterA-ipsec-proposal-RouterA] encapsulation-mode tunnel
[RouterA-ipsec-proposal-RouterA] esp authentication-algorithm sha1
[RouterA-ipsec-proposal-RouterA] esp encryption-algorithm aes-128
[RouterA] ipsec profile profile1
[RouterA-ipsec-profile-profile1] ike-peer RouterA
[RouterA-ipsec-profile-profile1] proposal RouterA
[RouterA-ipsec-profile-profile1] quit
[RouterA] interface tunnel 0/0/0
[RouterA-Tunnel0/0/0] ipsec profile profile1Misma lógica de interfaz de túnel, familia de comandos distinta: una interfaz de túnel en modo ipsec ipv4, crypto isakmp policy para los atributos de la fase 1, crypto ipsec transform-set para los de la fase 2, y un crypto ipsec profile vinculado a la interfaz de túnel con tunnel protection ipsec profile — el equivalente Cisco de aplicar el perfil ipsec de Huawei en Tunnel0/0/0.
RouterB#configure
RouterB(config)#interface gigabitethernet 0/1
RouterB(config-if)#ip address 1.1.1.10 255.255.255.0
RouterB(config-if)#exit
RouterB(config)#interface gigabitethernet 0/2
RouterB(config-if)#ip address 10.1.2.1 255.255.255.0
RouterB(config-if)#exit
RouterB(config)#ip route 0.0.0.0 0.0.0.0 1.1.1.1
RouterB(config)#interface tunnel 0
RouterB(config-if)#ip address 10.2.1.1 255.255.255.0
RouterB(config-if)#tunnel mode ipsec ipv4
RouterB(config-if)#tunnel source gigabitethernet0/1
RouterB(config-if)#tunnel destination 1.1.2.10
RouterB(config-if)#exit
RouterB(config)#RouterB ospf 2
RouterB(config-RouterB)#network 10.2.1.0 0.0.0.255 area 0
RouterB(config-RouterB)#network 10.1.2.0 0.0.0.255 area 0
RouterB(config-RouterB)#exit
RouterB(config)#crypto isakmp policy 10
RouterB(config-isakmp)#hash sha
RouterB(config-isakmp)#encryption aes 128
RouterB(config-isakmp)#group 5
RouterB(config-isakmp)#authentication pre-share
RouterB(config-isakmp)#exit
RouterB(config)#crypto isakmp key huawei@123 address 0.0.0.0 no-xauth
RouterB(config)#crypto isakmp keepalive 10 periodic
RouterB(config)#crypto ipsec transform-set tran1 esp-sha-hmac esp-aes 128
RouterB(cfg-crypto-trans)#mode tunnel
RouterB(cfg-crypto-trans)#exit
RouterB(config)#crypto ipsec profile profile1
RouterB(ipsec-profile)#set transform-set tran1
RouterB(ipsec-profile)#exit
RouterB(config)#interface tunnel 0
RouterB(config-if)#tunnel protection ipsec profile profile1
RouterB(config-if)#exitLa sintaxis del lado Cisco de esta nota se verificó en Cisco IOS Software, C3900e-UNIVERSALK9-M, versión 15.2(4)M1 — IOS-XE y ASA usan una sintaxis parecida pero no idéntica.
El primero es específico de construir IPSec sobre una interfaz de túnel; el resto aplica a este emparejamiento Huawei-Cisco sea cual sea el método usado para levantar el túnel.
SÍNTOMALa interfaz Tunnel0/0/0 aparece activa, e incluso los pings pasan a través de ella — pero display ike sa no muestra ninguna asociación de seguridad.
CAUSALos pasos 2 a 5 construyen una interfaz de túnel y un perfil IPSec como dos objetos separados. Nada los conecta hasta que el paso 6 aplica explícitamente el perfil a la interfaz. Hasta que se ejecuta ese comando, la interfaz de túnel se comporta como cualquier otra interfaz enrutable que transporta tráfico en claro — «interfaz activa» y «tráfico protegido» son dos hechos distintos.
SOLUCIÓNConfirme que el perfil ipsec está aplicado en la propia interfaz de túnel, no solo definido como un objeto independiente.
[RouterA] interface tunnel 0/0/0
[RouterA-Tunnel0/0/0] ipsec profile profile1SÍ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 Cisco 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 Cisco.
SOLUCIÓNEn el router Huawei, configure el formato de mensaje DPD como seq-hash-notify para que coincida con lo que espera el lado Cisco.
[RouterA-ike-peer-RouterA] dpd type periodic
[RouterA-ike-peer-RouterA] dpd msg seq-hash-notifySÍNTOMAdisplay ike sa (o show crypto isakmp sa) muestra la fase 1 y la fase 2 establecidas, pero un ping a través del túnel falla, o solo pasa parte del tráfico.
CAUSACuando el router Huawei y el dispositivo del otro fabricante usan un algoritmo SHA-2 en la propuesta de seguridad IPSec, 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ÓNEn el router Huawei, habilite el modo de compatibilidad SHA-2 para que ambos extremos procesen SHA-2 de la misma manera.
[RouterA] ipsec authentication sha2 compatible enableSÍNTOMAEl túnel se cae sin que haya cambiado ninguna configuración en ninguno de los dos lados — normalmente justo después de que la IP pública de la sucursal cambia por una renovación DHCP o PPPoE.
CAUSAEl origen de la interfaz de túnel se configuró como una dirección IP fija, pero esa dirección se asigna dinámicamente en la interfaz de salida. Cuando la dirección cambia, el origen configurado del túnel ya no coincide con la realidad.
SOLUCIÓNConfigure source como la propia interfaz de salida, no su dirección IP actual, para que el túnel siga a la interfaz en lugar de una instantánea de su dirección.
[RouterA-Tunnel0/0/0] source gigabitethernet 1/0/0SÍNTOMAEl peer se configuró esperando IKEv1 para coincidir con una configuración Cisco antigua, pero la negociación se comporta como 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 debe configurarse de forma explícita — no ocurre automáticamente solo porque el otro extremo sea un equipo Cisco antiguo.
SOLUCIÓNDeshabilite explícitamente IKEv2 para que el peer solo inicie y acepte IKEv1.
[RouterA-ike-peer-RouterA] version 1
[RouterA-ike-peer-RouterA] undo version 2SÍNTOMAUn comando de un ejemplo de configuración — remote-name, local-id-type name, o un pre-shared-key sin más — es rechazado, o se comporta de forma distinta, en el equipo que tiene delante.
CAUSAHuawei renombró varios comandos de peer IKE entre versiones de software. El comportamiento funcional es el mismo; la palabra clave no.
SOLUCIÓNHaga coincidir la sintaxis con la versión de software que realmente se está ejecutando antes de copiar una línea de configuración.
| Sintaxis anterior | Sintaxis actual (verifique su versión) |
|---|---|
| ike peer peer-name [ v1 | v2 ] | ike peer peer-name + version { 1 | 2 } (V200R008+) |
| remote-name | remote-id (V200R008+) |
| local-id-type name | local-id-type fqdn (V200R008+) |
| pre-shared-key key | pre-shared-key { simple | cipher } key (V200R003C00+) |
Las palabras clave de los comandos y los números de versión se mantienen en su forma original en todos los idiomas, para una referencia exacta.
Que la tabla de SA muestre «establecido» es necesario pero no suficiente — revise también los contadores de paquetes.
[RouterA] display ike sa
Conn-ID Peer VPN Flag(s) Phase
---------------------------------------------------------
8 1.1.1.10 0 RD|ST 2
6 1.1.1.10 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.
Las preguntas más frecuentes sobre este emparejamiento VTI exacto.
No — ese es precisamente el sentido del enfoque de interfaz de túnel virtual. No hay ninguna ACL de selección de tráfico; todo lo que la tabla de enrutamiento envíe hacia la interfaz de túnel obtiene protección IPSec. Aun así necesita una ruta normal, estática o dinámica, que le diga al router que envíe ese tráfico allí en primer lugar.
Sí. La propia guía de configuración de Huawei para este ejemplo exacto muestra cómo ejecutar OSPF entre las dos direcciones de interfaz de túnel para que la subred privada remota sea alcanzable sin ruta estática — una de las ventajas prácticas del VTI frente al IPSec basado en ACL, ya que el túnel es una interfaz de capa 3 enrutable, no solo un gancho de política sobre una interfaz física.
Si el origen de la interfaz de túnel se configuró como una dirección IP específica, el túnel se rompe la próxima vez que esa dirección cambie — algo que importa en una sucursal con IP pública dinámica por DHCP o PPPoE. Configure source como la propia interfaz de salida, no una instantánea de su dirección — vea el Problema 4 arriba.
Los parámetros IKE e IPSec y la lógica de la interfaz de túnel en esta nota son estándares neutrales respecto al fabricante; solo cambia la sintaxis de comandos del otro extremo. Esta guía se verificó con un router Cisco. Fortinet y otros fabricantes siguen la misma lógica de fase 1 / fase 2 por una ruta de configuración distinta — vea nuestra nota aparte sobre Huawei a FortiGate para un ejemplo basado en políticas frente a un firewall.
El ejemplo de esta nota se ejecuta con PFS deshabilitado, siguiendo la configuración de origen en la que se basa. Habilitar PFS añade un nuevo intercambio Diffie-Hellman en cada renovación de clave de la fase 2, lo que resiste mejor la reproducción por compromiso de clave a un pequeño costo de CPU — vale la pena activarlo para segmentos de mayor seguridad, siempre que ambos extremos acuerden el mismo grupo DH.
Esta nota se basa en una configuración verificada: un router Huawei (IKEv1, modo principal, clave precompartida, AES-128 / SHA-1) que llega a un router Cisco a través de una interfaz de túnel virtual. El IPSec basado en ACL/política, IKEv2, el modo agresivo, el traspaso de NAT y los peers que no son Cisco — FortiGate, por ejemplo, vea nuestra nota complementaria — cambian cada uno los detalles. Esta nota cubre el método VTI frente a Cisco, no todas las combinaciones.
Modelos de equipo, versiones de software y si se inclina por VTI o por ACL — envíelo por WhatsApp y le ayudamos a alinear los parámetros en ambos extremos.