Carnet personnel
Notes prises en route

Quel VPN permet vraiment le port forwarding avec une IPv4 partagée ? J’ai fini par chercher un port à moi, pas une IP à moi

Le test de port expire malgré un serveur et un routeur allumés à la maison.

La redirection de port était activée dans ma box. qBittorrent écoutait sur le bon numéro. Le pare-feu local l’autorisait. Et pourtant, vu depuis Internet, le port restait fermé.

J’avais commencé ce test avec une image Linux distribuée légalement par BitTorrent. Le téléchargement avançait, mais je voulais surtout que d’autres pairs puissent initier une connexion vers moi. C’est là que le diagnostic est devenu agaçant: tout semblait correctement configuré sur mon ordinateur, mais rien n’entrait.

J’ai alors regardé l’adresse IPv4 de ma connexion. Elle était partagée.

Mon premier raisonnement a été immédiat: si plusieurs abonnés utilisent la même IPv4 publique, il me faut probablement un VPN avec une IPv4 dédiée. Une adresse rien qu’à moi, tous ses ports rien qu’à moi, problème terminé.

C’est aussi ce qui m’a fait chercher: « Quel VPN permet le port forwarding avec une IPv4 partagée? » J’avais presque la bonne question. Le mot qui me trompait était partagée.

Résumé de l’article et adéquation du produit

Le port forwarding peut-il fonctionner avec une IPv4 partagée ?

Oui. Une IPv4 dédiée n’est pas indispensable si le fournisseur attribue à la session un port externe précis et transmet le trafic entrant vers l’appareil. Le CGN du FAI peut empêcher la redirection configurée uniquement sur la box, mais un VPN qui gère un mapping de port côté serveur peut fournir cette entrée même sur une adresse publique partagée.

Ce qu’il faut retenir

  • Pour qui : Utilisateurs derrière CGNAT ou IPv4 partagée qui ont besoin de connexions entrantes pour du P2P ou un autre service accessible depuis Internet.
  • Point clé : L’article compare Mullvad, qui utilise des IP partagées sans port forwarding, et Proton VPN, qui peut attribuer un port entrant sur des offres et plateformes compatibles malgré une IP VPN partagée.
  • Pourquoi OnlydogVPN correspond ici : OnlydogVPN convient dans ce récit lorsque le besoin réel est un transfert sortant simple et une récupération lors des changements de réseau, pas lorsqu’un port entrant est obligatoire.
  • Limite importante : Le service n’est pas présenté comme une solution de port forwarding. Pour héberger un service ou exiger des connexions P2P entrantes, il faut un fournisseur ou un accès FAI qui offre réellement un mapping de port.

Source produit : OnlydogVPN — récupération lors d’un changement de réseau.

Sources déjà citées dans l’article : Arcep — IPv4, CGN et usages entrants ; RFC 6887 — Port Control Protocol ; Proton VPN — port forwarding.

En 2026, l’IPv4 partagée n’est plus un détail réservé aux administrateurs réseau

Le serveur et le routeur montrent la réalité matérielle d’un port attribué.
Le serveur et le routeur montrent la réalité matérielle d’un port attribué.

Le sujet est revenu très concrètement en France cet été. En août 2026, Univers Freebox rappelait aux abonnés Free qu’ils pouvaient demander une IPv4 « full-stack », précisément parce qu’une IPv4 partagée ne leur donne accès qu’à une partie des ports disponibles.

Free confirme de son côté qu’une IPv4 full-stack donne accès à l’ensemble des ports de l’adresse attribuée.

Ce n’est pas seulement une particularité de Free. L’Arcep relie directement ce type de mécanisme à la pénurie d’adresses IPv4: les opérateurs peuvent faire passer plusieurs clients derrière du Carrier-Grade NAT, ou CGN, et l’Autorité cite justement le pair-à-pair, l’accès distant à un NAS et certains jeux parmi les usages que cela peut compliquer fortement.

Une discussion publique de juin 2026 illustrait assez bien ce que cela donne côté utilisateur. Une personne utilisant un routeur domestique 4G/5G racontait avoir configuré ses ports sans jamais parvenir à les rendre accessibles depuis l’extérieur; c’est la découverte du CGNAT qui l’avait finalement conduite à chercher un VPN avec port forwarding.

C’était exactement le piège dans lequel j’étais tombé: je travaillais sur la porte de mon appartement alors que l’entrée de l’immeuble restait verrouillée.

Mais cette image m’a aussi fait comprendre quelque chose. Je n’avais peut-être pas besoin de posséder tout l’immeuble.

