Networking

Cisco IOS Site-to-Site IPsec VPN with GRE: Full Configuration Walkthrough

Part of pathway: Full Guide for All IOS Commands →
7 min read

Why GRE-over-IPsec Instead of Plain IPsec

Plain IPsec encrypts unicast traffic between two peers. That’s fine for protecting host-to-host or LAN-to-LAN traffic, but it has one inconvenient limitation: it doesn’t carry multicast or broadcast. Which means it doesn’t carry routing-protocol updates — OSPF hellos, EIGRP multicasts, none of it. Through a plain-IPsec tunnel, you have to maintain static routes on both ends.

GRE (Generic Routing Encapsulation) wraps any Layer 3 payload — including multicast and broadcast — in a Layer 3 GRE header. By itself, GRE is unencrypted. The standard pattern for a site-to-site VPN that supports a routing protocol is therefore GRE inside IPsec: you build a GRE tunnel between two routers (which carries routing updates), then encrypt the tunnel’s traffic with IPsec.

This article walks through configuring a site-to-site IPsec VPN with a GRE tunnel on Cisco IOS, the two-phase IKE/IPsec negotiation, and the verification commands.

The Two Phases

IPsec authentication and key exchange happen via IKE (Internet Key Exchange) in two phases. Both have to succeed before traffic flows.

Phase 1 — ISAKMP / IKE Phase 1

Phase 1 builds the secure channel that protects Phase 2 negotiation. Both ends must agree on:

  • Authentication method — pre-shared key (most common for small deployments) or RSA signatures
  • Encryption — DES (don’t use), 3DES (legacy), AES (use)
  • Hash — MD5 (deprecated) or SHA
  • Diffie-Hellman group — 1 or 2 (weak, don’t use), 5 (legacy), 14 or higher (use)
  • Lifetime — how long the SA lasts before re-keying (default 86400 seconds)

Phase 2 — IPsec / IKE Phase 2 / Quick Mode

Phase 2 negotiates the actual data-protection SA: which traffic is interesting, which protocol (ESP — almost always — or AH), which transform set, and the lifetime.

Full Configuration — Both Ends

Here’s the symmetric configuration on Site A. Site B is a mirror with the IPs swapped.

! ===== Phase 1 =====
Router-A(config)# crypto isakmp policy 10
Router-A(config-isakmp)# authentication pre-share
Router-A(config-isakmp)# encryption aes 256
Router-A(config-isakmp)# hash sha
Router-A(config-isakmp)# group 14
Router-A(config-isakmp)# lifetime 28800
Router-A(config-isakmp)# exit

! Pre-shared key (must match on both ends; identify peer by IP):
Router-A(config)# crypto isakmp key SecretString123 address 198.51.100.2

! ===== Phase 2 =====
Router-A(config)# crypto ipsec transform-set TS-AES-SHA esp-aes 256 esp-sha-hmac
Router-A(cfg-crypto-trans)# mode tunnel
Router-A(cfg-crypto-trans)# exit

! Interesting traffic - the ACL says "encrypt traffic that matches this":
Router-A(config)# ip access-list extended VPN-INTERESTING
Router-A(config-ext-nacl)# permit gre host 203.0.113.5 host 198.51.100.2

! Crypto map ties everything together:
Router-A(config)# crypto map VPN-MAP 10 ipsec-isakmp
Router-A(config-crypto-map)# set peer 198.51.100.2
Router-A(config-crypto-map)# set transform-set TS-AES-SHA
Router-A(config-crypto-map)# match address VPN-INTERESTING
Router-A(config-crypto-map)# set pfs group14
Router-A(config-crypto-map)# exit

! Apply the crypto map to the WAN interface:
Router-A(config)# interface GigabitEthernet0/1
Router-A(config-if)# crypto map VPN-MAP

! ===== GRE Tunnel =====
Router-A(config)# interface Tunnel0
Router-A(config-if)# ip address 10.255.0.1 255.255.255.252
Router-A(config-if)# tunnel source GigabitEthernet0/1
Router-A(config-if)# tunnel destination 198.51.100.2
Router-A(config-if)# ip mtu 1400
Router-A(config-if)# ip tcp adjust-mss 1360

A few non-obvious lines explained:

  • Interesting traffic ACL. Because we’re encrypting GRE-over-IPsec, the ACL matches GRE protocol (47) between the two tunnel endpoints. Not the inner subnets. The IPsec layer sees only GRE-wrapped packets; it doesn’t look inside them.
  • PFS (Perfect Forward Secrecy). set pfs group14 regenerates DH keys on every Phase 2 rekey, so a future key compromise doesn’t expose past traffic. Always enable.
  • MTU and MSS clamping. GRE adds 24 bytes of header; IPsec adds another 50-60 in tunnel mode. With a 1500-byte WAN MTU, the inner MTU has to drop to ~1400. ip tcp adjust-mss 1360 rewrites the TCP MSS option in the SYN to prevent oversize packets that would later get fragmented or dropped.
  • The crypto map applies on the physical interface, not the tunnel. This catches everyone the first time. The tunnel produces GRE packets; those packets exit the WAN interface; the crypto map on the WAN interface matches them and encrypts.

