LFCE 32 🐧 GRE Tunnels
Generic Routing Encapsulation (GRE) is a tunneling protocol that wraps one network-layer protocol inside another. In its most common Linux configuration, GRE encapsulates IPv4 or IPv6 packets inside an outer IPv4 packet, creating a point-to-point virtual link between two routers across an IP underlay . The Linux kernel implements GRE as a virtual network interface, created with ip tunnel add mode gre, which behaves like a physical point-to-point link for routing purposes. Unlike VXLAN, which was designed for large-scale Layer 2 overlay networking, GRE is a simpler, older protocol that operates at Layer 3. It does not carry Ethernet frames, it does not provide tenant segmentation through a 24-bit identifier, and it does not encrypt. It is a straightforward IP-in-IP tunnel with support for optional keys, checksums, and TTL settings.
For the LFCE candidate, GRE tunnels appear in the networking domain as a method for configuring network traffic tunneling . They are used to connect two private networks across a public IP network, to create a virtual link between two routers that are not directly connected, and as the transport for other protocols such as IPsec or routing protocol adjacencies. The configuration is simpler than VXLAN because there is no FDB, no multicast discovery, and no 50-byte encapsulation overhead. The trade-off is that GRE provides no isolation beyond the tunnel endpoints themselves, and it provides no confidentiality.
Key point: GRE encapsulates packets with an outer IP header and a GRE header, adding 24 bytes of overhead on a standard IPv4 underlay (20 bytes for the outer IP header plus 4 bytes for the base GRE header) . A point-to-point GRE tunnel requires configuration on both endpoints: each side must specify the other side’s underlay address as remote and its own underlay address as local. The tunnel interface itself is then assigned an IP address, and routes direct traffic through it.
Why GRE tunnels exist
The private-network-connectivity problem.
Two private networks—for example, 192.168.1.0/24 in one office and 192.168.2.0/24 in another—cannot reach each other through the public internet because their addresses are not globally routable. A GRE tunnel creates a virtual point-to-point link between a router at each site. The routers encapsulate packets destined for the remote private network inside packets addressed to the remote router’s public IP. The public internet routes the encapsulated packets between the two public addresses, and the receiving router decapsulates them and forwards the original packets to the private destination . The private networks communicate as if they were directly connected, even though the underlay is the public internet.
The routing-adjacency problem.
Some routing protocols require a direct Layer 3 adjacency to exchange routes. Two routers separated by a non-routing device or an intervening network cannot form that adjacency directly. A GRE tunnel provides a virtual link that the routing protocol can use. The routers form the adjacency over the tunnel interface, and the routing protocol treats the tunnel as a normal point-to-point link. This is a common pattern for connecting OSPF or BGP speakers across a network that does not support the protocol natively.
The protocol-transport problem.
GRE can encapsulate more than just IPv4. It can carry IPv6, MPLS, and other Layer 3 protocols inside an IPv4 underlay. This makes it useful for transitioning between protocol versions or for carrying protocols that the underlay does not support. The Linux implementation supports this through the same tunnel interface mechanism.
a. Creating a point-to-point GRE tunnel
A GRE tunnel is created with ip tunnel add. The mode gre parameter specifies the protocol, remote specifies the peer’s underlay address, and local specifies the source address for the outer header .
# On Router A (local underlay 203.0.113.1, remote underlay 198.51.100.1)
ip tunnel add gre1 mode gre remote 198.51.100.1 local 203.0.113.1 ttl 255
# Assign an overlay IP address to the tunnel
ip addr add 10.0.0.1/30 dev gre1
# Bring the tunnel up
ip link set gre1 up
# Add a route for the remote private network through the tunnel
ip route add 192.168.2.0/24 dev gre1The ttl 255 parameter sets the TTL of the outer IP header. This is optional but commonly used to prevent the encapsulated packets from being dropped by intermediate routers that enforce a low TTL. The /30 prefix on the overlay address provides exactly two usable addresses for the point-to-point link.
The configuration on Router B mirrors Router A, with the local and remote addresses swapped .
# On Router B (local underlay 198.51.100.1, remote underlay 203.0.113.1)
ip tunnel add gre1 mode gre remote 203.0.113.1 local 198.51.100.1 ttl 255
ip addr add 10.0.0.2/30 dev gre1
ip link set gre1 up
ip route add 192.168.1.0/24 dev gre1Once both sides are configured, Router A can ping 10.0.0.2 through the tunnel, and hosts on the private networks can reach each other if the routers forward traffic between the private interface and the tunnel interface.
b. GRE keys and tunnel identification
GRE supports an optional 32-bit key field that identifies a tunnel. On Linux, the key parameter sets the key for both directions, or ikey and okey can be used to set different keys for input and output . The key is carried in the GRE header and can be used by the receiving endpoint to distinguish between multiple tunnels that share the same pair of endpoint addresses.
# Create a tunnel with a key
ip tunnel add gre1 mode gre remote 198.51.100.1 local 203.0.113.1 key 42
# The remote side must use the same key
# ip tunnel add gre1 mode gre remote 203.0.113.1 local 198.51.100.1 key 42Without a key, two GRE tunnels between the same pair of IP addresses cannot be distinguished. The key provides a way to multiplex multiple logical tunnels over the same endpoint pair, though this is less common than using distinct endpoint addresses or VLAN tags on top of the tunnel.
c. MTU and fragmentation
GRE encapsulation adds overhead. On a standard 1500-byte underlay, the GRE interface’s MTU is automatically reduced by the kernel to account for the encapsulation, typically to 1476 bytes (1500 minus 24) . This reduction prevents the tunnel from generating packets that exceed the underlay’s MTU.
# Verify the GRE interface MTU
ip link show gre1 | grep mtu
# Output: mtu 1476If the underlay supports jumbo frames, or if the tunnel carries traffic that must use a specific MTU, the MTU can be set manually with ip link set gre1 mtu <value>. However, setting the MTU too high causes fragmentation or drops on the underlay, and setting it too low reduces throughput for large packets. The default automatic reduction is usually correct.
The nopmtudisc option disables Path MTU Discovery on the tunnel interface. This is sometimes used when the underlay does not reliably deliver ICMP “fragmentation needed” messages, but it should be used with caution because it can cause silent packet loss for large packets.
# Disable PMTU discovery on the tunnel
ip link set gre1 type gre nopmtudiscComplete Example Session
# ============================================
# PART 1: CREATE THE TUNNEL INTERFACE
# ============================================
# Router A: local underlay 203.0.113.1, remote underlay 198.51.100.1
ip tunnel add gre1 mode gre remote 198.51.100.1 local 203.0.113.1 ttl 255
# ============================================
# PART 2: ASSIGN THE OVERLAY ADDRESS
# ============================================
# A /30 provides two addresses for the point-to-point link
ip addr add 10.0.0.1/30 dev gre1
# ============================================
# PART 3: BRING UP THE TUNNEL
# ============================================
ip link set gre1 up
# ============================================
# PART 4: VERIFY THE TUNNEL CONFIGURATION
# ============================================
ip tunnel show gre1
# Output: gre1: gre/ip remote 198.51.100.1 local 203.0.113.1 ttl 255
ip -d link show gre1
# Output confirms the GRE mode and endpoints
# ============================================
# PART 5: ADD A ROUTE FOR THE REMOTE PRIVATE NETWORK
# ============================================
ip route add 192.168.2.0/24 dev gre1
# ============================================
# PART 6: CONFIGURE THE REMOTE ENDPOINT (ROUTER B)
# ============================================
# On Router B: local 198.51.100.1, remote 203.0.113.1
ip tunnel add gre1 mode gre remote 203.0.113.1 local 198.51.100.1 ttl 255
ip addr add 10.0.0.2/30 dev gre1
ip link set gre1 up
ip route add 192.168.1.0/24 dev gre1
# ============================================
# PART 7: TEST CONNECTIVITY
# ============================================
ping -c 2 10.0.0.2
# The overlay addresses are reachable through the tunnel
# ============================================
# PART 8: VERIFY ENCAPSULATION ON THE UNDERLAY
# ============================================
tcpdump -i eth0 -n proto gre
# Output shows outer IP headers with protocol 47 (GRE)
# ============================================
# PART 9: CHECK THE MTU
# ============================================
ip link show gre1 | grep mtu
# Output: mtu 1476 (1500 minus 24 bytes of overhead)
# ============================================
# PART 10: CLEAN UP
# ============================================
ip route del 192.168.2.0/24 dev gre1
ip link set gre1 down
ip tunnel del gre1The ten parts demonstrate the complete GRE lifecycle: interface creation, overlay addressing, route configuration, remote endpoint setup, connectivity testing, encapsulation verification, and cleanup. The critical step is Part 6: the remote endpoint must be configured with the mirrored local and remote addresses. A GRE tunnel is not a one-sided configuration.
Quick Reference
GRE Configuration Commands
| Task | Command |
|---|---|
| Create tunnel | ip tunnel add <name> mode gre remote <peer> local <self> |
| Add key | ... key <number> |
| Show tunnel | ip tunnel show <name> |
| Verify mode | ip -d link show <name> |
| Assign overlay IP | ip addr add <addr>/<prefix> dev <name> |
| Bring up | ip link set <name> up |
| Add route | ip route add <network> dev <name> |
| Delete tunnel | ip tunnel del <name> |
GRE vs VXLAN
| Property | GRE | VXLAN |
|---|---|---|
| Layer | Layer 3 (IP-in-IP) | Layer 2 (Ethernet-in-UDP) |
| Encapsulation | IP protocol 47 | UDP port 4789 |
| Overhead | 24 bytes | 50 bytes |
| Identifier | Optional key (32-bit) | VNI (24-bit) |
| Peer discovery | Manual (remote address) | Multicast or FDB |
| Encryption | None | None |
MTU Overhead
| Underlay MTU | GRE MTU | Overhead |
|---|---|---|
| 1500 | 1476 | 24 bytes |
| 9000 | 8976 | 24 bytes |
Best Practices
✅ Do This:
# Configure both endpoints with mirrored local/remote addresses
ip tunnel add gre1 mode gre remote <peer> local <self> ttl 255 # ✅
# Use a /30 for the point-to-point overlay link
ip addr add 10.0.0.1/30 dev gre1 # ✅
# Add routes for the remote private networks
ip route add 192.168.2.0/24 dev gre1 # ✅
# Verify with ip tunnel show and tcpdump
ip tunnel show gre1; tcpdump -i eth0 proto gre # ✅
# Allow GRE protocol 47 in the firewall
iptables -A INPUT -p gre -j ACCEPT # ✅❌ Don’t Do This:
# Configure only one side of the tunnel
# The peer must have a mirrored configuration # ❌
# Forget the route to the remote private network
# The tunnel is up but the private traffic has no path # ❌
# Assume GRE provides encryption
# GRE is plaintext; use IPsec or WireGuard for confidentiality # ❌
# Set the MTU higher than the underlay allows
# Fragmentation or drops occur silently # ❌
# Use GRE when VXLAN is required for Layer 2 stretching
# GRE carries IP, not Ethernet frames # ❌Common Pitfalls
| Pitfall | Why It Happens | Fix |
|---|---|---|
| Tunnel up but no traffic | Remote endpoint not configured | Mirror the configuration on both sides |
| Private networks cannot reach each other | Missing route through the tunnel | Add ip route add <remote-net> dev gre1 |
| Fragmentation on underlay | MTU not reduced | Verify the GRE interface MTU is 1476 |
| GRE packets dropped | Firewall blocks protocol 47 | Allow GRE in iptables |
| Tunnel disappears after reboot | ip tunnel add is not persistent | Configure through network manager |
Real-World Examples
1. Basic point-to-point GRE
ip tunnel add gre1 mode gre remote 198.51.100.1 local 203.0.113.12. GRE with key
ip tunnel add gre1 mode gre remote 198.51.100.1 local 203.0.113.1 key 423. Assign overlay IP
ip addr add 10.0.0.1/30 dev gre14. Route remote network
ip route add 192.168.2.0/24 dev gre15. Verify tunnel
ip tunnel show gre16. Capture GRE traffic
tcpdump -i eth0 proto gre7. Check MTU
ip link show gre1 | grep mtu8. Delete tunnel
ip tunnel del gre19. Firewall rule for GRE
iptables -A INPUT -p gre -j ACCEPT10. Disable PMTU discovery
ip link set gre1 type gre nopmtudiscVisual
GRE Encapsulation
┌──────────────────────────────────────────────────────────────┐
│ GRE WRAPS THE ORIGINAL PACKET IN AN OUTER IP HEADER │
│ │
│ Original packet (private network): │
│ ┌──────────┬──────────┬───────────────────────────────┐ │
│ │ IP Header│ TCP/UDP │ Payload │ │
│ │ (private)│ Header │ │ │
│ └──────────┴──────────┴───────────────────────────────┘ │
│ │ │
│ ▼ │
│ GRE encapsulated packet: │
│ ┌──────────┬──────────┬──────────┬───────────────────────┐ │
│ │ Outer IP │ GRE │ Inner IP │ TCP/UDP + Payload │ │
│ │ Header │ Header │ Header │ │ │
│ │ (public) │ (4 bytes)│ (private)│ │ │
│ └──────────┴──────────┴──────────┴───────────────────────┘ │
│ │
│ Overhead: 20 (outer IP) + 4 (GRE) = 24 bytes │
│ Underlay sees only the outer IP header with protocol 47. │
└──────────────────────────────────────────────────────────────┘Point-to-Point Tunnel
┌──────────────────────────────────────────────────────────────┐
│ GRE TUNNEL CONNECTS TWO ROUTERS ACROSS AN IP UNDERLAY │
│ │
│ Site A Site B │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ Router A │ │ Router B │ │
│ │ │ │ │ │
│ │ eth0: 203.0.113.1 │ eth0: 198.51.100.1 │
│ │ gre1: 10.0.0.1 │ │ gre1: 10.0.0.2 │ │
│ │ │ │ │ │
│ │ LAN: 192.168.1.0/24 │ LAN: 192.168.2.0/24 │
│ └────────┬────────┘ └────────┬────────┘ │
│ │ │ │
│ │ Underlay IP │ │
│ └───────────┬───────────────────┘ │
│ │ │
│ ▼ │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ Public Internet │ │
│ │ Routes packets between 203.0.113.1 and 198.51.100.1 │ │
│ │ Does not see the GRE encapsulation │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
│ The private LANs reach each other through the tunnel. │
└──────────────────────────────────────────────────────────────┘MTU Reduction
┌──────────────────────────────────────────────────────────────┐
│ GRE INTERFACE MTU IS REDUCED AUTOMATICALLY │
│ │
│ Underlay MTU: 1500 bytes │
│ GRE overhead: 24 bytes │
│ GRE interface MTU: 1476 bytes │
│ │
│ Packet from private network: │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ 1476 bytes payload + headers │ │
│ └────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ GRE encapsulation: │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ 24 bytes overhead + 1476 bytes = 1500 bytes total │ │
│ └────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ Fits within underlay MTU. No fragmentation. │
└──────────────────────────────────────────────────────────────┘Summary
| Item | Value |
|---|---|
| Protocol | Generic Routing Encapsulation (GRE) |
| Encapsulation | IP-in-IP, protocol 47 |
| Overhead | 24 bytes |
| Configuration | ip tunnel add mode gre remote <peer> local <self> |
| Overlay addressing | Point-to-point, typically /30 |
| Both endpoints | Must be configured (mirrored) |
| MTU adjustment | Automatic, 1476 on 1500-byte underlay |
| Encryption | None (plaintext) |
| Key field | Optional 32-bit identifier |
| Typical use | Private network connectivity, routing adjacencies |
Key takeaways:
- GRE is a point-to-point IP tunnel. It encapsulates one network-layer protocol inside another, creating a virtual link between two routers. It operates at Layer 3, not Layer 2, so it carries IP packets, not Ethernet frames .
- Both endpoints must be configured. A GRE tunnel is not established until both sides have a tunnel interface with mirrored
localandremoteaddresses. One-sided configuration produces an interface that exists but carries no traffic . - The overhead is 24 bytes. The GRE interface’s MTU is automatically reduced to account for the outer IP header and GRE header. On a 1500-byte underlay, the tunnel MTU is 1476 bytes .
- GRE provides no encryption. The encapsulated packets are sent in plaintext. For confidentiality, GRE must be combined with IPsec, or replaced by a protocol that includes encryption, such as WireGuard or OpenVPN .
- Routes are required for the remote private networks. The tunnel interface provides connectivity between the overlay addresses. A route through the tunnel is required for the private networks behind the routers to reach each other.
- The GRE protocol must be permitted by firewalls. The outer packets use IP protocol 47. A firewall that blocks this protocol will silently drop the encapsulated traffic.
Remember: A GRE tunnel is a virtual point-to-point link that carries IP packets across an IP underlay. It is configured on both endpoints with mirrored local and remote addresses, assigned an overlay IP, and used as the next hop for routes to remote private networks. It adds 24 bytes of overhead, provides no encryption, and requires that protocol 47 be permitted on the underlay. GRE is simpler than VXLAN because it has no Layer 2 component, no FDB, and no peer discovery. It is the correct choice when the requirement is IP connectivity between two sites, not Layer 2 stretching or tenant segmentation.
Stop using slow, ad-bloated tool sites! 🤮
🔎 Search “KandZ Tools” on Google to use many professional utilities for free.
KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)
⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free
🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!