Opened 17 months ago

Last modified 17 months ago

#1407 new Bug / Defect

MTU Discovery is broken on multiple operating systems and Linux builds

Reported by: tedm Owned by:
Priority: major Milestone:
Component: Generic / unclassified Version:
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc: tct


Please refer to the following discussions and bugs:

(Explanation of the problem and basically a response of "yeah we know")

(explanation of the problem and a response by the head dd-wrt developer to modify dd-wrt to hard code tun-mtu to 1400 in the default OpenVPN setup)

(explanation of variation of the problem affecting windows and linux and a comment "it's known and not fixed")

(observation of the problem 7 years ago and request for a fix)

(observation of a dependent problem and statement that MTU overhead code calculation is a mess)

(observation of the problem on OpenWRT)

In ticket 930 Gert says:

"To work around this, scenarios where a smaller-than-1500 MTU is desired and should be consistent, using --tun-mtu 1400 (or such) should yield proper results."

This appears to be the source of the response in discussion 32309 to set -tun-mtu to 1400 as I can find no other source for the "magic" number of tun-mtu - 1400

My own testing shows tun-mtu of 1400 is too big. Perhaps it was OK for a 4 year old version of OpenVPN but not today.

My testing shows the optimal "magic" numbers for tun-mtu to be 1350 for UDP tunnels and 1348 for TCP tunnels. These "magic" numbers create a link-mtu of 1472 which when wrapped in a 28 byte packet create a packet of MTU of 1500 which fits in a standard Ethernet or GigE frame. There are other "magic" tun-mtu numbers for PPPoE frames and Jumbo gigabit frames of course. But "The Internet" has come to assume a de-facto MTU of 1500 across the Internet.

My testing has shown that OpenVPN is apparently unable to properly calculate tun and other internal parameters if link-mtu is set to 1472. It does appear to work if tun-mtu is manipulated.

In reviewing dozens of other bugs in the OpenVPN bug tracking, as well as user problem requests with OpenVPN in many other forums across the Internet it shows a very strong likelihood of many problems being based on too large MTU assumptions made by OpenVPN

THEREFORE as this problem has languished for many years my suggestion is to completely scrap all MTU discovery code in OpenVPN as well as scrapping the MTU autodiscover code.

Instead, have OpenVPN always assume a PHYSICAL MTU of 1500 and base it's calculations of link-mtu tun-mtu and the rest of it off that. In addition, issue a large warning in the OpenVPN log stating "Interface MTU not provided assuming interface MTU of 1500 and link-mtu of 1472"

Presumably the small minority of people running OpenVPN on devices with OC3's, or Token Ring interfaces will understand they are in Weirdsville and need to actually read the logs of software they use.

Change History (1)

comment:1 Changed 17 months ago by tct

Cc: tct added
Note: See TracTickets for help on using tickets.