non. le 4rd impose de fragmenter si c'est trop gros, c'est dans la norme. La freebox doit donc fragmenter (sauf si y'a DF dans le paquet) et pas rejeter le paquet.
y'a peut-être un souci ailleurs. genre un icmp qui passerai pas quelque part dans le réseau 4rd.
Il y a DF dans les premiers paquets, donc je suppose que le PMTU Discovery est activé.
Il semble que les PC derrière la Freebox en ZMD (au moins en mode bridge) ne reçoivent pas les ICMP "Destination Unreachable / Fragmentation required, and DF flag set" qui auraient dû être envoyés par la Freebox, créant un "black hole".
Je ne sais pas pourquoi ça semble affecter la Freebox elle même également (elle devrait connaitre la MTU du tunnel pourtant).
Pour un PC Linux derrière la Freebox, je vois 3 solutions :
- forcer la valeur de MTU (ce qui semble bien fonctionner)
- positionner /proc/sys/net/ipv4/tcp_mtu_probing à 1 (Linux devrait déterminer la PMTU à l'aide des pertes de paquets à défaut d'avoir les ICMP :
http://www.bortzmeyer.org/4821.html)
- positionner /proc/sys/net/ipv4/ip_no_pmtu_disc à 1, ce qui désactive le code de PMTU Discovery (le flag DF ne sera plus positionné pour le TCP, et la Freebox devrait fragmenter les paquets si elle implèmente bien du 4rd) : ça devrait fonctionner avec une MTU à 1500 mais des performances probablement moins bonnes
On ne sait pas si des ICMP "Destination Unreachable / Fragmentation required, and DF flag set" émis par des clients ou routeurs sur le réseau seraient reçus. Si ce n'est pas le cas ce qui pourrait aussi poser problème avec la première solution s'il y a une partie du réseau entre le client et le serveur (hors Free) qui a un MTU encore plus faible et qui n'ajuste pas le MSS.
Pour réellement corriger le problème, la Freebox devrait ajuster les MSS et/ou envoyer les ICMP (sachant qu'ajuster le MSS ne fonctionne que pour le TCP, et n'est pas parfait : les routes pouvant changer dynamiquement, le PMTU n'est pas forcèment une constante...).