Le NAT expliqué : comment votre box partage une seule adresse IP

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

Votre box possède une seule adresse IP publique, et pourtant votre téléphone, votre téléviseur, votre console et vos ampoules connectées accèdent tous à Internet en même temps. Le mécanisme qui rend cela possible s'appelle le NAT. Il explique aussi la plupart des problèmes réseau que vous rencontrez à la maison.

Le problème que le NAT résout

Un foyer français équipé compte facilement entre dix et quarante appareils raccordés au réseau : ordinateurs, smartphones, tablettes, téléviseur, box TV, console, imprimante, enceintes, thermostat, caméras, aspirateur robot, montres. Chacun a besoin d'une adresse IP pour communiquer. Votre abonnement, lui, ne vous donne qu'une seule adresse IPv4 publique, et parfois même moins, comme nous le verrons avec le CGNAT.

Cette rareté n'a rien d'un choix commercial. Le protocole IPv4 code les adresses sur 32 bits, soit environ 4,3 milliards de combinaisons, dont une partie substantielle est réservée à des usages particuliers et ne circulera jamais sur Internet. L'IANA a distribué ses cinq derniers blocs aux registres régionaux le 3 février 2011, et le RIPE NCC, qui gère l'Europe, a annoncé son épuisement définitif le 25 novembre 2019. Depuis, obtenir une adresse IPv4 supplémentaire relève du marché de l'occasion entre opérateurs.

La réponse tient en deux idées complémentaires. D'abord, on a réservé des plages d'adresses utilisables librement à l'intérieur de n'importe quel réseau privé, sans coordination mondiale : 10.0.0.0/8, 172.16.0.0/12 et 192.168.0.0/16, définies par la RFC 1918. Ce sont ces adresses que votre box distribue par DHCP à vos appareils, et que nous détaillons dans notre inventaire des plages d'adresses réservées. Ensuite, un dispositif placé à la frontière du réseau traduit ces adresses privées en adresse publique au moment de sortir : c'est le NAT, pour Network Address Translation, formalisé dès 1994 par la RFC 1631 puis précisé par la RFC 3022.

Le résultat est une asymétrie fondamentale, qu'il faut avoir en tête pour comprendre tout le reste : depuis l'intérieur, sortir est trivial ; depuis l'extérieur, entrer est impossible par défaut. La distinction entre ces deux mondes d'adresses fait l'objet de notre guide sur l'adresse IP publique et privée.

Ce qui se passe vraiment : la table de traduction

Le NAT n'est pas une opération magique : c'est une table tenue en mémoire par votre box, et une réécriture d'en-têtes. Suivons une requête complète, avec des valeurs concrètes.

Supposons que votre ordinateur portable ait reçu l'adresse privée 192.168.1.42 et que l'adresse publique de votre box soit 203.0.113.47. Vous ouvrez un site web hébergé à l'adresse 198.51.100.10, en HTTPS, donc sur le port 443. Votre système d'exploitation choisit pour cette connexion un port source dit éphémère : Windows et macOS puisent dans la plage 49152-65535 recommandée par l'IANA, Linux dans 32768-60999 par défaut. Disons 51344. Si la notion de port vous est encore floue, notre référence sur les ports TCP et UDP la reprend depuis le début.

Paquet à la sortie du portable	Source 192.168.1.42:51344 → destination 198.51.100.10:443
Ligne créée dans la table NAT	TCP · 192.168.1.42:51344 ⇄ 203.0.113.47:60012 · pair 198.51.100.10:443
Le même paquet à la sortie de la box	Source 203.0.113.47:60012 → destination 198.51.100.10:443
Réponse envoyée par le serveur	Source 198.51.100.10:443 → destination 203.0.113.47:60012
Réponse remise au portable	Source 198.51.100.10:443 → destination 192.168.1.42:51344

Trois observations méritent d'être soulignées. La box a choisi un port externe (60012) qui n'a aucune raison d'être identique au port interne ; elle aurait pu conserver 51344 s'il était libre, et la plupart des implémentations essaient de le faire, mais rien ne l'y oblige. Ensuite, chaque réécriture d'adresse ou de port invalide les sommes de contrôle des en-têtes IP et TCP : la box doit les recalculer, ce qui explique pourquoi le NAT est une fonction de traitement de paquet et non un simple aiguillage. Enfin, le serveur distant ne voit jamais 192.168.1.42. Pour lui, la connexion vient de 203.0.113.47, exactement comme celles de votre téléviseur et de votre téléphone.

