Remote DDoS Protection with a GRE Tunnel: How It Works and Full Setup

What remote DDoS protection is

Remote DDoS protection is mitigation applied at a network you do not host on. A provider announces a protected IP for you, scrubs incoming traffic in their datacentre, and forwards the clean traffic to your existing server through a tunnel. You get filtering capacity you could never buy for one box, without migrating anything.

The reason to want it is simple: you are being attacked, your current provider either cannot filter at scale or charges a fortune for it, and moving the server is disruptive or impossible. A tunnel to a scrubbing edge solves the capacity problem while leaving your stack untouched. It is the same model as our integrated DDoS-protected VPS hosting, except the protected server lives on someone else's network and reaches ours over an encapsulated link.

How traffic flows

Players and clients connect to a protected IP we announce from AS211138. That traffic lands on our Frankfurt edge, gets scrubbed, and the clean remainder is pushed into a GRE tunnel to your origin. Your origin's real IP never appears in DNS or routing, so attackers can only reach the filtered front door.

The path looks like this:

The return path is a real decision, not a detail. In direct return (A) your server replies straight out through its own ISP. That is lower latency, but the reply packets carry the protected source IP, and many networks drop those as spoofed because they did not arrive on the interface the route expects. In symmetric return (B) replies go back through the tunnel and leave from our edge, which keeps the source IP consistent and passes reverse-path filters everywhere. Symmetric is the safe default; use direct only when you control the upstream and have verified it accepts the source IP.

GRE vs EoIP vs IPIP vs WireGuard forwarding

Four encapsulations can carry the clean traffic. GRE is the default: broad support, low overhead, carries any IP protocol. EoIP gives you a Layer 2 bridge on MikroTik. IPIP is the fallback when GRE's protocol is filtered. WireGuard adds encryption and traverses hostile firewalls because it rides on UDP.

The GRE header adds 24 bytes over the 1500-byte underlay, per RFC 2784, so the tunnel interface MTU is 1476 and you clamp TCP MSS to 1436. EoIP carries an Ethernet frame, roughly 42 bytes of overhead, so plan an interface MTU of 1458 unless your underlay allows a larger L2MTU. Keep IPIP in your pocket as the fallback where protocol 47 is dropped but plain IP-in-IP survives.

Linux setup

On Linux you create the GRE interface, give it a small point-to-point subnet, then use policy routing so that only traffic from your protected IP is sent back through the tunnel. Adapt the addresses to the ones we issue and verify on a staging box before you cut over.

modprobe ip_gre
ip tunnel add gre1 mode gre local {{ORIGIN_PUBLIC_IP}} remote {{POP_IP}} ttl 255
ip link set gre1 up mtu 1476
ip addr add 10.255.0.2/30 dev gre1
echo "100 ddos" >> /etc/iproute2/rt_tables
ip rule add from {{PROTECTED_IP}}/32 table ddos
ip route add default via 10.255.0.1 dev gre1 table ddos
sysctl -w net.ipv4.conf.gre1.rp_filter=2

• ip tunnel add gre1 — builds the GRE interface between your public IP and our edge (the POP).
• mtu 1476 — the 1500-byte path minus GRE's 24-byte header, so encapsulated packets do not exceed the underlay.
• 10.255.0.2/30 — the tunnel's own tiny subnet; our end is 10.255.0.1.
• The ip rule + ip route ... table ddos pair is policy routing: traffic sourced from your protected IP must leave via the tunnel, otherwise replies exit your normal gateway with the protected source IP and get dropped as spoofed.
• rp_filter=2 — loose reverse-path filtering, required because traffic arrives on the tunnel but could plausibly leave elsewhere; strict mode (1) would drop it.

Persist the tunnel and rules in your network config (systemd-networkd, ifupdown or NetworkManager) so they survive a reboot, and add the MSS clamp described below.

MikroTik RouterOS v7 setup

