GRE and other tunnels
There are 3 kinds of tunnels in Linux. There's IP in IP tunneling, GRE tunneling and tunnels that live outside the kernel (like, for example PPTP)
-
A few general remarks about tunnels:
Tunnels can be used to do some very unusual and very cool stuff. They can also make things go horribly wrong when you don't configure them right. Don't point your default route to a tunnel device unless you know EXACTLY what you are doing :−). Furthermore, tunneling increases overhead, because it needs an extra set of IP headers. Typically this is 20 bytes per packet, so if the normal packet size (MTU) on a network is 1500 bytes, a packet that is sent through a tunnel can only be 1480 bytes big. This is not necessarily a problem, but be sure to read up on IP packet fragmentation/reassembly when you plan to connect large networks with tunnels. Oh, and of course, the fastest way to dig a tunnel is to dig at both sides.
-
IP in IP tunneling
This kind of tunneling has been available in Linux for a long time. It requires 2 kernel modules, ipip.o and new_tunnel.o.
Let's say you have 3 networks: Internal networks A and B, and intermediate network C (or let's say, Internet). So we have network A:
network 10.0.1.0
netmask 255.255.255.0
router 10.0.1.1The router has address 172.16.17.18 on network C.
and network B:
network 10.0.2.0
netmask 255.255.255.0
router 10.0.2.1
The router has address 172.19.20.21 on network C.
As far as network C is concerned, we assume that it will pass any packet sent from A to B and vice versa. You might even use the Internet for this.
Here's what you do:
First, make sure the modules are installed:
insmod ipip.o
insmod new_tunnel.o
Then, on the router of network A, you do the following
ifconfig tunl0 10.0.1.1 pointopoint 172.19.20.21
route add -net 10.0.2.0 netmask 255.255.255.0 dev tunl0
And on the router of network B:
ifconfig tunl0 10.0.2.1 pointopoint 172.16.17.18
route add -net 10.0.1.0 netmask 255.255.255.0 dev tunl0
And if you're finished with your tunnel:
ifconfig tunl0 down
Presto, you're done. You can't forward broadcast or IPv6 traffic through an IP−in−IP tunnel, though. You just connect 2 IPv4 networks that normally wouldn't be able to talk to each other, that's all. As far as compatibility goes, this code has been around a long time, so it's compatible all the way back to 1.3 kernels. Linux IP−in−IP tunneling doesn't work with other Operating Systems or routers, as far as I know. It's simple, it works. Use it if you have to, otherwise use GRE.
-
GRE tunneling
GRE is a tunneling protocol that was originally developed by Cisco, and it can do a few more things than IP−in−IP tunneling. For example, you can also transport multicast traffic and IPv6 through a GRE tunnel.
In Linux, you'll need the ip_gre.o module.- IPv4 Tunneling
Let's do IPv4 tunneling first:
Say you have 3 networks: Internal networks A and B, and intermediate network C (or let's say, Internet).
So we have network A:
network 10.0.1.0
netmask 255.255.255.0
router 10.0.1.1
The router has address 172.16.17.18 on network C. Let's call this network neta (ok, hardly original)
and network B:
network 10.0.2.0
netmask 255.255.255.0
router 10.0.2.1
The router has address 172.19.20.21 on network C. Let's call this network netb (still not original)
As far as network C is concerned, we assume that it will pass any packet sent from A to B and vice versa. How and why, we do not care.
On the router of network A, you do the following:
ip tunnel add netb mode gre remote 172.19.20.21 local 172.16.17.18 ttl 255
ip link set netb up
ip addr add 10.0.1.1 dev netb
ip route add 10.0.2.0/24 dev netb
In line 1, we added a tunnel device, and called it netb (which is kind of obvious because that's where we want it to go). Furthermore we told it to use the GRE protocol (mode gre), that the remote address is 172.19.20.21 (the router at the other end), that our tunneling packets should originate from 172.16.17.18 (which allows your router to have several IP addresses on network C and let you decide which one to use for tunneling) and that the TTL field of the packet should be set to 255 (ttl 255).
The second line enables the device.
In the third line we gave the newly born interface netb the address 10.0.1.1. This is OK for smaller networks, but when you're starting up a mining expedition (LOTS of tunnels), you might want to consider using another IP range for tunneling interfaces (in this example, you could use 10.0.3.0).
In the fourth line we set the route for network B. Note the different notation for the netmask. If you're not familiar with this notation, here's how it works: you write out the netmask in binary form, and you count all the ones. If you don't know how to do that, just remember that 255.0.0.0 is /8, 255.255.0.0 is /16 and 255.255.255.0 is /24. Oh, and 255.255.254.0 is /23, in case you were wondering.
But enough about this, let's go on with the router of network B.
ip tunnel add neta mode gre remote 172.16.17.18 local 172.19.20.21 ttl 255
ip link set neta up
ip addr add 10.0.2.1 dev neta
ip route add 10.0.1.0/24 dev neta
And when you want to remove the tunnel on router A:
ip link set netb down
ip tunnel del netb
Of course, you can replace netb with neta for router B.
-
IPv6 Tunneling
See Section 6 for a short bit about IPv6 Addresses.
On with the tunnels.
Let's assume that you have the following IPv6 network, and you want to connect it to 6bone, or a friend.Network 3ffe:406:5:1:5:a:2:1/96
Your IPv4 address is 172.16.17.18, and the 6bone router has IPv4 address 172.22.23.24.
ip tunnel add sixbone mode sit remote 172.22.23.24 local 172.16.17.18 ttl 255
ip link set sixbone up
ip addr add 3ffe:406:5:1:5:a:2:1/96 dev sixbone
ip route add 3ffe::/15 dev sixbone
In the first line, we created a tunnel device called sixbone. We gave it mode sit (which is IPv6 in IPv4 tunneling) and told it where to go to (remote) and where to come from (local). TTL is set to maximum, 255. Next, we made the device active (up). After that, we added our own network address, and set a route for 3ffe::/15 (which is currently all of 6bone) through the tunnel.
GRE tunnels are currently the preferred type of tunneling. It's a standard that is also widely adopted outside the Linux community and therefore a Good Thing.
