• Created on:2021-08-22 17:36:49
  • How to set up a GRE/IPIP tunnel Linux

Much like a proxy, a Tunnel allows you to pass traffic from your filtered IP to another destination. This traffic is forwarded as packets at a kernel-level as encapsulated traffic. A tunnel also forwards all packet details without the packet modifications required for techniques such as Reverse Proxying (RP), specifically this means clients connecting IP address is preserved.

Microsoft Windows does not support GRE or IPIP natively. GRE & IP-in-IP can be used on Microsoft Windows via a client developed for eFlame customers (Which we will send you in your email after purchase)

Note: This method is more complex than the standard Reverse Proxy method. Unlike the former method, this requires software/configuration on your backend server and should only be attempted by those with a reasonable level of Linux command line experience.

Using Choose the appropriate process for your operating system.

On Linux & FreeBSD

This process has been tested on common versions of Debian, CentOS and a large number of Ubuntu server versions. FreeBSD is somewhat supported on a best effort basis.


You will need to ensure that your backend has support for tunnels. A simple way to check this on Linux is to ensure that the ipip and/or ip_gre kernel modules are loaded. This can be done with the following commands. lsmod | grep ipip lsmod | grep ip_gre In some custom kernels, this feature may not be provided by modules, and may instead be compiled into the kernel. Additionally, it may also be possible to load these modules via modprobe if available. If something is returned, then they are loaded. On OpenVZ/LXC Virtual Private Servers you will be unable to load kernel modules. If not loaded you will need to request your provider load them. You should also ensure that if you are using an upstream firewall that UDP is unblocked. While GRE and IPIP are not transited over UDP, the transmission mode is similar and they can be grouped by firewalls. You may need to check with your provider in this regard too. These steps should work on any Linux Distribution with the iproute2 package and up to date supporting tools. These steps require kernel modules and tools installed by default in vanilla (standard) installations of most common Linux distributions. You can choose to start the tunnel your own way, this is just one example of the possible ways to do this task.

Step 1: Buy the service from us.

You will have to provide us with the backend IP, all the ports and protocols you will be using via the tunnel and wait for us to do work on our side.

Step 2:

We will send you the Commands to execute in your Linux server to download the script.

Step 3:

After the script is downloaded you will have to execute the following commands:

First, you should be able to run the downloaded tunnel.sh script on your server. This will install the tunnels for your current session.


This script needs to be run on boot, and should hence be set up to run on boot. If you are running a SysV style init process (i.e not new Debian, CentOS or Ubuntu distributions) then you can install the tunnel with a simple execution of:

./tunnel.sh install

On Windows, See the article on IP/IP on Windows for Microsoft Windows instructions.


Check your GRE/IPIP script runs on boot and that it has been run (ip tunnel will return a list of tunnels active) Check your firewall (iptables-save). For Anycast services tunnel.sh will install rules in the mangle table which should be checked. Certain firewall software may erase rules not created by it and compability should be checked with any software you are running. Check for X4B tables in ip rule. The tunnel.sh script creates policy based routing rules to ensure that tunnel traffic returns over the tunnel. These should exist for all tunnels deployed with tunnel.sh. Pinging over the 10.x.x.x IP (e.g to the gateway) should result in GRE traffic over your primary interface. You can inspect for this with tcpdump -n ip proto 47. You should see both a request and a reply. Not seeing a reply may indicate a hardware/provider level firewall. Check your connectivity to your backend communication IP(s) (ping [proxy ip]) from your backend Check any firewalls are disabled and the proxy IP is whitelisted (you and your provider) Check your provider does not filter GRE/IPIP. Verify correct operation of your tunnel using tools like tcpdump or ask them. If your tunnel is online, but your service offline then check your service is correctly bound to the 10.x.x.x address you are given (netstat -ln). Look for a listening port on or 10.x.x.x