Protecting Collocated Servers from DDoS Attacks Using GRE Tunnels

For any business that relies heavily on online sales and transactions, the growing number of cyberattacks targeting e-commerce websites is a growing concern.

E-commerce websites are vulnerable to attacks such as distributed denial of service (DDoS) and brute force attacks, which can result in the loss of valuable business traffic from legitimate customers or the compromise of their users’ sensitive information.

Fortunately, you can get another layer of protection remotely as long as your servers use a Generic Routing Encapsulation (GRE) tunnel. Such a tunnel helps to establish a private connection between your servers or network and a debugging center.

This allows the protection provider to scan all of your incoming traffic for malicious activity and block any potential threats before they can reach your servers.

After your incoming traffic is scanned, all secure traffic is forwarded to your network or servers for processing via the GRE tunnel. The response from your server is sent through the GRE tunnel to the debugging center and to the client.

Together with Gcore, a global security provider, we’ll explain what GRE tunnels are and how they help keep your data safe. It will then walk you through how to configure your routers and hosts in your data center to establish a seamless and secure connection to the Gcore debug center via a GRE tunnel.

Specifically, the article will explain how to configure a GRE tunnel interface to communicate over the Internet on a Cisco router or Linux host.

What is a GRE tunnel and how does it work?

A Generic Routing Encapsulation (GRE) tunnel is a network connection that uses the GRE protocol to encapsulate a variety of network layer protocols within point-to-point virtual links over an Internet Protocol (IP) network. It allows remote sites to connect to a single network as if both were directly connected to each other or to the same physical network infrastructure.

GRE is often used to extend a private network over the public Internet, allowing remote users to securely access resources on the private network.

GRE tunnels and VPNs may appear to be the same thing. However, GRE tunnels can carry or forward multicast traffic, which is essential for things like advertising routing protocols and for video conferencing applications, whereas a VPN can only carry unicast traffic.

Also, traffic through GRE tunnels is not encrypted by default, but VPNs offer different methods of encryption through the IPsec protocol suite, and your traffic can be end-to-end encrypted.

However, the traffic transmitted through most sites employs encryption standards such as TLS/SSL for all communications.

You can think of a GRE tunnel as a “tunnel” or “underground” connecting two different networks (eg your company’s private network and the Gcore debugging center network). Just like an underground tunnel allows people to travel between different stations, a GRE tunnel allows data to travel between different networks.

The “train” in this analogy is a data packet that is sent through the tunnel. These packets are “encapsulated,” or wrapped with a GRE header, which tells the network where the packets are coming from and where they are going, similar to how a subway train has a destination front and back.

Once the packets arrive at the “destination station”, the GRE header is removed and the original packets are sent to their intended destination. In this way, data can travel securely and privately over the public internet as if it were a private network.

Configuring your network hosts for GRE tunnels

Now that you understand what a GRE tunnel is, the following sections will show you how to configure tunnel interfaces on a Cisco router and a Linux server inside your data center. You will also be shown how to configure private IP addresses on these tunnel interfaces and test the connections.

Configuring a GRE tunnel on a Cisco router

First, you’ll configure your Cisco router to establish a connection to the Gcore debugging center via a GRE tunnel over the public Internet, as seen in the following diagram:

In the diagram above, both routers have physical public IPs that they can use to directly connect and interact on the Internet through their respective ISPs. There is also a private network behind the routers on both ends and private IPs for the tunnel interfaces ( for the customer router and for the debug center router).

Through a public connection over the Internet, a private connection is established using the private IPs on the tunnel interface as if the two tunnel interfaces on each device were physically directly connected to the same network.

First, connect to your router, either via a console cable directly or via SSH if you have it set up, and enter global configuration mode with the following command:

CR1# configure terminal

Now you can create a virtual tunnel interface. The tunnel interface can be any number you like. The following example uses 77 and also puts you in interface configuration mode:

CR1(config)# interface tunnel 77

Next, configure the tunnel interface you just created with the private IP address for the CR1 router:

CR1(config if)# ip address

Set the tunnel source or the interface through which the tunnel establishes a connection from your router. In the following example, the source is the public IP of the customer’s router,

CR1(config if)# tunnel source

You must also configure the tunnel destination; in this case, the public IP address of the debug center router, through which you connect to the private tunnel interface of that router:

