How to use remote DDoS protection to secure your network

If you’ve ever watched a production service crumble under a flood of malicious traffic, you know two truths: (1) downtime is brutal, and (2) on-box firewalls aren’t enough. Distributed denial-of-service (DDoS) attacks overwhelm links and edge devices long before traffic reaches your app.

Remote DDoS protection solves this by moving the fight off your network and into a dedicated mitigation platform that scrubs traffic and forwards only the clean packets back to you. In this guide, you’ll learn how remote DDoS protection works, when you should use it, how to deploy it step-by-step, and how Evolution Host’s Remote DDoS Protection can slot neatly into your stack.

What is remote DDoS protection?

Remote (a.k.a. out-of-path) DDoS protection is a network-level shield that sits outside your infrastructure. Instead of trying to filter attacks locally, you route your traffic through a scrubbing network that:

1. Receives your inbound traffic first (via BGP/Anycast or policy-based routing).

2. Identifies & mitigates attack traffic using global telemetry and layered defenses (L3/4 filtering, rate limiting, behavioral models, signatures).

3. Forwards clean traffic to your origin through an encrypted GRE tunnel or private interconnect.

4. Optionally returns outbound traffic the shortest way out (asymmetric routing) or back through the tunnel (symmetric).

Why it’s effective

• Link shield: Your last-mile bandwidth never sees the attack volume.

• Purpose-built hardware: Specialized filters and silicon handle PPS/Gbps you can’t match in-house.

• Global edges: Anycast and regional scrubbing cut latency during normal traffic and during attacks.

Remote vs. on-prem vs. CDN-only

Bottom line: If you run UDP services (VoIP, game servers), custom TCP protocols, or anything where raw bandwidth and packets matter, remote protection is the pragmatic path.

How remote DDoS protection works (in practice)

A common, proven pattern looks like this:

Internet ── Scrubbing POPs (Anycast)

│

Clean Traffic over GRE/IPsec

│

Your Edge Router

│

Private LAN

• Anycast/BGP announcement: The provider advertises your protected IP prefixes globally. Attackers hit the provider’s edges, not yours.

• Mitigation pipeline: Packet filters, stateless/stateful engines, heuristics, and rate shapers remove floods (volumetric UDP, SYN, ACK, amplification, carpet bombing, etc.).

• GRE tunnel: A lightweight, widely-supported encapsulation that carries clean packets to your router. Optionally pair with IPsec for encryption.

• Return path: Either NAT your egress through the provider (for symmetry) or let replies go out locally.

When to use remote DDoS protection

Consider moving to remote protection if you have any of the following:

• Repeated volumetric attacks that saturate your uplink (> your ISP’s burst).

• Protocol-agnostic services (game servers, VPN, RDP gateways, custom TCP/UDP).

• Strict SLAs with monetary penalties for downtime.

• Limited on-prem capacity or complex multi-site environments.

Evolution Host’s Remote DDoS Protection at a glance

Evolution Host offers a remote filtering layer designed for networks that need always-on mitigation without moving their infrastructure. At a high level, it provides:

• Anycast scrubbing that absorbs floods before they touch your circuits.

• Layer 3/4 protection for TCP/UDP services (game, VoIP, VPN, custom ports), with targeted rules for popular attack patterns.

• GRE tunnel delivery of clean traffic to your network.

• Simple onboarding: announce your IPs with them and set up a tunnel—no app changes required.

• 24/7 monitoring & alerting so you can see and verify mitigation events.

(If you’re currently running servers with Evolution Host, integrating remote protection is even simpler; if you’re elsewhere, you can still use it to protect your existing IP space.)

Step-by-step: Deploy remote DDoS protection (Evolution Host example)

1) Scope what you’ll protect

• IP ranges (single IPs or full /32, /31, /30 … up to your routed prefix).

• Protocols and ports (HTTP/S, game ports, VoIP, SSH, RDP, VPN, custom).

• Traffic patterns (peak Gbps/PPS, geo distribution, normal baseline).

2) Choose a routing model

• Anycast BGP + GRE (recommended): Evolution Host advertises your protected IPs; they receive all inbound traffic and forward clean packets over GRE to you.

• Policy-based routing: Point only certain flows/routes to the scrubbing network (useful for staged rollouts).

Tip: For production, favor always-on BGP advertisement over on-demand. Always-on avoids failover delays when an attack starts.

3) Prepare your edge

• Ensure your router/firewall supports GRE (almost all do).

• Confirm you can add static routes for the protected subnets through the GRE interface.

• Reserve public IPs for tunnel endpoints (your side ↔ Evolution Host side).

4) Exchange technical details

Share with Evolution Host:

• Your protected prefixes/IPs and origin ranges.

• Tunnel endpoint (your public IP) and preferred MTU.

• Whether you need symmetric routing (both directions via tunnel) or asymmetric (inbound via tunnel, outbound via your ISP).

They’ll provide:

• Their tunnel endpoint IP and BGP/route parameters (if applicable).

• Optional health-check and origin verification settings.

5) Build the GRE tunnel

Linux (example)

# Variables

REMOTE=203.0.113.10 # Evolution Host GRE endpoint

LOCAL=198.51.100.20 # Your public endpoint

TUN=tun0

TUN_IP=10.0.0.2/30 # /30 for point-to-point

PEER_TUN_IP=10.0.0.1

# Create tunnel

ip tunnel add $TUN mode gre local $LOCAL remote $REMOTE ttl 255

ip addr add $TUN_IP dev $TUN

ip link set $TUN mtu 1476 up # adjust for overhead

ip route add0.0.0.0/0 dev $TUN table 200 # optional policy table

# Route the protected /32 or prefix back to the tunnel

