Ouvrir un port sur sa box : la redirection de port pas à pas

Par La rédaction de Mon-Adresse-IP.net·Publié le 21 août 2026·

Héberger un serveur de jeu, joindre son NAS en déplacement, consulter une caméra à distance : certains usages exigent qu'une connexion venue d'Internet atteigne un appareil précis de votre réseau. Voici la procédure complète, les vérifications préalables que la plupart des tutoriels passent sous silence, et les précautions qui évitent de transformer une commodité en porte d'entrée.

Pourquoi une redirection est nécessaire

Chez un abonné français type, une dizaine d'appareils partagent une seule adresse IP publique. Ce partage repose sur la traduction d'adresses, le NAT, détaillé dans notre guide le NAT expliqué. Quand votre ordinateur ouvre une connexion vers un site, la box remplace l'adresse privée de la machine par l'adresse publique du foyer et note la correspondance dans une table temporaire. La réponse revient sur cette adresse publique, la box consulte sa table, et le paquet retrouve son destinataire.

Une connexion entrante que personne n'a sollicitée ne correspond à aucune entrée de cette table. La box ne dispose d'aucun élément pour deviner à quel appareil elle est destinée : elle la jette. Ce n'est pas un défaut, c'est le comportement normal, et c'est accessoirement la protection la plus efficace dont bénéficie un réseau domestique.

La redirection de port consiste à créer manuellement une entrée permanente dans cette table : « tout ce qui arrive sur le port 25565 en TCP, transmets-le à 192.168.1.42, port 25565 ». Le mécanisme s'appelle aussi PAT (traduction de port) ou port forwarding. Selon l'interface, vous chercherez « redirection de ports », « NAT/PAT », « serveur virtuel » ou virtual server : c'est la même chose. Si les notions de port et de protocole vous sont floues, notre table des ports TCP et UDP pose les bases nécessaires.

Avant de commencer : la checklist en 4 points

La plupart des redirections qui « ne marchent pas » échouent pour une raison extérieure à la box. Ces quatre vérifications prennent dix minutes et évitent une heure de tâtonnement.

1. L'appareil cible a-t-il une adresse locale stable ?

Votre box distribue les adresses privées automatiquement par DHCP, avec une durée de bail limitée. Après un redémarrage, une absence prolongée ou l'arrivée d'un nouvel appareil, la machine visée peut très bien récupérer une autre adresse. Votre règle pointe alors vers le vide, ou pire, vers un autre appareil du foyer. Le mécanisme est décrit dans notre guide le DHCP expliqué.

La bonne pratique consiste à créer une réservation DHCP dans la box plutôt qu'à figer l'adresse sur l'appareil : la box reste seule maîtresse du plan d'adressage et aucun conflit n'est possible. Il vous faut l'adresse physique de la carte réseau, c'est-à-dire son adresse MAC :

ipconfig /all              # Windows : « Adresse physique » et « Adresse IPv4 »
ip -4 addr show            # Linux : adresse IPv4 de l'interface
ip link show               # Linux : adresse MAC (link/ether)
ifconfig                   # macOS : lignes inet et ether

Dans la box, cherchez « Baux DHCP », « Réservation d'adresse » ou « Bail statique », puis associez l'adresse choisie à cette adresse MAC. Un piège classique : les ordinateurs portables et les smartphones récents utilisent par défaut une adresse MAC aléatoire par réseau Wi-Fi. Si vous ne désactivez pas cette option pour votre réseau domestique, la réservation cessera de fonctionner du jour au lendemain. Pour un service permanent, le câble Ethernet reste de toute façon préférable.

2. Êtes-vous derrière un CGNAT ?

Certains accès, notamment les box 4G/5G et une partie des offres fibre, ajoutent un second NAT chez l'opérateur : plusieurs abonnés partagent alors la même adresse IPv4 publique. Dans ce cas, les redirections configurées dans votre box sont le plus souvent sans effet, le trafic entrant étant arrêté chez l'opérateur. Certains accès en IPv4 partagée font toutefois exception : l'opérateur délègue à chaque abonné une plage de ports externes, indiquée dans l'interface de la box, à l'intérieur de laquelle les redirections fonctionnent normalement, hors de cette plage, aucune règle n'aboutira.

