GRE tunnels, how scrubbing services route traffic through their network

When a DDoS protection service "absorbs" attacks on your behalf, the actual mechanism usually involves a GRE tunnel: a virtual point-to-point link between your real server and the protection service's network. Cleaned traffic comes out the other side.

GRE tunnels are also used in VPNs, in some cloud network setups, and in many other "wrap-this-traffic-and-send-it-somewhere" scenarios. This article explains what they are and why they matter.

The basic idea

Sometimes you want to make a remote network appear as if it's directly connected to yours. A wire across the building works. A wire across the world doesn't.

Tunneling is the answer. You wrap your packets inside other packets and send them across the public internet, with the outer packets handling the cross-internet trip. At the other end, the wrapping is stripped off and the original packets emerge as if they'd just traveled a short hop.

GRE (Generic Routing Encapsulation, RFC 2784) is one of the simplest tunneling protocols. It wraps an arbitrary packet in a small GRE header and an outer IP header. The result rides across any IP network.

How DDoS scrubbing actually works

Game traffic goes through the scrubber, gets cleaned, arrives at your origin via the GRE tunnel. Origin's real IP is never exposed to attackers.

How a GRE tunnel works

Setup:

• Endpoint A is at IP 203.0.113.1.
• Endpoint B is at IP 198.51.100.1.
• Each side is configured with a GRE tunnel pointing at the other.

When A wants to send a packet to a destination inside B's network:

