skip to content

What does GRE, IP protocol 47, do to a packet, and why is a plain GRE tunnel across the internet not private?

level: juniorimportance: should knowfreq 30%

answer

  1. an envelope, not a safe
  2. delivery header, GRE header, payload
  3. Protocol Type is an EtherType
  4. the Key field identifies, never authenticates

basics

~20 s

GRE wraps any packet, multicast and non-IP included, in a 4-byte GRE header and a new IPv4 header marked protocol 47. It adds no encryption or authentication, so anyone on the path can read or forge what it carries.

solid answer

~50 s

GRE (RFC 2784) is generic encapsulation. The sending router puts a 4-byte header in front of the payload packet — a Checksum Present bit, reserved bits, `Ver` = 0 and a 16-bit `Protocol Type` holding the payload's EtherType, `0x0800` for IPv4 — and then a delivery IPv4 header whose protocol field is `47`. Because the payload is just bytes behind a type code, GRE carries multicast, routing-protocol traffic and non-IP protocols between two routers as easily as unicast. What it does not do is protect anything: there is no encryption and no peer authentication, the optional checksum only catches corruption, and RFC 2890 states that its `Key` field is not involved in security despite the name. A plain GRE tunnel over the internet is readable and forgeable, which is why it is run inside IPsec.

go deeper

for a junior

Recall that GRE is IP protocol 47, adds a small header naming the payload type, carries almost anything including multicast, and encrypts nothing.

for a middle

Walk the header field by field: the Checksum Present bit, Ver 0, the EtherType in Protocol Type, and the optional Key and Sequence Number fields from RFC 2890, saying why Key is not security.

for a senior

Explain what an on-path or spoofing attacker gains against plain GRE, why the checksum and Key do not stop it, and where filtering or IPsec closes the gap.

for a principal

Judge when an unencrypted GRE overlay is acceptable, for example inside a private transport you already trust, against the operational cost of running IPsec on every tunnel.

## The three layers of a GRE packet **Generic Routing Encapsulation (GRE)**, specified in RFC 2784 and extended by RFC 2890, solves one problem: carrying a packet of *some* network protocol across a network of *another* (or the same) protocol. RFC 2784 names the parts: 1. The **payload packet** — the original packet the router wants to send, for example an IPv4 packet from `10.1.0.5` to `10.2.0.9`. 2. The **GRE header**, which says what kind of packet the payload is. 3. The **delivery header** — a new outer header that gets the whole thing to the far tunnel endpoint. With IPv4 delivery, its protocol field is **47** (RFC 2784 section 4), and its addresses are the two routers' public addresses, for example `198.51.100.1` to `203.0.113.2`. The routers in the middle of the internet route only on the delivery header. To them the tunnel is ordinary unicast IPv4 between two hosts. ## The header, field by field | Field | Size | What it carries | |---|---|---| | `C` (Checksum Present) | 1 bit | When set, the `Checksum` and `Reserved1` fields follow | | `Reserved0` | 12 bits | Sent as zero; RFC 2890 reuses bit 2 as Key Present and bit 3 as Sequence Number Present | | `Ver` | 3 bits | Must be **0** for GRE as RFC 2784 defines it | | `Protocol Type` | 16 bits | The payload's **EtherType**: `0x0800` for IPv4, `0x86DD` for IPv6 (RFC 7676) | | `Checksum` + `Reserved1` | 4 bytes, optional | A one's-complement checksum over the GRE header and payload | | `Key` | 4 bytes, optional (RFC 2890) | A number identifying one traffic flow within the tunnel | | `Sequence Number` | 4 bytes, optional (RFC 2890) | A counter that lets the receiver detect loss and restore order | The base header is therefore **4 bytes**, and each optional field adds 4 more. When the far router decapsulates an IPv4 payload, RFC 2784 section 3.1 requires it to forward on the payload's own destination address and to decrement the payload's TTL — the tunnel looks like a single hop. ## What GRE makes possible - **Any payload.** Because the payload is identified by an EtherType, the same tunnel can carry IPv4, IPv6 or a non-IP protocol. - **Multicast and routing protocols.** A routing protocol's multicast hello is just a payload; inside GRE it travels as unicast between two public addresses, so two routers can form a routing adjacency across a network that would never forward that multicast. - **A point-to-point link.** Implementations present the tunnel as an interface, so routing treats the far router as a directly connected neighbour. - **No state.** RFC 2784 defines no handshake and no keepalive. A tunnel exists because both ends are configured; liveness is left to implementations or to the routing protocol running inside. ## What GRE does not do - **No confidentiality.** The payload is copied verbatim behind the GRE header. Anyone on the path who captures protocol 47 reads the inner addresses, the routing updates and whatever the applications sent in clear. - **No authentication.** Nothing proves a GRE packet came from the configured peer. An attacker who can send packets with the peer's source address can inject payloads into the tunnel, unless the network filters spoofed sources. - **The `Key` field is not a key.** RFC 2890 section 3 says the Key field "is not involved in any sort of security (despite its name)" — it only tells flows apart. - **The checksum is not integrity protection.** It detects accidental corruption; an attacker who changes the payload simply recomputes it. - **Sequence numbers can be abused.** RFC 2890 warns that forged sequence numbers can be injected to deny service, and requires ESP or AH to protect the GRE header when the Sequence Number field is used. RFC 2784's security considerations add an operator's point: route filtering is unchanged, but packet filtering must either look inside the GRE packet or happen at the tunnel endpoints, and terminating the tunnel at the firewall may be the answer. ## Version 0 and version 1 RFC 2784 defines GRE **version 0** and records that **version 1** is used by PPTP (RFC 2637), a legacy remote-access protocol with its own enhanced GRE header. A version-0 site-to-site tunnel and PPTP's data channel share protocol number 47 but not their header layout. ## Why it ends up paired with IPsec GRE supplies what a routed overlay needs — any payload, multicast, an interface for routing — and nothing it needs to be private. IPsec supplies confidentiality, integrity and peer authentication for unicast IP but, in its policy-based form, no interface for a routing protocol to run on. Putting the GRE packets inside IPsec gives two branches both, which is the subject interviewers most often reach next.

  • Why does the GRE Protocol Type field use EtherType values?
    RFC 2784 reuses the EtherType registry so any protocol that already has an EtherType can be carried without a new numbering space: `0x0800` for IPv4, `0x86DD` for IPv6 under RFC 7676. A receiver that sees a type it does not recognise SHOULD discard the packet.
  • How does a firewall between the two sites see a plain GRE tunnel?
    As unicast IPv4 protocol 47 between two addresses, with no ports. RFC 2784 notes that filtering the inner traffic requires the firewall to look inside the GRE packet or the filtering to happen at the tunnel endpoints, and suggests terminating the tunnel at the firewall where that matters.
  • Is PPTP's GRE the same protocol as a site-to-site GRE tunnel?
    No. RFC 2784 defines version 0 and records version 1 as PPTP's (RFC 2637), which uses its own enhanced header. Both use IP protocol 47, so a capture filter on protocol 47 alone does not tell them apart; the `Ver` field does.

GRE is a clear plastic mailing sleeve: the post office reads only the address printed on the sleeve to deliver it, but anyone who handles it can read the letter inside, and anyone can post a sleeve bearing your return address.

saying these in an interview costs you the question

  • GRE encrypts the traffic between the two tunnel endpoints.
  • The GRE Key field is a shared secret that authenticates the peer.
  • GRE runs over UDP, so the firewall needs a port opened for it.
  • GRE can only carry unicast IPv4 packets.
  • The GRE checksum stops an attacker from altering the payload.