One of the most common ways to protect a network from large volumetric DDoS attacks is to divert the malicious traffic to a scrubbing centre. These dedicated networks remove harmful packets and return only the clean traffic back to your network. GRE tunnels are often used for this return path because they work with any network that can speak BGP, and they do not require changes to your infrastructure, DNS, or application stack.
At first glance, this approach seems simple and reliable. When set up correctly, it allows legitimate traffic to continue flowing back from the scrubbing center, even during massive attacks. However, the simplicity can be deceptive. Once you start tunneling heavy traffic through GRE, you’ll start noticing the myriad of headaches this approach comes with.
In this article, we will explain from the ground up how GRE tunneling functions in DDoS mitigation, how traffic flows to scrubbing centres and back, and the common problems engineers encounter. We’ll also provide practical advice on mitigating these challenges. By the end, you’ll understand why GRE tunneling remains a standard tool in DDoS protection, despite its quirks and complexities.
Understanding GRE tunnels
GRE, or Generic Routing Encapsulation, is a simple yet powerful protocol used to send packets from one network to another through a tunnel. Think of GRE like an envelope: the original packet is the letter, and the GRE header is the envelope that allows the packet to travel safely across a different path. Just as a letter can be sent to a remote office without opening it, the original packet can pass through multiple networks without being altered.
When traffic is sent through a GRE tunnel, the original IP packet is encapsulated inside a new packet that contains the GRE header and a new outer IP header. This encapsulation allows the scrubbing provider to route traffic back to your network, keeping the original source and destination addresses intact. At the receiving end, the GRE header is removed, revealing the original packet, which is then delivered to your server as if it had never left your network.
This mechanism makes GRE a versatile tool for returning cleaned traffic from a scrubbing centre because it works independently of the original protocol or service, whether that’s IPv4, IPv6, or any other protocol encapsulated within IP.
GRE tunnels in DDoS traffic diversion
If a DDoS defence stack includes scrubbing centre automation, incoming traffic can be automatically redirected to a scrubbing centre where malicious packets are filtered out. GRE tunnels provide a reliable way to return the clean traffic to your network without altering your existing infrastructure or applications.
The process works as follows: once the scrubbing centre has removed harmful traffic, each clean packet is encapsulated in a GRE header — much like putting a letter into an envelope. This encapsulation allows the packets to travel across the network to your edge routers while preserving the original IP information. When the traffic arrives, the GRE header is removed, and the original packets are delivered to your servers seamlessly.
Using GRE in this way makes DDoS scrubbing largely transparent to your network. BGP reroutes the traffic to the scrubbing centre automatically, while GRE ensures the safe return of clean traffic. This setup avoids the need for changes to DNS, application configuration, or network infrastructure. However, this simplicity comes with hidden costs and technical challenges, which will be discussed in the next chapter.
Common challenges of GRE tunnelling
GRE tunnels are a key component of automated DDoS scrubbing, but they introduce specific challenges that network operators need to understand. At a high level, there are three main categories of issues: packet size overhead, MTU-related problems, and operational complexity.
1. Packet size overhead
Every packet sent through a GRE tunnel gains an additional header, typically around 24 bytes for IPv4. While this may seem small, the extra bytes can add up at high traffic volumes. This increase in packet size is called packet size overhead. If the network devices along the path are not prepared for the larger packets, fragmentation can occur. Fragmented packets reduce throughput, can introduce latency, and may even break protocols that do not handle fragmentation gracefully.
2. MTU-related problems
Packet size overhead directly impacts the Maximum Transmission Unit (MTU) of the path. If a GRE-encapsulated packet exceeds the MTU at any point along the route, it can be fragmented or dropped. Misconfigured MTU settings, blocked ICMP messages, or failure of Path MTU Discovery (PMTUD) can result in silent packet loss. During a DDoS attack, high traffic volumes amplify these effects, potentially impacting performance and reliability of critical services.
3. Operational complexity
GRE tunnels require careful configuration, monitoring, and ongoing maintenance. Operators must ensure tunnel endpoints are properly verified, MTU settings are aligned, necessary ICMP messages are allowed, and traffic patterns are continuously monitored. During live DDoS events, misconfigurations or failures can cause traffic loss or session resets. Troubleshooting under attack conditions is stressful and time-consuming, emphasizing the importance of thorough preparation and regular testing.
Solutions and alternatives to GRE tunnelling issues
When you use GRE tunnels for DDoS scrubbing, you don’t have to accept the risks silently – there are well‑understood best practices to mitigate the problems, and in some cases, legitimate alternatives that avoid GRE entirely.
How to mitigate GRE‑specific problems
Tune MTU / MSS carefully
Because GRE adds header overhead, you should reduce the MTU on the GRE/tunnel interface or adjust TCP segment sizes so that encapsulated packets remain under the MTU limit. For example:
- Lower the GRE interface MTU (many recommend something like 1400 bytes) to give headroom for the extra GRE header and avoid fragmentation.
- Use TCP MSS (Maximum Segment Size) clamping: force TCP sessions to negotiate a smaller MSS so payloads won’t exceed the safe size after encapsulation.
- Ensure that “don’t fragment” (DF) settings, PMTUD (Path‑MTU Discovery), and ICMP “fragmentation needed” messages are allowed end‑to‑end. Without proper PMTUD, packets may be silently dropped when too large – a common cause of mysterious failures after scrubbing.
In short: treat the GRE link MTU and packet size as a first‑class configuration parameter – set and test it before any real traffic has to be sent to the scrubbing centre.
Combine with fallback mechanisms or hybrid mitigation
Because GRE isn’t bullet‑proof, a robust defence stack often doesn’t rely solely on it. For example:
- Use scrubbing – and therefore GRE for only for selected traffic / prefixes when required. You can automate this with FastNetMon’s scrubbing centre diversion
- Keep alternate mitigation methods (like blackholing or filtering at upstream) as fallback when GRE paths break.
- Use proper documentation and runbooks so that operators know when to switch or failover if the tunnel misbehaves.
Alternatives to GRE‑based return paths
If you find GRE too fragile or complex, there are other options — each with trade‑offs:
Clean‑pipe / direct return over BGP (no GRE)
Some providers offer to send scrubbed traffic back over the same transit link via BGP announcements or routing changes, avoiding tunnels entirely. This eliminates encapsulation overhead and MTU/mss problems. However, it requires close coordination with your upstream provider and may not be available everywhere.
Anycast / edge‑based scrubbing (no backhaul tunnel)
With a global anycast network (often provided by large scrubbing / CDN providers), the attacker traffic is dropped at the edge, clean traffic is delivered directly — so there is no need for a tunnel back to your origin. This offers excellent performance and removes GRE‑tunnel risk. The trade‑off: you effectively put your service behind the provider’s edge, which might not fit every infrastructure or compliance requirement.
MPLS or Layer‑2 / L2VPN backhaul from scrubbing centre
If you have the ability (or the provider offers it), using a private link (MPLS, L2VPN, VLAN cross‑connect) from the scrubbing centre back to your network bypasses GRE/IP encapsulation entirely. This can give clean, stable connectivity. The downside is higher cost and more setup complexity, and usually only feasible for larger networks.
Use in‑network filtering (BGP FlowSpec / blackholing) instead of scrubbing + return
Depending on your use case, lightweight BGP-based mitigation like flow filtering or remote blackhole may be enough. This avoids tunnelling pitfalls entirely — but only works if filtering is effective and legitimate traffic is easy to separate from attack traffic.
Which option is “best practice”?
The honest answer: it depends. GRE tunnels are far from obsolete. In many cases – especially when you control both ends, can manage MTU/MSS, and have fallback plans – GRE remains the most flexible and universal way to return scrubbed traffic.
That said: when your applications are latency‑sensitive, deliver real‑time traffic (gaming, VoIP), or your network cannot easily support MTU tuning and reliable ICMP/PMTUD, then alternatives like anycast‑based scrubbing or clean‑pipe return (without tunnelling) often deliver more stable and predictable results.
About FastNetMon
FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats.For more information, visit https://fastnetmon.com