GRE: The Simplest Linux Tunnel
In the previous chapter, we learned why large networks cannot rely entirely on a single Layer 2 domain and why modern infrastructures often build overlay networks on top of routed IP networks.
The simplest way to create an overlay network in Linux is with a tunnel.
A tunnel allows packets to be encapsulated inside other packets and transported across an intermediate network that may not understand or care about the original traffic.
One of the oldest and simplest tunneling technologies is GRE (Generic Routing Encapsulation).
Although newer technologies such as VXLAN are more common in modern cloud environments, GRE remains an excellent tool for understanding how tunnels work because it is simple, widely supported, and easy to inspect.
In this chapter, you will learn:
- What GRE is
- How GRE encapsulation works
- How Linux implements GRE tunnels
- How to build a GRE tunnel between two Linux hosts
- How packets travel through a GRE tunnel
- The limitations of GRE
What Is GRE?
GRE stands for:
Generic Routing Encapsulation
It is defined in RFC 2784.
GRE provides a mechanism for transporting one packet inside another packet.
Instead of sending an original packet directly across a network:
Original Packet
|
v
Network
GRE wraps the packet:
+----------------------+
| Outer IP Header |
+----------------------+
| GRE Header |
+----------------------+
| Original Packet |
+----------------------+
The network only sees the outer IP header.
The original packet remains unchanged inside the tunnel.
Why Would We Tunnel Packets?
Suppose we have two sites:
Site A Site B
10.1.1.0/24 10.2.2.0/24
| |
| |
Router A -------- Router B
Internet
The Internet only understands public IP addresses.
The private networks behind the routers are not directly connected.
A tunnel allows the routers to create a virtual link:
Site A Site B
10.1.1.0/24 10.2.2.0/24
| |
| |
Router A ========= Router B
GRE Tunnel
From the operating system's perspective, the tunnel behaves like a normal network interface.
GRE Creates a Virtual Point-to-Point Link
Think of GRE as a virtual cable.
Instead of connecting two machines with Ethernet:
Host A -------- Host B
We connect them through a routed network:
Host A ==== Internet ==== Host B
The GRE tunnel creates the illusion of a direct connection.
Linux treats the tunnel like any other interface:
ip link show
Example:
gre1
Routes can be installed through it.
Packets can be captured on it.
Applications are unaware that tunneling exists.
GRE Encapsulation
Assume Host A sends:
10.1.1.10 -> 10.2.2.10
Without a tunnel:
+-------------------+
| Original Packet |
+-------------------+
With GRE:
+------------------------+
| Outer IP Header |
| Src: 203.0.113.1 |
| Dst: 198.51.100.1 |
+------------------------+
| GRE Header |
+------------------------+
| Original IP Packet |
| Src: 10.1.1.10 |
| Dst: 10.2.2.10 |
+------------------------+
The intermediate routers only examine:
203.0.113.1 -> 198.51.100.1
They never inspect the encapsulated packet.
GRE Tunnel Endpoints
Every GRE tunnel requires two endpoints:
Tunnel Endpoint A
|
|
Network
|
|
Tunnel Endpoint B
Each endpoint needs:
- A reachable IP address
- Tunnel configuration
- Routes pointing traffic into the tunnel
The intermediate network does not need GRE awareness.
It simply forwards IP packets.
Lab Topology
We will create a tunnel between two Linux hosts.
Host A Host B
192.168.10.1 192.168.20.1
| |
| |
10.100.100.1 -------- 10.100.100.2
Physical Network
Tunnel addresses:
172.16.1.1/30
172.16.1.2/30
Result:
Host A
gre1 (172.16.1.1)
||
||
gre1 (172.16.1.2)
Host B
Creating a GRE Tunnel
On Host A:
sudo ip tunnel add gre1 \
mode gre \
local 10.100.100.1 \
remote 10.100.100.2
sudo ip addr add 172.16.1.1/30 dev gre1
sudo ip link set gre1 up
Verify:
ip addr show gre1
Creating the Other Side
On Host B:
sudo ip tunnel add gre1 \
mode gre \
local 10.100.100.2 \
remote 10.100.100.1
sudo ip addr add 172.16.1.2/30 dev gre1
sudo ip link set gre1 up
Verify:
ip addr show gre1
Testing Connectivity
Ping the tunnel endpoint:
From Host A:
ping 172.16.1.2
Expected:
64 bytes from 172.16.1.2:
Check routes:
ip route
You should see:
172.16.1.0/30 dev gre1
At this point, the tunnel behaves like a normal point-to-point link.
Routing Traffic Through the Tunnel
Suppose Host A owns:
192.168.10.0/24
and Host B owns:
192.168.20.0/24
Add routes on Host A:
sudo ip route add 192.168.20.0/24 via 172.16.1.2
Add routes on Host B:
sudo ip route add 192.168.10.0/24 via 172.16.1.1
Now traffic between the networks traverses the GRE tunnel.
Watching GRE Traffic
One of the best ways to understand tunnels is to capture packets.
Start tcpdump on Host A:
sudo tcpdump -ni any proto gre
Generate traffic:
ping 192.168.20.1
Example output:
IP 10.100.100.1 > 10.100.100.2: GREv0
Notice that the packet visible on the physical network is GRE traffic rather than the original packet.
Inspecting the Encapsulation
Capture packets in detail:
sudo tcpdump -ni any -vv proto gre
You will observe:
Outer IP Header
GRE Header
Inner IP Header
ICMP Payload
This directly demonstrates packet encapsulation.
A packet is literally being transported inside another packet.
Viewing Tunnel Configuration
List tunnel devices:
ip tunnel show
Example:
gre1:
mode gre
remote 10.100.100.2
local 10.100.100.1
This command is extremely useful when troubleshooting.
GRE Overhead
Encapsulation increases packet size.
Consider an original packet:
1500 bytes
GRE adds:
Outer IPv4 Header: 20 bytes
GRE Header: 4 bytes
Total:
24 bytes
New packet size:
1524 bytes
This creates a problem.
The physical network still has an MTU of:
1500
The packet is now too large.
MTU Problems
When encapsulation occurs:
Original Packet
+ Tunnel Headers
----------------
Packet Too Large
Possible outcomes:
- Fragmentation
- Packet drops
- Poor performance
This is one of the most common tunnel-related issues.
Inspect MTU:
ip link show gre1
Adjust MTU:
sudo ip link set gre1 mtu 1476
Why 1476?
1500 - 24 = 1476
This leaves room for GRE encapsulation.
GRE Is Not Encryption
A common misunderstanding is:
GRE secures traffic.
It does not.
GRE provides:
- Encapsulation
- Virtual connectivity
GRE does not provide:
- Encryption
- Authentication
- Confidentiality
Anyone capable of capturing packets can inspect the encapsulated traffic.
For secure tunnels, GRE is often combined with IPsec.
GRE in Real Environments
GRE is commonly used for:
- Site-to-site connectivity
- Routing experiments
- Overlay network education
- Transporting routing protocols
- Legacy VPN architectures
Historically, many enterprise networks used:
GRE + IPsec
GRE provided the tunnel.
IPsec provided security.
GRE Limitations
GRE is simple, but it does not solve every problem.
Some limitations include:
- No built-in encryption
- Point-to-point design
- Manual configuration
- Limited scalability
- Additional MTU complexity
As infrastructure grows, managing hundreds or thousands of GRE tunnels becomes impractical.
This limitation led to the development of technologies such as VXLAN.
GRE vs VXLAN
| Feature | GRE | VXLAN |
|---|---|---|
| Encapsulation | Yes | Yes |
| Layer 2 Extension | Limited | Yes |
| Multi-host Scalability | Poor | Excellent |
| Built-in Segmentation | No | Yes |
| Typical Use Today | Small tunnels | Large data centers |
| Cloud Native Usage | Rare | Common |
GRE is excellent for learning and simple deployments.
VXLAN was designed for large-scale virtual networking.
The next chapter focuses on VXLAN and the problems it solves.
Key Takeaways
- GRE encapsulates packets inside another IP packet.
- Linux implements GRE as a virtual network interface.
- GRE tunnels create virtual point-to-point links.
- Routing can be performed across GRE interfaces.
tcpdumpcan reveal GRE encapsulation in real time.- GRE introduces additional packet overhead.
- MTU adjustments are often necessary.
- GRE does not provide encryption.
- GRE is simple and useful, but does not scale well for large virtual networks.
- VXLAN was created to address many of GRE's scalability limitations.