GRE over IPsec: When and How to Combine Them

GRE alone has no encryption. IPsec alone cannot natively carry multicast or non-IP protocols. The solution most enterprise networks have used for two decades is to combine them: build a GRE tunnel for routing and protocol transport, then wrap that tunnel inside IPsec for confidentiality and authentication. This article is the practical configuration walkthrough for GRE over IPsec on Cisco IOS XE: when to choose it, the modern IKEv2 + IPsec profile approach, the older crypto map approach, and the gotchas that catch engineers out.

The article is part of the PingLabz GRE Tunnels: The Complete Guide cluster. If you have not built a plain GRE tunnel yet, do that at GRE Tunnel Configuration: Cisco IOS XE Lab first. Adding IPsec on top is incremental once the GRE foundation works.

When to Use GRE over IPsec

The decision tree is simpler than it looks:

If you only need encrypted unicast IP between two sites, IPsec alone in tunnel mode is simpler than GRE over IPsec, has less overhead, and one fewer thing to break. Reach for GRE over IPsec specifically when you need a routing protocol (OSPF, EIGRP) to form a neighbor across an encrypted path, or when you are eventually going to scale this to mGRE / DMVPN. The full comparison is at GRE vs IPsec vs GRE-over-IPsec: Which Tunnel Type?.

How GRE over IPsec Works

The encapsulation order from inner to outer:

