What is remote DDoS protection?

02How is remote DDoS protection delivered?

There are three delivery models. They differ in the layer they work at, what you need to bring, and how clean traffic gets back to you.

• Reverse proxy (Layer 7): DNS points your hostname at the provider, which terminates HTTP and TLS, filters requests and opens its own connections to your origin. Covers websites and APIs; see what a reverse proxy is
• GRE or IP tunnel (Layer 3/4): the provider gives you protected addresses, or routes yours, and delivers filtered packets to your machine inside a tunnel. Covers any protocol, including UDP game and voice traffic; see what GRE tunnelling is
• BGP with your own prefix (Layer 3/4): the provider announces your address block, scrubs traffic for it and hands the clean part back over a tunnel or a direct connection. Covers whole networks; see what BGP is

03Reverse proxy vs GRE tunnel vs BGP: comparison

Choose by protocol first: anything that is not HTTP rules out the reverse proxy, and less than a /24 rules out announcing your own prefix. Layer 3/4 vs Layer 7 explains why the layers need different tools.

04Reverse proxy: websites and APIs

The quickest model to deploy: change DNS and traffic flows through the provider once the old record's TTL expires. Because the proxy terminates HTTP, it can inspect requests, challenge bots, cache pages and absorb HTTP floods that look like ordinary traffic.

Its weakness is the origin. If the real address still answers, attackers skip the proxy, so firewall the origin to the provider's published ranges and follow how to hide your origin IP. Your application also sees the proxy as the client, so it must restore the visitor's address from the proxy's header, trusting it only from the proxy's ranges.

05GRE tunnel: any protocol, your own machine

The provider wraps each clean packet in an outer IP header addressed to your machine. GRE (RFC 2784) adds a 4-byte header to the 20-byte outer IPv4 header, so every packet grows by 24 bytes; the optional key field from RFC 2890 adds 4 more. Your server unwraps the packet and sees the original, real source address included.

Two details matter. Replies normally go back through the tunnel, because your own upstream drops packets with source addresses it did not assign to you (ingress filtering, BCP 38, RFC 2827). And the tunnel endpoint is your server's real address: if it leaks, it can be flooded directly, so use an endpoint address that runs no public service and appears in no DNS record.

#!/usr/sbin/nft -f
# On a router that terminates the tunnel for servers behind it:
# rewrite the MSS in forwarded SYNs to fit the tunnel's MTU (1476).
table inet tunnel_mss
delete table inet tunnel_mss

table inet tunnel_mss {
    chain forward {
        type filter hook forward priority mangle; policy accept;
        oifname "gre1" tcp flags syn tcp option maxseg size set rt mtu
        # 1476 - 40 (IPv4 + TCP) = 1436; 1476 - 60 (IPv6 + TCP) = 1416
        iifname "gre1" meta nfproto ipv4 tcp flags syn tcp option maxseg size set 1436
        iifname "gre1" meta nfproto ipv6 tcp flags syn tcp option maxseg size set 1416
    }
}

06BGP: protecting your own prefix

If you run your own network, the provider can announce your prefix so the internet sends its traffic to their scrubbing sites. You need an autonomous system number and at least a /24 of IPv4 or a /48 of IPv6, because more specific prefixes are generally filtered; why a /24 is the minimum explains the rule. If your prefix has RPKI ROAs, they must cover the origin AS and prefix length the provider will announce, or validating networks treat it as invalid (RFC 6811).

Always-on means the provider announces the prefix permanently and every packet is filtered. On-demand means you announce it yourself and divert to the provider when flow telemetry shows an attack. That avoids the detour in peacetime but leaves a gap before the new route takes effect, and an unrehearsed switch can look to others like a BGP hijack.

Clean traffic returns over GRE, a cross-connect in a shared data centre, or a private VLAN at an internet exchange. Outbound traffic usually leaves through your own transit, since the prefix is yours.

07Questions to ask a remote DDoS protection provider

Marketing pages quote capacity; what keeps you online is operational. A good provider answers these directly.

08What remote DDoS protection cannot do

It protects the path it controls and nothing more. An address outside that path, such as an old server, a mail host, a forgotten IPv6 address or the tunnel endpoint itself, can still be flooded directly. A Layer 3/4 service does not inspect HTTP, so an application-layer flood passes straight through a tunnel unless the provider also proxies the web traffic. No network filter fixes a vulnerable application or a credential-stuffing campaign using real logins.

Every model costs a detour, tunnel overhead where used, and dependence on the provider. For most targets that is a good trade, but measure steady-state latency rather than assuming it. GuardX's remote protection for websites and APIs works as a reverse proxy and is available now; GRE transit for other protocols is marked coming soon.