Inicio / Notas técnicas / Resolución de problemas: el túnel VPN no responde al Ping

El túnel VPN está activo pero el Ping falla: diagnóstico de discrepancias de encapsulación GRE y enrutamiento

Un túnel GRE que se establece pero aun así no deja que dos sitios se hagan Ping entre sí en su dirección de túnel es uno de los tickets de VPN más comunes en la etapa inicial. Este es el orden que encuentra la falla más rápido — la encapsulación antes que el enrutamiento, los comandos display exactos para cada etapa, las comprobaciones que solo importan una vez que la interfaz ya está activa, y los casos reales de mala configuración detrás de todo esto.

Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026

Por qué la encapsulación va antes que el enrutamiento

El instinto es empezar de inmediato a hacer Ping y trazar rutas — pero en un túnel GRE, buena parte de los fallos de Ping ni siquiera llegan a eso: los dos extremos ni siquiera están hablando la misma encapsulación todavía.

Que una interfaz esté activa no significa que el túnel esté sano, y que la configuración se vea correcta en ambos extremos no significa que los dos sitios realmente puedan alcanzar la dirección IP de la interfaz Tunnel del otro. El orden que encuentra la falla más rápido es: confirmar que ambos extremos usan la misma encapsulación, confirmar que el direccionamiento del túnel está reflejado y completo, confirmar que existe una ruta entre las dos direcciones físicas de origen/destino, y solo una vez que la interfaz misma esté realmente activa, revisar la Clave GRE y la ruta hacia la dirección de la interfaz Tunnel del par específicamente.

A continuación, el orden de diagnóstico en el que se basa este texto, tomado del propio modelo de clasificación de fallas GRE del router Huawei AR, las comprobaciones y comandos display para cada etapa, un caso de mala configuración documentado, y una serie de respuestas de preguntas frecuentes extraídas del mismo material de mantenimiento. Si el túnel subyacente está protegido por IPSec, «¿El túnel VPN IPSec no se establece?» cubre la capa de negociación; si es un diseño dinámico en estrella en lugar de un túnel punto a punto fijo, «DSVPN over IPSec entre sucursales Huawei y un hub Cisco» cubre directamente esa variante.

Lea el árbol de fallas antes de tocar cualquier configuración

Los fallos de Ping en GRE se dividen en tres formas: la interfaz Tunnel misma nunca se activa, está activa pero los dos extremos aún no pueden hacerse Ping en su Tunnel IP, o está activa y el Ping funciona pero el enlace es inestable o lento.

Ubicar primero el síntoma en este árbol indica cuál de las etapas siguientes aplica realmente — y, de forma más útil, si siquiera se está ante un problema de enrutamiento.

Las etiquetas del diagrama se mantienen en inglés por claridad técnica.

Casi todas las comprobaciones de la rama izquierda son una simple discrepancia de configuración que debe coincidir, campo por campo, en ambos extremos. La rama del medio es lo que queda una vez que la interfaz misma está sana pero las dos direcciones Tunnel IP aún no se alcanzan; la rama derecha es un problema de diseño de enrutamiento, no un error de configuración del túnel.

Recorriendo cada etapa

Cuatro puntos de control, cada uno con su propio comando display — el árbol de fallas anterior indica por cuál empezar.

Etapa 0 — Confirmar que ambos extremos usan la misma encapsulación

Si el protocolo de capa de red de la interfaz Tunnel no se activa en absoluto, no toque el enrutamiento todavía — la encapsulación es lo primero que debe coincidir.

Verifique la configuración propia de la interfaz con display this en la vista de la interfaz Tunnel. La salida muestra directamente tunnel-protocol gre — esta es la encapsulación realmente en uso, no solo lo que cree que configuró.
Si los dos extremos muestran valores tunnel-protocol distintos, reconfigure el que esté mal. Reconfigurar tunnel-protocol en un router Huawei borra el source y destination previamente configurados, así que vuelva a ingresarlos inmediatamente después.
Si la encapsulación ya coincide, verifique a continuación el direccionamiento: ambos extremos necesitan una dirección IP más un source y un destination configurados, y — esta es la parte fácil de pasar por alto — los dos extremos deben reflejarse exactamente, siendo el destination de este extremo el source del par y viceversa. El par source/destination es lo que identifica de forma única un túnel; si los dos extremos no se reflejan, nunca se forma un único túnel.

