VPN Connected, but Some Websites Won’t Load? Check the MTU

The VPN status says connected. Search results open. One banking site spins forever, a login page stalls, or uploads fail halfway through. That selective pattern can point to packet size—not a complete loss of the VPN tunnel.

Think of the tunnel as a doorway. Small parcels pass; one oversized parcel catches on the frame. A VPN adds headers around ordinary traffic, so a packet that fit before encryption can become too large for part of the route afterward. The relevant limit is the maximum transmission unit, or MTU.

Why “connected” does not prove every packet works

A successful VPN handshake confirms that the router and VPN server established a tunnel. It does not prove that every packet size can travel through every ISP, modem, firewall and server on the route.

Standard Ethernet commonly uses an MTU of 1500 bytes. A VPN adds encryption and transport overhead. OpenVPN’s documentation describes how a packet that fit before encapsulation can become too large afterward, forcing fragmentation or adjustment. PPPoE and other links can impose a smaller limit as well.

Symptoms that fit an MTU problem

• Some lightweight pages work while image-heavy or authenticated pages stall.
• A website begins loading but never finishes.
• Downloads work but uploads or form submissions freeze.
• The same website works immediately when the VPN is disabled.
• One VPN protocol works while another fails on the same connection.

These symptoms are not exclusive to MTU. DNS, IPv6, content blocking, server selection and the website’s own VPN policy can produce similar behavior. Diagnose in a controlled order.

A safer troubleshooting sequence

MTU, MSS and fragmentation in plain language

MTU is the largest network packet an interface expects to send without further division. MSS applies to the TCP payload and can be adjusted so the final packet stays below the path limit. Fragmentation divides an oversized packet into smaller pieces.

Fragmentation is valid, but some NAT devices, firewalls and network paths handle fragments poorly. OpenVPN therefore supports controls such as tun-mtu and mssfix. Those values are not universal magic numbers: protocol, IP version, cipher, WAN type and implementation all affect the correct setting.

What a router owner should do

1. Record the failing site, VPN server, protocol and device.
2. Confirm whether every device behind the router shows the same failure.
3. Switch servers, then protocols, without changing other settings.
4. Check the VPN provider’s recommended MTU or MSS guidance for that protocol.
5. If the router exposes MTU controls, save the original value before testing a lower setting.
6. After each change, retest both the failing site and a large upload or download.

Make the failure reproducible before changing numbers

A useful support report says more than “some sites do not work.” Include one failing URL, the device, VPN protocol, server location, whether the page works with the VPN off, and whether changing only the server fixes it. That evidence often distinguishes an MTU pattern from DNS, IPv6 or a website blocking a particular VPN exit address.

Customers using a configured router can also start with the appropriate FlashRouters setup and troubleshooting portal. For protocol background, compare OpenVPN router options and WireGuard router options before changing a stable setup.

Do not treat MTU as the default explanation

If the hostname never resolves, begin with DNS. If only one server fails, change servers before touching MTU. If a different protocol works, keep that result as evidence rather than declaring the problem solved. MTU becomes a stronger candidate when the tunnel remains connected, small exchanges succeed and larger ones repeatedly stall across devices.

Source: OpenVPN Community Wiki: MTU and Fragments.