GRE over IPSec - Troubleshooting
Método general (de lo mínimo a lo complejo)
- Separa las capas: primero GRE, luego IPSec. Si el túnel GRE no sube, no es IPSec.
- ¿El túnel GRE está up/up?
show interfaces tunnel 1. - ¿La Fase 1 sube?
show crypto isakmp sa→QM_IDLE. - ¿Se cifra el GRE?
show crypto ipsec sa(protocolo 47, encaps/decaps). - ¿Hay ruta a las LAN remotas por el túnel?
Comando base:
Router# show interfaces tunnel 1
Router# show crypto ipsec sa
Caso 1 — El túnel GRE no sube
Síntoma: Tunnel1 up/down o down/down.
Causa: problema de GRE puro: el tunnel destination (IP WAN remota) no es alcanzable, o source/destination no son espejo.
Diagnóstico y solución: tratar como GRE (ver GRE - Troubleshooting). Asegurar ruta hacia la IP WAN remota y source/destination correctos.
Router# ping 10.10.20.1
Router# show running-config interface tunnel 1
Caso 2 — El túnel sube pero no se cifra (encaps/decaps en 0)
Síntoma: GRE up/up, pero show crypto ipsec sa no muestra tráfico cifrado.
Causas:
- Método profile: falta
tunnel protection ipsec profileen la interface tunnel, o el profile no tiene transform-set. - Método crypto map: la ACL no hace match del GRE, el crypto map no está en la interfaz física, o falta
set peer.
Diagnóstico:
Router# show interfaces tunnel 1 | include protection ! método profile
Router# show crypto map ! método crypto map
Router# show access-lists TUNEL
Solución (profile):
Router(config)# interface tunnel 1
Router(config-if)# tunnel protection ipsec profile PROTECT-GRE
Solución (crypto map): la ACL debe ser permit gre host <WAN-local> host <WAN-remota> y el crypto map ir en la interfaz física.
Router(config)# ip access-list extended TUNEL
Router(config-ext-nacl)# permit gre host 10.10.10.1 host 10.10.20.1
Caso 3 — La Fase 1 no se establece
Síntoma: show crypto isakmp sa no llega a QM_IDLE.
Causa: parámetros de Fase 1 distintos o clave pre-compartida incorrecta (misma raíz que en IPSec puro).
Solución: igualar la política y la clave atada a la IP WAN correcta (ver IPSec - Troubleshooting).
Router(config)# crypto isakmp key cisco123 address 10.10.20.1
Caso 4 — Mezcla de métodos (crypto map + tunnel protection)
Síntoma: comportamiento errático, doble cifrado o el túnel no pasa tráfico.
Causa: se aplicaron a la vez el crypto map en la interfaz física y tunnel protection en el túnel.
Diagnóstico:
Router# show running-config | include crypto map|tunnel protection
Solución: usar un solo método. Para el moderno, quitar el crypto map de la interfaz física y dejar solo tunnel protection.
Router(config)# interface fastEthernet 0/0
Router(config-if)# no crypto map IPSEC_TUNEL
Caso 5 — Fragmentación (túnel + cifrado suman overhead)
Síntoma: ping pequeño OK, transferencias grandes o multicast fallan.
Causa: GRE (24 bytes) + IPSec (~50-70 bytes) reducen mucho la MTU efectiva.
Diagnóstico:
Router# ping 192.168.20.2 size 1400 df-bit
Solución: ajustar ip mtu y ip tcp adjust-mss en la interface tunnel (valores más bajos que en GRE solo).
Router(config)# interface tunnel 1
Router(config-if)# ip mtu 1400
Router(config-if)# ip tcp adjust-mss 1360
Caso 6 — El IGP sobre el túnel no forma vecindad
Síntoma: el túnel cifra, pero OSPF/EIGRP no levantan vecinos.
Causas:
- El multicast del IGP no pasa (con IPSec puro no pasaría; con GRE sí debería).
- MTU del túnel muy distinta entre extremos (OSPF exige MTU igual para pasar de EXSTART).
Diagnóstico:
Router# show ip ospf neighbor
Router# show interfaces tunnel 1 | include MTU
Solución: igualar la MTU del túnel en ambos extremos; confirmar que el GRE (no IPSec puro) es quien transporta el IGP.
Recuerda el orden: separa capas (GRE primero, IPSec después), túnel GRE up/up, Fase 1 en QM_IDLE, cifrado del GRE confirmado (protocolo 47, encaps/decaps), un solo método (profile o crypto map, no ambos), y ajuste de MTU/MSS por el doble overhead.