DDoS Tunnel: How GRE Clean Traffic Delivery Works

A DDoS tunnel is a GRE tunnel, usually with a BGP session inside it, that carries clean traffic from a cloud scrubbing center back to your network. Your prefixes are announced from the scrubbing edge, attack traffic is dropped there, and only the filtered traffic reaches your router through the tunnel.

It protects at the IP layer, so it works for any protocol. That is the main difference from proxy-based protection, which only covers the traffic it terminates.

How a DDoS tunnel works

The flow has five steps:

1. Prefix announcement. The scrubbing provider announces your prefixes (for example 192.0.2.0/24) to the internet from its edge. Internet traffic for your IPs now arrives at the scrubbing network first.
2. Scrubbing. Traffic is inspected and filtered. Floods, malformed packets and known attack patterns are dropped.
3. GRE encapsulation. Clean packets are wrapped in GRE and sent to your router's public IP.
4. Decapsulation. Your router removes the GRE header and forwards the original packet to the destination host.
5. BGP inside the tunnel. A BGP session over the tunnel interface shows that the path is alive. It also lets routing change without manual work.

Because the original IP packet is delivered intact, your servers see the real client source IPs. You don't hand over TLS certificates or change DNS.

Return traffic design varies by provider. Many setups send replies out through your normal upstream (asymmetric routing). Others route them back through the tunnel. Confirm which one applies during onboarding, because it affects your uRPF and firewall rules.

DDoS tunnel vs proxy-based protection

Both put a filtering layer between attackers and your servers. They work at different layers.

A tunnel does not replace a WAF. If your main risk is HTTP request floods against one web app, a proxy fits well. If you run hosting, game servers, VoIP, DNS, or customer-assigned IP space, a tunnel covers all of it, because you can't proxy a customer's arbitrary UDP service.

Many networks use both: a tunnel for volumetric L3/L4 protection and a WAF in front of web properties.

When to use a DDoS tunnel

A tunnel fits when:

• You have your own ASN and at least one /24. That is the typical minimum for announcing a prefix. NixGuard Edge, for example, requires it.
• Your uplink is smaller than the attacks you see. Blackholing the target is a last resort because it completes the attack on that IP. Scrubbing keeps the service up.
• You serve mixed protocols or many tenants. ISPs, hosting providers and data centers rarely control what customers run.
• You want to keep client IPs and avoid certificate sharing.
• You need to retain your own routers and addressing and don't want to renumber.

It is less suitable if you have no ASN or only small IPv4 space. A proxy or provider-supplied IPs may be simpler in that case.

Always-on vs on-demand

• Always-on: your prefixes stay announced from the scrubbing edge. There is no switchover delay. Latency changes slightly because all traffic takes the detour.
• On-demand: you normally route traffic directly and divert it to the scrubbing edge when an attack is detected. Normal latency is unchanged, but diversion takes time and BGP convergence adds delay. Fast, flow-based detection matters here.

Example tunnel configurations

All addresses are documentation ranges. The scrubbing edge endpoint is 198.51.100.10 (AS64511). Your router is 198.51.100.50 (AS64496). The inner /30 is 203.0.113.0/30. Your protected prefix is 192.0.2.0/24. Your provider will give you the real values.

GRE adds 24 bytes (20 IP and 4 GRE). On a 1500-byte path, set the tunnel MTU to 1476 and clamp TCP MSS to 1436.

Linux (iproute2 + BIRD)

ip tunnel add gre-edge mode gre local 198.51.100.50 remote 198.51.100.10 ttl 255
ip addr add 203.0.113.2/30 dev gre-edge
ip link set gre-edge mtu 1476 up

iptables -t mangle -A FORWARD -o gre-edge -p tcp \
  --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

protocol bgp edge {
  local 203.0.113.2 as 64496;
  neighbor 203.0.113.1 as 64511;
  ipv4 {
    import all;           # tighten per provider guidance
    export none;          # or your agreed announcements
  };
}

