Opened 3 years ago
Closed 20 months ago
#1407 closed Bug / Defect (fixed)
MTU Discovery is broken on multiple operating systems and Linux builds
| Reported by: | tedm | Owned by: | |
|---|---|---|---|
| Priority: | major | Milestone: | release 2.6 |
| Component: | Generic / unclassified | Version: | |
| Severity: | Not set (select this one, unless your'e a OpenVPN developer) | Keywords: | |
| Cc: | tct |
Description
Please refer to the following discussions and bugs:
https://forums.openvpn.net/viewtopic.php?f=4&t=32309#p99407
(Explanation of the problem and basically a response of "yeah we know")
https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=329037
(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)
https://community.openvpn.net/openvpn/ticket/930
(explanation of variation of the problem affecting windows and linux and a comment "it's known and not fixed")
https://community.openvpn.net/openvpn/ticket/375
(observation of the problem 7 years ago and request for a fix)
https://community.openvpn.net/openvpn/ticket/1389
(observation of a dependent problem and statement that MTU overhead code calculation is a mess)
https://community.openvpn.net/openvpn/ticket/1103
(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 (3)
comment:1 Changed 3 years ago by
| Cc: | tct added |
|---|
comment:2 Changed 20 months ago by
comment:3 Changed 20 months ago by
| Milestone: | → release 2.6 |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
closing this, as there is not really something we're going to do about this ticket that we have not already done in the MTU-related fixes that went into 2.6 already
This is a slightly complex topic - actually, {{--mtu-disc}} does work, but only on Linux, and it was broken for a long time.
It won't actually do what people expect it to do - it will not adjust the inner interface MTU ({{--tun-mtu}}), but it will adjust {{--mssfix}} to make TCP packets small enough to avoid MTU issues. UDP and ICMP with large packets will be completely broken if {{--mtu-disc}} is used, as it will disable outside fragmentation, necessary for large non-TCP packets.
With 2.6.0, {{--tun-mtu}} is pushable, and the server will actually push a smaller-than-default MTU if configured (and a {{--tun-mtu}} mismatch will usually still work).
There's two camps in OpenVPN Community development - one camp says "links should be 1500 byte, and outside fragmentation should work, but for TCP performance, {{--mssfix}} is a good option to avoid outside fragmentation". The other camp says "{{--mssfix}} is just pampering the problem, use a {{--tun-mtu 1420}} instead, and OSes and client apps will do the right thing automatically (except when they don't)".
Both are right, so we didn't change the defaults, just made the infrastructure support changeable MTUs better.
(As a side-note, {{--link-mtu}} is really problematic, as the relationship between {{--link-mtu}} and {{--tun-mtu}} depends on ciphers etc. negotiated(!), so might actually be different for different clients on the same server... - so, use {{--tun-mtu 1420}} instead, and forget about {{--link-mtu}})
{{--tun-mtu 1420}} translates to "outside packets will be <= 1492 bytes when using AEAD ciphers, which is recommended anyway". If you add an explicit HMAC (SHA256 = 32 byte), you need to go even lower than 1400.