Skip to content
Log in Sign up My account

2.2.b GRE and IPsec Tunneling

Blueprint 2.2: Configure and verify data path virtualization technologies

  • 2.2.a VRF (covered on the previous page)
  • 2.2.b GRE and IPsec tunneling: GRE, IPsec crypto maps vs tunnel protection, IKEv1 vs IKEv2, transport vs tunnel mode, MTU and MSS, recursive routing

This is the most hands-on objective in the Virtualization domain. A lab item that asks you to bring up an encrypted GRE tunnel, or a troubleshooting item built on show crypto output, is very likely. Learn the configuration well enough to type it from memory, and learn which show line proves each layer works.

Overlay and underlay

A tunnel wraps one packet inside another. The underlay is the real network that carries the outer packet (the internet or a WAN). The overlay is the virtual point-to-point link that the routers see as a normal interface.

graph LR
  L1["HQ LAN<br/>10.10.10.0/24"] --- R1
  R1["R1"] -- "Gi1 203.0.113.1" --- NET(("Internet<br/>underlay"))
  NET -- "Gi0/0 203.0.113.6" --- R2["BRANCH"]
  R2 --- L2["Branch LAN<br/>10.20.20.0/24"]
  R1 -. "Tunnel0 172.16.0.1/30 to .2/30, overlay" .- R2
Term In the diagram
Tunnel source R1's Gi1, 203.0.113.1 (underlay address)
Tunnel destination BRANCH's Gi0/0, 203.0.113.6 (underlay address)
Tunnel interface address 172.16.0.1/30 (overlay address)
Passenger packet The original packet from 10.10.10.x to 10.20.20.x

GRE

Generic Routing Encapsulation (GRE) is IP protocol 47. It adds a new 20-byte IPv4 delivery header and a 4-byte GRE header in front of the original packet. The GRE header names the passenger protocol, so GRE can carry IPv4, IPv6, multicast and broadcast. That makes it the tunnel of choice when you want to run a routing protocol across it.

graph LR
  A["New IP header<br/>20 bytes, proto 47<br/>src 203.0.113.1 dst 203.0.113.6"] --> B["GRE header<br/>4 bytes"] --> C["Original IP header<br/>10.10.10.5 to 10.20.20.5"] --> D["Payload"]
GRE property Value
IP protocol 47
Overhead 24 bytes (28 with the optional key field)
Carries multicast and routing protocols Yes
Encryption or authentication None
State between endpoints None. GRE is stateless unless keepalives are configured
Default IOS mode tunnel mode gre ip
Default tunnel bandwidth 100 kbps (affects EIGRP and OSPF metrics)

Configuration

interface Tunnel0
 ip address 172.16.0.1 255.255.255.252
 tunnel source GigabitEthernet1        ! or an IP address
 tunnel destination 203.0.113.6
 ! tunnel mode gre ip is the default and does not appear in the config
 keepalive 5 3                         ! optional: hello every 5 s, down after 3 misses

The other side mirrors it, with source and destination swapped.

When is a GRE tunnel up?

A GRE tunnel interface is up/up when:

  1. The tunnel source interface is up and has an IP address.
  2. The tunnel destination is reachable in the routing table (through anything except the tunnel itself).
  3. If keepalives are configured, replies are coming back.

Exam trap

Without keepalives, a GRE tunnel stays up/up even if the far end is dead or not configured at all, because the line protocol only checks the local conditions. A question that shows Tunnel0 is up, line protocol is up does not prove the remote router is there. Keepalives (or a routing protocol adjacency over the tunnel) are what detect a dead peer.

Verification

R1# show interfaces Tunnel0
Tunnel0 is up, line protocol is up
  Hardware is Tunnel
  Internet address is 172.16.0.1/30
  ...BW 100 Kbit/sec, DLY 50000 usec,
  Keepalive set (5 sec), retries 3
  Tunnel source 203.0.113.1 (GigabitEthernet1), destination 203.0.113.6
  Tunnel protocol/transport GRE/IP
    Key disabled, sequencing disabled
  Tunnel TTL 255
  Tunnel transport MTU 1476 bytes
  ...