Le test est immédiat. Relevez l'adresse publique vue depuis Internet avec notre outil de recherche d'adresse IP, puis comparez-la à l'adresse WAN affichée dans l'interface de la box. Si elles diffèrent, ou si la box affiche une adresse comprise entre 100.64.0.0 et 100.127.255.255 (la plage réservée au NAT d'opérateur, recensée dans notre page adresses IP réservées), vous êtes concerné. Notre guide le CGNAT expliqué détaille les recours : demander une adresse IPv4 dédiée à son opérateur quand l'option existe, basculer sur IPv6, ou renoncer à l'ouverture au profit d'un tunnel.

3. Le service écoute-t-il vraiment sur ce port ?

Rediriger vers un service arrêté produit exactement le même symptôme qu'une règle mal écrite. Vérifiez d'abord sur la machine elle-même :

Get-NetTCPConnection -LocalPort 25565 -State Listen   # Windows, PowerShell
netstat -ano | findstr ":25565"                       # Windows, équivalent historique
ss -ltnp | grep ':25565'                              # Linux, ports TCP en écoute
ss -lunp | grep ':25565'                              # Linux, ports UDP
lsof -nP -iTCP:25565 -sTCP:LISTEN                     # macOS

Lisez attentivement la colonne d'adresse locale. 0.0.0.0:25565, *:25565 ou [::]:25565 signifient que le service accepte les connexions sur toutes les interfaces : c'est ce qu'il faut. 127.0.0.1:25565 signifie qu'il n'écoute que sur la boucle locale, donc uniquement les connexions issues de la machine elle-même. Aucune redirection au monde ne fera aboutir un paquet vers un service dans cet état : il faut modifier sa configuration, au moyen du paramètre souvent nommé bind address, listen address ou host.

4. Le pare-feu de l'appareil laisse-t-il passer ?

Windows bloque par défaut les connexions entrantes non autorisées, et classe tout réseau inconnu comme public, le profil le plus restrictif. Sous Linux, ufw ou firewalld font de même dès qu'ils sont activés.

New-NetFirewallRule -DisplayName "Service 25565" -Direction Inbound -Protocol TCP -LocalPort 25565 -Action Allow -Profile Private
# Ubuntu / Debian
sudo ufw allow 25565/tcp
# Fedora / RHEL
sudo firewall-cmd --permanent --add-port=25565/tcp
sudo firewall-cmd --reload

Validez ensuite depuis un autre appareil du réseau local, avant même de toucher à la box :

Test-NetConnection 192.168.1.42 -Port 25565    # Windows
nc -vz 192.168.1.42 25565                      # Linux / macOS

Si ce test échoue, le problème est sur la machine, pas dans la box. Inutile d'aller plus loin tant qu'il ne passe pas.

La procédure, étape par étape

Les interfaces diffèrent, la logique est partout la même. Comptez cinq minutes une fois la checklist validée.

1. Réunir les quatre informations Adresse locale de l'appareil cible, numéro de port attendu par le service, protocole exact (TCP, UDP ou les deux), et nom que vous donnerez à la règle. Notez-les avant d'ouvrir l'interface : on se trompe surtout en improvisant.
2. Se connecter à l'interface d'administration L'adresse est celle de votre passerelle par défaut. Obtenez-la avec ipconfig sous Windows (ligne « Passerelle par défaut ») ou ip route | grep default sous Linux. Le mot de passe demandé est celui de l'administration de la box, distinct de la clé Wi-Fi ; s'il est resté celui d'origine, changez-le avant d'ouvrir quoi que ce soit.
3. Trouver la bonne section Elle se cache presque toujours derrière un menu « Réseau », « Paramètres avancés » ou « Services de la box ». Le vocabulaire à repérer : redirection de ports, NAT/PAT, serveur virtuel, port forwarding, gestion des ports.
4. Créer la règle Renseignez le port externe (celui vu depuis Internet), le port interne (celui du service), le protocole et l'adresse IP de destination. Certaines interfaces acceptent une plage de ports : ne l'utilisez que si le service l'exige réellement. Si un champ « IP source » ou « adresse autorisée » est proposé, exploitez-le pour restreindre l'accès à une adresse connue : c'est la meilleure protection disponible à ce niveau.
5. Activer et enregistrer Deux oublis fréquents : la case « Activé » laissée décochée, et le bouton « Appliquer » situé en bas de page qui seul valide la saisie. Certaines box exigent en outre un redémarrage pour prendre la règle en compte.
6. Documenter la règle Consignez quelque part la date, le port, l'appareil concerné, la raison de l'ouverture et une date de révision. Dans deux ans, cette ligne vous évitera de laisser tourner une porte ouverte dont plus personne ne se souvient.
7. Tester depuis l'extérieur Et uniquement depuis l'extérieur, pour la raison expliquée dans la section suivante.

Où trouver le réglage selon la box

Les interfaces des opérateurs français évoluent à chaque mise à jour du micrologiciel, et un même opérateur propose plusieurs générations de matériel en parallèle. Plutôt que des chemins de menus figés, qui seraient périmés en quelques mois, voici l'adresse d'administration usuelle et le vocabulaire à chercher.

Tester réellement l'ouverture

C'est l'étape la plus souvent bâclée, et celle qui produit le plus de conclusions fausses.

Un test depuis le réseau local ne prouve rien

Saisir votre adresse publique dans un navigateur depuis votre salon demande à la box une manœuvre particulière : le paquet sort du réseau local, revient aussitôt vers l'adresse publique de la box, et doit être traduit deux fois pour repartir vers un appareil interne. Cette fonction porte le nom de NAT hairpin ou NAT loopback. De nombreuses box grand public ne l'implémentent pas, ou seulement partiellement.

Conséquence : un test interne qui échoue ne signifie strictement rien, et l'on peut passer des heures à corriger une règle qui était correcte dès le départ. Inversement, si l'accès fonctionne depuis chez vous, cela ne garantit pas qu'il fonctionne depuis l'extérieur.

La méthode fiable : le partage de connexion mobile

Prenez un smartphone, coupez son Wi-Fi pour qu'il utilise le réseau mobile, et activez le partage de connexion. Reliez-y un ordinateur, puis testez :

Test-NetConnection 203.0.113.10 -Port 25565     # Windows
nc -vz 203.0.113.10 25565                       # Linux / macOS, TCP
curl -sv http://203.0.113.10:8080/              # service web

Remplacez l'adresse d'exemple par votre adresse publique réelle, que la page d'accueil affiche en une seconde. Les testeurs de ports en ligne rendent également service, avec deux réserves : ils ne sondent en général que le TCP, et ils testent l'adresse depuis laquelle vous les consultez, vérifiez donc qu'ils affichent bien la vôtre.

Pourquoi l'UDP se teste autrement

Le TCP commence par une poignée de main : on sait immédiatement si le port répond. L'UDP n'a pas ce mécanisme ; un paquet envoyé sans réponse peut signifier « fermé », « filtré », ou simplement « le service a bien reçu et n'avait rien à répondre ». Un service UDP ne se valide donc pas au niveau réseau mais au niveau applicatif : en lançant le client du jeu ou de l'application depuis l'extérieur et en regardant s'il se connecte.

« Fermé » et « filtré » ne veulent pas dire la même chose

Cette distinction est le meilleur outil de diagnostic dont vous disposez, et elle est presque toujours passée sous silence.

• Port fermé : votre machine ou la box a renvoyé un refus explicite (un paquet TCP RST). Quelque chose a répondu : le chemin réseau est bon et la redirection fonctionne probablement, mais rien n'écoute à l'arrivée. Cherchez du côté du service arrêté ou lié à 127.0.0.1.
• Port filtré : aucune réponse, le test expire. Le paquet a été absorbé en silence : par la box faute de règle applicable, par le pare-feu de la machine cible, ou par un filtrage opérateur en amont. C'est le symptôme d'un blocage, pas d'un service absent.
• Port ouvert : la connexion s'établit. Vérifiez tout de même que c'est bien votre service qui répond, et non l'interface d'administration de la box, qui occupe déjà certains ports.

Si le résultat reste incohérent, un traceroute vers votre adresse publique aide à situer l'endroit où le trafic disparaît.

Les huit erreurs qui reviennent le plus

• L'adresse locale a changé : la règle pointe vers une adresse que la box a réattribuée à un autre appareil. Symptôme typique : cela fonctionnait, puis plus du tout après une coupure de courant. Remède : la réservation DHCP décrite plus haut.
• Le service n'est pas démarré : ou il ne redémarre pas automatiquement après un redémarrage de la machine. Sous Linux, pensez à systemctl enable en plus de systemctl start ; sous Windows, réglez le service sur « Automatique ».
• Le pare-feu local bloque : cas particulièrement sournois sous Windows, où une règle créée pour le profil « Privé » est ignorée si le réseau domestique a été classé « Public » lors de la première connexion.
• Vous êtes en double NAT : un routeur personnel branché derrière la box de l'opérateur crée deux traductions successives. Le signe qui ne trompe pas : l'adresse WAN de votre routeur est privée, du type 192.168.x.x. Deux solutions : créer la même redirection sur les deux équipements, ou passer la box de l'opérateur en mode bridge pour rendre au routeur le rôle de passerelle unique. Notre guide IP publique et IP privée aide à distinguer les deux niveaux.
• L'opérateur filtre le port : le cas emblématique est le port 25, dédié au courrier sortant, très largement bloqué sur les accès résidentiels pour limiter l'envoi de courriers indésirables depuis des machines infectées. Les ports historiques du partage de fichiers Windows (135 à 139 et 445) sont eux aussi couramment filtrés. Sur ces ports, aucune configuration de box n'y changera rien ; pour le courrier, notre guide adresse IP et courriers électroniques explique pourquoi héberger soi-même un serveur de messagerie sur une ligne grand public est un chemin sans issue.
• Confusion entre TCP et UDP : beaucoup de services de jeu et de voix utilisent l'UDP, parfois les deux protocoles sur des ports différents. Une règle créée en TCP pour un service UDP donne l'impression d'un blocage total. Consultez la documentation du service plutôt que de cocher systématiquement « les deux » : ouvrir un protocole inutile agrandit la surface exposée. Les usages de jeu en ligne sont traités dans notre guide adresse IP et jeux vidéo.
• L'application n'écoute que sur la boucle locale : beaucoup de logiciels se lient par défaut à 127.0.0.1 par prudence. Il faut explicitement leur demander d'écouter sur 0.0.0.0, c'est-à-dire toutes les interfaces IPv4, ou mieux sur la seule adresse locale de la machine.
• Le port externe est déjà pris par la box : l'interface d'administration à distance, un serveur de fichiers intégré ou le service de télévision occupent certains ports. La règle est alors refusée, ou acceptée puis silencieusement ignorée. Changez de port externe.

Sécurité : ce que vous exposez vraiment

Une redirection perce un trou dans le seul mur qui protégeait votre réseau par défaut. Il faut le dire sans détour : le service concerné devient joignable par n'importe qui sur la planète. Des robots parcourent en permanence l'espace d'adressage IPv4 et sondent les ports usuels ; votre service sera découvert et testé automatiquement, sans que personne ne vous vise personnellement. La question n'est donc pas de savoir si des tentatives de connexion arriveront, mais ce qu'elles trouveront.

Les règles à ne pas transgresser

• N'ouvrez que le strict nécessaire, et seulement le temps nécessaire. Une ouverture pour un week-end de jeu se referme le lundi. Une règle qui ne sert plus est une règle à supprimer.
• N'exposez jamais un accès d'administration. Le bureau à distance Windows (3389), VNC (5900), le partage de fichiers Windows (445) et l'administration à distance de la box elle-même n'ont rien à faire sur Internet. Ces protocoles concentrent une large part des intrusions constatées sur les réseaux domestiques comme professionnels.
• N'exposez jamais une base de données. MySQL (3306), PostgreSQL (5432), MongoDB (27017), Redis (6379) ou Elasticsearch (9200) ne sont pas conçus pour être joignables publiquement ; plusieurs d'entre eux ont d'ailleurs été livrés pendant des années sans authentification par défaut.
• SSH mérite un traitement particulier. Si vous devez l'exposer, désactivez l'authentification par mot de passe au profit des clés, interdisez la connexion directe du compte root, et installez un outil de bannissement automatique après échecs répétés. Déplacer le service sur un autre port réduit le bruit dans les journaux, rien de plus.
• Préférez un VPN d'accès distant à une ouverture directe. C'est probablement le conseil le plus utile de cette page. Plutôt que d'exposer trois services, vous n'exposez qu'une seule porte, chiffrée et authentifiée, puis vous accédez à tout votre réseau comme si vous y étiez. Certaines box, la Freebox notamment, intègrent un serveur VPN, et un mini-ordinateur suffit à en héberger un ; notre guide sur les VPN revient sur la différence entre ce type d'accès distant et les services commerciaux de navigation anonyme.
• Changez les identifiants d'usine et durcissez le service. Mot de passe long et unique, comptes de démonstration supprimés, double authentification lorsqu'elle est proposée, chiffrement TLS pour tout ce qui transporte des identifiants.
• Maintenez le service à jour. Un logiciel exposé et non mis à jour finit toujours par devenir vulnérable : c'est une question de temps, pas de chance.
• Surveillez. Consultez le journal de connexions de la box, journalctl sous Linux ou l'observateur d'événements sous Windows. Une salve de tentatives d'authentification échouées est une information exploitable, pas une fatalité.
• Isolez ce qui est exposé. Une caméra ou un enregistreur vidéo placé sur un réseau séparé ne pourra pas servir de tremplin vers vos ordinateurs personnels. Notre guide sécuriser ses objets connectés détaille cette séparation.
• Un port non standard n'est pas une sécurité. Placer un service sur le port 34567 le rend moins visible des balayages les plus grossiers, mais un scanner identifie un service à la bannière qu'il renvoie, quel que soit le numéro de port. Considérez cette mesure comme un filtre à bruit, jamais comme une protection.

Pour aller plus loin sur le durcissement de votre équipement, la page sécuriser sa box Internet reprend l'ensemble des réglages à contrôler, redirections comprises.

UPnP : les ports qui s'ouvrent tout seuls

Vous avez peut-être constaté qu'une console de jeu, un logiciel de visioconférence ou un client de partage de fichiers fonctionne parfaitement sans que vous ayez rien configuré. C'est le protocole UPnP IGD qui opère, avec ses cousins NAT-PMP et PCP : l'application demande elle-même à la box de lui créer une redirection, et la box obtempère.

Le confort est réel, le compromis aussi. Ces protocoles ne comportent aucune authentification : la box considère que toute demande venant du réseau local est légitime. Concrètement, un logiciel malveillant installé sur un ordinateur du foyer, ou un objet connecté compromis, peut s'ouvrir un accès entrant sans vous en informer. Certaines implémentations défectueuses ont même exposé le service UPnP côté Internet, ce qui permettait à un tiers d'y créer des règles à distance.

La conduite raisonnable tient en trois gestes :

1. Inspectez la liste UPnP La plupart des box l'affichent dans un onglet distinct des redirections manuelles. Vous y découvrirez souvent des règles créées par des logiciels désinstallés depuis longtemps.
2. Purgez ce qui n'est plus justifié Une entrée dont vous ne pouvez pas nommer l'application est une entrée à supprimer.
3. Désactivez UPnP si rien ne le réclame Puis créez à la main les deux ou trois règles réellement nécessaires. Si vous jouez en ligne, sachez que la désactivation peut faire passer votre connexion en NAT « strict » ou « modéré » et dégrader le fonctionnement des parties ; c'est l'arbitrage détaillé dans notre guide adresse IP et jeux vidéo.

Ne rien ouvrir du tout : tunnel inverse et VPN maillé

Depuis quelques années, une approche différente s'est généralisée, et elle rend la redirection de port inutile dans la majorité des usages domestiques. Le principe consiste à inverser le sens de la connexion. Puisque le NAT laisse toujours sortir et mémorise la correspondance le temps de la session, il suffit que la machine à joindre établisse elle-même une connexion sortante permanente vers un point de rendez-vous situé sur Internet. Le trafic entrant emprunte ensuite ce tunnel déjà ouvert, en sens inverse.

Deux familles coexistent. Le tunnel inverse associe un nom de domaine public à un relais qui redescend les requêtes vers votre service : pratique pour publier un site ou une interface web, mais le relais voit passer le trafic dès lors qu'il assure lui-même le déchiffrement TLS. Le VPN maillé, ou réseau superposé, construit de son côté un réseau privé chiffré entre vos seuls appareils : chacun s'annonce auprès d'un serveur de coordination, puis les pairs tentent une connexion directe par perçage de NAT, avec repli sur un relais chiffré quand la traduction d'adresses est trop restrictive. Vous joignez alors vos machines par une adresse privée propre à ce réseau superposé, jamais publiée sur Internet.

Pour un accès personnel à un NAS, à une caméra ou à une machine de développement, cette voie est presque toujours préférable à une ouverture de port. La redirection garde son intérêt lorsque le service doit être joignable par des personnes qui n'installeront rien : un serveur de jeu partagé avec des amis, par exemple.

En IPv6, on n'ouvre plus, on autorise

IPv6 change complètement la donne, et c'est probablement le point le moins bien expliqué du sujet. Faute d'adresses en nombre suffisant, l'IPv4 imposait le partage et donc le NAT ; en IPv6, chaque appareil de votre réseau reçoit sa propre adresse globale routable, comme le rappelle notre comparatif IPv4 et IPv6. Il n'y a donc plus rien à traduire ni à rediriger : le paquet connaît déjà sa destination exacte.

Ce qui arrête le trafic entrant n'est plus l'absence de correspondance NAT, mais le pare-feu de la box, qui refuse par défaut les connexions non sollicitées. La configuration consiste donc à créer une autorisation, et non une redirection. Cherchez « Pare-feu IPv6 », « Filtrage IPv6 » ou « Autorisations IPv6 », puis indiquez le protocole, le port et l'adresse IPv6 de destination. Notre guide activer IPv6 chez soi décrit la mise en route chez les opérateurs français.

Deux pièges sont propres à IPv6 :

• Les adresses temporaires : pour limiter le pistage, les systèmes récents génèrent des adresses IPv6 qui changent régulièrement. Une règle de pare-feu visant l'adresse du jour cessera de fonctionner. Sur la machine qui héberge le service, il faut viser une adresse stable : adresse configurée manuellement, ou désactivation des adresses temporaires sur ce poste précis (net.ipv6.conf.eth0.use_tempaddr=0 sous Linux). Ne le faites que sur un serveur : sur un poste de travail, ces adresses protègent votre vie privée.
• Le préfixe peut changer : l'opérateur vous délègue un préfixe dont la stabilité dans le temps n'est pas toujours garantie. Certaines interfaces ne demandent que les 64 derniers bits de l'adresse, ce qui rend la règle insensible à ce changement ; sinon, il faudra la reprendre, et associer un nom de domaine mis à jour dynamiquement comme décrit dans notre guide obtenir une IP fixe.

Enfin, pour tester une autorisation IPv6, il faut un client disposant lui aussi d'IPv6 : la plupart des testeurs de ports en ligne ne sondent que l'IPv4, et un partage de connexion mobile ne convient que si l'opérateur mobile fournit de l'IPv6. Côté sécurité, l'exigence est identique, voire supérieure : l'appareil est joint directement, sans aucune traduction d'adresse pour brouiller les pistes. Le seul confort supplémentaire est qu'il n'existe plus de conflit de ports entre appareils : chacun ayant sa propre adresse, plusieurs machines peuvent exposer le même numéro de port.

Questions fréquentes