How to Set Up GRE (Generic Routing Encapsulation) Tunnels on Cisco Routers: Complete Guide

If you’ve ever needed to connect two remote sites over the public internet, or carry traffic that your underlying network wasn’t originally built to support (like multicast, IPv6 over an IPv4-only backbone, or routing protocols across a provider network), you’ve probably run into GRE tunnels. I want to walk you through exactly what GRE is, how it works under the hood, and how to configure it on Cisco routers — from a basic point-to-point tunnel all the way to a more advanced enterprise deployment with security and troubleshooting baked in.

What Is GRE and Why Does It Matter?

GRE (Generic Routing Encapsulation) is a tunneling protocol developed by Cisco and later standardized in RFC 2784. At its core, GRE takes a packet — any packet, from almost any protocol — and wraps it inside a new IP packet. That new “outer” packet gets routed across the network like any other IP traffic, and when it arrives at the far end, the receiving router strips off the outer header and forwards the original “inner” packet as if it had arrived natively.

I like to think of GRE as a shipping container. It doesn’t care what’s inside — furniture, electronics, fragile glassware — it just wraps it in a standard container that any ship, truck, or train can carry. GRE does the same thing for packets: it doesn’t care if the inner payload is IPv4, IPv6, IPX, multicast, or even another tunneled protocol.

Why You’d Use GRE

• Connecting two private networks over a public network (like the internet) without needing every intermediate router to understand your internal addressing.
• Carrying routing protocols (EIGRP, OSPF) across a provider network that only offers a Layer 3 IP service and doesn’t support dynamic routing between your sites.
• Transporting multicast traffic across networks that don’t support multicast natively.
• Building the underlay for other technologies, such as DMVPN, which relies heavily on GRE (specifically mGRE — multipoint GRE).

How GRE Works: Packet Structure

Every GRE packet has this basic structure:

[New IP Header] [GRE Header] [Original IP Packet]

The new IP header uses the tunnel source and destination addresses (the real, routable public or transit addresses of your routers). The GRE header itself is fairly simple — 4 bytes at minimum — and includes a protocol type field that tells the receiving router what kind of payload is inside (IPv4, IPv6, etc.).

One important detail: GRE adds overhead. A standard GRE header adds 24 bytes total (20 bytes for the new IP header + 4 bytes for the GRE header) on top of your original packet. This matters a lot when it comes to MTU and fragmentation, which I’ll cover in the troubleshooting section.

GRE is stateless and has no built-in encryption — it’s just encapsulation. If you need confidentiality, you pair GRE with IPsec (a very common combo called GRE over IPsec).

Prerequisites

Before you start, you’ll need:

• Two Cisco routers with IOS or IOS-XE (this guide works on both, with virtually identical syntax)
• IP reachability between the tunnel source and destination addresses (i.e., the routers must already be able to ping each other over the underlying network)
• Basic interface and routing knowledge

I’ll use this topology for the examples:

R1 (LAN: 192.168.1.0/24)  ---  Internet/WAN  ---  R2 (LAN: 192.168.2.0/24)
R1 WAN interface: 203.0.113.1
R2 WAN interface: 198.51.100.1
Tunnel network: 172.16.0.0/30

Basic GRE Tunnel Configuration

Step 1: Configure R1

R1(config)# interface Tunnel0
R1(config-if)# ip address 172.16.0.1 255.255.255.252
R1(config-if)# tunnel source GigabitEthernet0/1
R1(config-if)# tunnel destination 198.51.100.1
R1(config-if)# tunnel mode gre ip
R1(config-if)# no shutdown
R1(config-if)# exit

Note: tunnel mode gre ip is actually the default mode for a Cisco tunnel interface, so you technically don’t need to type it — but I always include it explicitly. It makes the config self-documenting, and six months from now when you’re troubleshooting at 2 a.m., you’ll thank yourself.

Step 2: Configure R2

R2(config)# interface Tunnel0
R2(config-if)# ip address 172.16.0.2 255.255.255.252
R2(config-if)# tunnel source GigabitEthernet0/1
R2(config-if)# tunnel destination 203.0.113.1
R2(config-if)# tunnel mode gre ip
R2(config-if)# no shutdown
R2(config-if)# exit

