Recently I've been taking a new look at MTU issues. It seems that some people are having problems lately that are related to MTU or PMTU discovery.
I was trying to think up some ways to make OpenVPN's handling of MTU a bit less opaque, more automatic, and also give more manual control to those who know what they're doing. I have some preliminary code in the CVS (under branch MTU_EXPERIMENTAL) that adds an option (--mtu-disc) that gives manual control over whether path MTU discovery is performed on the UDP link. I also borrowed some code from tracepath to print the discovered PMTU size on UDP read/write errors. Unfortunately, I'm not sure whether this code will work on non-Linux OSes. See mtu.c for more info. I've also considered ways of making OpenVPN's MTU calculation more automatic without relying on PMTU which is often broken due to over-restrictive firewalls in the path that block ICMP messages. PMTU also lacks DoS resilience. One way might be to do our own PMTU discovery by transmitting various sized packets over the UDP channel and having the remote peer report back on the largest packet it received. One problem is that MTU size could change during a session, necessitating a re-ifconfig of the TUN/TAP device, which may not be possible on some platforms and breaks --user/--group nobody. This might be handled in a way similar to --ping-restart or SIGHUP/SIGUSR1, where the openvpn daemon would essentially restart if the MTU size changed. This would be effective if path MTU changes are infrequent but still creates problems when --user/--group nobody is used, since the openvpn daemon will lack sufficient privilege to reopen and re-ifconfig the TUN/TAP device. Comments? James
