Server config — IPIP and GRE Tunneling


Routing Encapsulation
 — GRE
 — Choosing a Protocol
 — Setting up
 — Troubleshooting

Routing Encapsulation

Like a proxy, tunneling allows you to pass traffic from a filtered IP to another destination. Tunnels are much like a VPN, except that not every tunnel involves encryption. A machine that is “tunneled” into another network has a virtual interface configured with an IP that is not local, but exists on a remote network. This traffic is forwarded in the form of packets at the kernel level, and therefore not susceptible to server interruptions.

Below is a quick summary of both protocols, check here for more details, or move directly to Troubleshooting if you want to get straight into it.

What’s important about tunnels is that they forward all packet details without packet modifications required for techniques such as Reverse Proxying and Transparent Proxying, namely, the clients connecting IP address is preserved.


Generic Routing Encapsulation (GRE) is used as a tool for conveying a tunneling OSI protocol over an IP network. This functions more like a VPN than IPIP does.

While you can more often that not use either/both GRE and IPIP, GRE is often a more robust option. GRE has the following advantages:

— GRE tunnels allow multicast (one-to-many or many-to-many) packets
— Allow VPN wide area networks (WAN)
— Can interoperate with Cisco routers


The additional key field available in GRE protocol can provide additional tunnel authentication which increases security by increasing key-space represented by a 32-bit source address.


IP-in-IP is a simpler encapsulation protocol. Through IPIP, packets are only encapsulated in an additional IP header. So unlike GRE tunnels, IPIP cannot carry multicast traffic, other protocols, or IPv6 between networks.

IP-in-IP tunnels have the following advantages:

— Lower overhead due to fewer encapsulated layers
— Use of IP packets for encapsulation can allow for support (e.g. forwarding) on devices not supporting the GRE protocol
— Supports a single tunnel between two endpoints

Choosing a Protocol

It us uncommon that you’ll be doing any non-IP (like routing, or research-based) protocols, but in such a case you’ll need GRE. And while lower overhead is easier, the difference in setup is nearly negligible, and given the added security, GRE is often the better option if a decision has to be made.

Setting up

More often than not, once you register an IP and get the green light from IT, one or both of these protocols will have already been set up on your kernel. You can confirm this by sshing into your server and checking the configuration. The following flow will confirm the existence (or lack) of your protocols, and manage how to configure it.

modprobe ip_gre modprobe ipip
 modprobe is used for making additions/deletions/prioritizing existing modules within your kernel.

These will load the kernel modules. If you get nothing back from either of these, you’re all set, and the configuration is good to either be configured, or has already been set up.

If that is not the case you’ll get back
 FATAL: Module ipip not found.

And will need to continue from Troubleshooting.

Next check if they fully configured the tunnel protocol

You can confirm which by checking ifconfig for something like
 tunnel <tunnel name> (IPIP Tunnel)

If this is set you should be golden. Otherwise, follow this guideline for hooking up IPIP and/or GRE manually.


Continuing from your last point of setup enter
 uname -r
 To list the current working/bootup kernel version. You'll need to know this.

modprobe -c | grep ipip
 modprobe -c | grep ip_gre
 If these exist at all, you'll want to check where:

ls -l /lib/modules
 Check this directory for a list of kernels, and look for the current one.

If the config was found, check which modules.dep files contain them,
 $ grep ip_gre /lib/modules/<working kernel>/modules.dep

kernel/net/ipv4/ip_gre.ko: kernel/net/ipv4/ip_tunnel.ko kernel/net/ipv4/gre.ko
 Confirm whether it belongs to boot.

If you don’t have any configuration set for your bootup kernel
 $ wc -l /lib/modules/<working kernel>/modules.dep

0 /lib/modules/<working kernel>/modules.dep
 You'll get something like this back.

Unfortunately, and atypically, this most likely means the janky DPS didn’t set this up for you. If this is the case you pretty much have 3 choices:

1 — Submit a ticket with the DPS. They will either configure it for you, or point you in the right (but likely expense-dependent) direction.

2 — Set up your own KVM and compile from source. You will need to know this source in advance. (I’ll be writing a tutorial after I finish configuring my own, but for now check out the link in Setting up.

3 — Find a new DPS and recreate the server.

Hope this helps.

Originally published at