Deep Diving into GRE Tunnels: Explanation, Configuration, and Optimization Tips

GRE (Generic Routing Encapsulation) allows you to create point-to-point virtual tunnels between routers over an IP network. This is extremely useful when you want to run a dynamic routing protocol like EIGRP or OSPF between sites without needing to configure ACLs for each subnet. GRE effectively abstracts the underlying IP transport and allows routing protocols to treat the tunnel like a direct link.

GRE over IPSec combines the flexibility of Generic Routing Encapsulation (GRE) with the security of IPSec, offering a powerful solution for building dynamic, routing-aware VPNs over the internet. Unlike traditional site-to-site IPSec VPNs, which require defining access-lists for “interesting” traffic, GRE allows you to simply run a routing protocol across the tunnel, making the setup more scalable and dynamic.

How GRE Encapsulation Works

When GRE sends data, it encapsulates the original IP packet inside a new packet with its outer IP header. For example:

• Original packet: 172.16.1.1 → 172.16.1.2
• Outer GRE header: 10.1.1.2 → 192.0.2.2 (used for routing over the internet)

Routing decisions are made based on the outer header, and once the packet reaches the remote router, the GRE header is removed to deliver the original IP packet.

GRE Tunnel Prerequisites

To bring a GRE tunnel interface up on a Cisco router, three essential elements must be configured:

1. Tunnel Interface IP – This is the IP address assigned to the tunnel itself.
2. Tunnel Source – Typically, an IP address or interface that exists on the router.
3. Tunnel Destination – The public IP address of the remote peer/router.

Without all three, the tunnel interface will remain down.

interface tunnel1
ip address 172.16.1.1 255.255.255.0
tunnel source gigabitethernet1
tunnel destination 192.0.2.2

interface tunnel1
ip address 172.16.1.2 255.255.255.0
tunnel source gigabitethernet1
tunnel destination 10.10.1.2

Once both ends are properly configured, you should be able to ping the remote tunnel interface (e.g., 172.16.1.2). This indicates the GRE tunnel is operational.

router eigrp 10
network 172.16.1.0 0.0.0.255
network 192.168.1.0 0.0.0.255

This configuration enables R1 and R3 to establish EIGRP neighbor relationships via the tunnel and advertise their internal networks.

If configured correctly, you should see EIGRP neighbors form and exchange routing updates over the GRE tunnel; no additional ACLs or static routes are required.

Important Note: GRE Alone Is Not Encrypted

While the tunnel may be fully operational and support dynamic routing, it’s essential to note that GRE does not provide encryption. All tunneled traffic can be seen in clear text by any router or device between the two. You can confirm this by placing a packet sniffer or running a debug on a transit router: GRE packets will be visible and unencrypted.

To secure GRE traffic, IPSec must be layered on top using an IPSec profile and the tunnel protection command.

Why use GRE with IPSec instead of a traditional site-to-site VPN?

Using GRE allows you to:

• Eliminate the need for defining proxy ACLs every time a new subnet is added.
• Support dynamic routing protocols (like OSPF or EIGRP) over a secure link.
• Simplify VPN architecture in hub-and-spoke or full mesh designs.

Considerations: Overhead and MTU

When you encapsulate a packet with GRE and then encrypt it with IPSec, you’re adding overhead. GRE adds 24 bytes, and ESP adds another 28 bytes—a total of 52 bytes. This can cause fragmentation if the path MTU is not properly managed.

By default, IOS disables PMTUD (Path MTU Discovery) for IPSec. Because PMTUD relies on ICMP, any upstream device blocking ICMP can break it. You may need to manually adjust the tunnel MTU or enable PMTUD explicitly.

crypto isakmp policy 10
authentication pre-share
encryption 3des
hash md5
group 2

crypto isakmp key key address x.x.x.x

crypto ipsec transform-set tset-name esp-3des esp-md5

crypto ipsec profile profile-name
set transform-set tset-name

interface Tunnel1
tunnel protection ipsec profile profile-name

show crypto ipsec sa

Look for in use settings = [Tunnel] or [Transport] to confirm the mode.

show interface tunnel1

Key indicators include:

• Tunnel protocol/transport GRE/IP
• Tunnel protection via IPSec profile “name“

GRE over IPSec: Tunnel Mode vs. Transport Mode, Deployment Options, and Best Practices

In modern enterprise networks, GRE over IPSec (GRE/IPSec) is a popular solution to create encrypted, dynamic tunnels over the internet. It enables the use of routing protocols across sites while encrypting the underlying traffic. However, choosing between tunnel mode, transport mode, and methods like GREoIPSec vs. IPSec over GRE can be confusing. This guide breaks down how these technologies work, how to configure them, and why choosing the right mode and method matters.

GRE over IPSec: Why and How?

