GRE Tunnels

GRE is a disguise. It takes a packet that can't travel somewhere and dresses it up as a packet that can.

That's the core insight behind Generic Routing Encapsulation. You have a packet—maybe IPv6, maybe a routing protocol update, maybe multicast video—that needs to cross a network that doesn't understand it. GRE wraps that packet inside a normal IP packet, and suddenly it can go anywhere IP can go.

The Envelope Inside an Envelope

Imagine putting a letter in an envelope, then putting that envelope inside another envelope with completely different addressing. The postal service only sees the outer envelope. They deliver it based on the outer address. When it arrives, the recipient opens the outer envelope, finds the inner envelope, and delivers that to its actual destination.

That's GRE. The "outer envelope" is a standard IP packet that routers know how to forward. The "inner envelope" is whatever you're actually trying to send. Intermediate routers never see inside—they just forward the outer packet like any other.

What a GRE Packet Looks Like

The structure is straightforward:

• Outer IP header: Source and destination are the tunnel endpoints
• GRE header: Identifies what type of packet is inside (4 bytes minimum)
• Inner packet: The original packet you're transporting, headers and all

When the packet reaches the tunnel endpoint, that router strips off the outer IP header and GRE header, then processes the inner packet as if it had just arrived normally. The disguise comes off, and the packet continues on its way.

The GRE header itself is remarkably minimal. Two bytes of flags and version, two bytes identifying the payload type (IPv4, IPv6, or dozens of other protocols). Optional fields can add checksums, keys for distinguishing multiple tunnels, or sequence numbers—but most implementations skip these and keep the header at 4 bytes.

Point-to-Point: One Tunnel, Two Endpoints

Every GRE tunnel connects exactly two points. You configure each end with the other's IP address, and that's it. Packets entering the tunnel always get wrapped with those same source and destination addresses.

This simplicity has a cost. Connecting three sites requires three tunnels. Four sites? Six tunnels. Ten sites in a full mesh? Forty-five tunnels. The math scales quadratically, which is why large networks use technologies like DMVPN that create tunnels dynamically rather than configuring each one manually.

GRE vs. IPsec: Different Jobs

People often confuse GRE and IPsec because both involve tunnels. But they solve different problems:

GRE is about encapsulation. It wraps packets so they can traverse networks that don't understand them. It provides zero security—no encryption, no authentication, nothing. Anyone who can capture GRE packets can read their contents.

IPsec is about security. It encrypts and authenticates packets. It can also tunnel (in tunnel mode), but security is the point.

These protocols complement each other. A common enterprise pattern is "GRE over IPsec": GRE provides the tunnel that routing protocols and multicast can traverse, while IPsec encrypts everything so the Internet can't see inside. You get the best of both.

Why GRE Matters: Routing Protocols and Multicast

Here's where GRE becomes valuable: it makes the tunnel look like a regular network interface.

Run OSPF over a GRE tunnel? The routers exchange routing updates as if they were directly connected. The tunnel is just another link in the topology. Routes can change dynamically without anyone manually updating static routes.

Need to send multicast traffic across a network that doesn't support multicast? The GRE tunnel carries it. The multicast packets get wrapped in unicast GRE packets between the endpoints, appearing on the other side as multicast again.

This is GRE's real power. It doesn't just move packets—it extends network services across gaps in infrastructure.

The MTU Problem

GRE adds overhead: 4 bytes for the GRE header, 20 bytes for the outer IPv4 header. That's 24 bytes added to every packet.

If your original packet is already at the network's maximum transmission unit (typically 1500 bytes), the GRE packet will be 1524 bytes—too large. It either gets fragmented (bad for performance) or dropped (if the Don't Fragment flag is set).

The solution: reduce the MTU on the tunnel interface. Set it to 1476 bytes (1500 minus 24), and packets will fit after encapsulation. If you're running GRE over IPsec, you need even more headroom for IPsec's overhead.

GRE and NAT: An Awkward Combination

GRE doesn't play well with NAT.

NAT works by rewriting port numbers—but GRE packets don't have port numbers. They use IP protocol 47, which NAT can't translate the way it translates TCP or UDP. Multiple GRE tunnels can't easily share a single public IP address.

Some NAT implementations include special handling for GRE, translating the optional key field like a port number. But this requires the key field to be enabled and doesn't work everywhere. If you need tunnels through NAT, L2TP (which uses UDP) or IPsec with NAT traversal are more reliable options.

Security: GRE Has None

This bears repeating: GRE provides no security whatsoever.

No encryption. No authentication. No replay protection. A GRE packet crossing the Internet is visible to anyone who can capture it. Attackers can read the contents, inject fake packets, or modify traffic in transit.

For any tunnel crossing untrusted networks, combine GRE with IPsec. Even on private networks, consider whether extending the tunnel extends your trust boundary further than intended.

Troubleshooting GRE Tunnels

Tunnel up, but no traffic flows: Check that the underlying IP path works and that firewalls aren't blocking IP protocol 47. Many firewalls block GRE by default.

Large packets fail, small packets work: MTU issue. Reduce tunnel MTU or enable Path MTU Discovery.

Intermittent failures: The underlying network path may be unstable. GRE tunnels depend entirely on the reliability of the path between endpoints. Many implementations add keepalive packets to detect failures—if keepalives fail, the tunnel interface goes down and routing protocols can react.

Routing loops: Traffic sent into a tunnel gets routed back into the same tunnel. This usually means your routing design needs work—check metrics and administrative distances carefully.

When to Use GRE

GRE makes sense when you need to:

• Run routing protocols (OSPF, EIGRP, BGP) across networks you don't control
• Transport multicast or broadcast traffic over infrastructure that doesn't support it
• Connect IPv6 networks across IPv4-only infrastructure
• Build overlay networks where logical topology differs from physical
• Link cloud VPCs to on-premises networks with full routing integration

For simple site-to-site connectivity where you just need encrypted access, IPsec alone may be simpler. GRE adds value when you need the tunnel to behave like a real network link—participating in routing, carrying multicast, acting as part of the network fabric rather than just a pipe.