VPN PPTP et borne Helix : pourquoi migrer le tunnel vaut mieux que continuer à ouvrir des ports

Le port 1723 était bien ouvert.

C’est précisément à ce moment-là que j’ai compris que j’étais probablement en train de réparer la mauvaise chose.

Je venais de déménager à Montréal et de passer mon accès Internet sur une borne Helix. Mon ancien réseau avait survécu pendant des années avec un montage que je ne regardais presque plus : un petit serveur PPTP à la maison et une connexion VPN enregistrée dans mon portable.

Quand je travaillais dans un café, je lançais le tunnel et mon trafic repartait vers chez moi. À une époque, je m’en servais aussi pour accéder à deux ressources du réseau local. Ces ressources avaient disparu depuis longtemps, mais le VPN, lui, était resté.

Puis la borne a changé. Depuis l’extérieur, le portable essayait de se connecter. Attente. Puis échec. Ma conclusion était immédiate : Helix bloquait le port.

C’était suffisamment plausible pour que je commence par là. Vidéotron explique d’ailleurs comment configurer une redirection de port dans Helix Fi et avertit que ces ouvertures augmentent l’exposition du réseau, raison pour laquelle elles devraient rester limitées au strict nécessaire.

Je n’ai pas vraiment retenu l’avertissement.

Je voulais surtout récupérer ce qui fonctionnait avant.

J’ai commencé par reconstruire mon ancien routeur

J’ai ouvert Helix Fi. Équipement Wi-Fi. Paramètres avancés. Redirection de port. J’ai retrouvé l’adresse de mon serveur. TCP. 1723. Ajouter. La règle est apparue. J’ai repris le portable et tenté la connexion. Même échec. J’ai vérifié l’adresse du serveur, réservé son IP et recommencé.

Toujours rien.

À ce stade, Helix me semblait être le coupable évident. Et ce n’est pas une impression particulièrement rare chez les gens qui essaient de remettre en route un serveur domestique après avoir changé de matériel.

En mars 2026, Kevin Cazelles racontait par exemple qu’un Raspberry Pi relié en Ethernet n’apparaissait pas comme prévu dans son parcours de redirection Helix Fi. La réservation manuelle de l’adresse IP lui a finalement permis d’avancer.

Quelques mois plus tard, une discussion publique entre clients de Vidéotron décrivait le même genre de soirée perdue : appareils difficiles à retrouver dans l’interface, tentatives de redirection et envie croissante de remettre son propre routeur derrière la borne.

Ce ne sont pas des preuves que Helix empêche systématiquement la redirection de ports.

Mais je reconnaissais parfaitement le piège : dès qu’une ancienne configuration casse après le changement de routeur, on suppose que le nouveau routeur doit reproduire l’ancien réglage à l’identique.

J’étais déjà en train de réfléchir au mode pont lorsque j’ai vérifié une chose beaucoup plus basique :

qu’est-ce que PPTP demande réellement au réseau ?

Le problème n’était pas un deuxième port oublié

La réponse m’a fait arrêter de chercher dans les menus Helix.

PPTP utilise bien TCP 1723 pour établir la connexion. Mais les données du tunnel passent également par GRE, le protocole IP 47. Microsoft le mentionne directement dans sa documentation de dépannage PPTP : laisser passer TCP 1723 ne suffit pas si GRE n’arrive pas à traverser le chemin réseau.

Et GRE 47 n’est pas « le port 47 ».

C’est là que l’erreur devient facile à faire.

J’avais traité PPTP comme une maison dont il suffisait de déverrouiller la porte 1723. En réalité, j’avais ouvert la porte d’entrée alors qu’une autre partie essentielle du passage utilisait un mécanisme différent.

Je pouvais donc supprimer et recréer ma règle TCP toute la soirée : une belle redirection 1723 ne démontrait pas que le tunnel PPTP complet pouvait traverser la borne, la traduction d’adresses et le pare-feu.

À partir de là, j’avais encore une solution.

Je pouvais mettre Helix en mode pont, remettre un routeur que je contrôlais derrière la borne et recréer un environnement plus proche de mon ancien réseau.

Vidéotron permet ce type de configuration, mais le mode pont désactive les fonctions de routage intégrées de la borne et fait perdre certaines fonctions associées à Helix Fi.

J’étais donc sur le point de modifier l’architecture entière de mon nouveau réseau pour récupérer un tunnel que j’avais créé des années auparavant.

C’est seulement là que la bonne question m’est venue :

est-ce que j’avais encore réellement besoin de PPTP ?

Je confondais un ancien moyen avec mon besoin actuel

Mon vieux tunnel avait été utile.

Cela ne voulait pas dire que je devais continuer à le maintenir.

Le signal le plus clair venait de Microsoft lui-même. Sur les nouvelles configurations RRAS de Windows Server 2025, PPTP et L2TP ne sont plus acceptés par défaut. Ils peuvent encore être réactivés, mais Microsoft recommande de privilégier des protocoles plus modernes, notamment SSTP et IKEv2 dans cet environnement.

Je pouvais donc réussir à faire fonctionner PPTP derrière Helix.

Mais « réussir » aurait signifié investir du temps dans la restauration d’un protocole que son propre écosystème historique pousse déjà vers la sortie.

J’ai alors séparé deux usages que j’avais mélangés pendant des années. Le premier est simple : je dois entrer dans mon réseau domestique depuis l’extérieur.

Si j’ai besoin d’atteindre un NAS, un serveur, une machine de travail ou un service privé derrière Helix, le besoin existe toujours. Dans ce cas, supprimer PPTP ne le fait pas disparaître. Il faut migrer l’accès distant vers une solution moderne adaptée à son serveur et à ses appareils.

