IKEv2 utilise UDP 500 et 4500 : lequel transporte les données ?

Ouvrir UDP 500 dans le pare-feu permet au tunnel de négocier, puis la connexion cesse de faire passer le trafic. La liste des ports était incomplète, pas fausse. IKEv2 démarre sur une socket et, dans de nombreux déploiements réels, continue sur une autre, tandis que la charge utile peut très bien ne pas être un port. Lire les étapes dans l’ordre explique quelle règle manque.

Deux ports, deux rôles

IKEv2 commence par un échange de clés sur UDP 500, où les pairs s’authentifient et établissent une association de sécurité pour le tunnel. Le chemin de données qui suit est une autre affaire : il peut s’agir d’ESP natif, qui est un numéro de protocole IP et non un port, ou de trafic encapsulé dans UDP sur 4500. Garder cette distinction lors d’un audit de pare-feu fait la différence entre un tunnel qui négocie et un tunnel qui fonctionne. Une socket porte le contrôle, l’autre la charge utile.

C’est pourquoi une règle qui n’autorise que 500 produit le symptôme le plus déroutant de toute la famille de protocoles : la négociation réussit et rien d’utile ne suit. L’état montre un pair, le journal montre une IKE SA établie, et l’application expire quand même. L’autorisation manquante appartient à un flux différent de celui qui vient de réussir.

Pourquoi 4500 existe

De nombreux équipements NAT ne peuvent pas transmettre un protocole autre que TCP ou UDP, et certains réécrivent les adresses d’une manière qui casse le contrôle d’intégrité d’ESP. Encapsuler ESP dans UDP résout les deux problèmes, au prix d’un en-tête supplémentaire et d’un second port à autoriser. C’est cet encapsulage qui justifie l’existence du second port.

Une fois NAT détecté, IKE lui-même bascule sur 4500 afin que tout le trafic partage un seul chemin à travers le traducteur. Un marqueur de quatre octets qui n’est pas ESP distingue les messages de contrôle des données sur cette socket. Ce basculement est une décision du protocole, pas une préférence de l’administrateur.

Où le port source change

Un traducteur peut réécrire le port source du client, si bien que le tuple vu par le serveur ne correspond pas à celui du client. Regardez les deux côtés de chaque saut NAT avant de conclure qu’une règle est ignorée. Un diagnostic mené uniquement sur le client peut produire une règle qui semble correcte et échoue malgré tout.

Les implémentations compatibles MOBIKE peuvent aussi passer à 4500 sans NAT détecté, et certains déploiements imposent délibérément ce chemin. Voir 4500 est donc la preuve d’une décision, pas celle d’un routeur domestique.

Vérifier les deux flux à chaque frontière

Parcourez les trois frontières : le réseau du client, tout pare-feu intermédiaire et le serveur. Chacune a besoin des flux documentés par le déploiement, pas de ceux d’un article sur un autre cas.

sudo swanctl --list-sas
sudo tcpdump -ni any 'udp port 500 or udp port 4500'
sudo iptables -S | grep -E '500|4500|esp'
ip xfrm state

La ligne ESP d’une liste de pare-feu est une correspondance de protocole, donc une règle de port ne la couvre jamais. Si l’opérateur utilise un port personnalisé, suivez la configuration documentée aux deux extrémités, car un client ne peut pas créer un écouteur sur le serveur en choisissant un numéro familier.

Notez où la négociation s’est arrêtée et si une association de sécurité enfant a été installée, car ce couple sépare un chemin bloqué d’une erreur d’authentification ou de politique. Répétez ensuite le test avec la vérification serveur activée, car l’accessibilité n’est pas l’authentification. Cette dernière étape sépare un port autorisé d’un pair de confiance.