On this page
Key points
- GRE is not the mitigation layer itselfIt is mostly a clean traffic delivery model after upstream mitigation.
- It often avoids a forced migrationA strong fit when you want to keep an existing server at another provider.
- Its limits are mostly operationalMTU, tunnel overhead, return path and endpoint capacity all matter.
- Use case decides everythingGaming, SaaS, APIs and network frontends do not all need the same handoff model.
Problem definition
When a service is exposed to the Internet, the challenge is not only to filter the DDoS attack. You also need a reliable way to hand legitimate traffic back to the real destination. Many teams already run a production server, proxy, cluster or frontend somewhere else and want to add protection without rebuilding everything.
That is where a GRE tunnel comes in. Traffic reaches the mitigation layer first, gets cleaned there, then legitimate flows are encapsulated and sent back to the customer endpoint. The goal is simple: stop the noise upstream and deliver usable traffic to production.
Why it matters
In many real incidents, the application does not fail first. The link saturates, latency rises, queues grow and the frontend becomes unstable before the business logic can react. Useful mitigation is not only about filtering the attack, but about handing legitimate traffic back in a stable and operable way.
It also matters because many customers do not want to move an already working environment under pressure. GRE often becomes the practical middle ground between doing nothing and migrating everything.
- Preserve the existing stack
- Keep the server or proxy where it already runs.
- Reduce friction
- Add network protection before discussing a larger redesign.
- Reduce risk
- A clean handoff is often safer than an emergency migration.
- Deploy faster
- A well-planned GRE delivery model can go live quickly.
Possible models
GRE is not the only post-mitigation delivery model. The right decision depends on who announces the IP space, where clean traffic should terminate and how much routing control the customer wants to keep.
| Model | Benefits | Limits | Typical fit |
|---|---|---|---|
| Simple GRE tunnel | Fast to deploy and low-friction | Less routing flexibility than a full BGP setup | Dedicated servers, gaming, APIs, SaaS |
| GRE + BGP | More control over announcements and routing | More advanced integration work | Operators and customers with their own prefixes |
| Protected IPs + GRE handoff | Good way to start fast | May not preserve original addressing at first | Trials and progressive rollouts |
| Cross-connect / direct handoff | Very clean for colocated environments | Less relevant for remote third-party hosting | Datacenter presence and operator-style designs |
- RFC 2784 — GRE
Base GRE specification.
- RFC 2890 — GRE extensions
Key and sequence extensions for GRE.
When GRE is relevant — and when it is not
GRE is highly relevant when you want to protect an existing server, keep your production where it already runs and accept a clean L3 handoff. It is less relevant when you mainly need a local datacenter cross-connect model or when the final endpoint itself is too weak to handle the clean traffic.
- Relevant
- Existing third-party hosted server, quick integration, clean L3 delivery.
- Very relevant
- Production service already online and hard to migrate quickly.
- Less relevant
- You primarily need a direct local datacenter handoff.
- Not enough on its own
- The final server is already undersized or the return path is not understood.
Our approach
- Quick review of IPs, routes, MTU and endpoint capacity.
- Choice of delivery model: GRE, GRE + BGP, protected IPs or another handoff.
- Validation before production cutover.
- Progressive rollout when needed.
Concrete use case
A gaming operator already runs everything on a dedicated server at another provider. The main goal is to stop repeated DDoS attacks from saturating the link while keeping the current server and application stack in place. In that scenario, sending clean traffic back through GRE after mitigation is often the best compromise.
Understand the service
Ports, latency sensitivity and desired delivery model are identified.
Prepare the GRE endpoint
MTU, firewall, return path and NIC behavior are validated.
Filter then hand off
Only legitimate traffic is delivered back through GRE.
Evolve later if needed
The setup can remain simple or move toward a richer routing model.
Common mistakes
The biggest mistake is to think GRE is the complete Anti-DDoS strategy. It is only a delivery method after mitigation. Another common mistake is to ignore MTU, fragmentation, return-path behavior and endpoint sizing.
- Picking GRE by habit without validating alternatives.
- Ignoring MTU and fragmentation issues.
- Forgetting the return path.
- Assuming the tunnel fixes an undersized endpoint.
FAQ
Is GRE mandatory for Anti-DDoS?
No. It is a common and useful handoff model, but not the only one.
Can I protect a dedicated server without migrating it?
Yes. That is one of the main strengths of a GRE handoff model.
When do I need GRE + BGP?
Mainly when you need more routing control or want to announce your own prefixes.