(Output trimmed to the lines that matter.) Tunnel protocol/transport GRE/IP confirms the mode. Tunnel transport MTU 1476 bytes is 1500 minus the 24 bytes of GRE overhead.

R1# show ip interface brief | include Tunnel
R1# ping 172.16.0.2
R1# show ip route 10.20.20.0        ! learned via Tunnel0 once a protocol runs over it

Recursive routing

The route to the tunnel destination must point out of the physical interface, never into the tunnel. If a routing protocol running over the tunnel advertises the underlay subnets, the router can learn a better route to the tunnel destination through the tunnel itself. The tunnel then needs itself to reach its own endpoint, which is impossible. IOS detects it and shuts the tunnel:

%TUN-5-RECURDOWN: Tunnel0 temporarily disabled due to recursive routing

The tunnel comes back a moment later, the protocol relearns the same route, and the cycle repeats. You see the routing adjacency flap every minute or so.

graph TB
  A["OSPF over Tunnel0 advertises 203.0.113.4/30"] --> B["R1 installs 203.0.113.4/30 via Tunnel0<br/>longer match than the default route"]
  B --> C["Route to tunnel destination 203.0.113.6 now points into Tunnel0"]
  C --> D["%TUN-5-RECURDOWN, tunnel disabled"]
  D --> E["OSPF route removed, default route used again"]
  E --> F["Tunnel comes back up"]
  F --> A
Fix How
Do not advertise underlay prefixes into the overlay protocol Use specific network statements (tunnel and LAN subnets only), never network 0.0.0.0 255.255.255.255 area 0
Filter A distribute-list or prefix-list that blocks the tunnel destination's subnet from being learned through the tunnel
Pin the destination A static host route to the tunnel destination through the physical next hop. A /32 static route beats any shorter learned prefix
Separate the tables Put the overlay in a VRF, or put the underlay in a front-door VRF (tunnel vrf), so the overlay protocol can never install routes into the table that resolves the tunnel destination

Exam trap

Administrative distance does not save you here. Longest match is checked first, so an OSPF /30 to the remote internet subnet beats a static default route even though static has AD 1. The question will often dangle "change the AD" as a distractor.

IPsec fundamentals

GRE provides the virtual link. IPsec provides confidentiality (encryption), integrity, origin authentication and anti-replay. IPsec on its own carries only unicast IP, which is why the classic design is GRE over IPsec: GRE carries the routing protocols and multicast, and IPsec encrypts the GRE packets.

Component Purpose On the wire
IKE (ISAKMP) Authenticates the peers and negotiates keys and security associations UDP 500
NAT traversal Wraps ESP in UDP when NAT is detected between the peers UDP 4500
ESP Encryption, integrity and authentication of the payload IP protocol 50
AH Integrity and authentication only, no encryption. Protects the outer IP header too, so it breaks with NAT IP protocol 51

A security association (SA) is a one-way agreement on algorithms and keys. IKE builds one bidirectional IKE SA for itself, then IPsec SAs in pairs, one inbound and one outbound.

Transport mode vs tunnel mode

graph TB
  subgraph TR ["Transport mode, GRE over IPsec"]
    direction LR
    T1["GRE delivery IP<br/>proto 50"] --> T2["ESP hdr"] --> T3["GRE"] --> T4["Original IP"] --> T5["Payload"] --> T6["ESP trailer + ICV"]
  end
  subgraph TU ["Tunnel mode, GRE over IPsec"]
    direction LR
    U1["New IP<br/>proto 50"] --> U2["ESP hdr"] --> U3["GRE delivery IP<br/>proto 47"] --> U4["GRE"] --> U5["Original IP"] --> U6["Payload"] --> U7["ESP trailer + ICV"]
  end
Transport mode Tunnel mode
IP header Original header kept, ESP inserted after it New outer IP header added, whole original packet encrypted
Extra overhead None beyond ESP 20 more bytes for the new header
When it works The traffic is sourced and destined by the IPsec peers themselves Always
Typical use GRE over IPsec, where the GRE endpoints are the IPsec peers Site-to-site with a crypto map protecting LAN-to-LAN traffic, VTI
IOS default No Yes (transform sets default to tunnel mode)

