What Are GRE Tunnels and How Do They Work?
GRE tunnels encapsulate one packet inside another so traffic can move between remote systems or networks over an IP path. In this article, we'll explain more about them.
Publish date: 3/27/2026
GRE tunnels encapsulate one packet inside another so traffic can move between remote systems or networks over an IP path. In this article, we'll explain more about them.
Publish date: 3/27/2026
Some networking tools sound much more complicated than they really are. GRE tunnels fall into that category. Once the jargon is stripped away, the concept is fairly straightforward: traffic is wrapped inside another packet and sent across an IP network to another endpoint.
That simple concept makes GRE useful in several real-world scenarios. It can connect remote private networks, carry routing traffic between servers or routers, and forward traffic from a DDoS-protected edge network to backend infrastructure hosted somewhere else. GRE has been around for a long time, but it still matters because it solves a specific problem cleanly.
GRE stands for Generic Routing Encapsulation. It is a tunneling protocol defined in RFC 2784. GRE creates a virtual point-to-point link between two endpoints by encapsulating an original packet inside a new outer IP packet.
The intermediate network only needs to route the outer packet to the far end of the tunnel. Once it arrives, the receiving endpoint removes the outer packet and forwards the original traffic normally.
In simple terms, GRE makes two remote systems or networks behave more like they are directly connected, even when the real path between them crosses the public internet or another unrelated IP network.
A GRE tunnel has two endpoints. One endpoint encapsulates the original traffic, and the other decapsulates it.
At the sending side, the original packet is wrapped with a GRE header and a new outer IP header. The outer source and destination addresses belong to the real tunnel endpoints. The original packet stays intact inside the new packet.
At the receiving side, the outer IP header and GRE header are removed, and the original packet is forwarded on to its destination.
A simple way to picture it looks like this:
Original packet: [Inner IP header][Payload]
GRE tunnel packet: [Outer IP header][GRE header][Inner IP header][Payload]
That extra encapsulation is what allows traffic to move across networks that otherwise would not carry it in the same way.
GRE remains widely used because it is flexible and relatively simple. It is not trying to be a security suite or an application delivery platform. Its main role is moving traffic between two endpoints in a useful way.
One of the most common GRE tunnel use cases is connecting one private subnet to another over an IP network. This can be useful when infrastructure is spread across two data centers, two providers, or two geographic regions.
Instead of redesigning the whole network, a GRE tunnel can create a virtual link between the two sides. Once routes are added, the remote networks can communicate as though there is a more direct path between them.
GRE is also useful for carrying routed traffic between remote systems. It can make remote endpoints act more like directly connected peers, which is one reason it appears so often in routing-heavy environments.
For more background on related topics, see xTom’s guides on what BGP is and how it works and what IP transit is and how it works.
GRE tunnels are also used in some hosting and DDoS mitigation setups.
In this type of design, traffic first reaches a DDoS-protected provider or protected network edge. After filtering or scrubbing, that traffic is forwarded through a GRE tunnel to a backend server or backend subnet hosted elsewhere, sometimes at a provider without the same level of DDoS protection.
This lets the backend infrastructure benefit from the protected edge without requiring the full application stack to be moved there. It is a common approach when the origin server is already deployed somewhere else, when infrastructure is split across providers, or when a business wants to keep compute and storage in one location while using another network for protected ingress.
That said, GRE does not automatically hide or secure the backend. If the origin is still publicly reachable, attackers may be able to bypass the protected edge entirely. Proper firewall rules, routing policy, and origin lockdown are what make this setup effective.
GRE tunnels are often confused with VPNs, but they are not the same thing.
GRE is an encapsulation protocol. It wraps traffic and transports it between two endpoints. By itself, it does not provide encryption, authentication, or confidentiality.
VPN technologies such as IPsec are designed to secure traffic. That is why GRE is often paired with IPsec in real deployments. GRE handles the flexible tunnel and routing behavior, while IPsec adds encryption and authentication.
This distinction matters because a tunnel does not automatically mean privacy. A plain GRE tunnel should be treated as transport, not security.
GRE is one of several tunneling methods available.
IP-in-IP is simpler, but generally less flexible. IPsec focuses on secure transport. WireGuard is a more modern choice for encrypted point-to-point networking. VXLAN is more common in virtualized and data center overlay environments.
GRE still makes sense when the main goal is routing flexibility, packet encapsulation, or forwarding traffic between remote systems without needing GRE itself to provide encryption.
GRE remains useful because it offers a few practical advantages.
It is relatively easy to understand once the basic concept clicks. It is flexible enough for a variety of Layer 3 networking scenarios. It is also widely supported across Linux, routers, and network appliances.
On Linux, GRE tunnels can be configured with standard tools such as iproute2, which makes them approachable for many sysadmins and network operators.
GRE also comes with tradeoffs.
The biggest limitation is that GRE does not encrypt traffic on its own. For anything sensitive crossing an untrusted network, GRE usually needs to be paired with something secure.
There is also packet overhead. Because GRE adds extra headers, the effective MTU drops. If that is not accounted for, fragmentation and inconsistent traffic behavior can show up.
GRE also depends on correct routing and firewall configuration. A tunnel may look correct in configuration, but still fail if the endpoints are not reachable, if intermediate devices block GRE, or if the right routes are not in place.
One common mistake is assuming GRE uses a normal TCP or UDP port. It does not. GRE is IP protocol 47, which is handled differently by firewalls and security policies.
The exact setup depends on the Linux distribution and the network management stack in use, but the basic workflow is usually the same.
Assume this example:
203.0.113.10198.51.100.2010.10.10.1/3010.10.10.2/30On Server A:
ip tunnel add gre1 mode gre local 203.0.113.10 remote 198.51.100.20 ttl 255
ip addr add 10.10.10.1/30 dev gre1
ip link set gre1 up
On Server B:
ip tunnel add gre1 mode gre local 198.51.100.20 remote 203.0.113.10 ttl 255
ip addr add 10.10.10.2/30 dev gre1
ip link set gre1 up
Then routes are added so traffic for each remote subnet goes through the tunnel.
For example, if Server A needs to reach 10.20.0.0/24 behind Server B:
ip route add 10.20.0.0/24 via 10.10.10.2 dev gre1
And if Server B needs to reach 10.30.0.0/24 behind Server A:
ip route add 10.30.0.0/24 via 10.10.10.1 dev gre1
At that point, traffic for those remote subnets is sent through the GRE interface instead of the normal path.
For related Linux setup and troubleshooting, these xTom guides may also help: how to diagnose network issues using ping, traceroute, and MTR and how to set up UFW on Debian.
A GRE tunnel only works if the network path between endpoints supports it.
The public IP addresses of both tunnel endpoints must be reachable. Any firewall or filtering layer in front of them must allow GRE traffic. Routes on both sides must point the correct remote networks into the tunnel.
In protected edge to backend designs, the backend often needs to be restricted so that only the protected edge or approved sources can reach it. Otherwise, the backend may still be directly exposed even though GRE forwarding is in place.
Packet size is one of the most common GRE tunnel issues.
Because GRE adds encapsulation overhead, the usable MTU becomes smaller. If MTU is not adjusted, traffic may fragment or fail unpredictably, especially under real application load.
That is why many GRE deployments lower the MTU on the tunnel interface. The exact value depends on the rest of the network path and whether GRE is combined with additional encapsulation or encryption.
GRE tunnels are sometimes mentioned alongside proxying, especially in protected edge and backend origin setups, but GRE is not the same thing as a reverse proxy.
A reverse proxy works at the application layer, usually handling HTTP or HTTPS requests. GRE works at the network layer and tunnels packets themselves.
So while GRE can forward traffic from a protected edge network to backend servers, it is not terminating and reissuing web requests the way an application-layer reverse proxy would.
For readers looking at application-layer traffic handling, xTom also has a guide on setting up NGINX as a reverse proxy for Apache on Debian and Ubuntu.
GRE is a good fit when a deployment needs a simple virtual link between two endpoints, site-to-site routing between remote networks, or traffic forwarding from a protected network edge to backend infrastructure hosted elsewhere.
It is less suitable when the main requirement is encrypted transport with minimal additional configuration. In those cases, technologies such as IPsec or WireGuard may be a better fit.
GRE is still relevant because it handles a specific networking job well, especially in routing-focused and hosting-focused environments.
GRE tunnels are a straightforward way to move traffic between remote endpoints by encapsulating one packet inside another. That makes them useful for site-to-site networking, routed links between remote systems, and protected edge-to-origin forwarding when a DDoS-protected provider is sitting in front of backend infrastructure hosted elsewhere.
The key thing to remember is that GRE is about transport and flexibility, not encryption. When security matters, GRE should be paired with the right tools, and the rest of the deployment, including routing, MTU, firewall rules, and origin protection, needs to be planned carefully.
Thanks for reading! If infrastructure is needed for routing, tunneling, hosting, or broader network deployments, xTom offers dedicated servers, colocation, IP transit, shared hosting, and general IT services. For scalable NVMe-powered KVM VPS hosting, V.PS is available for production workloads, testing environments, and edge deployments.
Ready to discuss infrastructure needs? Contact the team to explore the right solution for any project.
A GRE tunnel is used to encapsulate traffic and move it between remote endpoints over an IP network. Common use cases include site-to-site connectivity, routed links between servers or routers, and forwarding traffic from a protected network edge to backend infrastructure.
No. GRE tunnels do not provide encryption on their own. If confidentiality and secure transport are needed, GRE is often paired with IPsec or replaced with another secure tunneling option.
Yes. GRE tunnels are sometimes used to send traffic from a DDoS-protected provider or protected edge network to backend servers hosted at another provider. This can help keep the backend behind a filtered ingress path, as long as the origin is properly locked down.
GRE does not use a TCP or UDP port. It uses IP protocol 47, which means firewall rules need to specifically allow GRE traffic.
Yes. Linux supports GRE tunneling through built-in networking features and standard tools such as iproute2, which makes GRE practical for many server and infrastructure setups.
GRE is mainly for encapsulation and routing flexibility. IPsec is mainly for security. In many deployments, GRE and IPsec are used together so GRE handles the tunnel behavior and IPsec secures the traffic.
Yes. GRE adds overhead to packets, which reduces the effective MTU. If MTU is not adjusted properly, fragmentation or unreliable connectivity can occur.
Yes. GRE tunnels are still used in routing-heavy environments, site-to-site network designs, and protected edge-to-origin hosting setups where straightforward packet encapsulation is needed.