Cisco IOS / IOS-XE

interface Tunnel100
 ip address 203.0.113.2 255.255.255.252
 ip mtu 1476
 ip tcp adjust-mss 1436
 tunnel source 198.51.100.50
 tunnel destination 198.51.100.10
!
router bgp 64496
 neighbor 203.0.113.1 remote-as 64511
 neighbor 203.0.113.1 description scrubbing-edge

Juniper (MX, Junos)

set chassis fpc 0 pic 0 tunnel-services
set interfaces gr-0/0/10 unit 0 tunnel source 198.51.100.50
set interfaces gr-0/0/10 unit 0 tunnel destination 198.51.100.10
set interfaces gr-0/0/10 unit 0 family inet mtu 1476
set interfaces gr-0/0/10 unit 0 family inet address 203.0.113.2/30
set protocols bgp group EDGE type external
set protocols bgp group EDGE peer-as 64511
set protocols bgp group EDGE neighbor 203.0.113.1

The FPC/PIC numbers depend on your hardware. Confirm that tunnel services are enabled on your platform.

MikroTik (RouterOS 7)

/interface gre add name=gre-edge local-address=198.51.100.50 \
  remote-address=198.51.100.10 mtu=1476 keepalive=10s,3
/ip address add address=203.0.113.2/30 interface=gre-edge
/ip firewall mangle add chain=forward action=change-mss new-mss=1436 \
  protocol=tcp tcp-flags=syn out-interface=gre-edge
/routing bgp template set default as=64496
/routing bgp connection add name=edge templates=default \
  remote.address=203.0.113.1 remote.as=64511 local.role=ebgp

Also allow IP protocol 47 (GRE) from the edge endpoint in your input filters. Don't leave GRE open to the world.

Common mistakes

• Ignoring MTU. The classic symptom is that small pings work but HTTPS or large transfers stall. Set the tunnel MTU and clamp MSS. Test with ping -M do -s 1448 <host> on Linux.
• Blocking GRE on your edge firewall. Protocol 47 must be permitted from the scrubbing endpoint.
• Anycast or spoofed tunnel endpoints exposed. Restrict who can send GRE to your router. Otherwise the tunnel endpoint itself becomes a target.
• Strict uRPF on the wrong interface. Asymmetric return paths can break with strict mode. Use loose mode or design around it.
• No prefix filtering. Make sure only prefixes you own are announced. An AS-SET that lists your ASN and prefixes makes this filtering clean. NixGuard Edge supports customer AS-SET for prefix filtering.
• Never testing failover. Run a drill before an incident. Verify the BGP session, traffic path, and what happens if the tunnel drops.
• Slow detection in on-demand mode. A tunnel won't help if you notice the attack ten minutes late.

Where detection fits

On-demand tunnels depend on seeing attacks quickly. NixMon analyzes NetFlow v5/v9, IPFIX and sFlow with sub-second traffic analytics. It applies per-IP and per-prefix bps/pps thresholds. When a threshold trips, it can trigger mitigation: a BGP blackhole (RTBH), a BGP FlowSpec rule, the on-prem NixGuard firewall, or NixGuard Edge.

NixGuard Edge is cloud scrubbing for networks with their own ASN and at least one /24. Your prefixes are announced from the scrubbing edge, and clean traffic returns over a GRE tunnel with a BGP session inside. It can run always-on or on-demand.

You can test flow detection on your own routers with the 15-day free trial. No credit card is required.

Summary checklist

1. Confirm you have an ASN and a /24 or larger.
2. Decide between always-on and on-demand.
3. Build the GRE tunnel with MTU 1476 and MSS 1436.
4. Bring up BGP inside the tunnel and filter prefixes.
5. Allow GRE only from the edge endpoint.
6. Verify the return path and uRPF behavior.
7. Test a diversion and a failure before an attack.