Why your VPN drops? How to fix MTU and MSS Clamping

Why your VPN silently fails on the network

Who hasn't experienced the frustration of connecting to a corporate VPN only to find that heavy web pages simply hang midway through loading? In practice, this means the connection appears active, but real traffic isn't passing through. Often, the culprit isn't your ISP or the encryption itself, but an invisible detail called MTU, or Maximum Transmission Unit, which represents the maximum size of a data packet that can travel without being chopped into pieces.

When we add a VPN layer like WireGuard or OpenVPN, the original packet gets an extra 'helmet' of encryption data. If the resulting packet exceeds the limit that intermediate routers support, it must be fragmented. If those routers decide to drop these fragmented packets for security reasons, a handshake failure occurs, and the connection completely freezes. As we detailed in our guide on how to map packet loss and jitter in routes, understanding traffic behavior under the hood is the first step toward stabilizing any tunnel.

What is MTU and why encapsulation breaks everything

To understand the problem simply, think of MTU as the maximum height allowed for a truck to pass under a bridge. Standard internet has a traditional MTU of 1500 bytes. When you create a VPN tunnel, the protocol adds extra headers to ensure data security. WireGuard adds about 60 bytes of overhead, while UDP-based OpenVPN can add up to 64 bytes or more depending on the cipher used.

If your network card sends a 1500-byte packet and the tunnel adds another 60 bytes, the total packet becomes 1560 bytes. If it encounters a carrier router along the way that accepts a maximum of 1500 bytes, the packet must be fragmented. If the network ignores fragmentation or if the DF (Don't Fragment) bit is enabled, the packet dies mid-route, resulting in extreme slowness or total VPN session drop.

The ultimate solution: configuring MSS Clamping in practice

MSS Clamping, or Maximum Segment Size clamping, is an intelligent mechanism that tells the source computer to reduce the size of data chunks before they even enter the tunnel. Instead of letting the packet grow and blow past the limit further down the line, the router or the VPN server itself warns: 'send slightly smaller packets so they fit comfortably inside the tunnel'.

This solves the issue of websites opening partially and freezing, as the TCP protocol is forced to negotiate an appropriate segment right from the start. To apply this on Linux routers or firewalls handling encapsulated traffic, you can use direct rules in the packet filtering system. Here is a classic rule example to automatically adjust MSS on your tunnel interface:

iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

This magical line instructs the system to inspect every TCP packet initiating a connection and adjust its MSS based on the discovered path MTU, ensuring no packet exceeds the safe limit of your WireGuard or OpenVPN tunnel.

Manually tuning MTU in WireGuard and OpenVPN

Beyond MSS Clamping, setting the correct MTU value directly in the VPN interface configuration is an essential network engineering practice. In WireGuard, for example, the default value is usually 1420 to accommodate UDP and IP headers over a network with a 1500 MTU. However, if you are on a fiber connection using PPPoE, which reduces the base MTU to 1492, WireGuard needs to drop down to 1412.

To change this in your WireGuard client or server configuration file, simply add the MTU directive explicitly in the interface section. Here is what a typical optimized configuration block looks like:

[Interface] Address = 10.0.0.2/32 PrivateKey = aaaa... MTU = 1380 [Peer] PublicKey = bbbb... Endpoint = 203.0.113.5:51820 AllowedIPs = 0.0.0.0/0

Adjusting this value to 1380 or even 1360 creates a safety margin against restrictive corporate networks, unstable public Wi-Fi networks, and mobile 4G/5G connections that often fragment packets aggressively. Ensuring this structural resilience prevents support tickets and abrupt drops during crucial meetings.

Diagnosis and validation with advanced ping tests

Guessing the ideal MTU value is a common mistake that wastes time. The best way to discover the exact number your connection supports without fragmentation is to perform manual tests using the ping utility with a restricted packet size parameter and the flag to forbid fragmentation.

On Linux or macOS, you can run the command indicating the packet size and forcing the DF bit. Keep lowering the number until the packet passes without receiving an error message stating it needs fragmentation. Here is a practical example command to test the limit toward your VPN server:

ping -M do -s 1400 10.0.0.1

Remember that the value passed in the `-s` parameter refers only to payload data. To find the actual total MTU, you must add 28 bytes for the IP and ICMP headers. Thus, if the test with `-s 1420` passes without errors, your ideal MTU will be 1448. Doing this mapping prevents silent failures and guarantees maximum performance.

Conclusion and best practices for stable tunnels

Maintaining stable VPN connections requires understanding that modern network traffic handles complex layers of encapsulation and invisible infrastructure constraints. By combining fine-tuning of the MTU parameter with the efficient use of MSS Clamping, we eliminate the root cause of mysterious freezes and intermittent slowness in WireGuard and OpenVPN tunnels.

Adopting a proactive testing posture with the ping command and documenting proper values for each corporate or residential network scenario ensures an operation free of unpleasant surprises. Investing a few minutes configuring these parameters frees you and your team from frustrating handshake failures, delivering a truly solid and transparent network experience.