Why GRE changes MTU
GRE wraps the original packet inside a new outer IP header and GRE header. That extra encapsulation consumes space on the wire.
The physical path MTU does not increase just because a tunnel was added. That means the payload available for the original packet becomes smaller once GRE is used.
Basic idea
effective inner packet MTU
What happens if you ignore it
If hosts or routers continue sending packets as if the full original MTU were still available, the tunneled path may fragment the traffic or drop it entirely.
In practice this often shows up as websites partially loading, TLS sessions stalling, unexplained retransmissions, or applications behaving inconsistently despite basic ping tests looking fine.
Typical symptoms
- Fragmentation on the tunnel path
- TCP retransmissions and slow page loads
- Broken PMTUD behavior
- Traffic that works with some tools but fails in browsers or real applications
Why mitigation deployments hit this often
GRE is commonly used for remote DDoS mitigation because it allows traffic to be redirected without moving the customer infrastructure. That makes deployment easier, but it also introduces an extra encapsulation layer.
If the tunnel path crosses networks that do not fully support PMTUD or if endpoints assume the wrong MTU, the problems usually appear immediately under real application traffic.
How it is usually fixed
The common fixes are reducing MTU on the relevant interfaces, clamping TCP MSS, and validating the full end-to-end path rather than only checking one hop.
The important part is consistency. If only one side is adjusted while another system still sends oversized packets, the tunnel problems remain.
What this means operationally
Tunnel-based mitigation is easier to deploy than a fully inline design, but the trade-off is path sensitivity. GRE solves one problem while introducing another that has to be handled correctly.
The tunnel itself is usually not the issue. Incorrect assumptions about MTU and MSS are.