On RouterOS v7 the shape is the same — GRE interface, tunnel subnet, a routing rule that pins protected-IP traffic to a dedicated table, and an MSS clamp in the firewall mangle. Almost no competitor publishes this, so here it is in full.

/interface gre add name=gre-ddos local-address={{ORIGIN_PUBLIC_IP}} \
  remote-address={{POP_IP}} keepalive=10s,3 mtu=1476
/ip address add address=10.255.0.2/30 interface=gre-ddos
/routing table add name=ddos fib
/routing rule add src-address={{PROTECTED_IP}}/32 action=lookup-only-in-table \
  table=ddos
/ip route add dst-address=0.0.0.0/0 gateway=10.255.0.1 routing-table=ddos
/ip firewall mangle add chain=forward out-interface=gre-ddos protocol=tcp \
  tcp-flags=syn tcp-mss=1437-65535 action=change-mss new-mss=1436

The keepalive=10s,3 setting is what makes the tunnel self-heal: RouterOS pings the far end every 10 seconds and marks the interface down after three misses, so a dead edge does not silently swallow your traffic. The final mangle rule is the MSS clamp — it rewrites the maximum segment size on outbound SYNs so neither side ever negotiates a segment too large for the 1476-byte tunnel.

MTU and MSS: why large packets silently die

The most common tunnel failure is not a dead tunnel — it is a working tunnel that drops big packets. Once GRE's 24 bytes eat into the 1500-byte path, any full-size packet that arrives with "don't fragment" set is too large to encapsulate. If Path MTU Discovery is blocked by a firewall along the way, the sender never learns, and the connection stalls after the handshake.

The tell is a maddeningly specific symptom pattern:

The fix is the MSS clamp shown in both configs above: force TCP to advertise a maximum segment of 1436 so no segment ever exceeds the tunnel MTU. On our Frankfurt edge we clamp TCP MSS to 1436 on the tunnel interface by default, but you must clamp on your side too — the clamp only helps for the direction that applies it.

Testing and troubleshooting

After the tunnel is up, prove the MTU end to end and confirm routing is symmetric before you point real traffic at it. Two commands and one keepalive check cover almost every failure.

First, verify the path can carry a large, non-fragmentable packet just under the tunnel MTU:

# 1448 payload + 28 (ICMP+IP) = 1476, the tunnel MTU. Must NOT fragment.
ping -M do -s 1448 {{POP_IP}}

# One byte larger should fail with "message too long" — that confirms the ceiling.
ping -M do -s 1449 {{POP_IP}}

• Asymmetric routing. If inbound works but replies never arrive, your return path is leaking out the default gateway. Re-check the ip rule / routing rule and confirm the protected source IP is matched. Run a capture on both ends and make sure the reply leaves the interface you expect.
• GRE keepalives. On RouterOS, watch the interface flap counter; on Linux, GRE has no native keepalive, so monitor reachability of 10.255.0.1 with your own health check and tear down the route if it fails.
• Provider filters protocol 47. If the GRE interface never comes up and the underlay is otherwise fine, your host is dropping IP protocol 47. Switch the tunnel to IPIP (protocol 4) or WireGuard over UDP; both reach our edge the same way.

Remote tunnel vs migrating to protected hosting

A tunnel is the right tool when you must stay on your current host. If you are free to move, hosting behind the edge directly is simpler and lower latency — there is no detour and no second link to keep alive. Weigh it honestly.

If the server has to stay put, the tunnel is the answer and we can run it for you. If you can move, an integrated protected VPS is less to maintain. Server owners who also want their own IP space announced can look at BGP hosting with DDoS protection instead of a single-IP tunnel. Minecraft operators have a purpose-built managed version: remote DDoS protection for Minecraft servers.

FAQ

Next step

Build the tunnel from the configs above and test the MTU with ping -M do -s 1448 before you cut over. If you would rather not touch policy routing, we set the whole thing up for you — start with remote DDoS protection for Minecraft servers or open a ticket for a generic origin.