Improve MTU behavior

[amluto]

Current behavior with respect to MTU seems suboptimal. It mostly works for TCP (due to all kinds of magic related to mssfix), but it's problematic for everything else.

Currently, if mtu-disc is "yes", then an openvpn tunnel is a PMTU blackhole. (This is arguably a real bug, not just a feature request.) If mtu-disc is "maybe", then openvpn will send fragmented UDP packets if the encapsulated packet is too large and doesn't compress enough, which sucks

Here are a few thoughts for improving the situation.

1. Add an option to respect the DF bit. If openvpn receives a packet that (in the worst case) would cause the encapsulated packet to be too large, then openvpn should drop it and generate an ICMP error. This might be a bit tricky to get completely right, especially on non-Linux platforms. Even on Linux, I'm not sure how easy it is to tell *which* UDP packet was dropped due to being too large. On the other hand, generating ICMP errors only for packets that would exceed the current estimated link mtu would probably be good enough for most uses, especially if openvpn were to send a very large ping at startup to bootstrap the PMTU discovery process.

2. Automatically set the tunnel MTU. On Linux, at least, this could even be done dynamically. Even without dynamically changing the tunnel MTU, openvpn could quickly estimate link MTU at startup and get the tunnel MTU right most of the time. This way, at least when the tunnel MTU is right, PMTU discovery inside the VPN would work correctly.

If either of these options ends up working well, then turning them on (and possibly using mtu-disc=yes) might be a sensible default. This could remove any need to fiddle with tun-mtu, link-mtu, fragment, etc. (OK, this is a slight lie -- if the determined MTU is low enough that the implied tunnel MTU < 576 (IIRC), then fragment mode would have to be enabled to get a usable link.)

[mmokrejs]

See also bug #1001.

[Gert Döring]

Please give 2.6.2 a try in this regards - the whole MTU code has been significantly reworked.

For the "send back ICMP packet too big on DF" part, this is actually straightforward now - just set something like tun-mtu 1300 on both ends, which will configure the "inner" MTU to be low enough that no "outer fragmentation" will ever be required (combine with --mssfix so TCP never even sends over-large packets).

--mtu-disc is still not very well understood - it does what it claims, creating packets with DF bit and recording the resulting outer MTU, but it does not take the necessary consequences (like, reduce the inner MTU). If used together with --fragment it might do the right thing, but that option is incompatible with DCO, so the current recommendation among the OpenVPN developers is to either ensure inside MTU is low enough to not require external fragmentation, or to set inside MTU to 1500 and ensure external fragmentation works. Both are valid approaches, what is best depends on the particular network.