IPsec protège les échanges de données au niveau de la couche réseau sur des infrastructures publiques non fiables. Conçu à une époque où chaque hôte connecté à Internet disposait d'une adresse IPv4 routable mondialement, IPsec s'appuie sur le protocole Encapsulating Security Payload (ESP, protocole IP 50) pour garantir la confidentialité, l'authentification de l'origine et la protection contre le rejeu. Néanmoins, l'épuisement des adresses IPv4 a imposé l'usage massif de la translation d'adresses et de ports réseau (NAT/PAT). Comme le protocole ESP brut opère directement au-dessus d'IP sans ports de couche transport (TCP/UDP), les passerelles intermédiaires s'avèrent incapables d'assurer le suivi ou le démultiplexage du trafic chiffré entrant en retour. Les standards RFC 3947 (« Negotiation of NAT-Traversal in the IKE ») et RFC 3948 (« UDP Encapsulation of IPsec ESP Packets ») résolvent ce conflit architectural fondamental en encapsulant les paquets ESP dans des datagrammes UDP acheminés sur le port 4500.

Architecture ESP brut (échec à travers PAT/NAT) :
[En-tête IP (Proto 50)] [En-tête ESP : SPI (4o), Seq (4o)] [Données chiffrées]
                      └──> Aucun port UDP/TCP ! La table PAT ne peut router le retour.

ESP encapsulé NAT-T selon la RFC 3948 (port UDP 4500) :
[En-tête IP (Proto 17)] [En-tête UDP (Src 4500, Dst 4500)] [ESP] [Données]
                      └──> Les ports de couche 4 permettent un suivi d'état précis.

Le dilemme de la translation de ports PAT : pourquoi le protocole ESP brut échoue sous NAT

Comprendre la nécessité absolue d'IPsec NAT-Traversal (NAT-T) impose d'analyser le comportement des passerelles de translation d'adresses avec maintien d'état.

Invisibilité au niveau transport : l'absence de ports TCP/UDP dans ESP

Lorsque plusieurs appareils privés situés derrière un routeur de bureau ou une passerelle opérateur Carrier-Grade NAT (CGNAT) communiquent vers l'extérieur, le routeur réécrit leurs adresses IP privées vers une adresse IP publique partagée. Afin de distinguer à quel client interne correspond chaque paquet de réponse, la passerelle assigne un numéro de port source unique de couche 4 à chaque session TCP ou UDP sortante.

Le protocole ESP fonctionne au niveau de la couche 3 sous le numéro de protocole 50. Contrairement à TCP (protocole 6) ou UDP (protocole 17), ESP est totalement dépourvu de notion de port. Les quatre premiers octets d'un en-tête ESP contiennent un identifiant Security Parameter Index (SPI), une valeur arbitraire de 32 bits choisie par le destinataire pour identifier l'association de sécurité (SA) :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Security Parameters Index (SPI)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Sequence Number                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Payload Data (Variable)                    |

Lorsqu'un paquet ESP sortant traverse une passerelle PAT, celle-ci réécrit l'adresse IP source mais ne peut créer d'entrée de port dans sa table de correspondance. Quand un paquet ESP arrive en réponse, l'équipement PAT examine l'en-tête : sans port de destination, il ne peut déterminer quel hôte interne doit recevoir le flux. Si certains routeurs recourent au mécanisme « SPI passthrough », cette heuristique s'effondre dès lors que plusieurs clients du réseau local ouvrent un tunnel vers la même passerelle distante.

Modification du chemin réseau et invalidation du checksum TCP/UDP

Un second obstacle survient dans le mode Transport d'IPsec. Les algorithmes de somme de contrôle (checksum) des pseudo-en-têtes TCP et UDP valident l'intégrité combinée des adresses source, destination, du protocole et de la longueur du segment. Lorsque le routeur NAT intermédiaire modifie l'adresse IP, le checksum calculé à l'origine devient caduc. Le contenu du paquet étant intégralement chiffré par ESP, la passerelle intermédiaire ne peut recalculer cette somme de contrôle. Lors du déchiffrement à destination, la vérification du checksum échoue systématiquement, conduisant le noyau du système d'exploitation récepteur à rejeter silencieusement le paquet.

Détection RFC 3947 NAT-Discovery : identification dynamique des passerelles intermédiaires

Afin de gérer dynamiquement les environnements avec translation, la RFC 3947 (intégrée dans IKEv2 RFC 7296) formalise un mécanisme de détection automatisée (NAT-Discovery, NAT-D) lors de l'établissement initial des associations de sécurité.

Données utiles NAT-D et comparaison de hachages lors d'IKE_SA_INIT

Durant la phase initiale d'échange (IKE_SA_INIT), le client et le serveur communiquent via le port standard UDP 500. Chaque extrémité transmet une ou plusieurs charges utiles NAT-D (NAT-Detection). Chaque charge utile encapsule une empreinte cryptographique SHA-1 ou SHA-256 des adresses IP et ports des partenaires de la session :