[Huawei-Tunnel0/0/0] display this
[V200R009C00SPC300]
#
interface Tunnel0/0/0
 ip address 172.16.1.1 255.255.255.252
 tunnel-protocol gre
 source GigabitEthernet1/0/0
 destination 1.1.1.2
#
return
// tunnel-protocol gre confirms the actual encapsulation in use
// source/destination on this end must mirror the peer's destination/source

Etapa 1 — Ruta entre el origen y el destino físicos del túnel

Una encapsulación y un direccionamiento correctos aun así no harán que la interfaz se active si los dos extremos físicos en realidad no pueden alcanzarse.

Si las interfaces de origen y destino no están conectadas directamente, debe existir una ruta entre ellas — verifique con display ip routing-table, luego confirme que la tabla de reenvío coincide usando display fib.
Si no existe ninguna ruta entre las direcciones de origen y destino, agregue una ruta estática, o anuncie la red de destino mediante el protocolo de enrutamiento dinámico que ya se ejecuta entre las dos interfaces físicas.
Solo una vez confirmada la alcanzabilidad de origen a destino tiene sentido seguir solucionando el túnel en sí, en lugar de la red de transporte subyacente.

<Huawei> display ip routing-table
<Huawei> display fib
// confirm the FIB table agrees with the routing table before assuming
// the tunnel itself is the problem rather than the transport network below it

Etapa 2 — La interfaz está activa, pero los dos extremos aún no pueden hacerse Ping en su Tunnel IP

Aquí es donde vive un segundo par de comprobaciones menos evidente: la Clave GRE, y una ruta específicamente hacia la dirección de la interfaz Tunnel del par — no solo hacia su dirección física.

Verifique si hay una Clave GRE (palabra clave de identificación) configurada en cualquiera de los extremos con gre key. Si está establecida, ambos extremos deben llevar el mismo valor; si prefiere no gestionarla, asegúrese de que ninguno de los dos la configure.
Confirme que cada extremo realmente tenga una ruta hacia la dirección IP de la interfaz Tunnel del par, no solo hacia su dirección física de origen/destino — un túnel activo puede seguir sin tener ninguna ruta hacia la dirección lógica del otro extremo. GRE admite enrutamiento estático, OSPF, IS-IS, RIP y BGP sobre el túnel precisamente por esta razón.
Solo después de que la Clave coincida y exista una ruta hacia el Tunnel IP del par, un Ping a esa dirección tiene una posibilidad real de tener éxito.

Etapa 3 — El Ping tiene éxito, pero el túnel fluctúa o va lento

Dos síntomas de apariencia muy distinta se remontan a la misma causa raíz: la ruta hacia la propia dirección de destino del túnel apunta al tipo equivocado de interfaz saliente.

Si la propia interfaz Tunnel fluctúa Up/Down, verifique con display ip routing-table la interfaz saliente de la dirección de destino. Si esa interfaz saliente es la propia interfaz Tunnel GRE, la ruta es recursiva — replanifique la red para que el destino nunca se alcance enrutando de vuelta a través del túnel que depende de él.
Si el túnel permanece activo pero el rendimiento es bajo, verifique la misma entrada de la tabla de rutas para ver si la interfaz saliente es una interfaz VLANIF — esa combinación es una causa documentada de bajo rendimiento en GRE y necesita replanificación, no ajuste.
Cuando el ancho de banda no es el problema pero sesiones individuales son lentas o intermitentes, pruebe con ping -s packetsize -a source-ip-address host aumentando el tamaño para encontrar el punto de quiebre donde empieza la pérdida, ajuste el MTU de la interfaz en consecuencia, y use tcp adjust-mss value si las sesiones TCP en particular siguen afectadas después del cambio de MTU.

<Huawei> ping -s packetsize -a source-ip-address host
// increase packetsize until loss appears -- that breakpoint sets the working MTU

[Huawei-Tunnel0/0/0] mtu mtu-value
[Huawei-Tunnel0/0/0] tcp adjust-mss value

6 causas que aparecen una y otra vez

Una vez que las etapas anteriores le han indicado dónde está el problema, estas seis causas explican la mayor parte de lo que realmente falla.

1. El modo de encapsulación en realidad no coincide

SÍNTOMAEl protocolo de capa de red de la interfaz Tunnel nunca se activa, sin importar qué tan correcto se vea el resto de la interfaz.

