Fix GRE/IPsec Tunnel Fragmentation Dropping Packets
When your VPN tunnel drops packets or web pages hang, it's often MTU fragmentation. Here's how to fix it fast.
You're not crazy. You set up your tunnel, everything looks green, but web pages time out halfway through loading, or large file transfers just stall. I've seen this hundreds of times. The fix is almost always the same: your overlay tunnel's MTU is too high, and something downstream can't handle the fragments.
The Quick Fix: Lower the Tunnel MTU
Start here. This works 90% of the time. On your tunnel interface, change the MTU to 1400. That accounts for the typical 20-byte IP header and 8-byte GRE header (or 50-60 bytes for IPsec ESP). Here's how on common platforms:
Cisco IOS / IOS-XE
interface Tunnel0
ip mtu 1400
ip tcp adjust-mss 1360
After entering that, do a show interface tunnel 0. You should see the MTU change to 1400. The TCP MSS adjust command tells the router to rewrite TCP SYN packets so the maximum segment size is 1360. That prevents TCP from trying to send 1500-byte segments inside the tunnel.
Linux (iproute2)
ip link set dev tun0 mtu 1400
Then verify with ip link show tun0. You'll see the new MTU. Also run ip route change 0.0.0.0/0 dev tun0 mtu 1400 if you're using policy routing.
Windows (WireGuard or OpenVPN)
For WireGuard, edit your config file and change MTU = 1420 to MTU = 1380. For OpenVPN, add tun-mtu 1400 and fragment 1400 to your config. Then restart the service. You should see the tunnel come up with the lower MTU.
Why This Works
Tunnels encapsulate packets. A 1500-byte Ethernet packet gets wrapped in a GRE header (4 bytes), then an outer IP header (20 bytes). That makes it 1524 bytes. If your physical interface's MTU is 1500, the router has to fragment that packet. Many firewalls and ISPs drop fragments, especially for VPN traffic. The result? Your TCP connection stalls.
Lowering the tunnel MTU to 1400 means the encapsulated packet stays under 1500 bytes. No fragmentation, no drops. The TCP MSS adjust just enforces that end-to-end, so the server never even tries to send a big packet.
Less Common Variations
Path MTU Discovery Black Holes
Sometimes the real issue isn't the tunnel itself but a router along the path that silently drops ICMP "Packet Too Big" messages. That breaks PMTUD. If lowering the MTU didn't fix it, disable PMTUD on your side. On Linux:
sysctl -w net.ipv4.ip_no_pmtu_disc=1
On Cisco, add no ip unreachables on the outgoing interface (careful—that also blocks other ICMP).
Jumbo Frames on the Physical Side
If your physical network supports jumbo frames (MTU 9000), you can bump the physical interface's MTU but still keep the tunnel at 1400. That gives you room for encapsulation without fragmentation. But if your ISP doesn't support jumbo frames, this won't help.
Multipoint GRE (mGRE) with DMVPN
DMVPN tunnels often see fragmentation because spokes have different path MTUs. Set the global tunnel MTU to 1400, but also configure per-destination MTU on spokes if you know one path is tighter. Use ip mtu 1400 on the tunnel interface, and on the spoke's physical interface set ip tcp adjust-mss 1360.
Preventing This Going Forward
Three rules:
- Always set the tunnel MTU to 1400 when you build a new tunnel. Don't wait for complaints.
- Use TCP MSS clamping on every tunnel endpoint. The command
ip tcp adjust-mss 1360is your friend. - Test with a single large ping before you deploy. Run
ping -M do -s 1472 target(Linux) orping -f -l 1472 target(Windows). If it fails, you need to drop the MTU further. Keep dropping by 100 until it works.
One last thing: if you're using IPsec with ESP (not AH), the overhead is usually around 52-60 bytes depending on encryption. So 1400 is a safe bet. But if you're using GRE over IPsec, the overhead stacks. Go with 1350 to be safe.
I've seen this exact fix save a three-week troubleshooting cycle. Do the MTU change first. It's free, it's reversible, and it works.
Was this solution helpful?