A practical guide for protecting a production dedicated server hosted at OVH, Hetzner or another provider without migrating the whole stack, using GRE with or without BGP.
Protection without full migration
You can add an anti-DDoS layer without rebuilding the whole production environment.
A GRE tunnel is often quicker to deploy than a full migration project.
Tunnel only, GRE + BGP or protected IPs: the right design depends on your architecture.
MTU, return path, routing and actual server capacity all need proper validation.
Many companies, gaming operators, SaaS platforms and Internet-facing services already run their infrastructure on dedicated servers hosted by OVH, Hetzner or similar providers. When DDoS attacks start, the first idea people hear is often: migrate everything. In practice, that is neither the only option nor always the smartest one.
In many cases, an anti-DDoS design based on GRE, with or without BGP, makes it possible to protect the service while keeping the server where it already runs. The question is therefore not only how to block the attack, but how to choose a realistic, stable and production-friendly delivery model.
The most common scenario is straightforward: the customer already has a dedicated server at Hetzner, OVH or a similar provider. Services are live, IPs are already in production, backups exist, monitoring works and other machines may already depend on that environment.
When DDoS attacks become recurrent, the problem is not only at application level. The link may saturate before the application can react, latency increases, user experience degrades and an emergency migration often creates more risk than stability.
That is exactly the kind of case where protection through GRE, with or without BGP, becomes relevant: an upstream mitigation layer is added without breaking the existing production stack.
Moving the whole infrastructure may sound logical on paper, but production reality is different. Customers often need to preserve network dependencies, operating habits, scripts, licenses, inter-server flows and sometimes commercial or contractual constraints.
The rational goal is therefore not to move everything by default. The goal is to add effective protection without creating unnecessary operational risk.
Rebuilding a full architecture during an attack period or instability window is rarely the best move.
The customer keeps servers, workflows, storage, monitoring and local dependencies.
A properly integrated GRE tunnel is often faster to deploy than a full production move.
You can start by protecting one exposed service, then extend the model once it is validated.
A GRE tunnel encapsulates clean traffic between the mitigation infrastructure and your dedicated server or router. Public traffic first reaches the anti-DDoS layer, gets filtered, then legitimate traffic is sent back to your machine through the tunnel.
In this model, the final server stays at OVH, Hetzner or elsewhere. It no longer receives raw Internet traffic directly: it receives traffic after cleaning, which lets you preserve the existing environment while adding a serious network protection layer.
This is especially useful for services already in production, gaming workloads, business applications or infrastructures that cannot be moved overnight.
Protected IPs or announced prefixes first land on the anti-DDoS infrastructure.
The point is to stop malicious traffic before it reaches your production environment.
Clean traffic is sent through GRE to your dedicated server or router.
Your application stays on its current provider, but behind a dedicated mitigation layer.
BGP is mainly useful when the customer wants to announce its own IP prefixes, keep control over routing or integrate protection into a more advanced network architecture. That is highly relevant for some profiles, but it is not mandatory in every deployment.
In many cases, we can also use our own protected anti-DDoS IPs and route clean traffic back to the OVH or Hetzner dedicated server through the GRE tunnel. In that scenario, the customer does not need to announce its own prefixes to get started.
In other words, BGP is an architectural flexibility tool. It is not an absolute prerequisite to protect a service hosted elsewhere.
Best if you already have an ASN, your own prefixes or want fine-grained routing control.
A simpler approach when the goal is fast protection without adding routing complexity.
Traffic lands on protected IPs and is delivered back to your dedicated server through the tunnel.
You can start simple and move later to a BGP design if your requirements evolve.
The right choice depends on the level of network control you need, how fast you want to deploy and whether you use your own IP prefixes. There is no single model that fits every customer.
Often the best choice to quickly protect a production dedicated server without ASN or BGP announcements.
Better suited when you own your IP space, want to keep your announcements and need a more flexible network design.
Very convenient for getting started fast, validating latency and integration, and avoiding an immediate re-addressing project.
Relevant for larger environments or customers already present in datacenters with direct handoff requirements.
A good protection design should not be sold as magic. It is important to understand what this architecture truly solves and what still needs validation on the customer side.
The main value is preserving the servers already in place instead of forcing a complete move.
You can protect one service first, then expand the perimeter once the model is validated.
MTU, return routing, firewall rules, local policy and the actual capacity of the machine all need to be checked seriously.
If the application, server or internal design is already overloaded even without attacks, network protection alone will not solve everything.
At Peeryx, the point is not to push a full migration by default. We first look at the existing infrastructure, the most coherent delivery method and the actual level of network control that is needed.
Depending on the case, that can mean protected IPs delivered to your dedicated server through GRE, a BGP-based design when you want to keep your own announcements, or a progressive rollout focused first on the most exposed services.
Imagine a customer already hosting a game server or application backend at Hetzner. The customer wants to keep that machine because the whole environment is already in place, but recurrent attacks make the service unstable and a full migration is not desirable right away.
The cleanest deployment is often to land public traffic on a dedicated anti-DDoS layer, filter the attack, then send only legitimate traffic back through GRE to the Hetzner server. If the customer owns its own IP space or needs more routing control, BGP can be added. Otherwise, protected IPs operated on the anti-DDoS side can be used from day one.
We review the service type, latency sensitivity, operating mode and the server’s ability to receive clean traffic.
Tunnel only, tunnel + BGP or protected IPs depending on the level of control required.
GRE, return path, MTU and overall stability are validated before real cutover.
The customer keeps the existing infrastructure while gaining a mitigation layer aligned with the real use case.
Most problems do not come from GRE or BGP themselves. They usually come from weak scoping or from an architecture that looks simpler on paper than it really is in production.
Yes. That is one of the most common use cases: the server stays at Hetzner and receives legitimate traffic through GRE after upstream mitigation.
No. BGP is useful for some customers, but GRE with protected IPs is enough for many deployments.
Yes. The principle is the same: traffic is cleaned upstream and then delivered back to the OVH server through an appropriate design.
Yes. That is often the cleanest path: start simple, validate production, then add BGP later if it becomes useful.
Yes, precisely because it adds protection without forcing a full migration from day one.
Protecting a Hetzner or OVH dedicated server against DDoS does not automatically mean moving everything. In many cases, a GRE-based design, with or without BGP, adds a serious mitigation layer while preserving the existing production environment.
The right model depends on your actual technical reality: whether you need your own IP space, want routing control, prefer fast deployment or need to start quickly with protected IPs already operated on the mitigation side.
The real goal is therefore not only to stop an attack, but to choose an architecture that is credible, clean and workable in production.
Tell us about your current infrastructure, hosting provider, network constraints and desired level of control. We will tell you whether a simple GRE tunnel, GRE + BGP or protected IP delivery makes the most sense.
