8 min read Advanced 15.1k

rotect a remote server with a GRE tunnel and VeryCloud Remote Transit IP

Published on May 16, 2026 at 07:32 PM

Route traffic from a server hosted anywhere in the world through a GRE tunnel to VeryCloud, and benefit from Netrix Anti-DDoS on your public IP. Ideal for protecting an OVH, AWS, Hetzner server, or even a business residential connection.

Introduction

Got a server at OVH, AWS, or a host that doesn't provide Anti-DDoS, and that's regularly under attack? VeryCloud's Remote Transit IP service solves this: VeryCloud provides you a Netrix-protected public IP, and traffic is routed to your remote server via a GRE tunnel (Generic Routing Encapsulation).

From the Internet's point of view, your server has the VeryCloud IP. All attacks are absorbed by Netrix before reaching your server.

Prerequisites

A Remote Transit IP service subscribed at VeryCloud (public IP + tunnel)
A remote server (Linux, Windows, OVH, AWS, etc.) with a routable public IP
Root access to the remote server
IP protocol 47 (GRE) not blocked on the remote server's network (critical attention point, see step 1)

Step 1: Verify GRE protocol isn't filtered

GRE doesn't use a TCP/UDP port: it's a level 4 IP protocol (number 47). Some networks filter it by default:

Bbox / Bouygues Telecom (residential): ❌ GRE filtered by default
Freebox: ✅ GRE allowed (in bridge mode or with firewall open)
OVH / Hetzner / Scaleway / AWS: ✅ GRE generally allowed

Before subscribing to Remote Transit, open a ticket with your ISP or host to confirm that IP Protocol 47 is allowed inbound and outbound on your server.

Test from your remote server:

# Try to send a GRE packet to VeryCloud
sudo modprobe ip_gre
# If no error, GRE is kernel-supported.
# Network filtering only shows when bringing up the tunnel.

Step 2: Get tunnel information from VeryCloud

After subscribing, VeryCloud provides in your customer area:

Assigned public IP (e.g. 82.26.157.20) — the one visible on the Internet
Point-to-point IP VeryCloud side (e.g. 10.10.0.1)
Point-to-point IP client side (e.g. 10.10.0.2)
VeryCloud GRE endpoint (e.g. 185.X.X.X)

Note these 4 values.

Step 3: Set up the GRE tunnel on Linux

With iproute2 (modern method)

# Load the module
sudo modprobe ip_gre

# Create the tunnel
sudo ip tunnel add tun0 mode gre \
    remote 185.X.X.X \
    local YOUR_SERVER_IP \
    ttl 255

# Assign client-side point-to-point IP
sudo ip addr add 10.10.0.2/30 dev tun0

# Bring up the interface
sudo ip link set tun0 up

# Verify
ip addr show tun0

Configure the default route through the tunnel

This step makes all outbound traffic go through VeryCloud. Without it, the server keeps its original public IP.

# Add a specific route to reach VeryCloud without going through the tunnel
sudo ip route add 185.X.X.X via $(ip route show default | awk '{print $3}') dev $(ip route show default | awk '{print $5}')

# Replace default route with the tunnel
sudo ip route del default
sudo ip route add default via 10.10.0.1 dev tun0

Warning: from this moment, your server is no longer accessible from outside via its original IP! To reconnect, use the new VeryCloud IP (82.26.157.20).

Step 4: Configure VeryCloud public IP on the server

# Add the virtual IP on a dummy interface
sudo ip link add veryclouddummy type dummy
sudo ip addr add 82.26.157.20/32 dev veryclouddummy
sudo ip link set veryclouddummy up

Your server now listens on 82.26.157.20 (the VeryCloud IP).

Step 5: Test connectivity

From outside (your PC):

# Verify VeryCloud IP responds
ping 82.26.157.20

# Test HTTP if web is active
curl -I http://82.26.157.20

From the remote server:

# Verify output via VeryCloud
curl -s https://api.ipify.org
# Should return 82.26.157.20 (not your original IP)

Step 6: Tunnel persistence (on reboot)

Without persistent config, the tunnel disappears on reboot. Several options:

Option A: systemd service

sudo nano /etc/systemd/system/gre-tunnel.service

[Unit]
Description=GRE Tunnel to VeryCloud
After=network.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/bin/setup-gre.sh
ExecStop=/usr/local/bin/teardown-gre.sh

[Install]
WantedBy=multi-user.target

sudo nano /usr/local/bin/setup-gre.sh

#!/bin/bash
modprobe ip_gre

ip tunnel add tun0 mode gre remote 185.X.X.X local YOUR_SERVER_IP ttl 255
ip addr add 10.10.0.2/30 dev tun0
ip link set tun0 up

ip route add 185.X.X.X via $(ip route show default | awk '{print $3}') dev $(ip route show default | awk '{print $5}')
ip route del default
ip route add default via 10.10.0.1 dev tun0

