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.
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 ip_gre kernel modules are loaded. This can be done with the following commands. 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.
lsmod | grep ipip lsmod | grep ip_gre
If something is returned, then they are loaded. On OpenVZ Virtual Private Servers these commands will most likely not return anything for security reasons. In this case you should ask your provider if GRE and/or IPIP is enabled and supported.
You should also ensure that if you are using a 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
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
You can now download the script which has been generated to install your GRE, IP-in-IP or IPSec 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 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 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:
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.
See the article on IP/IP on Windows for Microsoft Windows instructions.
Types of tunnel supported include IP-in-IP (IPIP), GRE and IPSec
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.
IPSec is an advanced networking protocol for full encryption of the tunnelled data. In our case with the data being encrypted with a Pre-Shared Key (PSK or security key). This is not for the feint of heart, and is likely not compatible with any form of NAT or consumer hardware.
The Windows Client support IPSec, tested on Windows 8 and Windows 2012. An automated script for configuring the IPSec tunnel is provided for Linux, FreeBSD automated configuration is currently not provided. The script for linux requires that you have a working Strongswan or Openswan service and will most likely not work on OpenVZ (unless your provider has jumped through ALOT of hoops). Due to these external elements its is very hard for us to offer support for any issues experienced with this type of tunnel.
It is recommended that you add
ipsec up x4b-tunnel to a cron job running every minute to ensure that your IPSec tunnel does not fall offline in periods of inactivity.
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 10.17.0.0/16 range. 10.17.240.0/20 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.
The terminology Unified Tunnel is used to refer to a specific type of tunnel that meet the following conditions:
- Tunnels between Multiple Filtered IPs (Multihomed service) and a single backend IPs.
- 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 need to check before opening a support ticket. Be sure to include as much information as you can in the support ticket.
- 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.
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.