Cette ligne de table a une durée de vie. Les recommandations de l'IETF fixent des planchers : pour une connexion TCP établie et inactive, la RFC 5382 exige un délai d'expiration d'au moins 2 heures et 4 minutes ; pour l'UDP, la RFC 4787 impose de ne jamais expirer une correspondance en moins de deux minutes et recommande cinq minutes par défaut. En pratique, de nombreux équipements sont plus agressifs, en particulier sur l'UDP, ce qui a des conséquences très concrètes sur la téléphonie et les jeux en ligne.

NAT, PAT, NAPT : ce que fait réellement votre box

Le vocabulaire est flottant, et cette confusion entretient beaucoup de malentendus. Il faut distinguer deux mécanismes.

Le NAT de base, tel que décrit à l'origine, associe une adresse privée à une adresse publique, une pour une. Il suppose donc de disposer d'autant d'adresses publiques que d'appareils devant communiquer simultanément. C'est utile pour renuméroter un réseau d'entreprise ou pour interconnecter deux sites, mais cela ne résout en rien la pénurie d'adresses : c'est un échange, pas un partage.

Le NAPT (Network Address and Port Translation), également appelé PAT (Port Address Translation) dans le vocabulaire de certains constructeurs, ou encore « surcharge d'adresse » (NAT overload), traduit le couple adresse + port. C'est ce que fait la totalité des box grand public. En jouant sur les 65 535 valeurs de port disponibles, une seule adresse publique peut porter plusieurs dizaines de milliers de connexions simultanées : le port devient l'identifiant qui permet de savoir à quel appareil interne appartient une réponse.

Quand vous lisez « mon routeur fait du NAT », comprenez donc presque toujours « il fait du NAPT ». Cette précision n'est pas académique : c'est parce que la traduction porte sur le port que vous ne pouvez pas héberger deux serveurs web sur le port 443 derrière la même adresse publique, et c'est aussi pour cette raison que les redirections de port se configurent port par port, comme l'explique notre guide pour ouvrir un port sur sa box.

Les types de NAT et pourquoi les applications s'en soucient

Deux appareils situés chacun derrière son propre NAT ne peuvent pas s'appeler directement : aucun des deux n'est joignable de l'extérieur. Or c'est exactement la situation d'un appel visio ou d'une partie en ligne entre deux joueurs. Les applications ont donc appris à sonder le comportement du NAT qu'elles traversent, et une classification en quatre familles s'est imposée, issue de l'ancienne spécification STUN (RFC 3489).

• Cône complet (full cone) : une fois la correspondance créée par un envoi sortant, n'importe quelle machine extérieure peut écrire au port public associé et le paquet est remis à l'appareil interne. Très permissif, devenu rare.
• Cône restreint par adresse : seule une machine à laquelle vous avez déjà envoyé quelque chose peut vous répondre, quel que soit son port source.
• Cône restreint par port : le filtrage porte sur le couple adresse + port du correspondant. C'est le comportement le plus courant sur les box récentes.
• NAT symétrique : la box attribue un port externe différent pour chaque destination contactée. Le même appareil interne, sur le même port source, apparaîtra sous deux ports publics distincts selon qu'il parle au serveur A ou au serveur B.