ip route add203.0.113.200/32 via $PEER_TUN_IP dev $TUN

Edge router (generic)

• Create GRE interface to provider endpoint

• Set tunnel MTU (start with 1476 for GRE; adjust after testing)

• Add static routes:

  • To you: Your protected IP/prefix is locally hosted as normal.

  • To provider: Return path for clean traffic (usually a route to their tunnel IP).

If you want symmetric egress (replies out through the tunnel), SNAT/NAT your responses to the protected IP and set a policy route that prefers the GRE interface for that source.

6) Update DNS / announcements

• If they’re announcing your prefix, no DNS changes are needed. Traffic will naturally arrive at the provider first.

• If you’re only protecting a single service, you can point a DNS A/AAAA record to the protected IP managed through the scrubbing network.

7) Test, tune, and lock it in

• Connectivity: Ping/traceroute your protected IP. Verify it hairpins through the tunnel.

• MTU/PMTUD: Test large uploads. If you see fragmentation or stalls, lower tunnel MTU (e.g., 1460) and enable MSS clamping on your edge.

• Health checks: Ensure the provider only forwards traffic when your origin is healthy.

• Logging: Export NetFlow/sFlow from your edge; correlate with Evolution Host’s attack logs.

Operational best practices

1. Define a clean baseline
   Collect 7–14 days of normal PPS/Gbps per port. Baselines make detections faster and thresholds saner.

2. Segment by service
   If possible, map different services to distinct IPs. It allows granular filtering (e.g., stricter UDP rules on game ports without affecting HTTPS).

3. MSS clamping & MTU sanity
   With GRE, set TCP MSS to (MTU - 40) to avoid black-holed large packets.

4. Prefer stateless filters for volumetric bursts
   Let the provider’s stateless/line-rate filters blunt the initial PPS burst; stateful rules can follow once stabilized.

5. Maintain out-of-band access
   Keep management out-of-band (VPN on separate IP/range) so you can still reach devices during an event.

6. Drill your runbooks
   Simulate: “UDP flood on :27015,” “SYN flood on :443,” “carpet bombing across /24.” Practice the toggle points and verification steps.

Monitoring & verification

Track these metrics:

• Ingress vs. clean egress (provider portal export): attack magnitude, dropped PPS, allowed PPS.

• Tunnel health: up/down state, latency to provider edge, packet loss.

• Application KPIs: request rate, error rate, tail latency, disconnects.

• False positives: look for unusual protocol blocks or geo anomalies.

During an incident, annotate timelines: attack start → mitigation engaged → steady state → resolution. This helps with RCA and SLA reviews.

Cost model & architecture tips

• Predictability beats pennies. Always-on plans reduce toil and flap.

• Avoid single-points of failure. If you can, build two GRE tunnels to different POPs and set ECMP or primary/backup routing.

• Keep configs portable. Treat your tunnel/router config as code (Git, change control, rollback).

Migration checklist (copy/paste)

• Inventory services, ports, IPs, and peak PPS/Gbps

• Choose routing model (Anycast+BGP recommended)

• Confirm GRE support and capacity on your edge

• Exchange tunnel endpoints and IP/prefix details

• Build and test GRE (latency, MTU/MSS, failover)

• Enable health checks / origin verification

• Go live with always-on advertisement

• Monitor baselines and tune thresholds

• Document incident playbooks & contacts

Troubleshooting quick hits

• Symptom: Users time out on large uploads
  Fix: Reduce tunnel MTU; enable TCP MSS clamping (e.g., 1360–1460).

• Symptom: Random disconnects on UDP services (games/VoIP)
  Fix: Confirm provider’s UDP timeouts; request a longer session window.

• Symptom: Asymmetric routing breaks stateful firewall
  Fix: Either enable state bypass for protected flows or use symmetric (in+out) via tunnel.

• Symptom: GRE up, but no return traffic
  Fix: Ensure reverse route for your protected prefix via the tunnel and check policy routing/NAT.

Frequently asked questions

Q: Do I need to move my servers to Evolution Host to use remote protection?
A: No. Remote protection is designed to shield external infrastructure. You keep your servers where they are; traffic simply gets scrubbed first.

Q: Will this protect non-HTTP services like game servers or VoIP?
A: Yes. Remote protection is protocol-agnostic at L3/L4. You can protect custom TCP/UDP ports alongside web services.

Q: What about latency during normal operation?
A: With Anycast, traffic typically enters the nearest scrubbing POP and then traverses a backbone to your tunnel. For most regions the added latency is modest—measure it during staging and choose POPs accordingly.

Q: Can I use it only during attacks?
A: On-demand is possible, but always-on removes the failover gap when the attack starts and offers the most consistent performance.

Q: Will encryption work across the tunnel?
A: Yes. GRE carries your packets unchanged; TLS/VPN traffic is unaffected. If you need encryption at the network layer, pair GRE with IPsec.

Why teams choose Evolution Host for remote protection

• Rapid onboarding: Clear tunnel setup and routing guidance; sane defaults that work out of the box.

• Real-world playbooks for UDP: Tuned profiles for game and VoIP traffic (where volumetric floods are common).

• Transparent reporting: Visibility into mitigation events so you can verify effectiveness and satisfy stakeholders.

• 24/7 expertise: Humans who understand packet-level attacks and will help you tune policies, not just flip canned switches.

Get started

1. List the IPs and services you want protected.

2. Ask Evolution Host for a remote protection plan sized to your peak PPS/Gbps.

3. Build the GRE tunnel, test MTU/MSS, and run a controlled cutover.

4. Monitor, tune, and relax—your link isn’t the battleground anymore.

-------------------------------------------------------------