Generic routing encapsulation (GRE) is a communication protocol used to establish a direct, point-to-point connection between network nodes. Being a simple and effective method of transporting data over a public network, such as the Internet, GRE lets two peers share data they wouldn’t be able to share over the public network itself.
GRE protocol offers a number of advantages, including:
- Use of multiple protocols over a single-protocol backbone
- Providing workarounds for networks with limited hops
- Connection of non-contiguous subnetworks
- Being less resource demanding than its alternatives (e.g. IPsec VPN)
Imperva Incapsula uses GRE to establish a direct connection to our clients’ servers, after virtually deploying our DDoS mitigation solution at the edge of their network.
Regardless of the DDoS attack type or target, this enables us to provide protection for every type of network infrastructure, across all communication protocols—because of GRE’s ability to transmit packets of all types.
In this post we shed some light on the GRE protocol: how it works, what it is capable of and how it can be effectively utilized.
Like Mailing a Package
Before diving into GRE, let’s discuss how Internet communication works in general. When one computer needs to send information to another over a network, the data is divided into a series of packets—small bits of the original data. Each packet contains both user data and control information.
User data, (a.k.a., the payload), is the actual content being sent. Control information, on the other hand, comprises instructions required for the content to reach its destination—including source and destination IP addresses, error codes, etc.
In this way, a network packet is similar to a package being delivered in the mail, with user data representing the content inside the package and control information as the delivery instructions found on it.
Network packets and mailed packages also resemble each other in the way they travel from their point of origin to their final destination.
When a package is sent, it makes several stops during the delivery process, passing through at least two post offices. The same goes for data packets, which need to journey between several ISP networks as they move across the globe.
Certain rules have to be observed in both cases. For example, your package must have the correct stamps and be of a certain size and weight. Similarly, data packets need to comply with the rules of a given network in which they are passing through, which may or may not support certain packet sizes and communication protocol types (e.g., AppleTalk).
If the rules aren’t observed, your packet can’t be delivered. This is where GRE is useful.
Repackaging Your T-Rex Replica
A GRE is similar to a multi-faceted delivery service that can handle any kind of package—from a nylon bag full of water to a life sized T-rex replica—transporting it from door-to-door. It simply takes whatever you give it, puts it in one of its own boxes, slaps an address label on it and gets it to where it needs to go.
GRE does essentially the same thing in a process called encapsulation, which takes a data packet being sent and “repackages” it. This is achieved by adding two additional headers, one identifying it as a GRE packet and the second to provide new source and destination IPs.
Transporting Data Through a GRE Tunnel
For an encapsulated packet to be transmitted, a GRE tunnel must be established. This is a virtual point-to-point connection between two networks—a safe passage that enables direct, “no-questions asked,” door-to-door delivery.
With a tunnel in place, a GRE packet can travel directly between its two endpoints. That the tunnel is virtual means that, even as the packet travels through other routers, there is no interaction with its payload. Instead, the packet is pushed forward until it reaches the tunnel’s endpoint, where the outer packet is de-encapsulated and the payload parsed.
GRE Tunnel Configuration
A GRE tunnel is established on a router level and differs depending on the hardware type or service you use. Typically you’ll be required to set up the tunnel interface IPs and provide public IP addresses for both ends of the GRE tunnel.
Here is an example of a tunnel set up between two Cisco routers:
|Router 1: R1||Router 2: R2|
|R1(config)# interface Tunnel1||R2(config)# interface Tunnel1|
|R1(config-if)# ip address
|R1(config-if)# ip mtu 1400||R2(config-if)# ip mtu 1400|
|R1(config-if)# ip tcp adjust-mss 1360||R2(config-if)# ip tcp adjust-mss 1360|
|R1(config-if)# tunnel source 126.96.36.199||R2(config-if)# tunnel source 188.8.131.52|
|R1(config-if)# tunnel destination 184.108.40.206||R2(config-if)# tunnel destination 220.127.116.11|
It is important to remember that you may have to whitelist source addresses in firewalls on both ends of the tunnel. However, it is best practice to terminate the tunnel ahead of your firewall so it can inspect inner packets.
Another item to note is the maximum transmission unit (MTU) you set for the tunnel. Ethernet MTU is generally 1500 bytes. When using GRE, however, the additional header has an overhead of another 24 bytes that needs to be taken into account.
Therefore, when establishing a GRE tunnel with a symmetric traffic flow, we recommend setting the MTU to 1400 bytes, as shown in the above example.
For more questions about GRE tunneling and to learn how it’s being implemented in Incapsula’s DDoS mitigation services, contact us here or simply leave a comment below.