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 (192.168.1.1 for the customer router and 192.168.1.2 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:
bash
CR1# configure terminalNow 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 77Next, configure the tunnel interface you just created with the private IP address for the CR1 router:
CR1(config if)# ip address 192.168.1.1 255.255.255.0Set 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, 3.3.3.1:
CR1(config if)# tunnel source 3.3.3.1You 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 4.4.4.1As 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](https://en.wikipedia.org/wiki/Maximum\_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 1476Consequently, you should change the [MSS](https://en.wikipedia.org/wiki/Maximum_segment_size) is 40 bytes lower than the MTU at 1436:
CR1(config if)# ip tcp adjust-mss 1436Now exit to privileged EXEC mode and check the IP settings on your router:
CR1(config if)# end
CR1# show IP interfaces briefYou should have output similar to the following, showing the tunnel interface with the IP you configured for it:
CR1# show IP interface briefInterface IP-Address OK? Method Status Protocol
GigabitEthernet0/0 3.3.3.1 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 192.168.1.1 YES manual up up
Test the connection to the remote router, SCR1, using the private tunnel IP address 192.168.1.2:
CR1# ping 192.168.1.2Your output should look similar to the image below, confirming a successful connection:
Finally, save your running configuration:
CR1# copy running-config startup-configYou 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 13.51.172.192 and 196.43.196.101, respectively:
bash
# ip tunnel add tunnel0 mode gre local 13.51.172.192 remote 196.43.196.101 ttl 255If 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:
bash
# hostname -f
ip-172-31-38-152.eu-north-1.compute.internalYou can now create the tunnel by replacing the local public IP 13.51.172.192 with the private IP 172.31.38.152 you just got, as seen below. This is not necessary if you are doing it on a physical server.
bash
# ip tunnel add tunnel0 mode gre local 172.31.38.152 remote 196.43.196.101 ttl 255Next, you need to add a private subnet to use for the tunnel, which is 192.168.0.2/30 in this example:
bash
# ip addr add 192.168.0.2/30 dev tunnel0Once this is done, you can now open the tunnel link using the following command:
bash
# ip link set tunnel0 upFinally, 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:
bash
# ping 192.168.0.1 -c4
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=275 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=275 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=275 ms
64 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=281 ms
--- 192.168.0.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 274.661/276.239/280.724/ ms
asAt 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:
bash
// 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 192.168.0.0/30 table GRE
// Set the default route to make sure all traffic goes via the tunnel remote server
# ip route add default via 192.168.0.1 table GREThat’s all! You have successfully set up a connection from your server through a GRE tunnel to a cleaning center.
Conclusion
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