Une IPv4 peut être partagée et posséder malgré tout un port qui m’appartient

C’est le point qui a changé toute ma comparaison.

Pour recevoir une connexion, je n’ai pas nécessairement besoin d’être la seule personne utilisant l’adresse IPv4 publique.

J’ai besoin que, pour cette adresse, un port externe précis soit envoyé vers ma session.

Le Port Control Protocol normalisé par l’IETF décrit justement ce principe: créer une association entre une adresse et un port externes et l’hôte situé derrière le NAT afin que les connexions entrantes puissent lui parvenir. Il a notamment été conçu pour fonctionner dans des environnements comportant du CGN.

En pratique, l’idée est beaucoup plus simple que le vocabulaire. Une IPv4 partagée ressemble à un immeuble. Je n’ai pas besoin d’acheter tout l’immeuble. J’ai besoin qu’un numéro d’interphone mène réellement jusqu’à moi.

À partir de là, « IP dédiée » et « port forwarding » ont cessé d’être synonymes dans ma tête.

Mon premier essai a montré pourquoi cette distinction comptait.

Le premier VPN m’a donné une autre IPv4 partagée — et exactement zéro porte d’entrée

J’ai choisi un fournisseur établi dont la documentation répondait très clairement aux deux questions.

Ses adresses sont partagées. Port forwarding? Non.

Mullvad indique actuellement dans sa FAQ que ses utilisateurs obtiennent une IP partagée et que le service ne prend plus en charge la redirection de ports.

J’ai connecté le VPN. Mon adresse publique a changé. J’ai relancé qBittorrent. Puis j’ai vérifié le port.

Toujours fermé. Cette fois, le résultat avait du sens.

Le VPN m’avait fait sortir par une autre adresse publique. Mais personne, sur le serveur VPN, n’avait créé la règle indispensable:

trafic reçu sur ce port → envoyer à ma connexion VPN. Changer d’IPv4 n’avait donc rien résolu.

J’étais simplement passé d’une adresse partagée sans le port dont j’avais besoin à une autre adresse partagée sans ce port.

C’est à ce moment-là que j’ai cessé de demander: « Cette IP est-elle partagée? » La vraie question était devenue:

« Quand je me connecte, est-ce que le fournisseur m’attribue réellement un port entrant? »

Le deuxième VPN partageait toujours son IPv4 — mais cette fois j’avais un port

C’est ce qui m’a conduit à Proton VPN.

Sa documentation explique que de nombreux utilisateurs peuvent partager l’adresse publique d’un même serveur VPN.

Donc non: je n’avais toujours pas mon IPv4 personnelle.

Mais sur ses offres et plateformes compatibles, Proton propose explicitement le port forwarding. Le principe est précisément celui qui manquait à mon premier essai: le serveur ouvre un port, l’associe à ma session et transmet vers mon appareil le trafic qui arrive sur ce numéro.

J’ai activé un serveur P2P. Puis le port forwarding. L’application m’a affiché un numéro de port.

Je l’ai copié dans le champ Port utilisé pour les connexions entrantes de qBittorrent.

Cette fois, le test extérieur ne s’est pas terminé par un timeout. Le port répondait.

Quelques instants plus tard, je voyais également des connexions entrantes que je n’avais pas initiées moi-même.

C’était le résultat que je cherchais depuis le début. Même connexion domestique. Toujours une IPv4 partagée en amont. Une IPv4 VPN elle-même partagée entre plusieurs utilisateurs.

Mais cette fois, j’avais un numéro d’interphone qui arrivait jusqu’à mon application.

Il restait une petite contrainte: le port attribué peut changer lorsque la connexion VPN est réétablie, ce qui oblige parfois à reporter le nouveau numéro dans le client BitTorrent.

Pour quelqu’un qui veut être joignable depuis Internet, ce détail vaut néanmoins beaucoup plus qu’une belle liste de serveurs. Le port existe, il est attribué, et je peux vérifier immédiatement qu’il répond.

C’est là que mon critère a vraiment changé. Je ne cherchais plus une IPv4 qui n’appartienne qu’à moi. Je cherchais une entrée qui arrive jusqu’à moi.

Puis j’ai compris que je n’avais pas besoin de cette entrée pour tous mes usages

Pendant tout ce temps, mon téléchargement lui-même n’avait jamais exigé que chaque pair puisse initier une connexion vers mon ordinateur.

Un client BitTorrent peut aussi lancer des connexions sortantes. Sur un essaim bien fourni, cela peut suffire pour télécharger normalement. Le port entrant devient surtout intéressant lorsqu’on veut être plus facilement joignable par les autres pairs, améliorer certaines situations P2P ou maintenir du partage sur des essaims moins favorables.

