What is GRE Tunneling? | How GRE protocol works

Generic Routing Encapsulation (GRE) tunneling is a protocol that encapsulates packets to enable point-to-point network connectivity.

GRE is an IP tunneling protocol that encapsulates an inner packet (often IP) inside a GRE header and an outer IP header.

It creates a virtual point-to-point interface between endpoints so you can route traffic between networks as if they were directly connected.

When to use GRE

  • You need a simple routed tunnel between two routers/firewalls over an IP network.
  • You want to run routing protocols (e.g., OSPF, BGP, EIGRP) across the tunnel.
  • You need to carry multicast or non-TCP/UDP traffic through a tunnel (depending on platform support).
  • You need a “transport” for overlay designs (lab environments, interconnects, controlled networks).
  • You plan to add encryption separately (commonly GRE over IPsec).

When not to use GRE

  • You need encryption or authentication by default (GRE alone is not secure).
  • You want NAT-friendly tunneling without extra work (GRE can be harder across NAT/firewalls).
  • You need minimal overhead and best performance (GRE adds headers and can trigger fragmentation).
  • You want user-access VPN behavior (GRE is typically site-to-site/router-to-router, not end-user VPN).
  • Your network blocks IP protocol 47 (GRE is IP protocol number 47, not TCP/UDP).

Signals you need GRE

  • You have two private networks that must communicate over the internet, and you want it to behave like a routed link.
  • You need to extend routing adjacency across a provider/transit network you don’t control.
  • Your current solution requires static routes everywhere, and you want dynamic routing between sites.
  • You must transport traffic types that don’t fit cleanly into TCP/UDP-only tunnels.

How GRE tunneling works (step-by-step)

  1. A router receives an inner packet (e.g., an IP packet destined for the remote network).
  2. The router encapsulates that packet with a GRE header (to identify payload type) and an outer IP header (with tunnel endpoint IPs).
  3. The internet/transit network routes the packet using the outer IP header only.
  4. The remote endpoint decapsulates the packet, removes the GRE + outer IP headers, and forwards the original inner packet toward its destination.

What’s inside the packet (conceptually)

  • Outer IP header: source/destination = tunnel endpoints
  • GRE header: indicates what protocol is carried inside
  • Inner packet: the original packet you want to transport (often IP)

Key features (what GRE is good at)

  • Virtual point-to-point link semantics (a tunnel interface behaves like a routed interface).
  • Protocol encapsulation capability (commonly IP-in-IP via GRE; some platforms support additional payloads).
  • Works well with dynamic routing across the tunnel.
  • Simple design: often easier to deploy than more feature-heavy overlays.

Limitations (what GRE does not do)

  • No encryption and typically no strong authentication on its own.
  • Extra overhead can reduce effective MTU and cause fragmentation.
  • Firewall/NAT traversal can be problematic because GRE is IP protocol 47 (not port-based).
  • Operational complexity grows with many tunnels (mesh designs can become hard to manage).

Metrics and how to measure

  • Tunnel availability
    • Measure: interface status, keepalive status (if used), endpoint reachability.
  • Latency (RTT) across the tunnel
    • Measure: ping to inner tunnel IPs and to remote subnets; track baseline vs. spikes.
  • Packet loss
    • Measure: continuous pings, synthetic probes, flow monitoring.
  • MTU / fragmentation
    • Measure: path MTU discovery results; test with DF-bit pings.
  • Throughput
    • Measure: iperf3 between sites; compare with and without encapsulation.
  • Route stability
    • Measure: routing protocol adjacency flaps, route churn, convergence time.

Common mistakes (and fixes)

  • Mistake: MTU not adjusted → fragmentation or blackholing
    • Fix: lower tunnel MTU (or MSS clamp) to account for GRE overhead; verify PMTUD.
  • Mistake: Missing routes to the tunnel destination
    • Fix: ensure the outer destination IP (remote endpoint) is reachable in the underlay.
  • Mistake: Asymmetric routing
    • Fix: verify return path uses the tunnel as intended; check policy routing and route metrics.
  • Mistake: Firewall blocks GRE
    • Fix: allow IP protocol 47 and any required ICMP for PMTUD; validate intermediate devices.
  • Mistake: Expecting confidentiality
    • Fix: use GRE over IPsec (or another encrypted tunnel technology) if data must be protected.

Common GRE tunnel issues (quick troubleshooting list)

  • Endpoint IPs wrong or mismatched tunnel source/destination
  • Underlay routing failure between public endpoint IPs
  • MTU/MSS problems leading to intermittent application failures
  • Routing protocol neighbors not forming (timers, ACLs, multicast handling)
  • Security devices dropping GRE (protocol 47) or related ICMP

Mini FAQ

Q: Is GRE a VPN? A: GRE is a tunneling mechanism. By itself it is not an encrypted VPN; it’s often combined with IPsec to make a secure site-to-site VPN.

Q: Does GRE encrypt traffic? A: No. GRE provides encapsulation, not encryption. Use GRE over IPsec if encryption is required.

Q: What ports does GRE use? A: GRE does not use TCP/UDP ports. It uses IP protocol number 47.

Q: Why does GRE break some applications? A: Common causes are MTU/fragmentation issues or blocked ICMP needed for path MTU discovery.

Q: When should I prefer IPsec-only vs GRE over IPsec? A: Use IPsec-only when you just need encryption for IP traffic. Use GRE over IPsec when you need routing protocols, multicast, or more flexible encapsulation in addition to encryption.

How this applies in practice

  • Branch-to-HQ connectivity: GRE provides a routed link so sites can exchange routes dynamically.
  • Interconnecting networks across the internet: encapsulate private traffic and route it between sites.
  • Overlay routing: build an overlay where the underlay only needs to deliver packets between GRE endpoints.

How to implement on Azion

If you’re implementing tunneling, connectivity, or edge networking patterns, keep the learning model above (encapsulation, MTU, observability, and security layering) and apply it with Azion’s web networking capabilities and documentation:

Glossary

  • Encapsulation: wrapping one packet inside another for transport.
  • Underlay: the real IP network carrying the outer packets.
  • Overlay: the virtual network formed by tunnels (like GRE).
  • Endpoint: device that encapsulates/decapsulates GRE traffic.
  • MTU: maximum packet size before fragmentation occurs.

Related Content

Community