Bonjour alain_p,

je pense que je me suis mal exprimé, je n'écris pas en tant que client FREE ayant des problèmes, mais en tant que service informatique d'une banque ayant des utilisateurs chez FREE, qui eux présentent un problème. La majorité des utilisateurs se situe en région parisienne en ZMD.
Ayant parcouru le thread, j'ai effectivement lu les informations selon lesquelles le MTU ne devrait pas être un problème. Cependant j'ai précisé notre configuration pour écarter ce sujet.
J'ai lu tous ce qu'il y avait a lire sur les technos mentionnées dans ce thread concernant la configuration FREE en ZMD.
Si je me suis décidé a écrire ici, c'est essentiellement parce qu'il est impossible de contacter FREE si on n'est pas client. J'ai essayé en vain.
Puisque certains ici semblent avoir des contacts autres, je me suis décidé à poster.

Je finirai par décrire rapidement la configuration utilisée :
anyconnect (le client vpn cisco) utilise 2 tunnels : un TCP-443 et un UDP-443.
le TCP est monté en premier, et lui fonctionne bien, puisque TCP gère les pertes de paquets.
l'UDP est ensuite établi (avec les infos du premier) et une tentative de détermination du MTU du tunnel est lancée, avec le principe du Keep-alive (envoi hello, réponse ok), de taille, qui décrèmente, jusqu'a obtenir une réponse.
Le problème est donc : dû aux pertes de paquets, les keep-alive de détermination de MTU, sont perdus. Le client considère que le MTU est trop bas, et il relance la négociation indéfiniment. le tunnel est donc inutilisable.

Vous me direz : désactive l'UDP, comme ça le tunnel TCP sera utilisé et tout ira bien. C'est vrai. mais ce n'est pas possible, puisque nos 2500 utilisateurs ne sont pas tous chez free en fibre en zmd, et que dans tous les autres cas le tunnel UDP fonctionne. Le tunnel UDP est nécessaire pour des questions de performance des applications de TOIP déployées sur les postes.

Bref, heureusement que le full stack ipv4 résoud le problème, sinon nous aurions été obligé de spécifier au support utilisateur de conseiller aux personnes impactées de changer d'opérateur.

Malgré la solution trouvée, je suis interressé pour comprendre ce qu'il se passe.

Il est possible de pinger l'adresse IPv4 "full-stack".

PS : A mon avis il est possible d'avoir une réponse en contactant officiellement Free en tant que service technique de la banque dont les abonnés rencontrent des problèmes.

oui FRnOG me semble la bonne piste et si on sort d'un forum grand public pour aller vers un truc pro/expert cela fera peut-être réagir Free...

c'est en plus la 'raison d’être' de FRnOG. C'est par la: http://www.frnog.org/?lang=fr (oui c'est un peu vieillot, a l'ancienne sous forme de mailing-list plutot qu'un site web 2.0 mais bon une fois de plus le dicton sur les cordonniers s’avère vrai ).

Bonjour,

merci pour vos infos.
Je me suis inscrit sur frong .... on verra bien ce quel se passe sur la mailing list.
Je n'ai pas la possibilité d'activé l'IPv6, car nous avons une infrastructure mutualisée avec le groupe et l'opérateur en place ne propose pas l'IPv6.
Le groupe n'a de toute façon pas de plan pour l'IPv6 ... ce que j'essaie de faire bouger.

Bonjour,
Je suis sur une infra DSLAM IPV6 FULL.
je suis arrivé avec LEDE/OpenWRT et un modem VDSL en Bridge à avoir l'IPV6 avec un tunnel 6to4 et j'ai mis mes IPV4 en dur.
Cependant je n'arrive toujours pas à avoir internet. Mais c'est quand même une avancée.
J'ai aussi cloné l'@ MAC.

La piste me semble intéressante.

Bonjour!
Enfin quelqu'un de volontaire pour faire la connection sur un DSLAMv6.
T'es en IP full stack? Si non, cela peut être la source du problème mais une commande iptables qui va bien devrait résoudre cela.
Quand tu tcpdump un ping depuis le LAN vers le net, tu vois bien le ping sortir encapsulé dans l'IPv6 avec la bonne IPv4 source (en gros le masquerading marche bien)?
Edit: j'avais pas vu le 6to4. Faudrait du 4to6 plutôt. C'est vraiment un DSLAMv6 ou c'est juste pour avoir l'IPv6 donné par le tunnel 6rd (un DSLAMv4)?