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 X4B customers. For more information on Windows Tunnel support click here.

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.


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 with 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: Create and Tunnel and configure your service

First define a tunnel between your filtered IP and your backend using the interface provided. Then forward all necessary ports needed for your service, these should be created with the Encapsulated / NAT port types and be linked to the previously created tunnel.

Step 2: Download The Tunnel Script

Action > Setup Tunnel

After configuring a backend, and adding all the required port forwards to that tunnel backend you can get a script from the Setup Tunnel page (On the tunnel Action > Setup Tunnel) that you need to ensure runs on each boot of your server to start up the tunnel.

Step 3: Download The Tunnel Script

Download the Tunnel Script

You can now download the script which has been generated to install your GRE, IP-in-IP tunnel. If you are installing multiple tunnels, or you have multiple tunnels to the same backend IP address (i.e with multiple services) you should check the configuration matches your requirements.

Step 4: Install the Tunnel on your server

First you should be able to run the downloaded 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 setup 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:

./ install

Unfortunately we do not support SystemD at this time. If you are running SystemD you will need to setup the script to run on boot manually.

On Windows

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

Tunnel Types

Types of tunnel supported include IP-in-IP (IPIP) and GRE

IP-in-IP or GRE?

To help you make your decision between the two protocols a comprehensive article has been written. If in doubt, we recommend that you use Generic Routing Encapsulation (GRE) if supported.


Retrieving the Client IP

For TCP (Tunnel) and UDP (Tunnel) ports the client IP is available without any backend modifications.

For HTTP (Tunnel) or HTTPS (Tunnel) ports the Client IP is provided in an additional HTTP header. The IP can be retrieved with a web server model or through code (See the Real IP article. This is the same technique as used with HTTP reverse proxy services.


GRE / IPIP Tunnels improve the security and resilience to malicious attacks. This includes susceptibility to backend IP discovery attacks. Most IP discovery attacks are performed through missconfigured web environments or insecure services. In these cases with a GRE/IPIP tunnel the service is bound to a 10.x.x.x address, instead of the backend public IP and as such will only leak the internal IP (which to an attacker is useless).


Border Gateway Protocol is a standardised network protocol for exchanging routes and reachability information. For us this enables redundancy through Fallback & Failover for customers utilizing a GRE tunnel with their backend.

When creating a tunnel, you may choose to create a BGP Tunnel. Unfortunately at this time BGP can not be enabled on existing non-BGP tunnels. When enabled traffic will only be routed to the tunnel if a session is enabled and online. You may define multiple backends, with each getting their own session per tunnel. Traffic will be routed to the online backend with the highest local preference value.

Tunnels created for BGP will have a subnet in the range. is used for BGP peering. We will allocate you a ASN in the 32bit private ASN range. If you have your own ASN number that you wish to use and own (LOA required), please contact support.

Many BGP clients exist including Bird, Quagga and ExaBGP. You may also use a router or hardware solution. If you are unsure or have no preference then on Linux we recommend Bird. A tutorial for setup with Bird is available for Linux.

Unified Tunnels

The terminology Unified Tunnel is used to refer to a specific type of tunnel that meet the following conditions:

  1. Tunnels between Multiple Filtered IPs (Multihomed service) and a single backend IPs.
  2. The same internal subnet (i.e 10.x.x.x/30), and hence a single backend IP shared between all tunnels.

These are a very specific type of tunnel and are supported on Linux and Windows only (not BSD or third party solutions). To run these tunnels on Linux you will require a server with IP Conntrack (ip_conntrack) enabled. Support is included in X4BWinTunnel for Windows Unified Tunnels, this does not require any external software.


There are lots of things you should check before opening a support ticket. Please be sure to include as much information as you can in the support ticket, please remember that we do not have access to your backend (unless you provide a technical reading we won't have it). Unless we are contracted to provide management of your backend service it is strongly recommended you collect readings and identify the cause of your issue within reason before opening your ticket in order to make the best use of the resources available.

Things you should check:

  • Check that you have a tunnel defined in the X4B panel and that you have at-least one Port referencing it. Check that you have not accidentally created a Reverse Proxy port, the port backend type will be "Encapsulated" or "Routed". A port must be defined referencing a tunnel for that tunnel to be deployed in a region.

  • If you have modified your tunnel configuration since downloading the script you will need a new script and to run that script.

  • Check your configuration is sane, that you for example have defined tunnel spokes for the regions you are accessing from and ports referencing those. If making outgoing connections over the tunnel is required to be defined in all regions.

  • 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 will install rules in the mangle table which should exist. Certain firewall software may erase rules not created by it and compability should be checked with any firewall software you are running.

  • Check for X4B tables in ip rule. The script creates policy based routing rules to ensure that tunnel traffic returns over the tunnel. These should exist for all tunnels deployed with

  • 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 [backend 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 (Wireshark on Windows) 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


  • Each Tunnel Backend must be used at-least once in order to be deployed. If you are looking to send outgoing connections you will need to create a single incoming port.
  • Some Residential ISPs filter GRE & IP-in-IP traffic. Barely any consumer grade routers support GRE/IP-in-IP NAT, although most can handle it with a DMZ.

Known Issues with certain Linux kernels (OLD).

Kernels approximately within the range of 2.6.32-358.23.2.el6.x86_64 to 2.6.32-431.el6.x86_64 may have a MTU collapse issue resulting in intermittent tunnel failures. We recommend using a modern kernel.

More Information: