What is GRE tunneling?

02Why DDoS protection uses it

Protecting a non-HTTP service means getting its traffic to a filtering network first, and a web proxy cannot carry it, as Layer 3/4 vs Layer 7 protection explains. DNS cannot do it either — a DNS record points a name at an address, but the packets still go wherever that address routes. GRE solves the delivery problem: the provider advertises the protected addresses, so all traffic for them arrives at the scrubbing network first.

Once filtered, the clean traffic has to reach your actual machine, which is somewhere else entirely and has a different address. The tunnel carries it there. From your server's point of view the packets arrive with their original source addresses intact, so logging, geolocation and application logic all keep working normally.

• Works for any protocol, including UDP, which no HTTP proxy can handle
• Your hardware stays where it is — no migration required
• Original client addresses are preserved, so your logs stay meaningful
• The origin address is not published, so attackers have nothing to aim at directly

03Return traffic: through the tunnel or direct

Inbound traffic always arrives through the provider. Replies can take one of two routes, and the choice affects latency, MTU and what your own upstream must allow.

04Your own addresses, or the provider's

There are two ways to run this. With BYOIP (bring your own IP), you own an address range, in practice at least a /24 because longer prefixes are generally filtered, and authorise the provider to announce it on your behalf. Your addresses stay yours, which matters if they are baked into client configurations, allowlists or DNS you do not control. It also needs a ROA that authorises the announcing network, or networks that validate routes may reject it; what RPKI is explains how.

Alternatively the provider assigns you addresses from their own range. This is faster to set up and requires no address ownership, but the addresses are not portable — if you leave, you renumber.

05MTU, MSS and encryption

GRE adds 24 bytes to every packet on an IPv4 path: 20 for the outer IPv4 header and 4 for the GRE header. Each optional field, such as the key from RFC 2890, adds 4 more, and an IPv6 outer header makes the base overhead 44. If that is not accounted for, full-size packets fragment or are dropped, and the classic symptom is that small requests work while large uploads or TLS handshakes hang. RFC 4459 explains why path MTU discovery cannot be relied on to fix it over IPv4: firewalls and other middleboxes are often configured to drop the ICMP messages it depends on.

Set the tunnel MTU and clamp the TCP maximum segment size (MSS) on SYN packets, so connections never attempt segments that do not fit. The full arithmetic, including IPv6 inside the tunnel and the Linux commands, is in GRE vs IPIP, and the MTU and MSS calculator works the numbers out for stacked tunnels such as GRE over PPPoE.

GRE also provides no encryption or authentication of its own; it is a delivery mechanism, not a security protocol. That is rarely a problem here, because the payload is ordinary internet traffic that was never private in the first place, but it is worth being explicit about; where the link itself must be private, GRE is paired with IPsec.

06Checking a GRE tunnel

Three checks confirm a tunnel passes traffic and is sized correctly. In the example, 203.0.113.1 is the provider's tunnel endpoint and 10.10.10.1 the far end of the tunnel's own /30 link; a subnet calculator helps when planning those small point-to-point ranges.

# GRE packets from the provider's endpoint arriving on the physical interface
tcpdump -nni eth0 'ip proto 47 and src host 203.0.113.1'

# tunnel counters: RX should rise while traffic flows, errors should not
ip -s link show dev gre1

# largest unfragmented ping through a 1,476-byte tunnel: 1,476 - 28 = 1,448
ping -M do -s 1448 -c 3 10.10.10.1
# one byte more must fail locally with: message too long, mtu=1476
ping -M do -s 1449 -c 1 10.10.10.1

07Before you put a service behind a GRE tunnel

• Allow GRE (protocol 47) only from the provider's tunnel endpoints, and the service ports only through the tunnel
• Set the tunnel MTU and MSS clamping on day one, not after the first stalled upload
• Decide the return path and test it from an outside network
• If you bring your own prefix, publish the ROA before the first announcement
• Monitor the far tunnel address: RFC 2784 defines no keepalive, so a dead tunnel can still look up
• Remove old DNS records and banners that expose the real address