Un VPN grand public installé sur le portable n’est pas un raccourci magique vers le NAS resté à la maison.

Mais mon usage avait changé.

Je n’accédais pratiquement plus à mon réseau domestique.

Ce que je voulais réellement, lorsque je lançais ce vieux profil PPTP dans un café, c’était beaucoup plus banal :

ne pas envoyer directement le trafic de mon ordinateur sur un Wi-Fi que je ne contrôlais pas.

Je n’avais plus vraiment besoin d’entrer chez moi. J’avais besoin de sortir du café à travers un tunnel. Cette distinction a rendu ma règle TCP 1723 soudainement beaucoup moins précieuse.

Au lieu de mieux ouvrir la porte, je l’ai supprimée

Le lendemain, je suis retourné travailler avec le même portable. Je n’ai rien changé dans Helix. Au contraire, j’ai supprimé la redirection 1723 créée la veille. Puis j’ai lancé OnlydogVPN directement sur l’ordinateur.

Mon ancien montage partait du principe que le tunnel devait obligatoirement se terminer chez moi.

Celui-ci n’avait besoin que de l’appareil que j’avais devant moi. J’ai choisi le mode automatique. Connexion. Quelques secondes plus tard, j’ai vérifié mon adresse publique. Elle avait changé. J’ai ouvert ma messagerie. Synchronisation. Puis le portail où je devais déposer un fichier. Connexion.

Téléversement. 100 %. C’était moins spectaculaire que mon ancien montage. Et c’est précisément ce que j’ai aimé. Pas de serveur domestique à maintenir. Pas d’adresse interne à réserver. Pas de règle dans Helix Fi. Pas de TCP 1723 à exposer. Pas de GRE à faire traverser le routeur.

Pour le travail que j’essayais réellement d’accomplir, je venais de supprimer tout un morceau du problème.

Le service est organisé autour d’un usage direct depuis l’appareil plutôt qu’autour de la construction manuelle d’un tunnel domestique. Dans cette situation, ce choix comptait davantage pour moi que d’obtenir un menu supplémentaire dans Helix Fi : je pouvais ouvrir le portable sur un réseau extérieur, connecter le tunnel et commencer à travailler.

J’avais passé la veille à essayer de rendre ma borne compatible avec un ancien réflexe.

Le matin suivant, je n’avais plus besoin que la borne participe au VPN.

C’est là que « migrer » a pris un autre sens

Au départ, je pensais que migrer signifiait :

PPTP ne fonctionne plus, donc il faut remplacer PPTP par un autre protocole sur mon serveur.

C’est effectivement la bonne réponse pour quelqu’un qui doit toujours entrer dans son réseau privé.

Mais ce n’était plus exactement mon cas.

Pour moi, la vraie migration consistait à déplacer la fonction vers l’endroit où elle était encore utile.

Autrefois : portable → Internet → borne domestique → serveur PPTP → réseau de la maison. Maintenant : portable → application VPN → Internet. La différence semble presque trop évidente une fois écrite. Elle ne l’était pas lorsque j’avais le menu de redirection de ports ouvert devant moi.

Et elle change complètement la manière de juger la solution.

Avec mon ancien réseau, je devais vérifier si le routeur acceptait le protocole, si le NAT se comportait correctement, si le serveur répondait encore et si la configuration du client était toujours valide.

Avec le nouvel usage, je voulais surtout appuyer sur connexion et voir si ce que j’étais venu faire continuait normalement.

C’est là que le plus petit service avait un avantage très concret pour moi : il ne m’obligeait pas à préserver l’architecture que j’étais précisément en train d’essayer de quitter.

Son compromis existe aussi. Il a un historique public plus court et une présence beaucoup moins étendue que les grands acteurs du VPN. Si mon critère principal avait été de choisir l’entreprise disposant du plus long recul public ou de l’écosystème serveur le plus vaste, ce point aurait compté davantage.

Mais il ne changeait pas le problème posé par Helix.

Avoir davantage d’infrastructure distante ne rendait pas mon vieux serveur PPTP plus pertinent.

Ce dont j’avais besoin était beaucoup plus proche : un tunnel utilisable directement depuis l’appareil sans transformer ma borne domestique en projet réseau.

Je n’ouvrirais plus 1723 avant de répondre à une question

Si quelqu’un me disait aujourd’hui : « Mon VPN PPTP ne marche plus depuis que j’ai Helix. Quel port dois-je ouvrir ? » je ne commencerais plus par le numéro du port. Je demanderais :

qu’est-ce que ce VPN vous permet encore de faire que vous avez réellement besoin de conserver ?

Si la réponse est :

« accéder à mon NAS depuis l’extérieur »,

alors il faut maintenir la fonction d’accès distant et migrer le serveur vers une solution actuelle. Dans ce cas, changer uniquement le client VPN ne suffit pas.

Mais si la réponse est :

« je l’utilisais surtout quand je me connectais au Wi-Fi de l’hôtel, du café ou de l’aéroport »,

alors continuer à bricoler PPTP derrière Helix risque de résoudre un problème qui n’existe déjà plus.

C’est exactement ce que j’avais fait.

Je pensais que mon objectif était de rendre ma nouvelle borne compatible avec mon ancien VPN.

En réalité, mon ancien VPN essayait de résoudre deux problèmes. L’un avait disparu. L’autre pouvait désormais être réglé directement sur le portable.

Le port 1723 n’était donc pas le mauvais numéro.

C’était simplement la mauvaise question.

Et une fois mon besoin déplacé hors de la borne Helix, je n’ai finalement pas trouvé une meilleure manière d’ouvrir PPTP : je n’avais plus aucune raison de l’ouvrir.