Step 3: Route Traffic Through the Tunnel

Now you need to tell each router how to reach the remote LAN through the tunnel. You can do this with static routes or a dynamic routing protocol.

Static routing example:

R1(config)# ip route 192.168.2.0 255.255.255.0 Tunnel0
R2(config)# ip route 192.168.1.0 255.255.255.0 Tunnel0

Or, more commonly in production, run a routing protocol like OSPF over the tunnel:

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

Do the same on R2 with its LAN subnet. This way, if you add more subnets behind either router later, OSPF handles the propagation automatically.

Verifying the Tunnel

This is the part people skip and then wonder why nothing works. Always verify.

R1# show interfaces tunnel0
Tunnel0 is up, line protocol is up
  Hardware is Tunnel
  Internet address is 172.16.0.1/30
  MTU 17916 bytes, BW 100 Kbit/sec, DLY 50000 usec,
  Tunnel source 203.0.113.1, destination 198.51.100.1
  Tunnel protocol/transport GRE/IP

Key things to check:

• Line protocol is up — if it says “up/down,” the tunnel destination usually isn’t reachable.
• Tunnel source/destination match what you intended.

Ping across the tunnel:

R1# ping 172.16.0.2
!!!!!
Success rate is 100 percent (5/5)

Check the routing table to confirm the remote LAN is reachable via the tunnel:

R1# show ip route 192.168.2.0

And finally, test end-to-end from a host on R1’s LAN to a host on R2’s LAN.

MTU and Fragmentation: The Real-World Gotcha

This is, hands down, the most common GRE headache I’ve run into in production networks. Because GRE adds 24 bytes of overhead, a packet that was exactly 1500 bytes on the LAN becomes 1524 bytes once encapsulated — which exceeds the standard Ethernet MTU on the underlying path. If the “don’t fragment” bit is set (common with a lot of application traffic), those oversized packets get silently dropped, and you get the classic symptom: pings work fine, but larger transfers (like RDP sessions, file copies, or HTTPS pages) hang or time out.

Two ways to deal with it:

1. Adjust the TCP MSS on the tunnel interface so TCP sessions negotiate a smaller segment size from the start:

R1(config-if)# ip tcp adjust-mss 1360

2. Lower the tunnel interface MTU and enable path MTU discovery, or manually account for the 24-byte overhead when sizing packets elsewhere in the network.

I almost always apply ip tcp adjust-mss on production GRE tunnels as a standard practice — it heads off a huge percentage of “it works sometimes” tickets.

Adding Security: GRE over IPsec

Since GRE itself doesn’t encrypt anything, if this tunnel is crossing the public internet and carrying sensitive traffic, you’ll want to wrap it in IPsec. Here’s a simplified example using IKEv1:

R1(config)# crypto isakmp policy 10
R1(config-isakmp)# encryption aes 256
R1(config-isakmp)# hash sha256
R1(config-isakmp)# authentication pre-share
R1(config-isakmp)# group 14
R1(config-isakmp)# exit
R1(config)# crypto isakmp key MyStrongPreSharedKey address 198.51.100.1

R1(config)# crypto ipsec transform-set TS esp-aes 256 esp-sha256-hmac
R1(cfg-crypto-trans)# mode transport
R1(cfg-crypto-trans)# exit

R1(config)# crypto map GRE-MAP 10 ipsec-isakmp
R1(config-crypto-map)# set peer 198.51.100.1
R1(config-crypto-map)# set transform-set TS
R1(config-crypto-map)# match address GRE-TRAFFIC
R1(config-crypto-map)# exit

R1(config)# ip access-list extended GRE-TRAFFIC
R1(config-ext-nacl)# permit gre host 203.0.113.1 host 198.51.100.1
R1(config-ext-nacl)# exit

R1(config)# interface GigabitEthernet0/1
R1(config-if)# crypto map GRE-MAP

Mirror this configuration on R2 with the addresses reversed. This setup encrypts only the GRE traffic itself (transport mode against the GRE packets), which is a clean and efficient way to secure a site-to-site tunnel without the extra overhead of full tunnel-mode IPsec.