GRE over IPsec suits transport mode: the GRE delivery header already carries the tunnel endpoints, which are the IPsec peers, so a second outer header just wastes 20 bytes. You must ask for it with mode transport under the transform set.

Exam trap

The default mode of a transform set is tunnel. A configuration with no mode line under crypto ipsec transform-set is running tunnel mode. Look for in use settings ={Tunnel, } or {Transport, } in show crypto ipsec sa to prove which one was negotiated.

IKEv1 vs IKEv2

IKEv1 IKEv2
Standard RFC 2409 RFC 7296
Phases Phase 1 (main mode, 6 messages, or aggressive mode, 3) then phase 2 (quick mode, 3 messages) IKE_SA_INIT and IKE_AUTH exchanges, 4 messages, build the IKE SA and the first child (IPsec) SA
Authentication Both peers use the same method Asymmetric allowed, for example one side PSK and the other a certificate. EAP supported
NAT traversal, dead peer detection Later add-ons Built in
Anti-DoS None Cookie mechanism
Reliability No request and response pairing for every message Every request has a response, with retransmission by the initiator
IOS configuration crypto isakmp policy, crypto isakmp key crypto ikev2 proposal, policy, keyring, profile
Verify show crypto isakmp sa show crypto ikev2 sa
Cisco framework built on it Classic site-to-site, DMVPN FlexVPN, DMVPN

IKEv2 is the recommended choice for new designs. The exam expects you to recognise both configuration styles.

Crypto maps vs tunnel protection

There are two ways to tell IOS which traffic to encrypt.

Crypto map Tunnel protection (IPsec profile)
Applied to The physical egress interface (crypto map NAME) The tunnel interface (tunnel protection ipsec profile NAME)
What gets encrypted Traffic matching a crypto ACL Everything routed into the tunnel
Peer set peer in the map Taken from the tunnel destination
Routing protocols Need GRE plus an ACL matching GRE Run natively over the tunnel
Adding a new LAN Edit the crypto ACL on both sides (mirror image) Nothing, the routing protocol learns it
Feature support Policy is per ACL entry Interface features (QoS, ACLs, NetFlow) apply to the tunnel interface
Status Legacy, still common Recommended

A static VTI (tunnel mode ipsec ipv4) is tunnel protection without GRE. It saves the 4-byte GRE header and supports IP unicast and multicast, but cannot carry non-IP protocols.

Configuration: three ways to the same goal

crypto ikev2 proposal PROP1
 encryption aes-cbc-256
 integrity sha256
 group 14
crypto ikev2 policy POL1
 proposal PROP1
!
crypto ikev2 keyring KR1
 peer BRANCH
  address 203.0.113.6
  pre-shared-key Cisco-ENCOR-123
!
crypto ikev2 profile IKEV2-PROF
 match identity remote address 203.0.113.6 255.255.255.255
 authentication remote pre-share
 authentication local pre-share
 keyring local KR1
!
crypto ipsec transform-set TS esp-aes 256 esp-sha256-hmac
 mode transport
crypto ipsec profile IPSEC-PROF
 set transform-set TS
 set ikev2-profile IKEV2-PROF
!
interface Tunnel0
 ip address 172.16.0.1 255.255.255.252
 tunnel source GigabitEthernet1
 tunnel destination 203.0.113.6
 tunnel protection ipsec profile IPSEC-PROF

crypto isakmp policy 10
 encryption aes 256
 hash sha256
 authentication pre-share
 group 14
crypto isakmp key Cisco-ENCOR-123 address 203.0.113.6
!
crypto ipsec transform-set TS esp-aes 256 esp-sha256-hmac
 mode transport
crypto ipsec profile IPSEC-PROF
 set transform-set TS
!
interface Tunnel0
 ip address 172.16.0.1 255.255.255.252
 tunnel source GigabitEthernet1
 tunnel destination 203.0.113.6
 tunnel protection ipsec profile IPSEC-PROF

