Passthrough PPTP absent : corriger l’erreur 807 de Windows VPN

Le transfert du TCP 1723 ouvre souvent la première partie de PPTP et laisse le reste cassé, si bien que Windows renvoie encore l’erreur 807 à la tentative. Le réflexe suivant est d’ajouter une règle pour le port 47, et c’est précisément l’étape qui gaspille un après-midi : GRE est un numéro de protocole dans l’en-tête IP, pas un port qu’une table de transfert peut faire correspondre. Tant que le routeur ne laisse pas passer le protocole 47 et ne le lie pas au même appel, le tunnel ne peut pas démarrer. Les sections ci-dessous séparent les deux canaux, puis les testent un par un.

Une table de ports n’a pas de ligne pour un numéro de protocole

PPTP utilise deux conversations qui échouent de manières différentes. Celle sur TCP 1723 lance l’appel, transmet les informations de liaison et le coupe lorsque l’utilisateur se déconnecte. Le côté charge utile tourne à l’intérieur de GRE, que l’en-tête IP étiquette avec le numéro de protocole 47, et dans ce tunnel PPP négocie la liaison pendant que MS-CHAPv2 vérifie les identifiants.

Comme GRE ne porte aucun en-tête de transport, il n’expose aucun port, si bien qu’une règle écrite pour des ports n’a rien à faire correspondre. Un routeur qui transfère le 1723 crée une correspondance pour cette session TCP et s’arrête là. Le firmware qui gère la seconde moitié appelle la fonction passthrough PPTP ou PPTP ALG, et certains firmwares n’offrent ni l’un ni l’autre et ne mentionnent jamais la lacune. Le libellé de la case importe moins que la question de savoir si le protocole 47 est reconnu du tout.

Ce que Windows signale quand le chemin des données meurt

L’erreur 807 dit que la connexion n’a pas pu être établie, ce qui en pratique signifie que l’appel a atteint le serveur et que le canal de données ne s’est pas levé. C’est un verdict sur le transport, pas un verdict sur le compte. L’erreur 691 est celle qui pointe vers les identifiants ou vers une incompatibilité du protocole d’authentification, elle vous envoie donc ailleurs.

Travaillez le transport avant de toucher au mot de passe. Changer les identifiants pour traquer le 807 laisse la vraie panne en place et rend la tentative suivante plus difficile à lire.

Pourquoi un second client casse un tunnel qui fonctionne

Sans ports pour les distinguer, un appareil NAT ne peut pas séparer deux clients PPTP comme il sépare deux sessions HTTPS. Beaucoup d’appareils grand public n’autorisent donc qu’un seul appel PPTP et le suivent par adresse source. Un portable qui fonctionnait seul cesse d’aboutir dès qu’une seconde machine compose, et du côté du client la panne semble aléatoire. Ce schéma appartient au firmware, et aucun changement de profil ne le modifiera.

Surveillez la table des connexions pendant que les deux clients composent. Si seul le premier hôte détient jamais une correspondance, le routeur a atteint la limite de ce qu’il prend en charge et aucun réglage côté client ne la déplacera.

Prouvez quelle moitié échoue

Confirmez que le TCP 1723 arrive avant de changer quoi que ce soit sur le routeur, car cette réponse décide quelle moitié vous testez. Exécutez ces commandes depuis le client Windows vers votre propre nom de serveur. La première indique si le port a répondu, et la seconde compose sans boîte de dialogue, ce qui rend les tentatives répétées comparables.

Test-NetConnection vpn.example.com -Port 1723
rasdial "Work VPN"

Un résultat vrai au test de port signifie que le canal de contrôle est ouvert et que GRE est le suspect restant. Un résultat faux signifie que le routage, un filtre ou le transfert sont cassés, et aucun changement GRE ne sauvera cela. Le côté données doit être surveillé là où il est visible, sur le serveur ou sur le routeur.

tcpdump -ni any proto 47

L’équivalent dans Wireshark est le filtre d’affichage ip proto 47, plus facile à confier à quelqu’un qui n’est pas à l’aise dans un shell. Un GRE qui arrive sans que rien ne parte en réponse signifie que le chemin de retour doit être corrigé.

Ce qui corrige réellement l’erreur

Là où le routeur expose le réglage, activez le passthrough PPTP ou autorisez explicitement le protocole 47 sur un firmware qui accepte des règles. Sur RouterOS, la règle de transfert fait correspondre le protocole directement, ce qu’un transfert basé sur les ports ne pourrait jamais faire. Le firmware grand public cache généralement la même décision derrière une case, parfois dans les réglages de sécurité plutôt que dans le transfert de ports. S’il n’existe aucun tel contrôle, rien sur le client ne compensera.

/ip firewall filter add chain=forward protocol=gre action=accept
/ip firewall filter print where protocol=gre

Remplacer PPTP est l’autre option et souvent la moins chère. Un routeur qui termine lui-même le VPN évite le double NAT pour les clients entrants, et un protocole qu’un NAT basé sur les ports gère déjà n’a pas besoin de passthrough : OpenVPN sur UDP, SSTP sur TCP 443 ou L2TP/IPsec avec NAT-T qui enveloppe ESP dans UDP 4500. PPTP dépend aussi de MS-CHAPv2, dont les faiblesses documentées en font un mauvais choix pour un nouveau déploiement même une fois l’erreur disparue.

Notez quelle règle a fait la différence, car le même site rencontrera la même limite quand le second utilisateur demandera l’accès. Une correction au niveau du protocole appartient aux notes réseau, là où le prochain ingénieur regardera.