1. Inner IP packet (the original traffic the routing protocol or LAN hosts generated).
2. GRE header (4 bytes) wraps the inner packet.
3. Outer IP header (20 bytes) wraps the GRE-encapsulated packet, source = tunnel source, destination = tunnel destination.
4. IPsec ESP header and trailer encrypt and authenticate the entire GRE packet (the outer IP becomes the new inner from IPsec's perspective).
5. A second outer IP header (transport mode) or the original outer IP rewritten (tunnel mode) carries the IPsec packet across the underlay.

Two modes are commonly used. Transport mode reuses the existing outer IP header and only encrypts everything from the GRE header onward; it adds 20-30 bytes of overhead. Tunnel mode adds another outer IP header on top; it adds 50-60 bytes of overhead but works across NAT and through more middleboxes. Modern Cisco deployments usually use transport mode with IPsec profiles for site-to-site GRE because the outer IP is already there from the GRE encapsulation; tunnel mode is left for IPsec-only deployments.

Modern Approach: IKEv2 + IPsec Profile (recommended)

This is the configuration style you should use for any new IOS XE deployment. The crypto map approach in the next section still works but is older, more verbose, and harder to debug.

! ---- Common to both routers: IKEv2 + IPsec ----
crypto ikev2 keyring KR-GRE
 peer ANY
  address 0.0.0.0 0.0.0.0
  pre-shared-key local CISCO123
  pre-shared-key remote CISCO123
!
crypto ikev2 profile IKEV2-GRE
 match identity remote address 0.0.0.0
 authentication local pre-share
 authentication remote pre-share
 keyring local KR-GRE
 lifetime 3600
!
crypto ipsec transform-set TS-GRE esp-aes 256 esp-sha256-hmac
 mode transport
!
crypto ipsec profile IPSEC-GRE
 set transform-set TS-GRE
 set ikev2-profile IKEV2-GRE
!
! ---- R1: Tunnel interface ----
interface Tunnel0
 ip address 10.0.0.1 255.255.255.252
 ip mtu 1400
 ip tcp adjust-mss 1360
 tunnel source 198.51.100.1
 tunnel destination 203.0.113.1
 tunnel mode gre ip
 tunnel protection ipsec profile IPSEC-GRE
 keepalive 10 3
!
! ---- R2: same but with source / destination swapped ----

The magic command is tunnel protection ipsec profile IPSEC-GRE. Once that is on the tunnel interface, IOS XE silently builds the IPsec SA between the two tunnel-source IPs whenever interesting traffic flows, encrypts the GRE-encapsulated packets with the parameters in the profile, and decrypts them on the far side. There is no separate crypto ACL, no crypto map binding to a physical interface, no per-peer crypto map entry. It is the cleanest IPsec config IOS XE has.

Verification:

R1# show crypto ikev2 sa

 IPv4 Crypto IKEv2 SA

Tunnel-id Local                 Remote                fvrf/ivrf            Status
1         198.51.100.1/500      203.0.113.1/500       none/none            READY
      Encr: AES-CBC, keysize: 256, PRF: SHA256, Hash: SHA256, DH Grp:14, Auth sign: PSK, Auth verify: PSK
      Life/Active Time: 3600/142 sec

R1# show crypto ipsec sa peer 203.0.113.1

interface: Tunnel0
    Crypto map tag: Tunnel0-head-0, local addr 198.51.100.1
   protected vrf: (none)
   local  ident (addr/mask/prot/port): (198.51.100.1/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (203.0.113.1/255.255.255.255/47/0)
    #pkts encaps: 412, #pkts encrypt: 412, #pkts decaps: 410, #pkts decrypt: 410
    inbound esp sas:
      spi: 0xABCD1234(2882343476)
      transform: esp-aes 256 esp-sha256-hmac, in use settings ={Transport, }

If show crypto ikev2 sa shows a Status of READY and show crypto ipsec sa shows packets in #pkts encrypt and #pkts decrypt growing, the IPsec is working and protecting GRE.

Legacy Approach: Crypto Map (still found in production)

You will see this style in any deployment older than ~2018 and on platforms that have not been migrated. It works but is harder to extend.

! Define IKE phase 1
crypto isakmp policy 10
 encr aes 256
 authentication pre-share
 group 14
!
crypto isakmp key CISCO123 address 203.0.113.1
!
! Phase 2 transform
crypto ipsec transform-set TS-GRE esp-aes 256 esp-sha256-hmac
 mode transport
!
! Crypto ACL: encrypt only GRE traffic between the two tunnel endpoints
ip access-list extended ENCRYPT-GRE
 permit gre host 198.51.100.1 host 203.0.113.1
!
crypto map CMAP 10 ipsec-isakmp
 set peer 203.0.113.1
 set transform-set TS-GRE
 match address ENCRYPT-GRE
!
! Apply crypto map to the underlay interface (NOT the tunnel)
interface GigabitEthernet1
 ip address 198.51.100.1 255.255.255.252
 crypto map CMAP
!
! GRE tunnel - same as plain GRE, no extra knobs
interface Tunnel0
 ip address 10.0.0.1 255.255.255.252
 tunnel source GigabitEthernet1
 tunnel destination 203.0.113.1
 tunnel mode gre ip

Two key differences from the modern approach. First, the crypto map sits on the underlay interface, not the tunnel. The router examines outgoing packets, sees they match the crypto ACL (GRE between the two tunnel endpoints), and encrypts them. Second, the IPsec is not aware of the GRE relationship. If you typo the crypto ACL or change the tunnel destination, the tunnel will pass traffic in the clear because the crypto map will not match. The modern profile-based approach binds the IPsec directly to the tunnel and makes that mistake impossible.

Overhead and MTU

Stacking GRE and IPsec adds bytes you have to plan for:

Practical rule: on a 1500-byte underlay, set ip mtu 1400 on the GRE tunnel interface. That gives you 100 bytes of headroom for IPsec without thinking about the cipher choice. Combined with ip tcp adjust-mss 1360, TCP endpoints inside the tunnel will negotiate segments that fit even after IPsec encryption. The deeper math and the symptoms of getting it wrong are at GRE MTU and Fragmentation: Fixing Tunnel Packet Loss.

Running OSPF Across GRE over IPsec

The point of GRE over IPsec is that the routing protocol does not know IPsec exists. From OSPF's perspective there is a Tunnel0 interface with a neighbor reachable via multicast. OSPF forms an adjacency, exchanges LSAs, and converges. IPsec just makes sure no one in between can read the LSAs.

R1(config)# router ospf 1
R1(config-router)# network 10.0.0.0 0.0.0.3 area 0
R1(config-router)# network 192.168.1.0 0.0.0.255 area 0

R1# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
10.0.0.2          1   FULL/DROTHER    00:00:39    10.0.0.2        Tunnel0

If the IPsec SA goes down, the GRE keepalives stop returning, the tunnel goes down, OSPF tears down the neighbor and reconverges around alternate paths. That is the desired behavior. If keepalives are not configured (or are misconfigured) and only IPsec dies, the GRE interface stays up while traffic black-holes - which is one of the production failure modes covered in the troubleshooting guide.

Common Gotchas

• NAT-T and the source IP. If either tunnel endpoint sits behind NAT, IPsec needs NAT Traversal (NAT-T) which encapsulates ESP in UDP 4500. IOS XE detects this automatically. The catch: the NAT box must permit UDP 4500 and not rewrite the IPsec payload. NAT-T also adds 8 bytes to the overhead budget.
• Pre-shared keys at scale. The PSK approach works for two routers; for tens or hundreds, switch to PKI certificates. The IKEv2 + IPsec profile config above accepts certificates with minimal changes (replace authentication pre-share with authentication rsa-sig and configure a trustpoint).
• Keepalive interaction with IPsec rekey. When the IPsec SA rekeys, GRE keepalives may miss one or two transmissions. Set keepalive retry count high enough (3 or more) to ride through normal rekeys. Watch show crypto ikev2 sa for repeated ESTABLISH cycles, which indicates a deeper rekey or DPD issue.
• Asymmetric IPsec policy. Both ends must agree on transform-set, mode (transport vs tunnel), and crypto ACL. A common mistake: one end uses transport mode, the other uses tunnel mode. The IKE SA comes up but the IPsec SA never finishes negotiating. Check debug crypto ikev2 if the IKE SA forms but the IPsec SA does not.
• Packet captures show GRE in plaintext on the wire. If you SPAN the underlay interface and see GRE plaintext, your crypto map ACL does not match or your IPsec profile is not bound to the tunnel. Re-check the tunnel interface for tunnel protection ipsec profile.

Summary

GRE over IPsec is the standard pattern for routing-protocol-aware encrypted overlays on Cisco IOS XE. The modern config is small: an IKEv2 profile, an IPsec transform-set in transport mode, an IPsec profile bound to the tunnel interface, and the existing GRE configuration. Verification is two show commands (show crypto ikev2 sa and show crypto ipsec sa) plus the same routing protocol checks you would run on plain GRE. Set ip mtu 1400 on the tunnel and you have headroom for AES-256 encryption without further math.

If you are scaling this beyond two sites, the natural next step is DMVPN, which is mGRE plus NHRP plus IPsec on top. Start at mGRE and DMVPN Introduction. If you are debugging a specific failure mode, jump to GRE Tunnel Troubleshooting. The GRE pillar at PingLabz GRE Cluster is the always-current index.