crypto isakmp policy 10
 encryption aes 256
 hash sha256
 authentication pre-share
 group 14
crypto isakmp key Cisco-ENCOR-123 address 203.0.113.6
!
crypto ipsec transform-set TS esp-aes 256 esp-sha256-hmac
 mode transport
!
ip access-list extended GRE-TO-BRANCH
 permit gre host 203.0.113.1 host 203.0.113.6
!
crypto map CMAP 10 ipsec-isakmp
 set peer 203.0.113.6
 set transform-set TS
 match address GRE-TO-BRANCH
!
interface GigabitEthernet1
 crypto map CMAP
!
interface Tunnel0
 ip address 172.16.0.1 255.255.255.252
 tunnel source GigabitEthernet1
 tunnel destination 203.0.113.6

The crypto ACL on BRANCH must be the mirror image: permit gre host 203.0.113.6 host 203.0.113.1.

! Same IKEv2 and IPsec profile as the first tab, transform set left in tunnel mode
interface Tunnel0
 ip address 172.16.0.1 255.255.255.252
 tunnel source GigabitEthernet1
 tunnel destination 203.0.113.6
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile IPSEC-PROF

Exam trap

The IKE parameters must be compatible on both peers: encryption, integrity or hash, DH group and authentication method in IKEv1 policies or IKEv2 proposals, plus the same pre-shared key. The transform sets must share at least one matching set. Policy and proposal sequence numbers are local and do not need to match: IOS compares what the peer offers against all of its own policies.

Underlay in a front-door VRF

When the internet-facing interface sits in its own VRF (a front-door VRF, FVRF), the tunnel must be told where to resolve its destination:

interface GigabitEthernet1
 vrf forwarding INTERNET
 ip address 203.0.113.1 255.255.255.252
!
interface Tunnel0
 vrf forwarding CUSTOMER-A       ! overlay (inside VRF, IVRF)
 tunnel source GigabitEthernet1
 tunnel destination 203.0.113.6
 tunnel vrf INTERNET             ! underlay (front-door VRF)

With IKEv2, the profile also needs match fvrf INTERNET show crypto ikev2 sa shows the pair in its fvrf/ivrf column.

MTU and TCP MSS

Every encapsulation layer eats into the 1500-byte path MTU.

Layer Bytes added
GRE (IPv4 delivery header + GRE header) 24
ESP transport mode with AES-CBC and SHA-256 (SPI, sequence, IV, padding, trailer, ICV) about 42 to 57, depending on padding
ESP tunnel mode 20 more than transport mode
NAT-T UDP header 8 more

