Si le soucis se confirme être le MTU, alors ce qui peut faire varier l'accessibilité c'est la techno d'accès, xDSL, et aussi si l'opérateur à dégroupé ou si il passe par une collecte (L2TP, PPP)
Je dis ça car en passant par OpenVPN ça fonctionnait (donc le MTU du tunnel est plus faible, par dessus de l'ADSL).

Quelqu'un pour faire remonter une description claire du problème (avec vecteurs de tests) aux équipes réseau de Free ?

D'ailleurs maintenant que Rani a un compte sur le forum, ça pourrait être intéressant de voir s'il accepterait de répondre à une sélection de questions faite par Vivien (par exemple, ça peut être une/des autre(s) personne(s)). Ça pourrait permettre d'éclaircir certains points qui restent un peu obscurs et éventuellement de faire remonter les problèmes repérés et d'avoir des retours dessus.

Si le client offre une MTU de 1500, le serveur va envoyer des paquets de 1500 sauf que la Freebox va jeter le paquet, trop gros pour être encapsulé dans de l'IPv6.

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.

J'ai remis la config par défaut, interface standard Freebox, donc, ça marche pas. (MTU freebox supposée à 1500)

Je vous laisse faire les logs.
Bonne nuit :-)

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...).

Le probleme serait donc un filtrage trop fort de l'icmp sur la Freebox ?

Soit la Freebox jette le paquet trop gros, mais n'envoie pas l'ICMP.
Soit c'est plus loin dans le réseau, et là ça peut être soit un soucis de filtrage, soit de routage : avec le A+P, il faut regarder le port TCP dans les données ICMP (la copie du début du paquet ayant généré l'erreur : entête IP + 8 premiers octets de l'entête TCP/UDP) pour savoir à laquelle des 4 Freebox il faut envoyer l'ICMP.