GRE over IPSec - Troubleshooting

Método general (de lo mínimo a lo complejo)

  1. Separa las capas: primero GRE, luego IPSec. Si el túnel GRE no sube, no es IPSec.
  2. ¿El túnel GRE está up/up? show interfaces tunnel 1.
  3. ¿La Fase 1 sube? show crypto isakmp sa → QM_IDLE.
  4. ¿Se cifra el GRE? show crypto ipsec sa (protocolo 47, encaps/decaps).
  5. ¿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 profile en 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.