Port VPN IPsec : Comprendre les Fondements de la Sécurité Réseau #
Qu’est-ce que l’IPsec et pourquoi est-il essentiel ? #
L’IPsec (Internet Protocol Security) est un ensemble de protocoles de sécurité standardisé par l’IETF qui sécurise les communications réseau en chiffrant et en authentifiant les paquets IP. C’est le pilier des VPN (Virtual Private Network) d’entreprise et la référence du tunnel site-à-site : il garantit la confidentialité, l’intégrité et l’authenticité des données échangées sur Internet, quel que soit le réseau de transit.
L’IPsec fonctionne en deux modes complémentaires : le mode tunnel et le mode transport. Le mode tunnel encapsule l’intégralité du paquet IP d’origine — en-tête comprise — dans un nouveau paquet chiffré ; il est utilisé pour relier deux passerelles via un réseau public. Le mode transport ne chiffre que la charge utile et préserve l’en-tête IP d’origine, ce qui le destine aux communications hôte-à-hôte sur réseau de confiance.
Les ports utilisés par l’IPsec #
L’IPsec ne se résume pas à un seul port. La pile s’appuie sur deux ports UDP pour la signalisation et deux numéros de protocole IP pour le transport effectif des données chiffrées. Comprendre cette répartition est indispensable pour écrire des règles de pare-feu propres, dépanner un tunnel qui ne monte pas et anticiper le passage à travers les boîtiers NAT des opérateurs.
Le port UDP 500 porte le protocole ISAKMP / IKE : c’est là que les deux passerelles négocient les algorithmes (AES-GCM, SHA-2, DH group), s’authentifient mutuellement (PSK ou certificat X.509) et dérivent les clés de session. Une fois la SA établie, le trafic utile bascule sur ESP (IP 50) ou, derrière un NAT, sur UDP 4500 via NAT-T.
UDP
500 — ISAKMP / IKE
Échange de clés et négociation des SA. Phase 1 (Main / Aggressive) puis phase 2 (Quick Mode).
UDP
4500 — NAT-T
Encapsulation UDP d’ESP dès qu’un NAT est détecté entre les deux passerelles (RFC 3947 / 3948).
IP
50 — ESP
Encapsulating Security Payload : chiffrement (AES-GCM, ChaCha20) et authentification HMAC du payload.
IP
51 — AH
Authentication Header : intégrité et authentification du paquet IP complet, sans chiffrement. Incompatible NAT.
CRY
AES-GCM 256
Chiffrement authentifié recommandé en 2026 — AEAD, accélération matérielle AES-NI, débit ligne.
HSH
SHA-2 / HMAC
SHA-256 minimum pour l’intégrité. SHA-1 et MD5 considérés obsolètes pour toute nouvelle SA.
IKEv1 vs IKEv2 : choisir la bonne version #
IKEv1 (RFC 2409, 1998) a longtemps été la version par défaut, mais elle traîne plusieurs handicaps : 6 ou 9 messages pour monter une SA, support NAT-T greffé après coup, pas de rekey atomique, absence de MOBIKE. IKEv2 (RFC 7296, 2014) corrige tout cela en 4 messages, intègre nativement NAT-T, supporte la fragmentation IKE et la mobilité d’IP côté client.
| Critère | IKEv1 | IKEv2 |
|---|---|---|
| Messages négociation | 6 (Main Mode) ou 3 (Aggressive) | 4 (IKE_SA_INIT + IKE_AUTH) |
| NAT-T | Extension optionnelle | Natif et obligatoire |
| Mobilité client (MOBIKE) | Non supporté | Supporté — RFC 4555 |
| Fragmentation IKE | Dépend de l’IP fragmentation | Native (RFC 7383) |
| Détection peer mort (DPD) | Add-on (RFC 3706) | Intégré (liveness check) |
| EAP / authentification | XAUTH (non standardisé) | EAP standard intégré |
| Recommandé en 2026 | Legacy uniquement | Oui — défaut sur tous OS |
NAT-T : pourquoi UDP 4500 est devenu incontournable #
La traversée de NAT (NAT-T) est née d’un problème simple : ESP n’a pas de ports TCP/UDP, donc un routeur NAT classique ne sait pas réécrire les paquets ESP. Résultat : tout tunnel IPsec derrière une box opérateur ou un routeur d’agence tombait. NAT-T encapsule ESP dans un en-tête UDP sur le port 4500, permettant au NAT de tracker la session comme un flux UDP standard.
La détection NAT se fait dès la phase 1 : les deux peers échangent des hash de leurs adresses IP source dans des payloads NAT-D. Si le hash reçu ne correspond pas à l’IP perçue, un NAT est présent et le trafic ESP bascule automatiquement sur UDP 4500. La keep-alive NAT-T (paquet de 1 octet toutes les 20 secondes par défaut) maintient l’entrée dans la table de translation du routeur.
«
Quand un tunnel IPsec ne monte pas, neuf fois sur dix le problème est entre UDP 500 et UDP 4500. La phase 1 négocie, la phase 2 échoue : c’est presque toujours du NAT-T mal géré ou un pare-feu qui filtre IP 50.
Configuration des ports et règles pare-feu #
Côté pare-feu, la configuration d’un VPN IPsec se résume à quatre règles. Sans NAT entre les deux peers : UDP 500 (IKE) et IP protocole 50 (ESP) sortants et entrants. Avec NAT-T : UDP 500 et UDP 4500 dans les deux sens, et on peut alors se passer d’ouvrir IP 50 puisque ESP est encapsulé dans UDP 4500.
✓ À faire
- ✓Ouvrir UDP 500 et UDP 4500 dans les deux sens entre passerelles
- ✓Activer Dead Peer Detection (DPD) ou liveness check IKEv2
- ✓Fixer un MTU côté tunnel à 1400 octets pour absorber l’overhead ESP
- ✓Logguer les négociations IKE pour faciliter le diagnostic
✕ À éviter
- ✕Garder une PSK courte ou partagée entre plusieurs tunnels
- ✕Utiliser DH group 2 (MODP-1024) ou SHA-1 sur une nouvelle SA
- ✕Filtrer ESP (IP 50) sans le savoir parce que la règle pare-feu ne couvre que TCP/UDP
- ✕Activer Aggressive Mode en IKEv1 (PSK exposée à un brute-force offline)
IPsec face à OpenVPN et WireGuard #
IPsec n’est pas seul sur le marché du tunnel chiffré. OpenVPN (TLS, UDP 1194 ou TCP 443) et WireGuard (UDP arbitraire, défaut 51820) sont devenus des alternatives sérieuses. Chaque protocole a son terrain de prédilection : IPsec pour le site-à-site et l’interop entre constructeurs, OpenVPN pour la flexibilité (TCP 443 traverse tous les firewalls), WireGuard pour la simplicité et la vitesse brute.
IP
IPsec / IKEv2
Ports : UDP 500 + UDP 4500 + IP 50
Force : standard industriel, support natif Windows / macOS / iOS
Faiblesse : NAT-T et fragmentation parfois capricieux
OV
OpenVPN
Ports : UDP 1194 ou TCP 443 (camouflage HTTPS)
Force : traverse les pare-feux restrictifs, TLS bien compris
Faiblesse : overhead CPU, performance en mode TCP-over-TCP
WG
WireGuard
Ports : UDP arbitraire, défaut 51820
Force : 4000 lignes de code, performance maximale, in-kernel Linux
Faiblesse : pas de standard formel, moins d’options enterprise
Sécurité, supervision et bonnes pratiques #
Le talon d’Achille d’un déploiement IPsec n’est presque jamais le protocole lui-même, mais la configuration. Une PSK faible, un algorithme legacy laissé actif dans la proposal, une absence de PFS (Perfect Forward Secrecy) sur la phase 2 : autant de portes ouvertes alors que les fondations cryptographiques d’IPsec sont saines. La supervision continue est tout aussi importante que la configuration initiale.
Sur le terrain, un tunnel IPsec mature se surveille à trois niveaux : compteurs ESP (paquets reçus / décryptés / rejetés), état des SA (durée de vie restante avant rekey), et qualité du transit (perte, latence, jitter). Les exporters Prometheus pour strongSwan ou les MIB SNMP des appliances Cisco / Fortinet fournissent ces métriques nativement. Une alerte sur la chute du compteur « ESP decrypted » reste le meilleur signal précoce d’un tunnel qui se dégrade.
Synthèse #
L’IPsec reste le couteau suisse du tunnel chiffré entreprise : standardisé, supporté nativement par tous les OS, interopérable entre constructeurs. Quatre numéros — UDP 500, UDP 4500, IP 50, IP 51 — suffisent à décrire toute la pile. Le bon réflexe en 2026 : IKEv2, AES-GCM, SHA-2, DH group 19 ou 20, NAT-T systématique, MTU à 1400, supervision continue. Le reste relève du dépannage de routeurs, de pare-feux et de boîtiers NAT.
Questions fréquentes #
Mon tunnel IPsec ne monte pas derrière une box opérateur, pourquoi ? +
Dans 90 % des cas, NAT-T est bloqué. Vérifier que UDP 4500 est autorisé sortant et entrant côté box, et que la passerelle IPsec annonce bien NAT-T en phase 1. Sans NAT-T, ESP (IP 50) ne traverse pas le NAT du fournisseur d’accès.
Peut-on faire passer deux tunnels IPsec différents derrière le même NAT ? +
Oui, à condition d’utiliser NAT-T sur UDP 4500 : le NAT distingue les flux par leur port source. Sans NAT-T, ESP brut ne peut pas être démultiplexé par le boîtier NAT et un seul tunnel à la fois fonctionnera.
IKEv2 fonctionne-t-il sur iPhone et Android sans client tiers ? +
Oui. iOS supporte IKEv2 nativement depuis iOS 9 (configuration via profil .mobileconfig). Android supporte IKEv2 / IPsec PSK et MSCHAPv2 depuis Android 12, et l’IKEv2 PKI via certificat depuis Android 4.0 via le client intégré.
Quels ports ouvrir précisément sur le pare-feu pour un VPN IPsec ? +
UDP 500 et UDP 4500 dans les deux sens entre les deux endpoints, plus le protocole IP 50 (ESP) si NAT-T n’est pas utilisé. IP 51 (AH) seulement si AH est explicitement activé — ce qui est rare en pratique car incompatible avec tout NAT sur le chemin.
Comment surveiller un tunnel IPsec en production ? +
Trois métriques essentielles : compteurs ESP (paquets chiffrés / déchiffrés / rejetés via replay), état et durée de vie restante des SA IKE et child SA, qualité du transit sur le tunnel (ping, perte, jitter). Exporters Prometheus pour strongSwan / Libreswan, MIB IPSEC-FLOW-MONITOR sur les appliances commerciales.
Les points :
- Port VPN IPsec : Comprendre les Fondements de la Sécurité Réseau
- Qu’est-ce que l’IPsec et pourquoi est-il essentiel ?
- Les ports utilisés par l’IPsec
- IKEv1 vs IKEv2 : choisir la bonne version
- NAT-T : pourquoi UDP 4500 est devenu incontournable
- Configuration des ports et règles pare-feu
- IPsec face à OpenVPN et WireGuard
- Sécurité, supervision et bonnes pratiques
- Synthèse
- Questions fréquentes