$$\text{Empreinte NAT-D} = \text{SHA-1}(\text{SPI}_i ,|, \text{SPI}_r ,|, \text{IP} ,|, \text{Port})$$

  1. L'initiateur calcule l'empreinte de son couple IP/port local ainsi que celle de l'adresse de destination du serveur, puis les transmet dans le paquet.
  2. Le destinataire calcule à son tour les empreintes correspondantes à partir des adresses réelles observées à la réception.
  3. Si les valeurs transmises coïncident parfaitement avec les empreintes locales, la traversée s'effectue sans aucune translation d'adresse.
  4. Si une divergence est constatée, le protocole déduit immédiatement la présence d'un équipement NAT ayant modifié l'adresse externe en cours de transit.

Flottement de port : transition transparente de UDP 500 à UDP 4500

Dès lors que la détection NAT-D confirme la présence d'une translation, le protocole applique instantanément le mécanisme de flottement de port (Port Floating). À partir du message suivant IKE_AUTH, les deux homologues basculent l'ensemble des communications de UDP 500 vers le port UDP 4500.

Cette migration vers le port 4500 prévient les conflits avec les passerelles fermant ou filtrant UDP 500 lors de sessions multiples. Elle prépare également le canal à acheminer sur un même port les flux de contrôle et les données chiffrées des utilisateurs.

Architecture d'encapsulation RFC 3948 : le rôle du marqueur Non-ESP de 4 octets

La difficulté majeure liée à l'usage partagé du port UDP 4500 réside dans la nécessité de recevoir simultanément les échanges de contrôle IKE et les trames chiffrées ESP. La RFC 3948 répond à cette contrainte par une convention d'en-tête particulièrement sobre et rigoureuse.

Démultiplexage du trafic de contrôle IKE et des données ESP

À la réception d'un datagramme sur le port UDP 4500, la pile réseau IPsec doit identifier immédiatement si le paquet constitue un message IKE (destiné au démon de gestion en espace utilisateur) ou une trame ESP chiffrée (à traiter directement par les accélérateurs cryptographiques du noyau).

Ce tri s'appuie sur la présence d'un champ Non-ESP Marker d'une taille de 4 octets :

Message IKE sur UDP 4500 (avec marqueur Non-ESP) :
+---------------------------------------------------------------+
| En-tête UDP (Port source : XXXX, Port destination : 4500)    |
+---------------------------------------------------------------+
| Non-ESP Marker : 0x00000000 (4 octets nuls)                   |
+---------------------------------------------------------------+
| En-tête IKEv2 (SPI initiateur, SPI répondeur, drapeaux)       |
+---------------------------------------------------------------+

Trame ESP sur UDP 4500 (sans marqueur nul) :
+---------------------------------------------------------------+
| En-tête UDP (Port source : XXXX, Port destination : 4500)    |
+---------------------------------------------------------------+
| ESP SPI (32 bits, valeur strictement non nulle : 0xXXXXXXXX)  |
+---------------------------------------------------------------+
| Numéro de séquence ESP (32 bits)                              |
+---------------------------------------------------------------+
| Données chiffrées et champ d'intégrité ICV                    |
+---------------------------------------------------------------+

Conformément à la RFC 4303, les quatre premiers octets d'une trame ESP brute correspondent au SPI. Dans la spécification, la valeur 0x00000000 est formellement interdite et n'est jamais assignée à une association de sécurité active. Si les quatre premiers octets suivant l'en-tête UDP sont nuls, le noyau sait qu'il s'agit d'un message IKE et le transmet au démon de contrôle. Si cette valeur est différente de zéro, elle est interprétée comme un SPI ESP et le paquet est déchiffré immédiatement en espace noyau.

Mécanisme de maintien NAT Keepalive et temporisateurs d'état de translation

Les passerelles NAT maintiennent les liaisons UDP dans des tables dynamiques d'états. Lorsqu'aucun paquet ne transite par le tunnel pendant un certain délai, la passerelle purge l'entrée correspondante (souvent après 30 à 120 secondes sur les réseaux cellulaires). Une fois la table purgée, les paquets entrants provenant du serveur sont rejetés.

Afin d'éviter cette expiration prématurée, la RFC 3948 standardise l'envoi de trames de maintien (NAT Keepalive). Le client transmet périodiquement un datagramme UDP minimal :