Cette taxonomie a été officiellement abandonnée par la RFC 5389 puis la RFC 8489, car elle mélange deux propriétés indépendantes que la RFC 4787 sépare proprement : le comportement de correspondance (le port externe dépend-il de la destination ?) et le comportement de filtrage (qui a le droit de m'écrire sur ce port ?). Un équipement peut parfaitement combiner une correspondance indépendante de la destination, ce que la RFC 4787 exige explicitement, avec un filtrage strict par adresse et port. Beaucoup d'articles francophones présentent encore les quatre types comme la référence actuelle ; ils décrivent en réalité un modèle vieux de plus de vingt ans, commode mais imprécis.

Concrètement, ce qui compte pour vos usages est le NAT symétrique. Tant que le port externe est stable, un appareil peut le découvrir puis le communiquer à son correspondant : c'est le rôle d'un serveur STUN, une machine publique à qui l'on demande simplement « sous quelle adresse et quel port me vois-tu ? ». Les deux pairs échangent ces coordonnées par leur canal de signalisation, s'envoient simultanément des paquets, et chacun ouvre ainsi la correspondance qui laissera entrer l'autre. C'est la technique dite de perçage de NAT, orchestrée par le protocole ICE (RFC 8445).

Avec un NAT symétrique, ce raisonnement s'effondre : le port découvert auprès du serveur STUN n'est pas celui qui sera utilisé pour parler au correspondant. Il faut alors basculer sur TURN (RFC 8656), un serveur relais qui reçoit le flux de l'un et le retransmet à l'autre. La connexion fonctionne, mais tout le trafic média transite par un tiers, ce qui augmente la latence et coûte de la bande passante à l'éditeur du service. Si vos appels visio sont médiocres alors que votre débit est excellent, un double NAT ou un NAT symétrique est un suspect sérieux.

Ce mécanisme est directement visible dans votre navigateur : WebRTC, la technologie utilisée par la quasi-totalité des services de visioconférence dans le navigateur, interroge des serveurs STUN pour collecter ses candidats de connexion. C'est aussi pour cette raison qu'une page web peut, dans certaines conditions, apprendre vos adresses IP locales : un effet secondaire que vous pouvez mesurer avec notre test de fuite WebRTC.

Ce que le NAT casse

Le NAT viole un principe fondateur d'Internet : l'idée que toute machine peut en joindre une autre directement. Cette entorse a un coût, payé quotidiennement par plusieurs familles d'usages.

Les connexions entrantes. Aucun serveur hébergé chez vous n'est joignable tant que vous n'avez pas créé manuellement une redirection de port, c'est-à-dire une ligne permanente dans la table de traduction. C'est la condition pour exposer une caméra, un serveur de fichiers ou un site personnel ; la procédure complète figure dans notre guide sur l'ouverture d'un port, avec les précautions de sécurité qui l'accompagnent.

Les protocoles qui transportent des adresses dans leurs données. Le cas d'école est le FTP en mode actif : le client annonce au serveur, en clair dans la commande PORT, l'adresse et le port sur lesquels il attend la connexion de données. Comme cette adresse est privée, le serveur tente de joindre 192.168.x.x et échoue. Les box embarquent des modules d'inspection applicative (ALG) qui réécrivent ces valeurs à la volée, mais ces modules sont inopérants dès que le protocole est chiffré. Le mode passif, où le client initie les deux connexions, existe précisément pour contourner ce problème.

La téléphonie sur IP. Un téléphone SIP annonce ses coordonnées dans les en-têtes Contact et dans la description de session : mêmes symptômes. Plus subtil, la sonnerie repose sur la capacité du serveur à joindre le téléphone à tout moment, donc sur une correspondance NAT maintenue ouverte en permanence. Si la box expire les correspondances UDP en trente secondes alors que le téléphone ne rafraîchit son enregistrement que toutes les minutes, les appels sortants fonctionnent parfaitement et les appels entrants n'arrivent jamais. La panne est intermittente et déroutante ; le remède consiste à réduire l'intervalle de rafraîchissement ou à activer les paquets de maintien de session.

Le pair-à-pair et l'auto-hébergement. Un nœud non joignable ne peut que se connecter aux autres, jamais recevoir de connexion : il consomme la ressource du réseau sans y contribuer pleinement. Les jeux qui reposent sur une architecture pair-à-pair, où c'est la console d'un joueur qui héberge la partie, sont particulièrement sensibles à ce déséquilibre.

NAT et sécurité : la grande idée reçue

« Je suis derrière un NAT, donc je suis protégé » est l'affirmation la plus répandue et la plus trompeuse du sujet. Elle contient une part de vérité et une erreur de raisonnement qu'il faut séparer nettement.

La part de vérité : un paquet arrivant sur l'adresse publique de votre box sans correspondre à aucune ligne de la table de traduction est effectivement jeté. Vos appareils internes ne sont donc pas exposés aux balayages permanents qui parcourent l'espace IPv4. C'est un effet de bord réel et utile.

L'erreur : ce rejet n'est pas une décision de sécurité. La box ne se demande pas si ce paquet est légitime ; elle constate qu'elle ne sait pas à qui le remettre. Trois conséquences en découlent.

1. Aucune politique, aucun journal Un pare-feu applique des règles que vous pouvez lire, modifier et auditer, et il enregistre ce qu'il bloque. Le NAT ne produit rien de tout cela : vous ne saurez jamais ce qui a été écarté.
2. Aucun filtrage sortant Un objet connecté compromis à l'intérieur de votre réseau ouvre ses connexions vers l'extérieur en toute liberté, et le NAT lui crée obligeamment une correspondance. Les logiciels malveillants modernes travaillent presque tous en connexion sortante, précisément parce que cela traverse tous les NAT du monde.
3. La moindre ouverture annule l'effet Une redirection de port, une DMZ ou une règle créée automatiquement par UPnP ouvre un chemin direct vers un appareil interne. Si le service exposé est vulnérable ou protégé par un mot de passe par défaut, la traduction d'adresses ne vous sera d'aucun secours.

Cette distinction devient visible dès que vous activez IPv6 : il n'y a plus de traduction, donc plus d'effet de bord protecteur, et la sécurité repose entièrement sur le pare-feu de la box. Nos recommandations de configuration figurent dans le guide pour sécuriser sa box Internet.

Le NAT hairpin : injoignable depuis chez soi

Vous avez ouvert un port vers votre serveur personnel. Un ami y accède sans difficulté. Vous essayez depuis votre canapé, et rien ne répond. Le problème porte un nom : l'absence de hairpinning, aussi appelé NAT loopback ou « épingle à cheveux ».

Le scénario est le suivant. Votre portable en 192.168.1.42 tente de joindre 203.0.113.47:443, l'adresse publique de votre propre box. Le paquet remonte jusqu'à la box, qui doit accomplir un demi-tour : reconnaître que cette destination publique est la sienne, appliquer la redirection vers 192.168.1.10, et renvoyer le paquet dans le réseau local d'où il vient. Certains équipements ne savent pas faire, ou le font mal. La RFC 4787 l'exige pourtant (exigence REQ-9), en précisant que la source vue par le serveur interne doit être l'adresse publique : sans quoi le serveur répond directement au client local, qui reçoit une réponse d'une adresse à laquelle il n'a rien demandé et la rejette.

Trois contournements existent, du plus propre au plus rustique :

1. Un DNS local à vue partagée Faites répondre votre résolveur local (celui de la box, ou un résolveur installé sur un petit serveur) l'adresse privée 192.168.1.10 pour votre nom de domaine, tandis que le DNS public continue de renvoyer l'adresse publique. Le trafic reste alors intégralement dans le réseau local et ne traverse jamais le NAT. C'est la solution recommandée : elle est transparente pour tous les appareils du foyer et n'impose aucun réglage individuel.
2. Une entrée dans le fichier hosts Sur une machine isolée, ajoutez la correspondance nom → adresse privée dans /etc/hosts (Linux, macOS) ou C:\Windows\System32\drivers\etc\hosts (Windows). Efficace immédiatement, mais à répéter sur chaque appareil, et impossible sur la plupart des téléphones et téléviseurs.
3. Un accès par tunnel Si vous utilisez déjà un tunnel chiffré pour joindre votre réseau depuis l'extérieur, laissez-le actif en permanence sur vos appareils nomades : ils utiliseront toujours l'adressage privé, chez vous comme ailleurs. Solution robuste, au prix d'une petite surcharge de configuration.

Avant tout cela, vérifiez simplement l'interface de votre box : plusieurs modèles proposent une option de bouclage, parfois nommée NAT loopback ou hairpinning, désactivée par défaut.

Le double NAT : le repérer et le résoudre

Il y a double NAT quand votre trafic subit deux traductions successives avant d'atteindre Internet. Chaque niveau ajoute ses propres correspondances, ses propres expirations et son propre filtrage ; les redirections de port configurées sur l'équipement le plus proche de vous deviennent inopérantes, puisqu'elles ne sont pas connues du niveau supérieur.

Le repérer demande une seule vérification. Ouvrez l'interface d'administration de votre box et notez l'adresse indiquée pour l'interface WAN ou « Internet ». Comparez-la avec l'adresse publique affichée par notre outil de recherche d'IP. Si les deux sont identiques, tout va bien. Si l'adresse WAN appartient à l'une des plages suivantes, vous êtes derrière une traduction supplémentaire :

• 10.0.0.0 à 10.255.255.255, 172.16.0.0 à 172.31.255.255, 192.168.0.0 à 192.168.255.255 : adressage privé RFC 1918, signe d'un équipement en cascade ;
• 100.64.0.0 à 100.127.255.255 : l'espace partagé de la RFC 6598, réservé aux opérateurs : c'est la signature caractéristique du CGNAT, la traduction réalisée par votre fournisseur d'accès lui-même.

Une commande traceroute confirme le diagnostic : un ou deux premiers sauts en adressage privé au-delà de votre box trahissent un équipement opérateur intermédiaire. Le détail de ces plages et de leur usage figure dans notre tableau des adresses IP réservées.

Les causes sont au nombre de trois. La plus fréquente est l'installation d'un routeur personnel (pour son Wi-Fi, son VPN ou ses fonctions avancées) derrière la box de l'opérateur, chacun faisant du NAT de son côté. Vient ensuite le montage en cascade de deux box, par exemple pour couvrir une dépendance. Enfin, le CGNAT, imposé par l'opérateur et sur lequel vous n'avez aucune prise depuis votre matériel.

La résolution dépend de la cause :

• Mode bridge ou point d'accès : désactivez la fonction routeur du second équipement pour qu'il ne soit plus qu'un commutateur et un point d'accès Wi-Fi. Une seule machine fait alors du NAT, et le DHCP de la box distribue les adresses à tout le monde. C'est la solution la plus saine quand vous avez ajouté votre propre routeur.
• DMZ vers le second routeur : si vous tenez à conserver deux routeurs, déclarez sur la box l'adresse du second en zone démilitarisée : tout le trafic entrant non attribué lui sera transmis, et ses propres redirections redeviendront opérationnelles. Solution de repli, à n'utiliser que vers un équipement dont vous maîtrisez la configuration.
• Sortir du CGNAT : certains opérateurs proposent, dans l'espace abonné ou dans l'interface de la box, une option d'adresse IPv4 dédiée (parfois appelée « full-stack »), ou une offre d'adresse IP fixe. Vérifiez ce que permet votre contrat avant d'envisager quoi que ce soit d'autre.

IPv6 change-t-il la donne ?

Oui, radicalement, parce qu'il supprime la cause. IPv6 code les adresses sur 128 bits, et un abonné résidentiel se voit déléguer un préfixe entier (couramment un /56, soit 256 sous-réseaux) largement de quoi donner à chaque appareil, présent et futur, sa propre adresse globale. Le partage forcé d'une adresse n'a plus lieu d'être, et avec lui disparaissent le perçage de NAT, les serveurs relais et les redirections de port.

Ce changement est la meilleure raison de vérifier si votre connexion est déjà en IPv6 : la plupart des offres fibre françaises l'activent par défaut, souvent sans que l'abonné le sache. Notre guide sur l'IPv6 à la maison détaille la vérification et les réglages de la box, et notre comparaison IPv4 et IPv6 reprend les différences de format.

Il y a toutefois une contrepartie, souvent passée sous silence. En IPv4, l'inaccessibilité de vos appareils depuis l'extérieur était garantie par construction. En IPv6, chaque appareil possède une adresse routable : la caméra du salon, l'imprimante, l'objet connecté acheté à bas prix sont, en théorie, joignables depuis n'importe où. Ce qui les protège n'est plus le NAT, mais uniquement la politique de filtrage du pare-feu de la box, qui doit rejeter par défaut toute connexion entrante non sollicitée. Les box des opérateurs français appliquent en principe ce comportement par défaut, mais il se désactive en deux clics : c'est précisément le réglage à vérifier avant d'activer quoi que ce soit d'autre. Le sujet est développé dans notre guide sur la sécurisation de la box.

Notons enfin, pour être complet, que la traduction n'a pas totalement disparu du monde IPv6 : il existe une traduction de préfixe (NPTv6, RFC 6296) utilisée en entreprise pour la renumérotation, ainsi que des mécanismes de transition qui font cohabiter les deux protocoles chez les opérateurs. Rien de tout cela ne concerne le partage d'adresses tel que le pratique votre box aujourd'hui.

Observer sa propre table de traduction

La théorie prend une autre épaisseur quand on regarde les correspondances réelles. Deux points d'observation, complémentaires et inégaux.

Depuis un appareil, vous voyez le côté interne de la traduction : l'adresse privée et le port source choisis par votre système, avant réécriture. Les commandes suivantes listent les connexions actives :

ss -tunp                     # Linux : connexions TCP et UDP avec le processus
netstat -ano -p tcp          # Windows : la colonne PID identifie l'application
netstat -an -p tcp           # macOS

Repérez la colonne d'adresse locale : 192.168.1.42:51344 correspond exactement à la partie gauche de la ligne de table NAT décrite plus haut. Vous ne verrez jamais depuis cette machine le port externe attribué par la box ; seul un service distant capable de vous renvoyer le port source qu'il observe, ou l'interface de la box, peut vous le révéler.

Depuis la box, vous voyez la table elle-même. La plupart des interfaces d'administration exposent, dans les sections consacrées au réseau, à la NAT ou au diagnostic, la liste des connexions suivies avec adresse interne, port interne, port externe, destination et protocole. Sur certains modèles, cette page est réduite à un compteur du nombre de sessions actives : c'est déjà une information utile, car une valeur anormalement élevée au repos signale un appareil bavard sur votre réseau. Un client de partage de fichiers ou un objet connecté défaillant peut à lui seul saturer la table et dégrader la connexion de tout le foyer, avec des symptômes trompeurs : pages qui ne chargent plus alors que le débit mesuré reste excellent.

Questions fréquentes