CAUSAtunnel-protocol debe ser idéntico en ambos extremos; display this en cada lado es la única forma fiable de ver lo que realmente está configurado, porque un tipo de encapsulación no coincidente es, de otro modo, completamente silencioso — sin registro, sin mensaje de error.

SOLUCIÓNReconfigure tunnel-protocol gre en el extremo que esté mal; como esto borra el source y destination existentes, vuelva a ingresarlos inmediatamente después.

[Huawei-Tunnel0/0/0] tunnel-protocol gre
[Huawei-Tunnel0/0/0] source GigabitEthernet1/0/0
[Huawei-Tunnel0/0/0] destination 1.1.1.2

2. El source y el destination en realidad no se reflejan

SÍNTOMAAmbos extremos se ven completamente configurados, individualmente, pero la interfaz Tunnel nunca se activa.

CAUSAEl par source/destination identifica un único túnel; si el destination de este extremo no es el source del par (y viceversa), los dos extremos técnicamente están construyendo cada uno un túnel distinto que nunca se encuentra con el otro.

SOLUCIÓNLea display this en ambos extremos, uno junto al otro, y confirme explícitamente el espejo — no confíe simplemente en que quien configuró el otro extremo lo hizo bien.

3. La Clave GRE está configurada solo en un extremo

SÍNTOMALa interfaz Tunnel está activa en ambos extremos, la encapsulación y el direccionamiento son correctos, pero los dos lados aún no pueden hacerse Ping en su Tunnel IP.

CAUSAgre key es opcional, pero si cualquiera de los extremos lo configura, ambos deben llevar el mismo valor — una Clave establecida en un extremo y sin establecer (o establecida de forma diferente) en el otro impide que el túnel realmente pase tráfico, aunque el estado de la interfaz se vea perfectamente sano.

SOLUCIÓNConfigure el mismo valor de gre key en ambos extremos, o elimínelo de ambos — nunca lo deje configurado en un solo lado.

4. No hay ruta hacia el IP de la interfaz Tunnel del par

SÍNTOMALas direcciones físicas de origen y destino son alcanzables y la interfaz está activa, pero un Ping al Tunnel IP del par sigue fallando.

CAUSAQue un túnel esté activo solo confirma que la capa física subyacente es alcanzable — llegar a la dirección lógica de la interfaz Tunnel del par es una cuestión de enrutamiento distinta, resuelta mediante el protocolo de enrutamiento que corre sobre el túnel, no algo que el propio estado activo del túnel implique automáticamente.

SOLUCIÓNConfirme que existe una ruta hacia el Tunnel IP del par — mediante un protocolo de enrutamiento que corra sobre el túnel (GRE admite enrutamiento estático, OSPF, IS-IS, RIP y BGP), o una ruta estática — antes de asumir que el túnel en sí está roto.

5. La ruta de destino recurre a través del propio túnel

SÍNTOMAEl Ping funciona bien, pero la interfaz Tunnel fluctúa Up/Down repetidamente, o el rendimiento es inesperadamente bajo, sin nada más visiblemente mal.

CAUSASi la ruta hacia la propia dirección de destino del túnel se resuelve con la propia interfaz Tunnel GRE como interfaz saliente, el túnel depende de sí mismo para mantenerse activo — una causa documentada de fluctuación. Por separado, una ruta de destino cuya interfaz saliente es una interfaz VLANIF es una causa documentada de bajo rendimiento.

SOLUCIÓNVerifique con display ip routing-table específicamente la interfaz saliente de la dirección de destino; si es el propio túnel, replanifique el enrutamiento subyacente para que el destino se alcance a través de una interfaz física real, no el túnel que depende de él.

6. La tabla de sesiones NAT prevalece sobre la tabla de rutas tras una fluctuación del túnel

SÍNTOMAEn una implementación GRE over IPSec, el tráfico circulaba por el túnel, el túnel fluctuó a Down y el tráfico pasó al NAT, y cuando el túnel volvió a estar activo, el tráfico se quedó en el NAT en lugar de volver a él.

CAUSAEste es un caso real documentado. Una vez que el tráfico ha pasado a una sesión NAT, esa entrada de la tabla de sesiones NAT tiene mayor prioridad que la tabla de rutas — así que incluso después de que el túnel GRE vuelva a estar activo y la tabla de rutas dirigiría correctamente el tráfico hacia él, la sesión NAT existente sigue prevaleciendo.