If a full 1500-byte packet enters the tunnel, the encapsulated packet is too large for the path. The router must fragment it (slow, and fragments complicate the far end's reassembly and any firewall in between), or drop it if the DF bit is set and send back an ICMP "fragmentation needed" message, which is often filtered.

The usual fix has two parts:

interface Tunnel0
 ip mtu 1400              ! largest IP packet the router will put into the tunnel
 ip tcp adjust-mss 1360   ! rewrite the MSS in TCP SYNs passing through
  • ip mtu controls when the router fragments or drops (DF set) before encapsulating. 1400 is Cisco's common recommendation for GRE over IPsec because it leaves room for GRE plus ESP transport mode with common ciphers. Tunnel mode or NAT-T may need a lower value.
  • ip tcp adjust-mss makes the endpoints send smaller TCP segments in the first place. The MSS is the IP MTU minus 40 bytes (20 IP and 20 TCP), so 1400 gives 1360.
  • MSS clamping works only for TCP. UDP and ICMP still rely on fragmentation or path MTU discovery.

Exam trap

Symptoms of an MTU problem: pings work, SSH logs in, but web pages hang half-loaded and file transfers stall. Small packets fit and large ones do not. The answer is ip mtu plus ip tcp adjust-mss on the tunnel, not a change to the physical interface MTU (you do not control the internet's MTU).

Verification

R1# show crypto ikev2 sa
 IPv4 Crypto IKEv2  SA

Tunnel-id Local                 Remote                fvrf/ivrf            Status
1         203.0.113.1/500       203.0.113.6/500       none/CUSTOMER-A      READY
      Encr: AES-CBC, keysize: 256, PRF: SHA256, Hash: SHA256, DH Grp:14, Auth sign: PSK, Auth verify: PSK

R1# show crypto isakmp sa              ! IKEv1 equivalent
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
203.0.113.6     203.0.113.1     QM_IDLE           1001 ACTIVE

QM_IDLE means phase 1 is complete and idle, ready for quick mode. It is the healthy state, despite the word "idle".

R1# show crypto ipsec sa
interface: Tunnel0
    Crypto map tag: Tunnel0-head-0, local addr 203.0.113.1
   protected vrf: CUSTOMER-A
   local  ident (addr/mask/prot/port): (203.0.113.1/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (203.0.113.6/255.255.255.255/47/0)
   current_peer 203.0.113.6 port 500
    #pkts encaps: 214, #pkts encrypt: 214, #pkts digest: 214
    #pkts decaps: 209, #pkts decrypt: 209, #pkts verify: 209
     ...
     inbound esp sas:
        transform: esp-256-aes esp-sha256-hmac ,
        in use settings ={Transport, }

(Trimmed.) The ident lines show protocol 47: IPsec is protecting GRE between the two tunnel endpoints. Encaps and decaps should both climb while traffic flows. Tunnel protection builds an internal crypto map named after the tunnel, which is where Tunnel0-head-0 comes from.

R1# show crypto session            ! one line per peer: UP-ACTIVE is good
R1# show crypto map                ! crypto map configs, including tunnel protection ones
R1# debug crypto ikev2             ! or debug crypto isakmp, then clear the SA and watch

Troubleshooting map

Symptom Likely cause
Tunnel up/down No route to the tunnel destination, source interface down, or keepalives failing
Tunnel flaps with %TUN-5-RECURDOWN Recursive routing: tunnel destination learned through the tunnel
No IKE SA at all UDP 500 blocked, wrong peer address, or (crypto map) no traffic matched the crypto ACL so IKE never started
IKEv1 stuck in MM_WAIT_MSG2 The peer is not answering: unreachable, UDP 500 filtered, or no ISAKMP config on it
IKEv1 MM_NO_STATE or IKEv2 negotiation fails early Phase 1 policy or IKEv2 proposal mismatch
IKE fails at authentication Pre-shared key mismatch, or the key configured for the wrong peer address
IKE up, no IPsec SA Transform set mismatch, or crypto ACLs that are not mirror images
Encaps climbing, decaps zero The far end is not sending back: its routing, its own SA, or ESP (protocol 50) blocked on the return path
Small packets work, large fail MTU, add ip mtu and ip tcp adjust-mss
Works until NAT is added AH in use (cannot pass NAT), or UDP 4500 blocked

Lab: GRE over IPsec in VRF CUSTOMER-A

This is the week 2 deliverable from the study plan. Build it in stages so you see each layer work before the next one hides it.

Topology: base topology routers R1 (Catalyst 8000v), ISP (IOSv) and BRANCH (IOSv). The ISP only knows its connected networks. Each router has a static default route to the ISP.

graph LR
  H1["R1 Lo10<br/>VRF CUSTOMER-A<br/>10.10.10.1/24"] --- R1["R1"]
  R1 -- "Gi1 203.0.113.1/30" --- ISP["ISP"]
  ISP -- "203.0.113.6/30 Gi0/0" --- BR["BRANCH"]
  BR --- H2["BRANCH Lo10<br/>VRF CUSTOMER-A<br/>10.20.20.1/24"]
  R1 -. "Tunnel0 172.16.0.1/30 to .2/30<br/>VRF CUSTOMER-A" .- BR

Stage 1: plain GRE in the VRF.

  1. On both routers create vrf definition CUSTOMER-A with address-family ipv4.
  2. Create Loopback10 in the VRF with the LAN address shown and ip ospf network point-to-point.
  3. Create Tunnel0 with vrf forwarding CUSTOMER-A first, then the overlay address, source Gi1 (Gi0/0 on BRANCH) and the peer's physical address as destination. Leave the physical interfaces and default routes in the global table.
  4. Run router ospf 10 vrf CUSTOMER-A on both routers with network statements for 172.16.0.0/30 and the loopback /24 only.
! R1
vrf definition CUSTOMER-A
 address-family ipv4
 exit-address-family
interface Loopback10
 vrf forwarding CUSTOMER-A
 ip address 10.10.10.1 255.255.255.0
 ip ospf network point-to-point
interface Tunnel0
 vrf forwarding CUSTOMER-A
 ip address 172.16.0.1 255.255.255.252
 tunnel source GigabitEthernet1
 tunnel destination 203.0.113.6
router ospf 10 vrf CUSTOMER-A
 router-id 10.255.255.1
 network 10.10.10.0 0.0.0.255 area 0
 network 172.16.0.0 0.0.0.3 area 0

Expected: show ip route vrf CUSTOMER-A ospf on R1 shows O 10.20.20.0/24 [110/1001] via 172.16.0.2, Tunnel0 (tunnel cost 1000 from its 100 kbps bandwidth, plus 1). ping vrf CUSTOMER-A 10.20.20.1 source Loopback10 succeeds. If you capture on the ISP link in CML, you see IP protocol 47 with the inner 10.x addresses readable in clear text.

Stage 2: see recursive routing (optional detour). Remove vrf forwarding from both tunnels (re-add their addresses), run router ospf 1 in the global table with network 0.0.0.0 255.255.255.255 area 0 on both, and wait. Within a minute R1 logs %TUN-5-RECURDOWN. Remove the global OSPF process and restore the VRF configuration. Note that the VRF design made this failure impossible: OSPF in CUSTOMER-A cannot install routes into the global table that resolves the tunnel destination.

Stage 3: add IKEv2 and tunnel protection. Apply the "IKEv2 + tunnel protection" configuration from the tabs above on R1, and its mirror on BRANCH (peer address 203.0.113.1, same key). Keep mode transport.

Expected: OSPF stays up (it may flap once while the SAs form). show crypto ikev2 sa shows READY with none/CUSTOMER-A in the fvrf/ivrf column. show crypto ipsec sa shows encaps and decaps rising and {Transport, }. A capture on the ISP link now shows only ESP (protocol 50) between 203.0.113.1 and 203.0.113.6.

Stage 4: MTU and MSS.

interface Tunnel0
 ip mtu 1400
 ip tcp adjust-mss 1360

Expected: ping vrf CUSTOMER-A 10.20.20.1 source Loopback10 size 1400 df-bit succeeds, and size 1450 df-bit fails (IOS typically prints M, could not fragment) because the packet is larger than the tunnel IP MTU.

Break it (one at a time, predict the symptom first, then check against the troubleshooting map):

  • Change the pre-shared key on BRANCH.
  • Change the IKEv2 proposal on BRANCH to group 19.
  • Remove mode transport on one side only, then clear the SAs with clear crypto session and check the mode that gets negotiated.
  • Add an ACL on the ISP that permits UDP 500 but denies ESP.

Quick check

A GRE tunnel shows up/up on R1, but OSPF across it never forms. The remote router has no tunnel configured at all. Why is the tunnel up?

A GRE tunnel only checks local conditions: the source is up and the destination is routable. Without keepalives it has no way to know the far end does not exist.

Why is transport mode the better choice for GRE over IPsec?

The IPsec peers are the GRE endpoints, so the GRE delivery header already carries the right outer addresses. Tunnel mode would add another 20-byte IP header with the same addresses for no benefit.

show crypto ipsec sa on R1 shows #pkts encaps: 500 and #pkts decaps: 0. Where do you look?

At the return direction. R1 is encrypting and sending, but nothing is coming back: check the far end's SA and routing, and any filter that blocks ESP (protocol 50) from the far end toward R1.

References