Routing Through the Tunnel

With the GRE tunnel up, you can run any dynamic routing protocol over it:

Router-A(config)# router eigrp 100
Router-A(config-router)# no auto-summary
Router-A(config-router)# network 10.255.0.0 0.0.0.3
Router-A(config-router)# network 10.1.0.0 0.0.255.255

Now Site A’s LAN routes are advertised to Site B over the EIGRP adjacency that runs across Tunnel0. No static routes, automatic failover if the tunnel goes down (assuming you have a backup path).

Verification — What to Check, In What Order

When the tunnel doesn’t come up, walk these in order:

1. Phase 1 status

Router# show crypto isakmp sa

Look for state QM_IDLE (success) or MM_NO_STATE/MM_KEY_EXCH (failing somewhere in main mode). If no SA exists at all, no IKE traffic is reaching the peer — firewall on UDP 500 (and 4500 for NAT-T) is the usual culprit.

2. Phase 2 status

Router# show crypto ipsec sa

Look for #pkts encaps and #pkts decaps counters incrementing. If encaps grows but decaps doesn’t, the other side isn’t receiving (or its return traffic isn’t coming back). If neither moves, no traffic is matching the interesting-traffic ACL.

3. Crypto map sanity

Router# show crypto map

Confirms which ACL is the interesting-traffic match, which peer is configured, which transform-set is in use. If you have multiple crypto-map entries, check sequence numbers — lower numbers match first, just like ACLs.

4. GRE tunnel

Router# show interface Tunnel0
Router# ping 10.255.0.2

Tunnel should show up/up. The ping verifies end-to-end connectivity through GRE. If GRE works but IPsec doesn’t encrypt, your interesting-traffic ACL probably doesn’t match GRE.

5. Routing

Router# show ip route eigrp
Router# show ip eigrp neighbors

The remote site’s LAN should show up in the routing table via Tunnel0’s far-side IP.

Common Pitfalls

  • Crypto map on the wrong interface. Apply to the physical WAN interface, NOT the tunnel. The tunnel generates the traffic; the WAN interface encrypts it.
  • Interesting traffic ACL points at the wrong thing. For GRE-over-IPsec, the ACL matches the GRE protocol between the two tunnel-source IPs — not the inner LAN subnets.
  • MTU not lowered. 1500 – 24 (GRE) – ~50 (IPsec) = 1426 effective. Set ip mtu 1400 on the tunnel and ip tcp adjust-mss 1360 for safety. Without this, large TCP transfers stall on the connection MSS negotiation.
  • Pre-shared key mismatch. Phase 1 fails with %CRYPTO-4-IKMP_BAD_DOI_NOTIFY or similar. Check both ends; remember the peer IP in crypto isakmp key … address X.X.X.X must match the peer’s actual sourcing IP.
  • Mismatched transform sets / DH groups. Phase 2 fails. show crypto isakmp sa detail on both sides shows what each negotiated.
  • NAT in the path. If a peer is behind NAT, IPsec ESP doesn’t pass — the NAT changes IPs that the IPsec hash signed. Enable NAT-T (Cisco does it automatically for IKEv1, ports UDP 4500). Open both UDP 500 and 4500 in any firewall in the path.
  • One side has the crypto map, the other doesn’t. Tunnel forms one direction only; you see encaps on one side, decaps never goes up on the other. Always configure symmetrically.

Conclusion

A GRE-over-IPsec site-to-site VPN combines the encryption strength of IPsec with the routing-protocol-friendliness of GRE. The configuration has more moving parts than a plain IPsec tunnel, but the result is a tunnel you can drop OSPF or EIGRP into and have it just work, with automatic failover and no static-route maintenance.

The core habits:

  1. Modern crypto only. AES-256, SHA, DH group 14+. No DES, no MD5, no DH-1/2.
  2. PFS on Phase 2. One configuration line; significantly stronger forward secrecy.
  3. Crypto map on the physical interface, not the tunnel. Cisco-specific gotcha; remember it.
  4. Interesting traffic = GRE between tunnel endpoints. Not the inner LANs.
  5. MTU and MSS clamping on the tunnel interface. Without them, big-packet apps fail intermittently and you spend an afternoon staring at packet captures.

For larger deployments, the modern alternative is DMVPN (Dynamic Multipoint VPN), which scales the hub-and-spoke pattern to dozens of sites without per-pair pre-shared keys. But for a clean two-site VPN with dynamic routing, GRE-over-IPsec remains the right call.

Tags: #Cisco IOS #GRE #IPsec #Site-to-Site #VPN

Related Articles

Leave a Reply