GRE provides a method to encapsulate a wide range of Layer 3 traffic types, making it ideal for running routing protocols like EIGRP or OSPF over a VPN. When paired with IPSec, GRE tunnels gain encryption and confidentiality.

There are two common architectures:

• GRE over IPSec (GREoIPSec): GRE encapsulation happens first, then encryption with IPSec.
• IPSec over GRE (IPSecoGRE): IPSec encrypts the original IP packet, and GRE wraps the IPSec-protected data later.

GREoIPSec is the standard and widely supported method. IPSecoGRE is technically possible but not supported by Cisco and should not be used in production.

Tunnel Mode vs. Transport Mode: What’s the Difference?

Tunnel Mode

In tunnel mode, IPSec encrypts the entire GRE-encapsulated packet and adds a new outer IP header. This increases overhead significantly:

• ESP adds 20 bytes.
• GRE adds 24 bytes.
• The new IP header adds 20 more bytes.
• Total overhead: ~120 bytes for IPv4, ~140 bytes for IPv6

This is the default mode and works in most environments, but comes with higher bandwidth consumption and MTU issues.

crypto ipsec transform-set tset-name esp-3des esp-md5
mode transport

crypto ipsec profile PROFILE
set transform-set TSET

This configuration allows all tunnel protection to be handled with one profile and supports routing protocols, multicast, and dynamic IPs

interface f0/0
crypto map CM

Issues with IPSec over GRE (IPSecoGRE):

• Not supported by Cisco TAC
• Complex to troubleshoot
• Cannot scale with multiple interfaces or asymmetric paths
• Traffic must pass through a crypto ACL, increasing processing overhead

This avoids having to define individual internal subnets, since GRE encapsulates and routes traffic using tunnel IPs.

Summary Comparison

Look for:

• Tunnel up/up
• ESP encryption and decryption counters increasing
• Transport or tunnel mode confirmation

mGRE and Its Role in Dynamic VPN Architectures

When building scalable, secure, and flexible VPN solutions, technologies like Generic Routing Encapsulation (GRE) and Multipoint GRE (mGRE) play a critical role. In dynamic environments, especially those utilizing DMVPN (Dynamic Multipoint VPN), GRE becomes more than just an encapsulation method; it serves as the bridge to scale beyond simple point-to-point designs. Let’s break down how GRE, mGRE, and NHRP come together to make it work.

Introduction to Multipoint GRE (mGRE)

Multipoint GRE, or mGRE, enables a single GRE tunnel interface to act as the endpoint for multiple VPN peers, thereby eliminating the need for a separate tunnel for each site. This is especially useful for hub-and-spoke or full mesh topologies.

DMVPN and FlexVPN are common use cases:

• DMVPN uses mGRE + NHRP to dynamically establish tunnels.
• FlexVPN does not use multipoint tunnels and instead relies on Virtual Tunnel Interfaces (VTIs).

How mGRE Works

• An mGRE interface functions like a virtual switch: all remote peers share the same subnet and communicate as if on a directly connected LAN.
• NHRP acts as the DNS of the tunnel network – mapping tunnel IPs to NBMA (real-world) IPs.
• Each router registers its tunnel endpoint and NBMA address with the NHS.
• When a peer needs to send traffic, NHRP resolves the NBMA of the remote peer and builds a dynamic IPSec tunnel.

Performance & CEF Optimization

Cisco devices use CEF (Cisco Express Forwarding) to speed up forwarding:

• Adjacencies are built to NHRP-discovered peers.
• These are cached in the FIB (Forwarding Information Base) to prevent constant lookups.
• This helps avoid latency by ensuring fast switching even as peer tables grow.

Why GRE Is Needed for Non-IP Protocols

Native IPSec is limited to handling IPv4 and IPv6 traffic only. It cannot transport non-IP protocols on its own. This is where GRE encapsulation comes into play. GRE wraps non-IP packets in an IP header, allowing IPSec to encrypt and transmit them.

This makes GRE essential not just for flexibility but also for compatibility. Even in environments that appear to only need IP-based encryption, GRE is mandatory in scenarios like DMVPN, which rely on NHRP (Next Hop Resolution Protocol) for dynamic peer discovery.

This configuration includes:

• The tunnel IP and subnet
• A network ID for NHRP
• The Next Hop Server (NHS) and NBMA IP (used for resolving dynamic peers)
• The source interface (e.g., GigabitEthernet1)
• Enabling multipoint GRE mode
• Applying an IPSec profile for encryption

Summary: Why mGRE + IPSec + NHRP Matters

Multipoint GRE, when combined with IPSec and NHRP, becomes a key component in building dynamic and scalable VPN solutions, such as DMVPN. It simplifies tunnel management, supports rich routing protocols, and ensures secure transmission – even for non-IP traffic.