What is GRE tunneling?

How encapsulation works

A normal packet has one IP header saying where it came from and where it is going. GRE adds an outer header around the whole original packet, so the original becomes payload.

The outer header addresses the tunnel endpoints — the provider's router and yours. Routers in between only see that outer header and forward it like any other traffic, with no knowledge of what is inside. When it reaches your end, the outer header is stripped and the original packet is processed as if it had arrived directly.

The result is a virtual point-to-point link between two networks that may be far apart, without either party needing a physical circuit to the other.

┌─────────────── outer IP header ───────────────┐
│ src: provider edge   dst: your tunnel endpoint │
│  ┌────────────── GRE header ──────────────┐   │
│  │  ┌────────── original packet ────────┐ │   │
│  │  │ src: visitor   dst: your service  │ │   │
│  │  └───────────────────────────────────┘ │   │
│  └────────────────────────────────────────┘   │
└───────────────────────────────────────────────┘

Why DDoS protection uses it

Protecting a non-HTTP service means getting its traffic to a filtering network first. DNS cannot do that — a DNS record points a name at an address, but the packets still go wherever that address routes. GRE solves the delivery problem: the provider advertises the protected addresses, so all traffic for them arrives at the scrubbing network first.

Once filtered, the clean traffic has to reach your actual machine, which is somewhere else entirely and has a different address. The tunnel carries it there. From your server's point of view the packets arrive with their original source addresses intact, so logging, geolocation and application logic all keep working normally.

• Works for any protocol, including UDP, which no HTTP proxy can handle
• Your hardware stays where it is — no migration required
• Original client addresses are preserved, so your logs stay meaningful
• The origin address is never published, so it cannot be attacked directly

Your own addresses, or the provider's

There are two ways to run this. With BYOIP (bring your own IP), you own an address range and authorise the provider to announce it on your behalf. Your addresses stay yours, which matters if they are baked into client configurations, allowlists or DNS you do not control.

Alternatively the provider assigns you addresses from their own range. This is faster to set up and requires no address ownership, but the addresses are not portable — if you leave, you renumber.

Practical considerations

GRE adds 24 bytes of overhead per packet, which reduces the usable MTU. If that is not accounted for, large packets fragment or are dropped outright — the classic symptom is that small requests work perfectly while large uploads or TLS handshakes hang. Setting the MTU and clamping TCP MSS on the tunnel interface avoids it.

GRE also provides no encryption or authentication of its own; it is a delivery mechanism, not a security protocol. That is not usually a problem here because the payload is ordinary internet traffic that was never private in the first place, but it is worth being explicit about.