• Routing Encapsulation
• GRE
• IPIP
• Choosing a Protocol
• Setting up
• Troubleshooting
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 Layer 3 protocol over an IP network. This functions more like a VPN than IPIP.
While you can use either/both GRE and IPIP, if you have to the biggest difference being that GRE has the following advantages:
• GRE tunnels allow multicast (one-to-many or many-to-many) packets
• GRE tunnels allow VPN wide area networks (WAN)
• Can interoperate with Cisco routers
• Better support on devices and systems that miss-interoperate IP-in-IP packets or are unable to forward them
• When using the optional tunnel identifier field can support up to 64K tunnels between two unique endpoints (IPv4 pairs)
The additional key field available in GRE protocol can provide additional tunnel authentication which increases security by increasing key-space which the 32-bit source address represents.
IP-in-IP is a simpler encapsulation protocol. Through IPIP, packets are only encapsulated in an additional IP header. So unlike GRE tunnels and IPIP cannot carry multicast traffic, other protocols, or IPv6 between networks.
In contrast to GRE tunnels, IP-in-IP tunnels have the following advantages:
• Lower overhead due to less layers encapsulated
• 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
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.
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.
So from your last point of setup,
uname -r
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, this 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 monetizing) direction.
2 -- Set up your own KVM and compile from source. You will need to know this 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.