OpenVPN says MTU used inconsistently: what the warning compares

That warning reports a comparison between peer options, not a measurement of the path between them. People read it as 'the MTU is wrong' and change the number until the line disappears. That treats a configuration comparison as a network measurement, and it often makes the tunnel worse while making the log quieter. The useful first step is deciding which of those two problems you actually have.

Three conditions decide the answer: what the peers compare, whether the value is legacy, and what symptom exists beyond the warning.

The warning compares options, not packets

OpenVPN peers exchange their option strings during the handshake and compare them as part of the options consistency check. When one side reports link-mtu or tun-mtu differently from the other, the mismatch is recorded with both values. That exchange never sends a large packet to see what happens, so the warning describes configuration rather than capacity. A tunnel can carry full-size traffic and still print it, or fail on large packets and print nothing at all.

Keep the complete warning with its local and remote values. The pair is the evidence; the single number you remember is not.

link-mtu is deprecated for a reason

OpenVPN 2.6 deprecates link-mtu because variable headers and negotiated ciphers make a fixed link value unreliable. The option assumed a packet layout that the protocol no longer guarantees, so an old profile carrying a literal link-mtu describes an intent the current code cannot honour. Copying that number into a new profile spreads an obsolete assumption. Read it as part of the old profile's history, not as a recommendation.

The consistency check also has an optional OCC value tied to tun-mtu, which changes what gets compared without changing what the network carries. Setting it does not make larger packets fit.

Repair the profile before testing the path

Fix an unintended mismatch through whoever owns the profiles, and remember that a server-side change affects every client. Edit the profile the instance actually loads, not an export sitting in a downloads folder. Then reconnect one test client and note which warning survives. If the message changes shape rather than disappearing, you are comparing different options than you think.

A shared server needs its client inventory checked before a global value moves, because the value that suits one site can break another.

Then test the symptom you actually have

If large transfers stall while small requests succeed, measure packet sizing against a controlled destination. A probe that sets the don't-fragment bit and increases the payload size finds the path's usable MTU far more reliably than a ping that simply succeeds. Include the failing application in the test: an ICMP timeout may reflect filtering, and a small successful ping says nothing about a full-size application packet.

mssfix clamps the MSS advertised for TCP sessions inside the tunnel, which helps TCP and does nothing for an inner UDP workload. Fragmentation and offload settings have their own compatibility conditions. Choose a mechanism for the demonstrated problem rather than changing several at once to quiet a log line.

Keep the effective values with the result

Record the original and corrected effective values next to the outcome of a real transfer. That pairing is what separates an obsolete profile option from a path-MTU problem that exists independently. Without it, the next reader sees a warning that went away and assumes the network changed.

Suppressing the consistency check reconciles nothing. It removes the observation and leaves both configurations as they were.