Pourquoi L2TP/IPsec a besoin d'UDP 1701 en plus d'IPsec

Les pare-feu qui autorisent IKE et ESP mais pas UDP 1701 cassent les connexions L2TP d'une manière qui ressemble à un problème d'identifiants. La raison est que L2TP est un second protocole qui voyage à l'intérieur du premier. IPsec transporte et authentifie l'échange, et L2TP fait tourner son propre tunnel sur UDP 1701, que la pile locale doit quand même livrer. Savoir où apparaît chaque en-tête explique quel équipement a besoin de quelle règle.

Deux protocoles, deux jeux de ports

Une connexion L2TP/IPsec utilise IKE sur UDP 500, la traversée NAT sur UDP 4500 là où une traduction existe, et ESP comme protocole IP 50 là où il n'y en a pas. L2TP lui-même est un protocole de tunnel sur UDP 1701, et il s'exécute après qu'IPsec a authentifié le pair. Les deux moitiés échouent différemment, et les lignes de journal qui en rendent compte viennent de composants différents. Un jeu de règles qui ne couvre que la première moitié produit une connexion qui négocie puis meurt au stade du tunnel.

Les numéros de port décrivent des extrémités de transport, et ESP n'est pas un port du tout. C'est pourquoi une interface de pare-feu qui n'offre que des règles TCP et UDP ne peut pas exprimer une politique IPsec complète. Le protocole 50 doit être autorisé en tant que protocole, et une règle qui ne mentionne qu'UDP ne le correspondra jamais.

L'enveloppe explique le port

Sur le fil, une connexion L2TP/IPsec montre normalement IKE sur 500 et ESP encapsulé sur 4500. L'en-tête UDP 1701 se trouve à l'intérieur de la charge protégée, c'est pourquoi une capture sur l'interface externe ne le montre pas. L'hôte local doit quand même livrer ce datagramme au démon L2TP, et la livraison a lieu après la décapsulation. La règle 1701 appartient donc au pare-feu de l'extrémité elle-même, même quand aucun équipement intermédiaire ne voit jamais le port.

L'ordre de traitement explique la majeure partie de la confusion. Si la pile applique la politique IPsec avant le filtre de l'hôte, le paquet L2TP décapsulé est mis en correspondance comme UDP 1701 ; si l'ordre est inversé, ce sont les ports externes que voit le jeu de règles. Les deux comportements existent en pratique, c'est pourquoi le même jeu de règles semble fonctionner sur une plateforme et échouer sur une autre.

Vérifiez le chemin dans l'ordre

Capturez d'abord l'interface externe et confirmez qu'IKE et ESP encapsulé circulent dans les deux sens. Vérifiez ensuite les compteurs du pare-feu local pour le trafic décapsulé. L'ordre compte, car une capture qui ne montre absolument rien signifie que le problème se situe en amont de l'hôte.

sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'
sudo nft list ruleset | grep -i -A2 1701
sudo ss -lunp | grep 1701

La capture confirme la première moitié de l'échange et montre si le pair répond. La liste des règles montre si une règle 1701 existe et où elle se situe par rapport à une éventuelle politique de rejet. La liste des sockets confirme que le démon L2TP est lié et à l'écoute, ce qui écarte un service qui n'a jamais démarré. Lisez les trois avant de changer une règle, car un écouteur absent et un port filtré produisent les mêmes plaintes de la part de l'utilisateur.

Ce qu'un scan de ports ne peut pas montrer

Un scan externe d'UDP 1701 contre un serveur correctement configuré ne signale généralement rien, et c'est le résultat attendu. Le port n'est pas exposé à internet ; on ne l'atteint qu'après qu'IPsec a authentifié le pair. Traiter le résultat fermé comme une panne conduit à ouvrir un port qui devrait rester fermé. Le scan ne peut pas voir à l'intérieur du tunnel pas plus qu'il ne peut voir le trafic de l'application.

Testez plutôt avec un vrai client, et lisez l'étape qu'il atteint. Si la connexion négocie puis se bloque, le démon L2TP ou le filtre local est le suspect ; si elle ne négocie jamais, ce sont les ports externes. Ce seul partage élimine la majeure partie des suppositions sur la règle à ajouter, et l'empilement des protocoles rend la chose prévisible plutôt que mystérieuse.