1. A creates the original packet (say, going to 10.0.0.5).
2. A wraps this inside an outer IP packet from 203.0.113.1 to 198.51.100.1, with a GRE header in between.
3. The wrapped packet travels the internet to B.
4. B receives it, sees the GRE header, strips off the outer wrapping.
5. B processes the inner packet (which destined 10.0.0.5, which is on B's network).
6. B forwards to the local destination.

Effectively, A's network and B's network are connected as if by a wire, even though the actual data has crossed the public internet.

What GRE looks like on the wire

A GRE-wrapped packet structure:

The 20-byte overhead is the outer IP header plus GRE bookkeeping. Inside is your original packet, untouched. The outer IP and GRE headers add 24 bytes of overhead. So a 1500-byte original packet becomes a 1524-byte tunneled packet. This causes MTU problems if the network can't handle the larger size. We have a dedicated MTU article in this series for the details.

Why GRE is used for DDoS protection

A common DDoS protection model:

1. You point your DNS at an IP belonging to the protection service.
2. The protection service receives all your traffic at its scrubbing centers.
3. The service filters out attack traffic. Clean traffic remains.
4. The service forwards clean traffic to you via a GRE tunnel.

The tunnel preserves the source IP of the original requester (so your server sees real visitor IPs, not the protection service's). It also lets your real server be invisible to the public internet (your true IP isn't advertised; attackers can't bypass the scrubber).

This works because:

• Attack traffic targets the protection service's IP, which is hardened for DDoS.
• Your real server only ever sees scrubbed traffic, via the tunnel.
• If the attack overwhelms the protection service, your service degrades but your network doesn't collapse.

Alternatives to GRE

GRE is the classic. Several alternatives exist:

IP-in-IP. Slightly simpler than GRE. Less commonly used today.

VXLAN. Network virtualization protocol. More features than GRE, more overhead. Common in cloud data center networking.

GENEVE. Newer encapsulation, designed to be extensible. Used by some cloud providers.

WireGuard / IPsec. Encrypted tunnels. Use when traffic needs encryption end-to-end, not just transit.

SD-WAN solutions. Higher-level products that often use GRE or similar underneath, with management UI on top.

For DDoS protection specifically, GRE is dominant because it's simple, well-supported, and doesn't add encryption overhead (the protection service inspects traffic anyway, so encryption between scrubber and origin isn't useful).

A specific scenario

Imagine you run a game server with a real IP of 192.0.2.10. You're under attack.

You sign up for a protection service. They give you:

• A protected IP: 198.51.100.42 (their IP, anycast).
• A GRE tunnel endpoint: 203.0.113.99 (their tunnel server).
• Configuration instructions for your server.

You:

• Update DNS so play.myserver.com resolves to 198.51.100.42 (the protected IP).
• Configure a GRE tunnel on your server: local endpoint 192.0.2.10, remote endpoint 203.0.113.99.
• Configure routing: traffic for users should leave via the GRE tunnel.

Now:

• Players resolve play.myserver.com to 198.51.100.42.
• They send packets to that IP.
• The protection service receives them, scrubs them, wraps them in GRE, sends them through the tunnel to you.
• Your server sees them as if they arrived directly (with original source IPs preserved).
• You respond. Your response goes back through the GRE tunnel.
• The protection service receives your response on its tunnel side, unwraps it, and sends it directly to the player.

To the player, nothing changed. To an attacker, your real IP is invisible. To your server, traffic looks normal.

The MTU problem

Because GRE adds 24 bytes to each packet, the effective MTU through the tunnel is 1476 bytes (instead of 1500).

Packets larger than 1476 inside the tunnel can't traverse it without fragmentation. If fragmentation is blocked (which some networks do), the packet is dropped silently. The application sees connections that "work for small data and break for large data."

Common fixes:

• Adjust TCP MSS clamping. Force TCP connections through the tunnel to use a smaller MSS, so packets stay under the tunnel MTU.
• Allow ICMP "fragmentation needed" messages. This lets Path MTU Discovery work.
• Use a tunnel with larger underlying MTU (jumbo frames on the underlying network).

This is a classic source of "tunnel works fine except for one specific user" complaints. The cause is usually MTU.

GRE keepalives

GRE has no built-in mechanism for detecting whether the tunnel is still working. If the other end goes down, your side might happily keep sending packets into a black hole.

Some implementations add keepalive mechanisms (often via small probe packets). When keepalives fail, the tunnel is marked down and routing fails over.

For production deployments, configure keepalives. Don't rely on bare GRE for critical paths.

Performance characteristics

GRE adds some overhead beyond the 24 bytes:

• Encapsulation/decapsulation CPU. Modern hardware routers do this at line rate. Software routers (Linux boxes) can hit limits at high traffic.
• No encryption, no compression. Pure overhead.
• No reliability or retransmission. Same as the underlying IP.

For DDoS protection scenarios, GRE's lightweight nature is the point. You don't want encryption or reliability overhead between the scrubber and origin; you want maximum throughput with minimum complexity.

Security considerations

GRE is plaintext. Anyone watching the underlying network can see the tunneled traffic.

For DDoS protection: usually fine. The scrubber and origin are operating in known networks, and the protection service is trusted. Plus, anything sensitive should be HTTPS or otherwise encrypted at higher layers.

For VPNs across the internet: GRE alone is insufficient. Wrap GRE inside IPsec, or use a protocol like WireGuard that has built-in encryption.

GRE also has no authentication. If you forget to filter, anyone can send packets to your GRE endpoint and they'll be unwrapped and processed. Always firewall GRE endpoints to accept traffic only from expected peers.

When you'd choose GRE manually

For most administrators, GRE tunnels are an "as configured by my upstream service" thing. The protection service tells you exactly how to set up your end.

You might configure GRE yourself if:

• You're running your own multi-site network and want to link sites at layer 3.
• You're testing or developing protocols that need tunneling.
• You're building a custom DDoS mitigation infrastructure.

For ordinary hosting operations: GRE is a tool used by services you buy, not something you build often.

Why this matters for game servers

A game server connected via GRE to a protection service has specific traits:

Slightly higher latency than direct internet. The tunnel adds at least one extra hop. Often 1-5 ms of additional RTT.

Source IP visibility preserved. Players' real IPs reach the server (important for moderation, geo-restriction, log review).

Real IP hidden. Attackers can't bypass the scrubber by attacking your server's true IP directly.

Single point of failure (the tunnel). If the tunnel breaks, players can't reach the server even though both sides are up.

MTU sensitivity. Game protocols using larger packets may need MTU tuning.

For most game servers behind reputable protection services, GRE works fine. The latency hit is usually small. The protection benefit is meaningful.

Conclusion

GRE tunnels are an old, simple, robust technology that the modern internet uses everywhere: DDoS protection, multi-site networks, certain cloud architectures. They wrap one IP packet inside another and send it across the public internet, creating virtual point-to-point links.

For most users, GRE is invisible. For administrators of services using DDoS protection, GRE is the actual mechanism by which the protection works. Understanding it helps you debug strange MTU issues and reason about your network's actual architecture.

Coming up

Next we step out of "fancy network engineering" and into a problem that affects ordinary internet users: CGNAT, the carrier-grade NAT that's slowly degrading the open internet for residential users.