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
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 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) 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 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 containing multiple spokes and a single backend IP on a Anycast Service.
- 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.
On Anycast services a Unified tunnel with a spoke defined for each location is required to make outgoing connections.
Advanced: How Unified tunnels work
NOTE: You don't need to know this, for all but the most advancted cases
tunnel.sh takes care of everything. This information however can be useful for troubleshooting or customization.
This information is valid for Linux on Windows x4bwintunnel takes care of all routing and forwarding in userland inside the Application (.exe).
What tunnel.sh installs for you:
- Policy Based Routes (PBR) via
- Routing tables with the prefix
X4B*and with IDs incrementing up from
- IPTables rules in the mangle table via
iptablesin system chains and in chains with the prefix of
What IPTables rules are installed?
X4BINP is responsible for marking every tunneled connection with a mark unique to the tunnel it originated on (or last communicated over). This mark (ctmark) will be used to ensure traffic that originates on one tunnel returns via the same tunnel.
The IPTables chain INPUT is responsible for calling the X4BINP chain. A rule is added for this.
If the packet is from an IP owned by the tunnel (non-exclusive mode) or if the connection entry has a connection mark (exclusive mode) then restore this (set) the packets mark. The policy based routing rules will use this mark to direct the packet to the appropriate tunnel.
The IPTables chain OUTPUT and FORWARD is responsible for calling the X4BOUT chain. Rules are added for this.
X4BPRE is called by the IPTable PREROUTING chain in the mangle table. This chain is used to handle packets for clients performing ip forwarding and nat activities (advanced setups).
We install rules in this chain to handle both X4BINP and X4BOUT roles as well as additional rules for handling customer nat matching (if tunnel.sh is not configured for exclusive control).
What do Policy Based Routes (PBR) do?
A policy based route is a rule that directs traffic to a specific network interface (e.g tunnel) given a specific set of conditions. In our case with unified tunnels this means a specific packet mark set by IPTables.
What is exclusive mode
Exclusive mode is disabled by default but is enabled by setting
X4B_EXCLUSIVE_MODE=1 in the generated tunnel.sh. This will relax the IPTables rules created in a way that may reduce compatibility with other scripts or services also using IPTables. This is however advisable in any double NAT or complex networking setup (for the sake of your sanity),
Exclusive mode requires that you allocate the fwmark & ctmark mask
0xff000000 exclusively to us. If you are running any other firewall scripts making use of fwmark or ctmark you must not enable this option.
When running with exclusive mode enabled the source IP address will not be checked before routing via the tunnel. This allows for modules that change the IP Address at a later stage (e.g SNAT/MASQUERADE) to function without excplicit rules being added.
Tunnels behind NAT (and consumer ISPs)
We get asked often if you can run a tunnel behind a NAT on a Consumer Grade (Residential) ISP. The answer is often yes, but you need a higher level of technical know-how to do it. We would generally advise our customers to run services on a non-consumer setup (such as a VPS or Dedicated server service). If however this setup still interests you our notes are below.
Requirements: - You need to know how to configure your NAT router to forward tunnel (i.e GRE) traffic to the destination within your local network. This may require placing your server on a "DMZ" which may forward all protocols depending on router implementation or replacement of your router or modem with a device with this capability. - You need to know that your ISP supports forwarding GRE traffic (some ISPs require business services to be able to use GRE tunnels). - You need to have a dedicated IP (no CGNAT) or dynamic (rotating) IPs - You need to know how to troubleshoot any issues and perform any maintenance required. We can not advise (outside of management) you on the successful operation of hardware or software within your local network (e.g your ISP issued router or modem).
Both provided scripts (
tunnel.sh) are technically compabile with NAT setups. Neither script can perform administration of hardware other than the server it is run on, if that device is a PC behind a NAT router this means that configuring that NAT router is your responsibility (not the script/applications). Or in other words our network will deliver traffic to your publicly routable network IP, if the server terminating the tunnel does not have that public IP directly attached then you will need to make appropriate configuration to route traffic from the device with the public IP to the server terminating the tunnel.
Setup for servers behind NAT is located in the header of
tunnel.sh (be sure to also disable auto-updates for your changes to apply) and automated when detected in WinTunnel (in some cases you will be asked questions via prompt).
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 tunnel.sh 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 a spoke is required to be defined in all regions.
Check your GRE/IP-in-IP script runs on boot and that it has been run (
ip tunnelwill return a list of tunnels active)
Check your firewall (
iptables-save). For Unified tunnels (multiple spokes) on Anycast services
tunnel.shwill install rules in the
mangletable 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
tunnel.shscript 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.xIP (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/IP-in-IP. 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 0.0.0.0 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.
- OLD: Kernels approximately within the range of 2.6.32-358 to 2.6.32-431 may have a MTU collapse issue resulting in intermittent tunnel failures. If you are using a kernel this old you should really upgrade.