+-----------------------------------------------+
| En-tête IP (Proto 17, adresses d'extrémité)   |
+-----------------------------------------------+
| En-tête UDP (Src 4500, Dst 4500, Longueur 9)  |
+-----------------------------------------------+
| 0xFF (Octet unique de maintien)               |
+-----------------------------------------------+

À la réception d'un datagramme UDP d'un seul octet contenant 0xFF, la passerelle intermédiaire réinitialise son temporisateur d'inactivité pour cette session, puis supprime l'octet sans consigner d'erreur. La connectivité reste ainsi continue même lors des périodes d'inactivité applicative.

Surcharge d'encapsulation, découverte du Path MTU et ajustement du TCP MSS

L'encapsulation supplémentaire dans des en-têtes UDP induit une légère augmentation de la taille des paquets, exigeant une gestion attentive des paramètres de MTU.

L'ajout de l'en-tête UDP de 8 octets réduit l'unité maximale de transmission (MTU) utile. Sur une interface Ethernet standard à 1 500 octets :

  • La surcharge standard d'ESP sur IPv4 oscille entre 50 et 60 octets selon l'algorithme cryptographique employé (AES-GCM-128 ou association AES-CBC-256 avec HMAC-SHA256).
  • L'encapsulation UDP ajoute 8 octets, portant la surcharge cumulée du tunnel entre 62 et 72 octets.
  • La taille maximale de segment TCP (TCP MSS) interne doit être ajustée (MSS Clamping) pour passer de la valeur par défaut de 1 460 octets à une plage de 1 360 à 1 380 octets.

Sans ajustement du MSS, les paquets volumineux subissent une fragmentation IP. Comme de nombreux opérateurs télécoms bloquent les fragments au niveau de leurs routeurs de transit, une mauvaise configuration de MTU entraîne des blocages de connexions TCP et une dégradation sensible des débits.

Résilience en environnement CGNAT d'entreprise : intégration avec RiceGuard

Au sein de l'infrastructure VPNRice, le moteur RiceGuard implémente l'architecture RFC 3948 NAT-T pour fournir des liaisons stables sur les réseaux cellulaires stricts et les topologies à translation multiniveau.

Architecture RiceGuard Zero-Trust NAT-T :
Client mobile / Poste nomade
  │  (Derrière un équipement Carrier-Grade NAT ou double NAT)
  │  Initialise IKE_SA_INIT sur UDP 500
  ▼
Vérification automatisée NAT-D
  │  - Détecte l'altération du couple IP externe
  │  - Réalise le basculement atomique vers UDP 4500
  │  - Insère les marqueurs Non-ESP de 4 octets pour les échanges IKE
  ▼
Passerelle haute performance RiceGuard
  │  - Reçoit les flux ESP encapsulés dans UDP 4500
  │  - Traite les tables SAD via l'accélération XFRM du noyau
  │  - Ajuste la cadence des paquets keepalive selon la télémétrie
  ▼
Cœur de réseau d'entreprise chiffré / Accès Internet
  1. Bascule déterministe de port : RiceGuard détecte la présence de NAT dès la phase initiale, basculant automatiquement vers UDP 4500 afin d'éviter le filtrage du port 500 fréquent chez les fournisseurs d'accès.
  2. Gestion adaptative du Keepalive : Au lieu de temporisateurs statiques rigides, le système module l'intervalle des paquets de maintien en fonction des caractéristiques mesurées du lien, préservant ainsi l'autonomie des terminaux mobiles.
  3. Démultiplexage accéléré par le noyau : Grâce à l'intégration des politiques de sockets XFRM sous Linux, les données chiffrées sont traitées directement par les modules matériels en espace noyau sans transiter inutilement par l'espace utilisateur.

Procédures de diagnostic : inspection des sockets NAT-T et de la base SAD du noyau Linux

Les administrateurs réseau peuvent vérifier en détail l'état des sessions NAT-T actives sous Linux à l'aide des commandes système standard.

Vérification de l'écoute des sockets UDP 4500

Assurez-vous que le service IPsec maintient des sockets actifs à l'écoute des ports 500 et 4500 :

# Vérification des sockets d'écoute UDP pour IKE et NAT-T
ss -uan '( sport = :500 or sport = :4500 )'

Exemple d'affichage :

State    Recv-Q    Send-Q       Local Address:Port        Peer Address:Port
UNCONN   0         0                  0.0.0.0:500              0.0.0.0:*
UNCONN   0         0                  0.0.0.0:4500             0.0.0.0:*

Examen de l'état XFRM dans le noyau pour l'encapsulation UDP

Consultez la base de données des associations de sécurité (SAD) du noyau pour vérifier l'activation de l'encapsulation :

# Affichage des associations IPsec actives et des paramètres d'encapsulation
ip xfrm state show

Extrait de configuration :

src 198.51.100.2 dst 203.0.113.1
	proto esp spi 0xc7a41289 reqid 1 mode tunnel
	replay-window 64 flag af-unspec
	auth-trunc hmac(sha256) 0x6e7a... 128
	enc cbc(aes) 0x4f12...
	encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
	sel src 0.0.0.0/0 dst 0.0.0.0/0

La mention encap type espinudp valide formellement que le noyau Linux encapsule le trafic sortant dans des paquets UDP sur le port 4500 et attend les paquets entrants sous ce format, assurant une traversée fluide des passerelles de translation.

La publication de la RFC 3948 a permis de pérenniser le protocole IPsec dans un environnement Internet dominé par les passerelles NAT. Grâce à l'encapsulation standardisée dans UDP 4500 et à la rigueur du marqueur Non-ESP, les tunnels réseau conservent une fiabilité et des performances optimales à travers les infrastructures opérateur et d'entreprise les plus exigeantes.

Pour déployer des tunnels zero-trust résilients capables de franchir en toute transparence les passerelles d'entreprise, Télécharger VPNRice.