GRE and IP tunnels
Sometimes you need to carry traffic between two points as if a cable ran between them, across the internet in between. A GRE tunnel does exactly that — and understanding its one awkward side effect saves a lot of debugging.
A GRE tunnel wraps your packets inside other packets and sends them across the internet to the far end, where they are unwrapped. To the two endpoints it looks like a direct link, even though real networks sit in between. It is how you carry routed traffic, odd protocols, or a routed subnet to where it is needed.
What people use it for
- Carrying a routed subnet to a server that is not where the addresses live
- Linking two sites at the IP layer
- Getting traffic to a scrubbing or filtering point and back
The MTU problem is not optional
Wrapping a packet makes it bigger. A full-size packet plus the tunnel header is now too large for a standard 1500-byte link, so it must be fragmented or dropped — and when path MTU discovery is broken by a firewall in the middle, connections hang for no visible reason. Lower the MTU on the tunnel interface, or clamp TCP MSS, and this class of mystery disappears. See MTU, fragmentation and tunnels.
GRE does not encrypt
Plain GRE carries your traffic in the clear — it is an encapsulation, not a protection. If the data is sensitive and crosses the public internet, you want encryption around it (IPsec over GRE) or a tunnel that encrypts by design. For most “connect two of my servers” needs, a WireGuard VPN is simpler and encrypted.
When GRE is still the right tool
GRE shines when you need to carry routing — running a dynamic routing protocol between sites, or delivering a routed block — which encrypted point-to-point tunnels handle less naturally. If that is the job, GRE (optionally inside IPsec) is the classic answer.
Ask us for the routed side
If you need a subnet delivered to you over a tunnel, or a tunnel to a filtering point on our network, tell us the endpoints and what you are carrying — see running BGP with us. We set up our end to match.
Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base