Test a Suspected VPN MTU Problem Without Guessing Values

Trying a list of internet MTU values until one feels faster is not a test, it is a search with no stopping rule. The method that works changes one controlled size condition and compares the result against the same path. Start from a repeatable harmless failure and keep the working configuration that lets you undo the experiment. Everything below assumes that discipline, because without it you end up with a number you cannot defend.

Fix the path before you change a number

Write down the device, the access link, the tunnel protocol, the endpoint, the destination and the address family before you touch a setting. Those six facts are the path, and a probe aimed at a different path measures a different problem. They also make the result reproducible, which is what separates a test from an afternoon of poking. Keep the note beside the terminal rather than in your head.

Start with the narrowest test you are authorized to run. A server-side change reaches every user of that endpoint, so it belongs at the end of the investigation, not the beginning.

Probe with a size you control

On Linux the probe looks like ping -M do -s 1400 host, and on Windows like ping -f -l 1400 host. Either way you are setting payload rather than packet size, because the IP and ICMP headers are added on top.

Read the documentation for the system in front of you instead of copying a flag from a forum post. Pick a destination you control, so a missing reply is a signal rather than a mystery. Record the exact command and the exact size in the same note as the path. A result without a size is an anecdote. Change two things in one run and you will not know which one produced the result.

A failed probe is not proof of an MTU limit

A dropped probe can mean ICMP filtering rather than a size limit, and that mistake sends people tuning a value that was never the problem. Compare the probe with the real application, and with a size-related error message or a scoped capture, before changing anything. Successful small pings prove nothing either, since they may sit comfortably below the limit. Two independent observations are the minimum before a configuration moves.

If the application fails while the probe succeeds, you have evidence that this is not a simple size limit on that path. Write that down, because it removes a whole branch of candidate changes.

Adjust one parameter the client already supports

Change the setting the client documents for this protocol, and leave the endpoint and the destination untouched, or you have changed two things at once. A TCP MSS clamp does not cover every UDP workload, which is why a browser that starts working can leave the tunnel protocol exactly as broken. IPv4 and IPv6 are separate paths here, because the headers differ before any routing does.

Test both families if you publish both, since a result from one says nothing about the other. A value that worked on this path tonight is a datum, not a VPN-wide MTU. Do not promote it to a global setting on the strength of one successful transfer. Write the value down next to the path it came from.

Undo, verify, and write it down

Put the original value back if the comparison does not support the hypothesis. Check that a network manager did not save a persistent override elsewhere, because that is how an experiment becomes policy. Reconnect and exercise ordinary applications, not only the one you were testing. Then record the symptom, the effective path, the old and new values, and how repeatable the result was.

Keep that record with the change request before anyone widens the change. The path MTU discovery mechanism in RFC 1191 explains why a smaller value can rescue one path and do nothing for another, and a list of numbers is no substitute for that model. The test is finished when you can name the path, the size, the observation and the value you restored.