Get One Month of Starlink FreeSPECIAL OFFER: GET A FREE MONTH OF STARLINK >
Wireless router and cable representing Starlink hardware and accessories

Starlink MTU Problems: How to Test Packet Size and Fix VPN Hangs

Troubleshooting & Fixes

Back to Troubleshooting & Fixes

A Starlink connection can look healthy while a VPN behaves badly: the tunnel says connected, small pages load, but a large website hangs, file uploads stall or one work application refuses to start. That pattern often points to a packet-size problem rather than a weak satellite signal.

This guide shows how to test for an MTU or path-MTU problem without guessing at a Starlink-wide value, changing several network settings at once or weakening security.

What MTU means

MTU, or maximum transmission unit, is the largest IP packet that can cross a link in one piece. The path MTU is the smallest packet size supported by every link between your device and a destination.

A VPN adds an encrypted wrapper around your traffic. If the resulting packet is too large for part of the route, it may be fragmented, rejected or dropped. Path-MTU discovery is designed to find that limit, but it can fail when a device or firewall blocks the control messages needed to report it. That is why a connection can complete its initial handshake and then appear to freeze when real data moves.

The important point is that path MTU belongs to a particular route. There is no single MTU number that is correct for every Starlink customer, VPN provider, destination or protocol.

Signs that packet size may be the problem

Look for a repeatable pattern rather than one slow test:

  • The VPN reports connected, but larger pages never finish loading.
  • Chat messages or short requests work while file uploads, downloads or video calls fail.
  • Only some websites or work applications hang.
  • The issue appears only when the VPN is enabled.
  • Reconnecting the VPN helps briefly, then the same symptom returns.
  • A second device using the same VPN shows a similar failure.
  • The same VPN works on another internet connection.

These symptoms can also come from a busy VPN gateway, DNS, routing, weak Wi-Fi or an application problem. An MTU test is a way to separate those causes, not proof that Starlink is at fault.

Before testing

Use one device, one VPN profile and one destination at a time.

  1. Disconnect the VPN and confirm that ordinary websites work.
  2. Repeat the same test with the VPN connected.
  3. Pause cloud backups, large downloads and streaming on other devices.
  4. If possible, test over Ethernet or close to the Starlink router so local Wi-Fi is not the variable.
  5. Record the time, device, VPN server or region, protocol and the exact application that fails.

If this is a company-managed device, stop at the comparison test and send the results to IT. Do not remove security software or alter a managed VPN profile.

Test an IPv4 path with a non-fragmenting ping

A common first test is to send an IPv4 packet that must not be fragmented. The number after the command is the ICMP payload, not the complete packet. For IPv4, add 28 bytes for the IP and ICMP headers.

Windows

Open Command Prompt and try:

unknown node

If it succeeds, the tested path accepted a 1,500-byte IPv4 packet. If Windows reports that the packet needs to be fragmented, lower the payload in small steps:

unknown node

Continue until you find the largest payload that succeeds reliably. Add 28 to that payload to estimate the IPv4 path MTU for that destination.

Linux

On a Linux device with iputils, use:

unknown node

Lower the value after -s if the packet is too large. If your distribution does not support -M do, tracepath 1.1.1.1 can provide a path-MTU estimate.

A public test address may ignore ICMP or follow a different route from your VPN endpoint. A passing test is useful evidence, but it does not guarantee that the VPN path accepts the same size.

Test the route that actually fails

If the normal internet test passes but the VPN still hangs, the relevant route is the path to the VPN endpoint or the destination reached through the tunnel.

Use the VPN provider's approved diagnostic address if it supplies one. Otherwise:

  • Keep the VPN connected while testing a destination that reliably fails.
  • Compare a small request with a large page or file transfer.
  • Test the same VPN on a second device if permitted.
  • Try one approved VPN server or protocol at a time.
  • Do not run a flood of pings or automated probes.

The result you want is a pattern such as: small traffic works, larger traffic fails, and lowering the tunnel MTU makes the larger traffic reliable. That is stronger evidence than a single timeout.

Account for VPN overhead

The VPN interface has less room for the original traffic because it must add encryption and transport headers. A tunnel MTU that is safe on a plain Ethernet path may be too large when the same traffic crosses a VPN.

If your personal VPN client exposes a tunnel MTU setting:

  1. Write down the original value.
  2. Lower the VPN tunnel MTU by 10 or 20 bytes.
  3. Reconnect the tunnel.
  4. Repeat the same large-page or file-transfer test.
  5. Keep the change only if the failure is repeatably improved.
  6. Restore the original value if there is no improvement.

Some WireGuard configurations start around 1420 on a 1,500-byte path, but that is a starting point, not a Starlink requirement. Choose the value from testing the failing route and leave room for the protocol's overhead.

Do not lower the Starlink router's WAN MTU blindly. Do not assume 1492, 1420 or 1280 is the correct answer for every plan, router or VPN.

When the VPN is managed by work

For a work VPN, the client may hide the MTU setting or enforce it centrally. Send IT a short evidence pack:

  • Starlink app status and the time of the test
  • Device and operating system
  • VPN client and protocol, if visible
  • VPN gateway or region
  • What works with the VPN off
  • What fails with the VPN on
  • Whether Ethernet or a second device changes the symptom
  • The largest test payload that passed and failed
  • Whether a temporary tunnel-MTU change helped, if your policy allowed it

Do not share passwords, private keys, recovery codes or confidential screenshots. IT may need to adjust tunnel settings, TCP MSS clamping or the VPN gateway rather than the Starlink equipment.

IPv6 is a separate path

IPv6 has different headers and path-MTU behaviour from IPv4. A value that works for an IPv4 test is not automatically correct for IPv6. If the failure occurs only when an application uses IPv6, use an IPv6-capable path-MTU test and report that distinction to the VPN provider or IT team.

Do not disable IPv6 as a first response. It can hide the symptom while leaving the underlying path or tunnel configuration unresolved.

If changing the tunnel MTU does not help

Return the setting to its original value and continue with controlled comparisons:

  • Test the VPN with another approved server or region.
  • Compare Ethernet with Wi-Fi.
  • Check whether DNS works while the failing page is loading.
  • Look for local router QoS, parental controls or security filtering.
  • Confirm that the VPN client is current and the device clock is correct.
  • Check the Starlink app for an outage, obstruction event or local connection fault.
  • Try the same VPN on another permitted network, such as a phone hotspot, while watching mobile-data use.

If the VPN is bad everywhere, contact the VPN provider or IT. If only the Starlink path fails and the failure follows the tunnel, provide the comparison results to both teams. Avoid factory-resetting Starlink or replacing the dish based only on a VPN symptom.

Quick decision guide

  • Bad with the VPN off and on: troubleshoot Starlink, power, Wi-Fi, obstructions or cabling first.
  • Bad only in one room: improve the local Wi-Fi path before changing MTU.
  • Bad only on one VPN server: test another approved server or contact the VPN provider.
  • Small traffic works but large transfers hang: test path MTU and tunnel MTU.
  • Only IPv6 traffic fails: report it as an IPv6 path or tunnel problem.
  • Only a managed work device fails: send the evidence to IT instead of changing policy-controlled settings.
  • The same VPN fails on several networks: investigate the VPN service, endpoint or gateway.

A good MTU diagnosis is a measured comparison. Test the path, change one setting, repeat the same transfer and keep the smallest change that fixes the specific symptom.

Related Starlink guides

Sources and further reading

Get One Month of Starlink Free

Claim Your Free Month

Order through my referral link and activate your service. Your second month of Starlink service will be free.

Answers for your next step