Real-World Enterprise Scenario

I’ve deployed GRE tunnels most often in these situations:

• Branch office backup connectivity: A branch has an MPLS circuit as primary and a GRE-over-IPsec tunnel over broadband internet as backup, with EIGRP or OSPF handling automatic failover based on route metrics.
• Extending routing protocols across a provider’s Layer 3 VPN: Some service providers only offer static routing on their MPLS handoff. A GRE tunnel between customer edge routers lets you run OSPF or EIGRP across that link as if it were a private line.
• DMVPN hub-and-spoke deployments: mGRE tunnels form the underlay that DMVPN then layers dynamic IPsec and NHRP on top of.

Common Configuration Mistakes

• Forgetting that tunnel source must be reachable independently of the tunnel itself. If your default route points out the tunnel (recursive routing), the tunnel will flap or fail entirely.
• Mismatched tunnel modes between the two ends (e.g., one side set to GRE, the other set to IPsec-only mode).
• Overlapping tunnel and LAN subnets.
• Not accounting for MTU, leading to mysterious application-layer failures that look nothing like a networking problem at first glance.
• Using the same source interface for tunnel and default routing without proper route filtering, which can create recursive routing loops.

Troubleshooting Checklist

1. show interfaces tunnel0 — confirm line protocol is up.
2. ping <tunnel destination> from the source interface — confirm underlying reachability.
3. show ip route <tunnel destination> — make sure the route to the destination doesn’t recurse through the tunnel itself.
4. debug tunnel (use cautiously in production) — shows tunnel encapsulation/decapsulation events.
5. Check MTU-related symptoms: small pings work, large transfers don’t.
6. Verify ACLs or firewalls between the endpoints permit IP protocol 47 (GRE) — this is often blocked by default on internet-facing firewalls.

Performance Tuning Tips

• Set ip tcp adjust-mss proactively on all GRE tunnel interfaces.
• Consider ip mtu and ip tunnel path-mtu-discovery settings if you’re dealing with variable path MTUs.
• For high-throughput links, remember GRE processing can be CPU-intensive on lower-end platforms without hardware offload — check show processes cpu if you notice unexpected load after enabling tunnels.
• Use QoS policies on the physical egress interface (not just the tunnel interface) to properly classify and prioritize tunneled traffic, since some platforms don’t inherit QoS markings cleanly through encapsulation.

FAQs

Does GRE support IPv6? Yes. GRE can encapsulate IPv6 packets, and you can also run a GRE tunnel over an IPv6 transport network. Just adjust the tunnel mode accordingly (tunnel mode gre ipv6 in some contexts, or by using IPv6 addressing on the tunnel interface).

Is GRE the same as a VPN? Not by itself. GRE is an encapsulation and tunneling method — it moves packets between two points but doesn’t encrypt them. When people say “GRE VPN,” they usually mean GRE combined with IPsec.

Can I run multiple GRE tunnels on one router? Absolutely. You simply create multiple tunnel interfaces (Tunnel0, Tunnel1, Tunnel2, and so on), each with its own source, destination, and IP addressing.

What’s the difference between GRE and mGRE? Standard GRE is point-to-point — one tunnel, one destination. Multipoint GRE (mGRE) allows a single tunnel interface to communicate with multiple remote endpoints, which is the foundation of DMVPN.

Why does my tunnel keep flapping? The most common cause is recursive routing, where the route to reach the tunnel destination is itself learned through the tunnel. Always ensure your tunnel destination is reachable via a route that doesn’t depend on the tunnel.

Summary

GRE tunnels are one of the most versatile tools in a network engineer’s toolkit — simple enough to configure in a few lines, yet powerful enough to underpin technologies like DMVPN. The key things to remember: GRE encapsulates almost anything, it adds 24 bytes of overhead you need to plan for, it doesn’t encrypt on its own, and recursive routing is the classic pitfall that trips people up. Get the tunnel source/destination reachability right, handle MTU properly, and layer in IPsec when security matters, and you’ll have a rock-solid tunnel.

References

• Cisco: Configuring GRE Tunnels
• RFC 2784: Generic Routing Encapsulation (GRE)
• Cisco IOS IP Application Services Configuration Guide