CR1(config if)# tunnel destination

As you know, GRE adds additional headers with information to the original packets. This changes the packet size by 24 bytes over the standard [MTU limit](\_transmission\_unit) of 1500 bytes, which can cause packet drops. You can resolve this by lowering the MTU by 24 bytes to 1476, so that the MTU plus any additional headers does not exceed 1500:

CR1(config if)# ip mtu 1476

Consequently, you should change the [MSS]( is 40 bytes lower than the MTU at 1436:

CR1(config if)# ip tcp adjust-mss 1436

Now exit to privileged EXEC mode and check the IP settings on your router:

CR1(config if)# end
CR1# show IP interfaces brief

You should have output similar to the following, showing the tunnel interface with the IP you configured for it:

CR1# show IP interface brief
Interface                  IP-Address      	OK? Method   Status                Protocol
GigabitEthernet0/0         	YES manual   up                      up      
GigabitEthernet0/1         unassigned      	YES NVRAM    down                    down    
GigabitEthernet0/2         unassigned     	YES NVRAM    administratively down   down    
GigabitEthernet0/3         unassigned      	YES NVRAM    administratively down   down    
Tunnel77              	YES manual   up                      up    

Test the connection to the remote router, SCR1, using the private tunnel IP address

CR1# ping

Your output should look similar to the image below, confirming a successful connection:

Finally, save your running configuration:

CR1# copy running-config startup-config

You have successfully configured your router to establish a connection through a GRE tunnel.

Configuring a GRE tunnel on a Linux server

This section explains how to configure the tunnel interface and establish a connection through the GRE tunnel to the remote server. This particular configuration uses the Ubuntu 20 LTS operating system.

Below is a configuration diagram illustrating the various aspects of this configuration:

Create a new tunnel using the GRE protocol from your server’s public IP address to the remote server’s IP, in this case and, respectively:

# ip tunnel add tunnel0 mode gre local remote ttl 255

If you are using an Amazon EC2 instance or similar VPC behind a network or application firewall, then you need to get the instance’s private IP because public IP traffic is only routed to and from the VPC via a private IP .

As you can see in the output of the following command, the instance’s private IP is hyphenated in the fully qualified hostname of its VPC:

# hostname -f

You can now create the tunnel by replacing the local public IP with the private IP you just got, as seen below. This is not necessary if you are doing it on a physical server.

# ip tunnel add tunnel0 mode gre local remote ttl 255

Next, you need to add a private subnet to use for the tunnel, which is in this example:

# ip addr add dev tunnel0

Once this is done, you can now open the tunnel link using the following command:

# ip link set tunnel0 up

Finally, test if the remote server can be reached through the tunnel by pinging its tunnel IP address, as seen in the output below, which means a successful connection through the GRE tunnel:

# ping -c4 
PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=64 time=275 ms
64 bytes from icmp_seq=2 ttl=64 time=275 ms
64 bytes from icmp_seq=3 ttl=64 time=275 ms
64 bytes from icmp_seq=4 ttl=64 time=281 ms

--- ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 274.661/276.239/280.724/ ms

At this point, you need to ensure that all traffic coming to you through the tunnel has the reply routed back through the tunnel by adding some rules to your routing table. Use the following commands:

// Create the routing table
# echo '100 GRE' >> /etc/iproute2/rt_tables

// Respect the rules for the private subnet via that table
# ip rule add from table GRE

// Set the default route to make sure all traffic goes via the tunnel remote server
# ip route add default via table GRE

That’s all! You have successfully set up a connection from your server through a GRE tunnel to a cleaning center.


In this article, you learned what a GRE tunnel is and how it works. We discussed how a GRE tunnel can protect your servers from cyberattacks such as denial of service attacks by routing incoming network traffic through Gcore’s scrubbing center.

Then we explain how to set up a GRE tunnel connection using your Cisco router or your Linux server.

We prepared this article in collaboration with Gcore, a provider of powerful web and server protection with multi-Tbps filtering capacity on every continent except Antarctica.

Gcore can protect the servers in its data centers as well as the servers in customer data centers using the GRE tunnel. Both forms provide clients with protection against high-volume attacks with less than 1ms latency.

Sponsored and written by Gcore

Source link

James D. Brown
James D. Brown
Articles: 8614