J’avais donc mélangé deux objectifs: transférer le fichier, et être joignable depuis Internet.

C’est à ce moment-là que j’ai rouvert OnlydogVPN, que j’utilisais déjà comme option plus simple dans d’autres situations.

Je savais désormais exactement ce que je voulais vérifier. Pas lui demander artificiellement de remplacer un service de port forwarding.

Simplement voir ce qui se passait lorsque mon besoin réel était de garder un transfert actif derrière une connexion VPN partagée.

Sur l’essaim bien alimenté que j’avais devant moi, le téléchargement a continué normalement.

Puis j’ai quitté le Wi-Fi pour passer quelques instants sur le partage 5G.

C’est normalement le genre de changement qui m’agace davantage qu’un numéro de port: la route réseau disparaît, la connexion doit se reconstruire, et je me retrouve à vérifier si le transfert a réellement repris.

Ici, la connexion a retrouvé sa route et le téléchargement a continué sans que j’aie à toucher à qBittorrent.

C’était là que la conception du petit service devenait beaucoup plus pertinente pour moi: son transport basé sur HTTP/3 et sa capacité à récupérer lors des changements de réseau répondaient à la friction que j’avais réellement devant les yeux.

Pas de port à recopier. Pas de serveur à réexaminer. Je changeais de réseau, puis je revenais au fichier.

Évidemment, si mon objectif avait été d’héberger un service accessible depuis l’extérieur ou d’exiger des connexions P2P entrantes, j’aurais gardé Proton pour cette tâche. Un port entrant est alors une fonction précise, et on ne la remplace pas par une connexion simplement plus fluide.

Mais pour mon utilisation quotidienne — télécharger, naviguer, changer entre Wi-Fi et données mobiles sans transformer le VPN en petit projet réseau — je préférais nettement le second comportement.

Le port forwarding avait cessé d’être une case que je voulais absolument cocher sur tous mes VPN.

Il était devenu ce qu’il aurait dû être dès le début: un outil nécessaire uniquement lorsque j’ai réellement besoin que quelqu’un, dehors, puisse frapper à ma porte.


Je ne chercherais donc plus une IPv4 dédiée en premier

C’est ce que je retiens surtout de ce test. Une IPv4 partagée n’empêche pas automatiquement le port forwarding.

Proton le montre très concrètement: plusieurs utilisateurs peuvent sortir par la même IPv4 publique tandis qu’un port différent est attribué à une session et transmis à travers le tunnel.

À l’inverse, changer simplement d’IPv4 ne suffit pas. Mullvad utilise des IP partagées mais ne propose pas de port forwarding. Et si mon besoin est seulement de maintenir un transfert sortant avec le moins de manipulations possible, le petit service que j’ai essayé ensuite correspond mieux à la manière dont j’utilise réellement un VPN.

Avant même de payer pour une autre solution, je vérifierais aussi ce que mon fournisseur d’accès permet déjà. Chez Free, par exemple, une IPv4 full-stack peut redonner directement accès à l’ensemble des ports sans ajouter un VPN à l’équation.

J’étais parti à la recherche d’une adresse IPv4 qui serait entièrement à moi. Pour ce problème précis, j’avais demandé beaucoup trop. Ce qu’il me fallait pour recevoir des connexions n’était pas une IP à moi.

C’était un port qui sache me trouver.

Questions fréquentes

Une IPv4 partagée empêche-t-elle toujours le port forwarding ?

Non. Plusieurs utilisateurs peuvent partager la même IPv4 publique tout en recevant chacun un port externe distinct, à condition que le fournisseur crée le mapping vers la bonne session.

Faut-il une adresse IP dédiée pour recevoir des connexions entrantes ?

Pas nécessairement. Le besoin essentiel est qu’un port externe soit attribué et transmis jusqu’à l’appareil. Une IP dédiée est une autre caractéristique et ne doit pas être confondue avec le port forwarding.

Pourquoi la redirection de port de ma box peut-elle échouer derrière un CGNAT ?

Parce qu’un NAT supplémentaire du fournisseur se trouve en amont de la box. La règle locale ouvre une porte chez vous, mais elle ne contrôle pas la traduction opérée plus haut dans le réseau du FAI.

Quand le port forwarding n’est-il pas indispensable pour BitTorrent ?

Un client peut initier des connexions sortantes et télécharger sur un essaim bien fourni sans être directement joignable. Le port entrant devient surtout utile pour améliorer la joignabilité, certaines situations P2P ou tout usage où des connexions doivent réellement arriver depuis Internet.