SOLUCIÓNVacíe la tabla de sesiones NAT para que el tráfico se resuelva de nuevo contra la tabla de rutas ahora correcta y regrese al túnel; no asuma que «túnel activo» por sí solo significa que el tráfico realmente volvió a él.

<RouterA> system-view
[RouterA] reset nat session all
Warning:The current all NAT sessions will be deleted.
Are you sure to continue?[Y/N]Y

Seis preguntas que surgen constantemente

Sacadas directamente del terreno — las que vale la pena tener una respuesta lista.

¿Qué causa realmente que un túnel GRE ni siquiera llegue a establecerse?

En orden de frecuencia: discrepancia de encapsulación entre los dos extremos; dirección IP, source o destination no configurados, o no reflejados entre los dos extremos; Clave GRE configurada de forma inconsistente; falta de ruta entre las direcciones físicas de origen y destino; una configuración de Keepalive donde los contadores de envío/recepción no coinciden; valores de MTU no coincidentes entre los dos extremos; y un valor de TCP MSS de interfaz configurado lo bastante alto como para que la trama más la sobrecarga supere el MTU.

La interfaz Tunnel se muestra activa en ambos extremos — ¿qué queda por revisar si los dos lados aún no pueden hacerse Ping en su Tunnel IP?

Dos cosas específicamente: una discrepancia en la Clave GRE (configurada en un extremo y no en el otro, o configurada con valores distintos), y una ruta faltante hacia la propia dirección de la interfaz Tunnel del par — la alcanzabilidad entre las direcciones físicas de origen y destino no otorga automáticamente una ruta hacia el Tunnel IP lógico por encima de ella.

El túnel funcionaba bien y de repente empezó a fluctuar o se volvió lento — ¿qué cambió?

No necesariamente cambió nada en la configuración propia del túnel. Verifique si la interfaz saliente de la ruta de destino es el propio túnel — eso es una causa documentada de fluctuación por enrutamiento recursivo — o una interfaz VLANIF, que es una causa documentada de bajo rendimiento. Ambos son problemas de diseño de red a replanificar, no errores de configuración del túnel a parchear.

¿GRE admite protocolos de enrutamiento dinámico y multicast sobre el túnel?

Sí — GRE admite enrutamiento estático, OSPF, IS-IS, RIP y BGP sobre el túnel, y puede transportar protocolos multicast incluyendo PIM. Esa es una razón por la que existe GRE over IPSec: un túnel IPSec puro solo protege tráfico unicast, así que cualquier multicast que necesite cifrado se encapsula primero en GRE, y luego IPSec protege el propio túnel GRE.

Si ya tengo un túnel IPSec entre dos sitios, ¿por qué añadir GRE encima?

Dos razones habituales: un túnel IPSec por sí solo solo protege tráfico unicast, así que cualquier multicast que también necesite cifrado — megafonía por voz, algunos protocolos de enrutamiento — debe encapsularse primero en GRE y entregarse luego a IPSec; y GRE le da una interfaz lógica real sobre la cual ejecutar un protocolo de enrutamiento dinámico, algo que una simple política IPSec no proporciona por sí sola. Vea «DSVPN over IPSec entre sucursales Huawei y un hub Cisco» para un ejemplo trabajado exactamente de esta combinación.

¿Configurar un MTU en la interfaz Tunnel realmente hace algo?

Sí — un MTU configurado en la interfaz Tunnel GRE se aplica al tráfico reenviado a través de ese túnel; cualquier cosa más larga que el valor configurado se fragmenta antes de enviarse. Ese es exactamente el mecanismo en el que se basa la prueba ping -s de la Etapa 3 anterior.

Límites honestos de esta nota

Límites honestos de esta nota

Esta nota se basa en el modelo de clasificación de fallas GRE del router Huawei serie AR — display this, display ip routing-table, display fib — y los casos de campo que los respaldan, tomados de la misma documentación de mantenimiento. Asume un túnel GRE estático punto a punto, no la variante mGRE dinámica de DSVPN ni una implementación GRE over IPSec completamente desarrollada. Para la negociación IPSec superpuesta a un túnel como este, vea «¿El túnel VPN IPSec no se establece?»; para el caso multipunto dinámico, vea «DSVPN over IPSec entre sucursales Huawei y un hub Cisco».

¿Atascado con un túnel activo que no responde al Ping?

Cuéntenos si la interfaz Tunnel en sí está activa, junto con la salida de display this de ambos extremos, y le ayudamos a interpretarla.

WhatsApp con un ingeniero →