GRE tunnel between sites

A GRE tunnel (Generic Routing Encapsulation) encapsulates IP packets inside other IP packets. HolyCloud may use it to return filtered traffic (anti-DDoS) or to link two sites over the Internet. This guide describes typical Linux setup; any production GRE with HolyCloud must be validated by support.

Prerequisites

• Two endpoints with public IPs (VPS, dedicated server, router)
• root access on Linux servers
• ip_gre kernel modules available
• Parameters from HolyCloud if tunnel to scrubbing: tunnel local IPs, allowed prefixes

Do not create a GRE tunnel toward HolyCloud infrastructure without documented peering IP and any keys.

Logical diagram

[Site A — VPS 203.0.113.10] === GRE encapsulation ===> [Site B — 198.51.100.20]
         gre0 10.10.10.1/30                              gre0 10.10.10.2/30

Application traffic uses private tunnel IPs; encapsulation crosses the Internet between public IPs.

Site A — create GRE interface

modprobe ip_gre
ip tunnel add gre0 mode gre remote 198.51.100.20 local 203.0.113.10 ttl 255
ip addr add 10.10.10.1/30 dev gre0
ip link set gre0 up

• local: local public IP (outbound to Internet)
• remote: remote peer public IP
• 10.10.10.1/30: point-to-point IP on side A (B will be .2)

Site B — mirror configuration

modprobe ip_gre
ip tunnel add gre0 mode gre remote 203.0.113.10 local 198.51.100.20 ttl 255
ip addr add 10.10.10.2/30 dev gre0
ip link set gre0 up

Connectivity test

On A:

ping -c 4 10.10.10.2

Capture to verify encapsulation:

tcpdump -i eth0 host 198.51.100.20 and proto gre

Routing through the tunnel

Example: private network 192.168.50.0/24 behind site B, reachable from A:

On Site A:

ip route add 192.168.50.0/24 via 10.10.10.2 dev gre0

On Site B (return to A LAN 192.168.40.0/24):

ip route add 192.168.40.0/24 via 10.10.10.1 dev gre0

Enable IP forwarding if the VPS acts as a router:

sysctl -w net.ipv4.ip_forward=1

Firewall: allow proto 47 (GRE) and the tunnel subnet.

iptables -A INPUT -p gre -j ACCEPT
# or nftables equivalent

Persistence on reboot (netplan / Debian)

File /etc/systemd/network/gre0.netdev (systemd-networkd) or @reboot script.

Example /etc/network/interfaces.d/gre0 (ifupdown):

auto gre0
iface gre0 inet static
    address 10.10.10.1
    netmask 255.255.255.252
    pre-up ip tunnel add gre0 mode gre remote 198.51.100.20 local 203.0.113.10 ttl 255
    post-down ip tunnel del gre0

Adapt to your distribution (Ubuntu netplan, NetworkManager, etc.).

GRE and HolyCloud anti-DDoS

On advanced scrubbing offers:

Internet → [Filtering center] --GRE--> gre0 on your server → local services

Particularities:

• Only cleaned traffic arrives on gre0.
• The « raw » public IP may be removed from the main interface during attack.
• Reduced MTU (often 1476 or less) — adjust mtu on gre0 and TCP MSS:

ip link set gre0 mtu 1476

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Security

• GRE is not encrypted — for confidentiality, overlay IPsec or WireGuard.
• Filter on routers: accept GRE only from known remote IP.
• On Windows Server: GRE is possible but out of scope; prefer Linux or a dedicated router for documented HolyCloud scenarios.

Troubleshooting

| Symptom | Action |

|----------|--------|

| Tunnel ping fails | Firewall blocks proto 47; wrong local/remote IP |

| MTU / fragmentation | Lower gre0 MTU; MSS clamp |

| Asymmetric routing | Check ip route on both sides |

| Tunnel up, no remote LAN | ip_forward; static routes; misplaced NAT |

ip -d link show gre0
ip route get 192.168.50.1

Need help?

For GRE provisioning: provide public IPs of both ends, prefixes to route, IPv6 need (GRE over IPv6 possible). HolyCloud support provides official parameters and enables network-side peering.