Hello, I'd like to bring to your attention serious compatibility issue with OpenVPN Connect client regarding mssfix config option.
For unknown reasons, developers decided to "extend" its functionality in the following way (quoting reply from support): "In addition to modifying MSS option in TCP SYN (which affects all TCP packets), we also send ICMP "fragmentation needed" for IPv4 or "packet to big" for IPv6 if a packet coming from tun exceeds MSS value. This is needed to support non-TCP protocols over VPN tunnel". mssfix defaults to 1492 mtu and is on by default. In practice the above means, that OpenVPN Connect rejects and blackholes non-TCP packets larger than e.g. 1440 bytes on MacOS, despite the tun-mtu is 1500 bytes. The exact range of blackholed packet sizes will vary based on cipher and VPN transport used. When e.g. mssfix 1400 is configured, it completely disables QUIC protocol, which is based on UDP. I tried to explain to support, that this is very bad idea which breaks compatibility with properly behaving OpenVPN servers. mssfix is not expected to manipulate non-TCP packets and if they want to completely avoid fragmentation, they should lower tun-mtu instead. Sadly, noone wants to listen. Fortunately, workaround exists to circumvent this broken behaviour. When OpenVPN Connect client is configured with e.g. mssfix 1550, UDP starts working again. TCP MSS clamping could be performed on the server, since it's obviously enough to do it on one side. Perhaps someone from this group could explain to OpenVPN Connect developers, that breaking OpenVPN and basic networking principles is never a good idea... With kind regards, MD _______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
