How GRE Tunnels Work: Encapsulation, MTU, and Uses

GRE — Generic Routing Encapsulation — is one of the oldest and most widely deployed tunneling protocols in networking. Defined in RFC 2784 (and updated by RFC 2890), GRE wraps arbitrary network-layer packets inside an IP header, creating a virtual point-to-point link between two routers across any IP network. What travels inside the tunnel looks like a direct connection; what the underlying network sees is ordinary IP traffic destined for the tunnel endpoint. That simplicity is both GRE's greatest strength and its most important limitation.

GRE carries no encryption and provides no authentication. It is a pure encapsulation mechanism. If you need confidentiality, you pair GRE with IPsec — a combination so common it has its own configuration idiom on virtually every enterprise router platform. The two roles are deliberately separated: GRE handles encapsulation of arbitrary protocols; IPsec handles encryption and integrity.

Packet Format

GRE uses IP protocol number 47. The encapsulation adds two layers on top of the original packet: an outer IP header identifying the tunnel endpoints, and a GRE header identifying the carried protocol.

The GRE header's minimum size is 4 bytes: 2 bytes of flags and 1-bit fields (Checksum present, Key present, Sequence present, etc.) plus a 2-byte Protocol Type field that carries an EtherType value identifying the encapsulated payload. Optional extensions for checksum, key, and sequence number add 4 bytes each when enabled. In baseline GRE without any optional fields, the total tunnel overhead over IPv4 is 24 bytes: 20 bytes outer IP + 4 bytes GRE.

GRE Carries Almost Anything

The Protocol Type field accepts any EtherType value, meaning GRE can tunnel:

• IPv4 inside IPv4 (most common — GRE tunnel between two IPv4 routers)
• IPv6 inside IPv4 (6in4 — a straightforward IPv6 transition mechanism)
• IPv4 or IPv6 inside IPv6 (6RD, ISATAP-like deployments)
• MPLS (carrying labeled packets across non-MPLS networks)
• Any routable protocol including legacy IPX, AppleTalk, CLNS

This matters operationally: IPsec transport mode protects only unicast IP and cannot carry multicast or broadcast traffic. GRE can carry multicast, making GRE-over-IPsec the standard pattern for encrypted OSPF or EIGRP adjacencies across an untrusted WAN — the routing protocol runs over the GRE tunnel (which supports multicast), and IPsec encrypts all GRE packets in transit.

MTU and MSS Clamping

GRE's 24-byte overhead directly reduces the effective MTU available to encapsulated traffic. On a standard Ethernet path with a 1500-byte MTU:

Effective inner MTU = 1500 − 20 (outer IP) − 4 (GRE) = 1476 bytes

If the optional Key field is enabled, the GRE header grows to 8 bytes, dropping the inner MTU to 1472 bytes. If GRE is carried inside IPsec (ESP in tunnel mode, AES-256, SHA-256), the combined overhead can reach 70–90 bytes, pushing the inner MTU below 1420 bytes.

The danger is silent drops: a host sends a 1500-byte IP packet with the Don't Fragment (DF) bit set. The GRE router cannot fragment it (DF is set) and cannot forward the encapsulated 1524-byte packet through a 1500-byte interface. The correct behavior is to send an ICMP "Fragmentation Needed" (type 3, code 4) message back to the sender, signaling the actual MTU. But many firewalls block ICMP, breaking Path MTU Discovery and causing TCP sessions to stall at large message sizes while small packets (DNS, HTTP headers) work fine — the notorious MTU black hole.

The practical fix for TCP traffic is MSS clamping: the GRE router rewrites the TCP SYN's Maximum Segment Size option to account for tunnel overhead:

Clamped MSS = 1500 − 40 (IP+TCP) − 24 (GRE overhead) = 1436 bytes

This is configured with ip tcp adjust-mss 1436 on Cisco IOS or iptables -j TCPMSS --set-mss 1436 on Linux. Non-TCP traffic (UDP, ICMP) still faces the fragmentation problem and must rely on PMTUD working correctly.

GRE Keepalives

Standard GRE has no native liveness detection — the tunnel interface stays up even if the remote endpoint is completely unreachable. This means a router can continue forwarding traffic into a black hole indefinitely. The solution is either:

• GRE keepalives (Cisco IOS): the local router encapsulates keepalive packets inside the GRE tunnel addressed to itself, so the remote endpoint must forward them back. If keepalives fail, the tunnel interface is brought down, allowing the routing protocol to select an alternate path. Default: 10-second interval, 3 retries.
• BFD over GRE: BFD sessions run over the tunnel interface, providing sub-second liveness detection independent of the routing protocol timers.

Real Uses of GRE

Connecting islands. Two office sites connected via an ISP that does not carry your routing protocol or your multicast traffic. A GRE tunnel between the two edge routers creates a virtual direct link. OSPF, BGP, or PIM can run over the tunnel as if the sites were directly connected.

Carrying multicast where IPsec cannot. DMVPN (Dynamic Multipoint VPN) uses mGRE (multipoint GRE) combined with NHRP (Next Hop Resolution Protocol) and IPsec. Spoke sites form GRE tunnels to the hub and optionally build direct spoke-to-spoke tunnels on demand. Because the outer transport is GRE, multicast routing protocols can distribute updates across the entire VPN, something impossible with pure IPsec.

DDoS scrubbing return path. A common architecture for DDoS mitigation is to divert attack traffic to a scrubbing center (via BGP blackholing or more selective BGP manipulation), clean it, and return the clean traffic to the origin via a GRE tunnel. The scrubbing center decapsulates the GRE and delivers clean packets to the origin, which sees the traffic arriving from its own address space as if the scrubbing center were a router on the path.

Overlay networks. Before VXLAN became dominant, GRE was the encapsulation of choice for OpenStack Neutron's tenant network overlays. Modern systems prefer VXLAN (which uses UDP, hardware-offloadable) over GRE (which uses IP protocol 47, harder to load-balance in hardware), but GRE remains widely deployed in existing installations.

mGRE and DMVPN

Standard point-to-point GRE requires a separate tunnel interface for each peer — in a hub-and-spoke network of 100 spokes, that means 100 tunnel interfaces on the hub. mGRE (Multipoint GRE) allows a single tunnel interface to dynamically communicate with any peer. Combined with NHRP, which resolves tunnel endpoint addresses on demand, this enables DMVPN — a scalable hub-and-spoke VPN architecture where spoke-to-spoke traffic can bypass the hub entirely using dynamic direct tunnels.

GRE vs. VXLAN vs. WireGuard

VXLAN's use of UDP is a deliberate choice: network hardware can ECMP UDP flows using the 5-tuple (src IP, dst IP, src port, dst port, protocol), so VXLAN traffic distributes across ECMP paths naturally. GRE's IP protocol 47 has no L4 header, making 5-tuple hashing impossible — hardware must fall back to src/dst IP only, severely limiting load distribution in Clos fabrics.

WireGuard is increasingly used where GRE-over-IPsec was previously deployed, offering simpler configuration, modern cryptography, and similar UDP-based transport, but it does not carry multicast and has a different operational model.

Explore It Live

GRE tunnels appear in many ISP and enterprise networks. You can examine the routing that GRE tunnels complement by looking up autonomous systems that operate large VPN or scrubbing-center infrastructures:

• AS3356 — Lumen/Level 3 (major transit provider whose network underlies many GRE scrubbing deployments)
• AS6939 — Hurricane Electric (well-known for GRE-tunneled IPv6 transit offerings)
• AS13335 — Cloudflare (uses GRE return paths for Magic Transit DDoS scrubbing)