GRE tunnels and MTU: the "site loads but downloads never finish" problem
By Datafex Engineering TeamPublished 6 min read
There are two ways to take scrubbed traffic off the filtering layer and carry it to your own infrastructure. If your servers are on the protection provider's side, a direct connection. If you are in another location, a GRE tunnel. The second works and is common — but it brings with it a detail that takes five minutes during the build and days to find afterwards.
The symptom is always described in the same sentence: the site loads but downloads never finish. And the cause is always the same: packet size.
GRE adds a header to every packet
GRE is an encapsulation protocol. It takes your packet as it is, puts its own header on top and sends it to the other end of the tunnel. That header takes 24 bytes per packet.
The rest is arithmetic. On a tunnel running over a standard 1500-byte MTU, the payload you can carry inside drops to 1476 bytes. If you do not set the MTU at the tunnel ends to reflect that, the operating system keeps generating 1500-byte packets — and those packets cannot get through the tunnel.
Why the symptom is so strange
Small packets fit; large packets do not. Most everyday traffic is small packets: a DNS query, a TLS handshake, an HTTP request itself, a game client's status query. All of those pass. The site loads, you log in, the panel works.
The trouble starts when packets that actually carry data come into play: a file download, a backup transfer, a large form submission, a database dump. Those generate full-size packets, and they vanish silently in the tunnel.
The word "silently" matters here. The mechanism called Path MTU Discovery relies on the sender getting back the message "this packet did not fit, make it smaller". If the ICMP messages carrying that news are dropped by a firewall somewhere on the path — and "let's just block ICMP entirely" is a very common decision — the sender learns nothing. It sends the same large packet again and again, it disappears every time, and the connection hangs without ever returning an error. Because there is no error message, people look in the application first, then the disk, then the database. The answer is in the network.
Two settings: tunnel MTU and MSS clamping
The fix has two parts, and both belong to the build.
First, the MTU of the tunnel interface. At both ends of the tunnel it is set to the value left after the encapsulation header. The right number depends on the real MTU of the underlying path — not every path is 1500 — so enter it after confirming with your operator rather than assuming.
Second, MSS clamping for TCP sessions. During the TCP handshake the two sides tell each other the largest segment size (MSS) they will accept. Clamping lowers that announcement as it crosses the tunnel to a value that fits. The session is then established at the right size from the outset, and whether PMTUD works stops mattering. This value is derived from the tunnel MTU too — what remains after the IP and TCP headers — and it differs between IPv4 and IPv6.
Setting the MTU and skipping the clamping is the most common half-fix. Your own server starts producing correctly sized packets, but the client on the other side has no idea; traffic in the download direction still disappears.
What MSS clamping does not solve
MSS is a TCP option. It has no equivalent in UDP — so clamping does nothing at all for UDP traffic. Game, voice and some tunnelling protocols run over UDP, and the application itself decides packet size there.
In practice UDP game traffic mostly uses small packets and causes no trouble, but protocols that push large state updates or transfer maps and assets can be the exception. So when the tunnel goes live, do not test it with a web interface alone: try it with the real game client, with a real file transfer and, where you can, with large packets that are not allowed to fragment. The "do not fragment" and "packet size" options of the ping command exist for this; the option names differ by operating system.
Is the symptom really MTU?
The distinction that speeds up diagnosis is this: an MTU problem establishes the connection and then fails to finish the transfer.
| What you see | Does it fit an MTU problem |
|---|---|
| Small requests work, large transfers hang midway | Yes — the textbook case |
| The connection never establishes, an error returns at once | No — routing or firewall |
| Everything is slow but eventually completes | No — bandwidth or latency |
| The same file sometimes downloads and sometimes does not | Partly — the path may be changing, if the two paths differ in MTU |
| The symptom exists only on traffic crossing the tunnel | Yes — a strong signal |
The last row is the most decisive. If you can reach the same server from outside the tunnel and a large transfer completes cleanly, looking inside the tunnel is almost certainly the right next step.
A direct connection instead of a tunnel
There is one option where this whole class of problem disappears: if the servers sit on the same network as the filtering layer, no encapsulation is needed. If you want the hardware to stay yours, colocation gives you that; if you want your own rack and your own switch, cabinet rental does. In hybrid setups where part of the traffic is here and part at a remote location, a tunnel is unavoidable and the MTU conversation happens up front.
Which route you choose does not change the protection model: BGP protection announces your range through the Datafex network in either case, cuts volumetric attacks at router level and passes the rest through the Fexwall filter. The only thing that changes is the path clean traffic takes to reach you.
Five things to settle before the build
- The IP addresses at both tunnel ends and the real MTU of the underlying path.
- The tunnel interface MTU at each end — setting it on one side is not enough.
- Which side applies MSS clamping for TCP.
- Whether ICMP is filtered anywhere on the path; if it is, PMTUD cannot be relied on.
- How acceptance will be tested: with a large transfer, not a small request.
Writing those five down before installation day is far cheaper than hunting the "site loads but downloads never finish" symptom later. If you are already seeing it on an existing setup, write to us with the MTU values at both tunnel ends — the diagnosis usually falls out on first inspection.