Windows L2TP ne charge que certains sites : effacez le bit DF sur pfSense

Le portable se connecte, l’intranet se charge et une poignée de sites publics se bloquent. L’authentification et le routage fonctionnent manifestement, ce qui laisse la taille des paquets comme explication. Dans un tunnel L2TP/IPsec, la MTU utilisable est plus petite que ce que l’adaptateur annonce encore, et le client continue d’envoyer des paquets pleine taille avec le bit « ne pas fragmenter » activé. On peut ordonner à une passerelle pfSense d’effacer ce bit, et c’est le moyen le plus rapide de confirmer le diagnostic avant de corriger proprement.

Commencez par les pages qui échouent

Notez quelles destinations échouent et lesquelles réussissent avant de toucher au moindre réglage. Les poignées de main qui restent sous la limite du tunnel aboutissent normalement, tandis que les transferts qui exigent un segment pleine taille calent à mi-chemin. Cette coupure est la signature d’un problème de taille et non d’un filtre, car une destination bloquée échoue à l’établissement de la connexion et non au milieu de la page. Ces deux observations ne coûtent rien et resserrent immédiatement la recherche.

Testez avec un ping qui active le bit et contrôle la taille de la charge utile. La plus grande charge utile qui passe vous donne la MTU réelle du chemin, et la valeur annoncée de l’adaptateur montre à quel point les deux diffèrent.

Notez les deux nombres. Le correctif dépend de celui qui est faux, et c’est le couple qu’une capture confirmera plus tard.

Ce que fait le bit DF en sortie

L’encapsulation explique l’écart des nombres. IPsec ajoute ESP, L2TP ajoute un autre en-tête, et le tunnel transporte donc moins de charge utile que la liaison physique. Windows annonce toujours 1500 octets sur l’adaptateur et active « ne pas fragmenter » sur ce qu’il envoie. Quand un tel paquet ne passe pas, la bonne réponse de la passerelle est un message ICMP qui demande à l’émetteur de réduire. C’est pourquoi un tunnel qui laisse passer de petits pings peut tout de même faire échouer un téléchargement.

Ce message n’arrive souvent jamais. Un saut peut filtrer ICMP, ou rien ne le génère, et l’émetteur répète la même taille jusqu’à ce que le transfert abandonne.

Le silence est ici la présentation normale, d’où la lecture du symptôme comme un blocage sélectif. Rien dans le journal du client n’enregistre un message ICMP manquant.

L’option pfSense, et ce qu’elle ne fait pas

L’option se trouve sur la page Système, Avancé, Pare-feu et NAT, sous le libellé « Effacer les bits DF invalides au lieu de supprimer les paquets ». Plutôt que de jeter un paquet trop gros qui porte l’indicateur, le filtre retire l’indicateur et laisse le paquet se scinder plus loin. Un paquet compte comme invalide quand il ne peut pas franchir l’interface sortante d’un seul tenant.

L’option rétablit la connectivité sans toucher au client, d’où sa popularité. C’est aussi un contournement : la fragmentation coûte du CPU et rend chaque fragment perdu plus cher.

Elle ne s’applique qu’au trafic transmis, pas au trafic que le pare-feu émet lui-même. La même page propose « Désactiver le nettoyage du pare-feu », qui coupe entièrement la normalisation, et c’est un changement bien plus large que ce problème n’en a besoin.

Un correctif plus étroit qui garde TCP non fragmenté

Presque tous les flux bloqués sont TCP, et TCP peut négocier un segment plus petit au lieu de compter sur la fragmentation. Limiter le MSS sur l’interface du tunnel réécrit la valeur annoncée pendant la poignée de main, si bien que chaque côté envoie ce qui passe réellement. Le chemin se comporte alors de façon prévisible et aucun paquet n’a besoin d’être scindé.

Cela laisse UDP à la découverte ou à l’option DF. Quand les sites qui échouent sont des pages web ordinaires, la limitation est le changement à privilégier.

Le client peut signaler sa propre MTU d’adaptateur via netsh interface ipv4 show subinterfaces. Comparez ce chiffre à celui que le serveur croit avoir négocié, car les deux ne coïncident pas toujours. Cette valeur est celle que le système d’exploitation utilisera réellement, quoi qu’ait annoncé la négociation.

Confirmez avec une capture, puis réinitialisez l’état

Capturez des deux côtés avant de décider : une trace là où passe le tunnel, une autre là où passe l’interface WAN. Les paquets qui sortent pleine taille sans ICMP en retour désignent la limitation comme la bonne couche. Les réponses qui arrivent puis meurent au retour désignent en revanche la MTU du tunnel.

Videz la table d’états avant de réessayer, car les flux existants gardent leurs anciennes tailles de segment. Chargez ensuite la page qui a échoué et lisez la vue des états pour le trafic bidirectionnel plutôt que des compteurs à sens unique. Si elle cale encore, capturez de nouveau au lieu d’essayer une autre case.