ip link add veryclouddummy type dummy
ip addr add 82.26.157.20/32 dev veryclouddummy
ip link set veryclouddummy up

sudo nano /usr/local/bin/teardown-gre.sh

#!/bin/bash
ip tunnel del tun0
ip link del veryclouddummy

sudo chmod +x /usr/local/bin/setup-gre.sh /usr/local/bin/teardown-gre.sh
sudo systemctl daemon-reload
sudo systemctl enable --now gre-tunnel

Option B: Netplan (Ubuntu 22.04+)

sudo nano /etc/netplan/99-gre.yaml

network:
  version: 2
  tunnels:
    tun0:
      mode: gre
      local: YOUR_SERVER_IP
      remote: 185.X.X.X
      addresses:
        - 10.10.0.2/30
      routes:
        - to: 0.0.0.0/0
          via: 10.10.0.1

sudo netplan apply

Step 7: Configure Windows Server (alternative case)

On Windows, GRE is natively supported but requires admin PowerShell.

# Enable IP routing
New-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\Tcpip\Parameters" -Name "IPEnableRouter" -Value 1 -PropertyType DWord -Force

# Create the GRE tunnel (RAS API)
# (More complex on Windows, see Add-VpnConnection with mode "Gre" if available)

For Windows, VeryCloud rather recommends using WireGuard or OpenVPN as alternative tunnel. Open a ticket to discuss the best approach for your case.

Step 8: Configure the firewall

With the tunnel active, your firewall must allow the GRE protocol:

# UFW
sudo ufw allow proto gre from 185.X.X.X

# iptables
sudo iptables -A INPUT -p gre -s 185.X.X.X -j ACCEPT
sudo iptables -A OUTPUT -p gre -d 185.X.X.X -j ACCEPT

Step 9: Advanced routing — protect only certain services

If you don't want everything to go through VeryCloud (e.g. keep SSH on original IP for server management), use policy routing:

# Create a dedicated routing table
echo "100 verycloud" | sudo tee -a /etc/iproute2/rt_tables

# All traffic from VeryCloud IP goes through tunnel
sudo ip rule add from 82.26.157.20 table verycloud
sudo ip route add default via 10.10.0.1 dev tun0 table verycloud

From now on:

SSH on original IP → goes through classic connection
Web on VeryCloud IP → goes through tunnel and is protected

Step 10: Verify Anti-DDoS protection

With the tunnel active, any attack against 82.26.157.20 is mitigated by Netrix before reaching you. You can verify:

In the VeryCloud customer area: mitigated attack statistics
Your logs (Nginx, app) no longer show attack sources (only legitimate traffic)

Troubleshooting

Tunnel comes up but no traffic passes

Protocol 47 is filtered somewhere. Inspect:

sudo tcpdump -i any proto gre -n

If you only see outgoing packets and no return, filtering is on the ISP/network side. Solution: change ISP/host or contact them to open it.

MTU and fragmentation

GRE adds 24 bytes of overhead. If your packets are fragmented, HTTPS/web connections may fail.

Adjust the MTU:

sudo ip link set tun0 mtu 1476
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Routing loop

If you put the VeryCloud IP 82.26.157.20 as via in a route instead of 10.10.0.1, the server tries to reach its own IP = loop. Always use the client-side point-to-point IP (10.10.0.2 client side, 10.10.0.1 VeryCloud side as gateway).

Connection lost after adding default route

You locked yourself out! If you were accessing via SSH on the original IP, the route change breaks the session.

Solution: before switching the default route, open a second session via screen or tmux, or use the KVM noVNC from the VeryCloud / OVH customer area to recover.

Useful commands

# View all active tunnels
ip tunnel show

# View routes
ip route show
ip route show table all

# Tear down the tunnel
sudo ip tunnel del tun0

# Inspect GRE traffic
sudo tcpdump -i any proto gre -n

# Test ping through tunnel
ping -I tun0 8.8.8.8

# View externally-seen public IP
curl -s https://api.ipify.org

Conclusion

You now protect a remote server with VeryCloud Netrix Anti-DDoS, without physically moving the server. It's the ideal solution to:

Continue using an existing OVH/Scaleway/AWS infra
Host on a business residential server (Free, pro subscription)
Share Netrix protection between multiple sites

For very high performance use (competitive Gaming, low latency), VeryCloud recommends hosting directly at VeryCloud rather than tunneling, since each network hop adds 5-15ms.

Resources

VeryCloud Anti-DDoS documentation: https://verycloud.fr (Anti-DDoS page)
GRE RFC: https://tools.ietf.org/html/rfc2784
VeryCloud guide — Combine Cloudflare and Netrix: /docs/article/cloudflare-netrix
Open a ticket for Remote Transit IP: https://manager.verycloud.fr