GRE tunnels are traditionally used for unencrypted IP in IP tunneling.

Usages

If your company has two sites: One in Tel-Aviv Israel and the other in Brno Czech Republic, you might want to connect them in such a way that users feel as if they’re sitting in the same space. The two sites are behind a NAT and so normally a user in one office would not be able to ping or SSH into another user’s machine that’s sitting in the other office. Another usage of tunnels is remote work – A VPN is simply an encrypted tunnel. The idea is to get an IP address from your office’s pool so that employee services “think” you’re actually sitting inside the site walls and not in your pajamas. Another usage would be to enable IPv6 sites to communicate through an IPv4 network.

Example

The goal is to enable hosts in the Tel-Aviv branch the ability to ping hosts in the Brno branch. Without a tunnel this would not be possible. It’s done via statically configuring a GRE tunnel on both site routers, and requires no involvement from the different ISPs. If encryption is desired it can be later configured on top of the GRE tunnel. Two things need to be done on each router:

1. Bringing up a (virtual) tunnel device
2. Defining static routing to the remote 192.168.x.0/24 network through the local tunnel

Great – We configured the routers, but why do the pings suddenly work?

The flow work like this: Host 192.168.1.1 in the TLV office pings 192.168.2.1 in the Brno office. 192.168.1.1 prepares the ping, and the host’s TCP/IP stack implementation compares the source and destination IP addresses and subnet masks and notices (Computers tend to be pedantic like that) that they are in different layer 3 subnets. The host then forwards the packet to 192.168.2.1, but the layer 2 frame to the host’s default gateway MAC address.

The router receives the frame. It sees that the destination MAC address is of its LAN interface, but the destination IP address is not. It then searches for a match to 192.168.2.1 in its routing table, since we configured the router it should have a match for 192.168.2.0/24. The routing entry tells the router to forward the packet through the tunnel interface. Since the tunnel device is configured as a GRE tunnel the router performs the needed encapsulation to make it work.

GRE encapsulation

At this point the encapsulation is as follows:

The router then creates a new IP packet. The source IP will be 1.1.1.1 and the destination IP 2.2.2.2. In the IP packet it marks the next protocol as GRE (Normally it is TCP, UDP or ICMP, for example). It then creates a new GRE header, setting the important “next protocol” field as IPv4. Of course the router discards the Ethernet frame and creates a new layer 2 frame of the WAN technology type the router uses (For example: Cable or xDSL). The final encapsulation looks like this:

The effect is that routers throughout the internet see only the packet with a 1.1.1.1 source and 2.2.2.2 destination, routing it normally towards the Brno router. On the other end, the Brno router receives the message and sees that it is destined to itself. The packet says the next protocol in line is GRE, so the router opens the packet’s data as a GRE header. The next protocol field in that header is IPv4, so it opens the next header as an IP packet, and forwards that packet to the 192.168.2.1 host.

Resources

GRE header (Note 16 bit ‘Protocol Type’ and 32 bit optional key used in Neutron and Open vSwitch) – http://en.wikipedia.org/wiki/Generic_Routing_Encapsulation#Packet_header

GRE configuration in Cisco router (May aid understanding even if no interest in the configuration syntax or Cisco gear) – https://supportforums.cisco.com/docs/DOC-2569